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

wt_row/col_modify shouldn't put updates on top of aborted entries or tombstones

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • StorEng - Refinement Pipeline

      This is fallout from WT-10905. Besides the fix made in that ticket, there are other places where, while appending to either the insert list or update chain, we can set the new WT_UPDATE's next pointer to an aborted update or a tombstone.

      That's bad for the same reason as in that ticket - a reader at the read-uncommitted isolation level cannot tell the difference between a committed abort from an old transaction, and an in-progress abort that's moving through the update chain. This means a function like wt_modify_reconstruct_from_upd_list can't correctly reconstruct a full update from a modify pointer, since it can't guarantee the same visibility as the writer did when calculating the delta for the modify.

      The code in question is wt_row_modify (and I'm pretty sure wt_col_modify as well), where we choose upd_entry and pass that to wt_update_serial - we need to put a full value on the chain if this entry is a tombstone or aborted.

      There might be other ways around this, but you'll need to be creative.

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            will.korteland@mongodb.com Will Korteland
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: