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

Transaction can conflict with previous transaction on the session if the all committed point is held back

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.4, 4.3.3
    • Component/s: Replication
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.2
    • Sprint:
      Repl 2019-11-18, Repl 2019-12-16, Repl 2019-12-30, Repl 2020-01-13, Repl 2020-01-27
    • Linked BF Score:
      7

      Description

      After SERVER-38028, participants block requests for higher txn numbers instead of failing them. So, a transaction started with read concern snapshot following a prepared transaction could have its read timestamp held back due to oplog holes (since the read timestamp will be set to the all committed point).

      The following scenario describes the bug:

      • Thread 1 prepares txn0 at time 5
      • Thread 2 starts new txn1 that blocks on txn0 since it is on the same session
      • Thread 3 opens oplog hole at time 8
      • Thread 1 commits txn0 at time 6, but commit oplog entry (and txn table update) written at time 9
      • On thread 2, txn1 opens storage transaction at all_durable, which would be time 7 since there is an oplog hole at time 8
      • txn1 gets a write conflict when writing to the txn table bc it's reading from time 7 and doesn't see the write from time 9

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: