Loading...

XML

Word

Printable

JSON

With the new schema epochs API, if a client attempts to create a checkpoint that corresponds to a state:

...where a table does not exist, the table should be excluded from a checkpoint.
...where a table has been dropped, WiredTiger should panic (at least for now), regardless of whether the table has been recreated. This is because the recreated and the original tables are logically two different tables, even though they have the same name.
...where a table exists, and it has not been dropped after that point, the table should be included in the checkpoint.

Or to put this visually:

We need to ensure that this behavior is correct.

blocks

WT-18343 schema-disagg-abort: Let schema publish operations straddle step-down timestamp

depends on

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

WT-18324 Panic when a checkpoint schema epoch refers to a recreated table and fix API-violating tests

WT-18405 Do not drop a table on the follower with uncheckpointed data

WT-18272 Validate a pending DROP before panicking on skipped shared metadata creates

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

is related to

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

SERVER-133635 Pass the schema epoch to WiredTiger in dropIdent()

related to

WT-18501 Exercise the era-scoped publish rules in schema_disagg_abort

(1 depends on, 2 is related to, 1 related to)