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

Make snapshot consistent with read_timestamp

    XMLWordPrintable

    Details

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

      Description

      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:

      session->begin_transaction(...)
      acquire lock
      get a timestamp
      session->timestamp_transaction("read_timestamp=X")
      

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              michael.cahill Michael Cahill
              Reporter:
              michael.cahill Michael Cahill
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: