Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-3981

Make snapshot consistent with read_timestamp

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 3.6.4, 3.7.4, WT3.1.0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Storage Non-NYC 2018-03-26, Storage Non-NYC 2018-04-09
    • v3.6

      To support SERVER-32876, in WT-3926 we allowed WT_SESSION::timestamp_transaction to set the read_timestamp on a running transaction. This was done because WT_SESSION::begin_transaction is relatively heavyweight, and waits if the cache is overfull, whereas setting a read timestamp may hold an application lock.

      However, this pattern:

      acquire lock
      get a timestamp

      is currently unsafe. That is because a concurrent transaction could commit while this one is waiting for the lock, with a transaction ID that is not visible to the snapshot allocated when the transaction starts, even though it has a timestamp less than X.

      One solution is to update the snapshot during the timestamp_transaction call, but that means it will become a common case to get a snapshot, throw it away, then get a new one here. Since getting a snapshot can be somewhat costly, we would prefer not to slow down the common case.

            michael.cahill@mongodb.com Michael Cahill (Inactive)
            michael.cahill@mongodb.com Michael Cahill (Inactive)
            0 Vote for this issue
            4 Start watching this issue