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

Perform rollback to stable on the history store as a final step

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT10.0.0, 4.4.0-rc9, 4.7.0
    • Affects Version/s: None
    • Component/s: None
    • None
    • 5
    • Storage - Ra 2020-06-15

      The scenario is:
      Two tables t1 and t2
      Checkpoint starts with stable timestamp 25.
      Checkpoint finishes checkpointing t1 writes k1 -> v1, timestamp (20)
      Checkpoint starts checkpointing t2
      Now a page on t1 is evicted with data newer than the checkpoint
      k1 -> v3 (40) -> v2 (30)
      V2 goes to history store with timestamp 30.
      Eviction starts on history store
      Writes the history store page with v1 (20) and v2 (30) on it.

      We checkpoint the history store, then finish the checkpoint

      We rollback to stable and end up with k1 -> v2 (30) left in the history store.

      In order to fix this scenario I think we need to do a final pass of the history store file as part of rollback to stable, inspect aggregated timestamp ranges and if their newest_durable_ts > stable_ts then delete individual updates from that page.

      That said if we're searching for k1 in the history store to fix it up we could delete all other version on that key at the same time potentially?

            Assignee:
            haribabu.kommi@mongodb.com Haribabu Kommi
            Reporter:
            luke.pearson@mongodb.com Luke Pearson
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: