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

Setting lastApplied before startup recovery has finished causes race with reconstructing prepared transactions

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Duplicate
    • None
    • 4.4.2
    • None
    • None
    • ALL
    • v4.7, v4.4
    • Execution Team 2020-09-07, Execution Team 2020-09-21
    • 64

    Description

      When preparing a transaction, WT requires that the prepare timestamp is greater than the latest active read timestamp. To allow for this, we often expect readers to do untimestamped reads during startup to avoid conflicting with prepared transactions (which are only reconstructed at the end of recovery). One way we achieved this in the past was by only setting lastApplied at the end of recovery, so that anything that reads with a kLastApplied read source does an untimestamped read instead.

      However, we now set lastApplied on the snapshot manager before finishing recovery (and specifically before reconstructing prepared transactions). We do this to prevent a race with kNoOverlap that could cause a reader to see writes that shouldn't be visible. Ultimately, this means that operations reading with a kLastApplied read source during startup can race with reconstructing prepared transactions.

      Attachments

        Issue Links

          duplicates

          Improvement - An improvement or enhancement to an existing feature or task. SERVER-48452 Internal readers should default to reading without a timestamp

          • Major - P3 - Major loss of function.
          • Closed
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. WT-6626 WT_SESSION.prepare_transaction: __txn_assert_after_reads, 539: prepare timestamp (1598420116, 56) must be greater than the latest active read timestamp (1598420116, 58) : Invalid argument"}

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

          Bug - A problem which impairs or prevents the functions of the product. SERVER-44529 Re-acquiring locks after a yield and step down results in wrong parameters on recoveryUnit

          • Critical - P2 - Crashes, loss of data, severe memory leak.
          • Closed

          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

          Activity

            People

              louis.williams@mongodb.com Louis Williams
              samy.lanka@mongodb.com Samyukta Lanka
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: