The history verification failure in WT-6467 is caused by the following case:
Suppose we have an update chain like:
T@100 -> U@80 -> U@60 and the stable timestamp is 120 and the oldest timestamp is 40.
Eviction writes T@100 -> U@80 to the data store and U@60 to the history store.
Checkpoint starts at stable timestamp 120 and oldest timestamp 40.
oldest timestamp is moved to 100
Eviction or checkpoint comes to that page again and remove that key from the page as it has a tombstone now is globally visible.
We open the database in backup again with stable timestamp 120 and oldest timestamp 40. We see U@60 in the history store but T@100 -> U@80 is missing from the data store.
This issue doesn't impact mongodb currently as mongodb doesn't query historical data at restart. However, it is blocking us from merging the rts-test-format branch back into develop so we need to address it soon.
- causes
-
WT-6667 Document checkpoint's oldest timestamp behavior
- Closed
- is depended on by
-
WT-6648 Checkpoint doesn't retain the full historical data as per the oldest timestamp in the checkpoint
- Closed
-
WT-6603 Merge rts-test-format back into develop
- Closed
-
WT-6467 Fix history store verification
- Closed
- is related to
-
WT-6617 Investigate pinned timestamp when backup cursor is open
- Closed
- related to
-
WT-6670 Fix uninitialized buffer
- Closed