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

Fix handling of multiple subsequent tombstones

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT3.2.2
    • Component/s: None
    • Story Points:
      5
    • Sprint:
      Storage Engines 2020-03-09

      Description

      As part of WT-5640 Chenhao Qu made a change to squash multiple subsequent tombstones on an update chain. There is an open question about what scenario leads to having multiple tombstones in an update chain. That ticket is closed, so moving the conversation here to a new ticket.

      I only see this in test_wt2323_join_visibility.

      Chenhao Qu it seems as though your explanation for why it was safe to ignore multiple tombstones wasn't correct. Could you explain what testing scenario this is handling?

      I would generally not expect multiple subsequent tombstones in an update chain. I'm also concerned that your change is going to mean that the content we have on disk has invalid timestamp ranges in it. Shouldn't we use the start timestamp of the newer tombstone as the stop timestamp for the previous entry in the history store, and with this change we'll use the start timestamp for the older tombstone?

      There are also a number of cases we've introduced recently where having a pair of tombstones has special meaning. Squashing them here as your change does feels risky.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              luke.pearson Luke Pearson
              Reporter:
              alexander.gorrod Alexander Gorrod
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: