-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Checkpoints
-
Storage Engines
-
StorEng - 2024-10-15
-
5
-
v8.0, v7.0
During RTS, updates might be evicted which would update the btree->rec_max_timestamp field, see here. If this is set to a greater value than the stable checkpoint ts, the RTS checkpoint will mark the btree dirty.
As soon as a btree is dirty, this can block operations such as dropping the dhandle. The btree needs to be marked as clean before its dhandle can be dropped. While this could be resolved with a checkpoint, there are cases in MongoDB where the checkpoint thread is stopped and the btree has to be dropped before the checkpoint thread is resumed.
- is caused by
-
WT-10820 Checkpoint to mark the tree dirty when the tree has more data
-
- Closed
-
- is related to
-
WT-13745 Revert WT-13591
-
- Closed
-
- related to
-
WT-16933 Assertion failure during RTS checkpoint after WT-16698 backport on 7.0
-
- Backlog
-
-
WT-13746 Conflict between RTS and eviction regarding btree->rec_max_timestamp (take 2)
-
- Closed
-
-
WT-13618 Ensure the maximum timestamp seen by reconciliation at the btree level is reset during RTS/recovery/shutdown
-
- Closed
-