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

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.2.4, 4.3.3
    • Replication
    • 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

    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

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

              Dates

                Created:
                Updated:
                Resolved: