Background

WT-18662 fixed one instance of a category error: WT_SESSION::verify on a disaggregated follower can reconstruct a delta-chain page using the reading connection's own, live oldest timestamp, then compare the result against a parent aggregate that was computed by the checkpoint's writer, at a different point in time, under different visibility. When the two disagree, verify reports corruption that isn't real – the content and the aggregate are each internally correct, just derived from two different frames of reference.

WT-18662's fix is a targeted, narrow tolerance: in __time_value_validate_parent, a delta-reconstructed cell that's already obsolete against the checkpoint's own recorded oldest timestamp (last_checkpoint_oldest_timestamp) is allowed to fall outside the parent aggregate rather than failing. That closes the specific case that was reproduced, but it's a patch on one comparison site – the same mismatch could in principle recur anywhere else verify compares reconstructed content against a checkpoint-authored aggregate.

Proposed fix

Generalize WT-18662's tolerance across every relevant verify check, rather than rewriting how reconstruction works: a cell (or aggregate) that's "extra" relative to the checkpoint's own recorded timestamps should be ignored by verify's validation wherever it's compared against checkpoint-authored state, not just in the one call site WT-18662 patched. Reconstruction itself keeps using the reading connection's own live visibility, exactly as it does for a normal read.

Alternative to weigh: making reconstruction itself checkpoint-aware

A more thorough alternative would have the base+delta reconstruction that happens during verify decide obsolescence using the checkpoint's own recorded oldest timestamp instead of the connection's live one, so reconstructed content and the checkpoint's aggregate always agree by construction, rather than relying on a growing set of validation-site exceptions.

The tradeoff to evaluate before choosing this: the page built that way is not the same page a live read on the same node would build (a live read uses the node's own current oldest timestamp), so it can't be shared with the node's own page cache as-is – verify would either need a second, parallel cached copy of the page, or risk contaminating the shared cache with a version that's wrong for ordinary reads. Whether that cost is worth paying for the more principled fix, versus the narrower validation-only tolerance above, needs a closer look before committing to an approach.

Scope note

Either way, this is about verify's own validation of reconstructed content against checkpoint-authored aggregates – it should not change how reconstruction decides what a page contains for ordinary reads.