Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Unresolved
Priority: Major - P3
Fix Version/s: None
Affects Version/s: None
Component/s: Metadata, Schema Management
Labels:
- schema-epoch-contract
- schema-epoch-drop-atomicity

Assigned Teams:

Storage Engines, Storage Engines - Persistence
Total Hours with Assigned Team:
0.001
Epic Link:
SPM-4842
Sprint:
SE Persistence backlog
Story Points:
1

While reconciling the shared metadata with the local metadata during checkpoint pick up, handle table drop by the primary.

The hard part of this ticket is ensuring that we can correctly handle the scenario in which the table that was dropped by the primary is still in use by the secondary. As explained in WT-18726, two possible approaches are:

Make the drop safe to fail: split it into two phases, where the first acquires everything the drop needs (for example, all of the table's handles) so the second is guaranteed to complete; or make the drop undoable, so a failed pickup can be rolled back completely.
Make drop behave like a Unix "unlink": existing readers keep the old table while new opens of the same name get the new one.

is depended on by

WT-18726 Handle drop and re-create of a layered table during checkpoint pickup

Backlog

is fixed by

WT-18068 Follower reads stale btree ID after leader create/drop/create of a layered table

Closed

is related to

WT-18360 Checkpoint pickup attaches a dropped incarnation's stable constituent to a recreated layered table

Closed

WT-18150 Panic on btree ID conflict when picking up a new layered table

Closed

related to

WT-18310 Queued shared metadata entries carry a dead era's snapshot across role transitions

Open

WT-18099 (Leader) create/drop/create above stable schema epoch survives database recovery

Closed

WT-18360 Checkpoint pickup attaches a dropped incarnation's stable constituent to a recreated layered table

Closed

WT-18068 Follower reads stale btree ID after leader create/drop/create of a layered table

Closed

WT-18318 Unpublished layered tables can diverge across step-down and step-up

Closed

WT-17090 Reconcile checkpoint pick-up with metadata operations on the follower

Closed

WT-18150 Panic on btree ID conflict when picking up a new layered table

Closed

WT-18320 Run epoch-less operations during schema-disagg-abort test

Closed

WT-18230 Disagg checkpoint can expose a recreated table before it is visible

Closed

WT-18231 failed: schema-disagg-abort-smoke-test-disagg-1 on amazon2023-disagg-asan-stress [wiredtiger-disagg @ f85479d5]

Closed

WT-18232 failed: schema-disagg-abort-smoke-test-disagg-1 on amazon2023-disagg-stress [wiredtiger-disagg @ f85479d5]

Closed

WT-18415 Schema Disagg Abort failure: EBUSY for 30 seconds

Closed

WT-18528 schema_disagg_abort: FAILED: Node 0: peer did not adopt the step-down checkpoint (lsn 1684) in 30 seconds

Closed

(12 related to)

Assignee:: Unassigned
Reporter:: Peter Macko
Votes:: 0 Vote for this issue
Watchers:: 3 Start watching this issue

Created:: Jun 03 2026 05:53:55 PM UTC
Updated:: Sep 25 2026 02:35:04 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates