Motivation

The block cache shares reconstructed disk images across btrees keyed only on (file ID, address cookie). A btree opened by a checkpoint cursor is a separate dhandle over the same file, so it resolves the same address cookies and can share cache entries with the normal btree. This is not safe: the two reconstruct full disk images from deltas differently.

Problem details

When flattening base image + deltas, page_read_build_full_disk_image calls time_window_clear_obsolete on every cell, stripping time windows that are "globally visible". Global visibility is relative to the session's transaction: a normal read checks against the live oldest timestamp, while a checkpoint-cursor read runs under WT_TXN_IS_CHECKPOINT and checks against the frozen checkpoint_oldest_timestamp, which can be older. The same base + deltas therefore flatten to different bytes, but the cache has one slot per cookie.

If the normal btree inserts its image first, a checkpoint reader between the checkpoint's oldest and a stripped timestamp gets silent wrong results:

• A start cleared to WT_TS_NONE makes a too-new version look visible — the reader returns it instead of descending into the HS checkpoint.
• A stop cleared to WT_TS_NONE makes a delete look eternal — the reader returns not-found for a value alive at its read timestamp.

Proposed fix

Skip blockCache->tryGet when getArgs->flags & WT_PAGE_LOG_CACHE_BYPASS and treats it as a miss.