-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Metadata
-
Security Level: Public (Available to anyone on the web)
-
Storage Engines - Foundations
-
4,062.143
-
SE Foundations - 2026-03-27, SE Foundations - 2026-04-10
-
5
Here's the code we open the shared metadata in __disagg_pick_up_checkpoint. This is called by the follower. Thus, we should open a checkpoint of the shared metadata but from the code we are opening the shared metadata as a live btree.
cfg[0] = WT_CONFIG_BASE(session, WT_SESSION_open_cursor);
cfg[1] = NULL;
WT_ERR(__wt_open_cursor(shared_metadata_session, WT_DISAGG_METADATA_URI, NULL, cfg, &cursor));
There are other places we open the shared metadata the same way.
We need to ensure we only open checkpoint of shared tables when we are the follower. Can we add some verification to detect this?
- is depended on by
-
WT-15449 test/format (disagg.mode=switch) cache stuck
-
- Closed
-
- is duplicated by
-
WT-16528 Investigate whether a separate internal session is required to apply checkpoints
-
- Closed
-
- is related to
-
WT-16221 Dhandle sweep should quickly expire outdated btrees
-
- Closed
-
-
WT-15800 Eviction server trying to write the page from a follower on shutdown
-
- Closed
-
-
WT-15619 Implement rewriting leaf page deltas directly into a full page
-
- Closed
-
- related to
-
WT-17103 Deadlock assertion when statlog and sweep race on shared metadata on leader
-
- Closed
-
-
WT-17040 Investigate whether the creation of shared metadata is necessary on followers
-
- Open
-