-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Cache and Eviction, Reconciliation, RTS
-
Storage Engines
-
3
-
2024-07-23 - Mining crypto
Summary
WT-12917 discovered a race condition between:
- an RTS pass over the history store, and:
- updates to the HS during eviction & reconciliation due to __wti_rec_hs_clear_on_tombstone.
Fortunately, both threads try to remove the same key, so ignoring the WT_NOT_FOUND error during a HS key removal in RTS would result in the correct outcome—which is the proposed fix for WT-12917.
Having this race condition to begin with is nonetheless undesirable. In this ticket, we should understand why this race condition is happening and prevent it from happening if possible. Please refer to WT-12917 for a full discussion of the investigation thus far. TL;DR:
- RTS does not currently remove HS entries from the insert list, even if there is a stable update. Is there something that we could do about it?
- Is it always necessary to clean up HS entries during eviction when deleting a key?
- Is there a possible connection to
WT-12602(order in which updates and tombstones become visible)?
- related to
-
WT-12917 Potential memory corruption in __rts_btree_abort_ondisk_kv
- Closed