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?
- is depended on by
-
WT-6263 Reenable history store verification
- Closed