Summary

A layered primary truncate does not detect a conflict with a write that was installed before the truncate and that the truncate cannot see. An example is an uncommitted insert into a gap between existing keys, or a reinsert over a key the truncate sees as deleted. The follower already detects these through its ingest scan. This ticket covers the primary's write-before-truncate cases from WT-18999 while keeping whole-page fast truncate.

Current behaviour

Point writes (remove, update without overwrite, modify) search for an exact key and run the write-conflict check before deciding whether the key has a visible value. They catch conflicts even when no value is visible.

Truncate instead removes each key returned by a cursor walk, and the walk filters by visibility first. Records with no value visible to the truncate are skipped inside the walk, so the conflict check never runs on them.

For example, a table holds keys 100 and 200. W inserts 150 and stays uncommitted. T truncates [100, 200]. T's walk skips 150, both transactions commit, and 150 survives inside T's range.

A committed insert newer than T's read timestamp is missed the same way.

Proposed solution

During a layered primary truncate, when the cursor walk skips a record because it has no value visible to the truncate, run the existing write-conflict check on that record and return WT_ROLLBACK on conflict. This reuses the check point writes already use.

• Cost: fast-truncated pages need no change. A page is fast-truncated only if it is on disk, has no prepared updates, and its aggregated newest changes are visible to the truncate, so it cannot hold a conflicting write. The extra check runs only on records the walk already visits.
• Range: every skipped record lies between two visible keys of the resolved range, so the range needs no extra bound check.
• Scope: limit the check to layered primary truncates. Ordinary truncates keep their current behaviour.
• Prepared updates: keep the existing behaviour of ignoring them.

Definition of Done

• Primary uncommitted gap inserts, hidden reinserts over deleted keys, and committed inserts newer than the truncate's read timestamp all conflict.
• A negative control shows these cases fail without the check.
• Whole-page fast truncate still happens on unmodified on-disk pages.
• Non-layered truncate behaviour is unchanged.