By default opening a checkpoint cursor on a table will default to use the history store corresponding to that table. To refer to the proper history required for the table, both the table and the history store are to be from the same checkpoint for data consistency.
To avoid returning inconsistent data, during the opening of the checkpoint cursor, we loop until we find both the table and history store are from the same checkpoint.
WiredTiger doesn't allow checkpointing individual tables separately other than from the system-wide checkpoint except when the table is opened for the bulk cursor operation. Performing individual table checkpoints leads to table and history store mismatch. In these scenarios, opening a checkpoint cursor on that table waits indefinitely until it finds a proper table and history store to use.
- causes
-
SERVER-73599 Investigate (for WT) implications of opening a checkpoint cursor returns an error in MongoDB
- Closed
-
WT-10721 failed: race-condition-stress-sanitizer-test-3 on ubuntu2004-stress-tests [wiredtiger @ 5a2abd1c]
- Closed
-
WT-10725 wt_wrap_open_cursor failed with no such file or directory error
- Closed
- is depended on by
-
SERVER-73599 Investigate (for WT) implications of opening a checkpoint cursor returns an error in MongoDB
- Closed
- is duplicated by
-
WT-10753 failed: format-stress-pull-request-test on ubuntu2004-msan [wiredtiger @ 48a7d4fd]
- Closed
- related to
-
WT-10564 Hang after opening a checkpoint cursor
- Closed
-
WT-10715 Automatically try previous checkpoints when opening a checkpoint cursor
- Open