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

Step up may cause reads at PIT with holes after yielding

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.4.0-rc7, 4.2.9, 4.7.0
    • Affects Version/s: None
    • Component/s: Concurrency
    • Labels:
      None
    • Fully Compatible
    • ALL
    • v4.4, v4.2, v4.0
    • Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-05-04, Execution Team 2020-05-18
    • 0

      When we acquire collection locks with AutoGetCollectionForRead on a secondary, we set the TimestampReadSource on the recovery unit to kLastApplied if we were 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, even we've become a primary since. This is bad for the oplog specifically, because on a primary, the last applied time is not oplog-hole-free, meaning we can read past oplog holes. More in general, we should not read at a PIT if there are still write transactions that may commit at that PIT.

      Suggested fix: Have secondary reads use the kNoOverlap read source instead of kLastApplied, which is std::min(*lastApplied, allDurable). This is the same as kLastApplied while a node is remains secondary, but is equivalent to kAllDurableSnapshot after transition to primary.

            Assignee:
            louis.williams@mongodb.com Louis Williams
            Reporter:
            geert.bosch@mongodb.com Geert Bosch
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: