Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-44529

Re-acquiring locks after a yield and replication state change results in wrong parameters on recoveryUnit

    XMLWordPrintable

    Details

    • Operating System:
      ALL
    • Sprint:
      Execution Team 2019-12-02, Execution Team 2019-12-16
    • Linked BF Score:
      13

      Description

      When we acquire collection locks with AutoGetCollectionForRead, we set the TimestampReadSource on the recovery unit based on whether we were a primary or a secondary at the time. However, when we re-acquire locks after a yield in PlanExecutor, we use the same TimestampReadSource we had when we originally acquired those locks. Since reads survive replication state changes, that can result in a read on the primary using the lastApplied read source, or a read on the secondary using noTimestamp read source. The latter can result in us reading from within the middle of a replication batch, which means reading possibly causally-related data out of order. The former is bad for the oplog specifically, because on a primary, the lastApplied time is not oplog-hole-free, meaning we can read past oplog holes.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: