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

Globally visible tombstone in history store could hide update from long running transaction

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 5.0 Required
    • Component/s: None
    • Labels:
      None
    • Story Points:
      5
    • Sprint:
      Storage - Ra 2020-10-19, Storage - Ra 2020-11-02

      Description

      Given the following update chain:
      U1 -> U0

      A transaction exists in the system that can see U0. Called Txn A.

      U0 is written to the history store, and U1 to the data store. U0 has timestamp 5, and U1 10.

      Now two new updates are added to the chain, U2 and U3, U2 has timestamp 0 and U3 has timestamp 15.

      U2 being a mixed mode operation expects to delete all the history store content behind it. U1, U2 are moved to the history store and globally visible tombstones are placed in front of U1, and U0.

      Txn A now attempts to read U0 and gets WT_NOTFOUND.

      In hs_rec.c:1056 we set the txnid of the tombstone to WT_TXN_NONE, instead it should be set to the txnid of U2. Originally WT_TXN_NONE was thought to be fine as it was understood that if a non timestamped update was written then all the content behind it was guaranteed to never be read. Its unclear if this is an actual bug but it could explain the issue seen in SERVER-50971.

        Attachments

          Activity

            People

            Assignee:
            luke.pearson Luke Pearson
            Reporter:
            luke.pearson Luke Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Dates

              Created:
              Updated: