-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: Timestamps
-
Storage Engines - Transactions
-
415.142
-
SE Transactions - 2026-10-23, SE Transactions - 2026-11-06
-
3
Issue Summary
Time aggregate and time window validation failures (src/support/timestamp.c) are inconsistent about the global timestamps they report. Only the "against the stable point with an empty parent aggregate" failures, raised through the WT_TIME_ERROR macro, print the stable timestamp. Every other validation failure prints only the time window or time aggregate (and its parent), and none print the oldest timestamp. Several of these checks depend on the verifying connection's stable and oldest timestamps (for example the obsolete-at-checkpoint relaxation and the stable comparison for delta-built pages), so a failure message alone is not enough to tell whether the cause is a bad time window or an unexpected stable/oldest timestamp on the verifying connection, such as a follower with timestamps unset.
Context
- WT_TIME_ERROR currently prints the stable timestamp, but not the oldest timestamp.
- The remaining failures in the aggregate and value validators (parent comparisons, internal consistency checks, prepare checks) print neither timestamp.
- In disaggregated storage the verifying connection's stable and oldest timestamps can differ from those of the checkpoint writer, so diagnosing verify failures there needs both values (and ideally the checkpoint's own oldest timestamp).
Proposed Solution
- Make every validation failure message include the connection's stable timestamp and oldest timestamp, via a shared helper or by extending WT_TIME_VALIDATE_RET, rather than only through WT_TIME_ERROR.
- Consider also printing the checkpoint's oldest timestamp when validating a page built from deltas.
- Definition of done: any failure from the aggregate or value validators reports stable and oldest timestamps; existing tests that match on these messages are updated.