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

XMLWordPrintableJSON

    • 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.

            Assignee:
            Salman Javed
            Reporter:
            Jie Chen
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: