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

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Duplicate
    • Priority: Major - P3
    • 4.4.2
    • Affects Version/s: None
    • Component/s: None
    • None
    • ALL
    • v4.7, v4.4
    • Execution Team 2020-09-07, Execution Team 2020-09-21
    • 64
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            Louis Williams
            Reporter:
            Samyukta Lanka
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: