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

Re-acquiring locks after a yield and step down results in wrong parameters on recoveryUnit

    XMLWordPrintableJSON

Details

    • Fully Compatible
    • ALL
    • Execution Team 2019-12-02, Execution Team 2019-12-16, Execution Team 2020-01-13, Execution Team 2020-01-27, Execution Team 2020-02-10, Execution Team 2019-12-30, Execution Team 2020-02-24, Execution Team 2020-03-09, Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-05-04, Execution Team 2020-05-18
    • 13

    Description

      When we acquire collection locks with AutoGetCollectionForRead on a primary, we by default set the TimestampReadSource on the recovery unit to kUnset. However, when we re-acquire locks after a yield in PlanExecutor, we still use that same TimestampReadSource even if we have stepped down. Since reads survive replication state changes, that can result in us reading from within the middle of a replication batch, which means reading possibly causally-related data out of order.

      Note: This ticket initially described both step up and step down, but step up is now separated out into SERVER-46721.

      Potential fix: After recovery from yield, change the read source to kNoOverlap if it was kUnset or kNoTimestamp.

      Attachments

        Issue Links

          depends on

          Bug - A problem which impairs or prevents the functions of the product. SERVER-46721 Step up may cause reads at PIT with holes after yielding

          • Major - P3 - Major loss of function.
          • Closed
          is related to

          Improvement - An improvement or enhancement to an existing feature or task. SERVER-47084 Support AutoGetCollectionForRead-like readSource validation after query yielding

          • Major - P3 - Major loss of function.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. SERVER-48475 Secondary reads always calculate all_durable despite only using lastApplied

          • Major - P3 - Major loss of function.
          • Closed
          related to

          Bug - A problem which impairs or prevents the functions of the product. SERVER-49781 Setting lastApplied before startup recovery has finished causes race with reconstructing prepared transactions

          • Major - P3 - Major loss of function.
          • Closed

          Activity

            People

              louis.williams@mongodb.com Louis Williams
              matthew.russotto@mongodb.com Matthew Russotto
              Votes:
              0 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: