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

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.2.4, 4.3.3
    • Affects Version/s: None
    • Component/s: Replication
    • Labels:
    • Fully Compatible
    • ALL
    • v4.2
    • Repl 2019-11-18, Repl 2019-12-16, Repl 2019-12-30, Repl 2020-01-13, Repl 2020-01-27
    • 7

      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

            pavithra.vetriselvan@mongodb.com Pavithra Vetriselvan
            samy.lanka@mongodb.com Samyukta Lanka
            0 Vote for this issue
            13 Start watching this issue