-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Schema Management
-
Storage Engines - Foundations
-
25.083
-
None
-
None
Problem
A layered table created while a stable schema epoch is set awaits publication, and its stable constituent carries WT_BTREE_AWAITS_PUBLISH to keep the tree out of every checkpoint until the table is published. If the handle is swept while the table is still unpublished, the flag is lost, and the table is thereafter treated as published: it is checkpointed, its pages are written out, and the guard in __checkpoint_disagg_maybe_publish (src/checkpoint/checkpoint_txn.c:459) does not fire because the state it tests for has been erased.
The pending create still sitting in the shared metadata queue is drained later and overwrites the shared row with its create-time snapshot, leaving checkpoint= empty. A follower picking up that checkpoint reads no rows. That downstream behaviour is tracked in WT-18310.
Reachable in normal use: create a layered table, do not write to it, leave it idle past the sweep idle time.
Root cause
The flag is derived once, at handle open, in _btree_conf (src/btree/bt_handle.c:629). It requires the WT_SESSION_CREATE_BTREE session marker, set only for the duration of _create_file (src/schema/schema_create.c:396-408), so on any later open the condition is false and the flag is cleared (bt_handle.c:637). There is no durable record of "not yet published" for the btree layer to re-derive it from.
Sweep has no notion of publication state. Its only content gate is that it will not close a modified tree, with an exception for ingest btrees (src/conn/conn_sweep.c:151-175), and it never consults __wt_btree_stays_in_memory(). An unpublished stable constituent that has not been written since it was created is clean, so nothing stops the close. Inside the publication window the flag is a one-way latch: btree->modified is cleared only by a checkpoint the tree never reaches, so a first write pins the handle open for good.