-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Cache and Eviction, Checkpoints
-
Storage Engines - Transactions
-
SE Transactions - 2025-11-21, SE Transactions - 2025-12-05
-
3
We rely on the checkpoint generation to ensure that we don't evict anything should be included in the next checkpoint in the current checkpoint for disagg.
/*
* Don't evict the disaggregated page that should belong to the next checkpoint.
*
* It is safe to evict when checkpoint is not running because we have opened a new checkpoint
* before we set the checkpoint running flag to false.
*/
if (modified && F_ISSET(btree, WT_BTREE_DISAGGREGATED) && !WT_SESSION_BTREE_SYNC(session)) {
checkpoint_gen = __wt_atomic_load_uint64_acquire(&btree->checkpoint_gen);
if (checkpoint_gen == __wt_gen(session, WT_GEN_CHECKPOINT)) {
checkpoint_running =
__wt_atomic_load_bool_v_acquire(&S2C(session)->txn_global.checkpoint_running);
if (checkpoint_running) {
WT_STAT_CONN_DSRC_INCR(session, cache_eviction_blocked_disagg_next_checkpoint);
return (false);
}
}
}
However, we increase the checkpoint generation for a btree only after we have finished checkpointing it. This creates a gap that we can evict a page from the btree after we have finished checkpointing it but before we update its checkpoint generation.
In addition, we don't track checkpoint generation for metadata. In disagg, we should track it for all the tables including the shared metadata. Otherwise, we can evict a metadata page should not be included in the current checkpoint.
- related to
-
-
- Open
-