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

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

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT3.2.2, 4.4.0-rc9, 4.7.0
    • Component/s: None
    • Labels:
      None
    • Story Points:
      5
    • Sprint:
      Storage - Ra 2020-06-15

      Description

      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?

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: