-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Schema Management
-
Storage Engines - Foundations
-
214.521
-
SE Foundations - 2026-09-01
-
None
Split out from WT-18230. This ticket covers the API check and fixes tests that use invalid schema epochs.
Checkpoint below a published drop
BFG-3485199, BFG-3499971, and BFG-3508343 checkpointed a table after it had been dropped and recreated, using an epoch below the drop.
A checkpoint below a published drop is legal if no recreate is queued. It becomes an API violation when a later CREATE for the same table is part of that checkpoint. Checkpoints covering the recreate remain legal.
Add this check to __wt_disagg_shared_metadata_queue_process. Update the schema-abort test so it does not recreate a table until a checkpoint covers its published drop.
Invalid Python reproducer
The reproducer switches from epoch-less operation to schema epochs midway through the test, so the recreated table does not receive the AWAITS_PUBLISH flag.
Set the stable schema epoch before the first operation, publish every schema operation, and checkpoint at the drop epoch while the recreate remains deferred. Cover the invalid drop-and-recreate sequence separately with a panic test.
- is depended on by
-
WT-18284 Ensure correct handling of CREATE/DROP/CREATE patterns
-
- Backlog
-
- is related to
-
WT-18272 Validate a pending DROP before panicking on skipped shared metadata creates
-
- Backlog
-
-
WT-18230 Disagg checkpoint can expose a recreated table before it is visible
-
- Closed
-
- related to
-
WT-18230 Disagg checkpoint can expose a recreated table before it is visible
-
- Closed
-