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

A failure to timestamp a storage transaction requires restarting the transaction

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0.7, 4.1.8
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Storage NYC 2019-01-28
    • Linked BF Score:
      0

      Description

      In SERVER-37121, instead of crashing when a commit_timestamp races with the oldest/stable timestamp for the "ready: true" write of a secondary background index build, we changed the behavior to retry.

      I incorrectly thought a transaction could be timestamped with a new value if the old one raced with constraints such as the stable_timestamp. However, a failure to timestamp a transaction requires redoing the whole transaction.

      Note WT does not return a WT_ROLLBACK error code in this case, which presumably would have resulted in a WriteConflictRetry exception being thrown. Instead WT returns their generic error code.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: