First part of work tracked from WT-7285:
Investigate how we are going to store the checkpoint information, I like the idea proposed by Susan LoVerso, so would start with keeping 1 (or 2) ckpt structures around attached to the dhandle. The cached ckpt structures will be used instead of reparsing the strings, and then updated as new checkpoints get created. Let's start with the common (non-backup) path. In the debug build, we will still parse and create ckpt structures and assert if the structures created from metadata do not match the one we hold in the cache. We will need to figure exactly how many ckpt structures to keep around, including handling checkpoint deletion.
- causes
-
WT-7517 Code cleanup: Introduce a is-part-of-ckpt-array field
- Closed
-
WT-7521 Remove excess ckplist invalidations
- Closed
-
WT-7524 Refactor functions to obtain checkpoint list; Clear delete on skipping checkpoints
- Closed
- is duplicated by
-
WT-7421 Handle backup checkpoints when maintaining most recent checkpoints
- Closed
-
WT-7422 Find and account for all code paths that invalidate cached checkpoint information
- Closed
- related to
-
WT-5479 Checkpoint schema lock can cause long stalls in command execution on systems with many active data handles
- Closed
-
WT-7285 Maintain Most Recent Checkpoint information
- Closed