-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Verify
-
None
-
Storage Engines - Persistence
-
181
-
StorEng - Defined Pipeline
-
None
Background
When a parent time aggregate is empty, _time_value_validate_parent_stable (src/support/timestamp.c) compares a value's time window with a stable timestamp that it fetches itself, using _wt_get_stable_timestamp for the verifying connection. The fix for WT-18771 added a from_delta branch there that reads S2BT(session)->checkpoint_timestamp instead. A reviewer asked why this function works out the bound rather than being handed it. The function already behaved this way before WT-18771, and WT-18771 did not change that.
Proposal
Pass the bound in from the caller instead of having the validation function derive it:
- _wt_time_value_validate and _time_value_validate_parent_stable take the bound as a parameter, and the function no longer depends on the btree or the connection's stable timestamp.
- __verify_page_content_leaf (bt_vrfy.c), which knows which checkpoint it is verifying and whether the page was rebuilt from deltas, supplies the checkpoint's own timestamp for delta pages and leaves full pages on the existing check.
- The other callers need a defined value: _verify_dsk_value_validity (bt_vrfy_dsk.c, reached from the wt_verify_dsk_image callers in bt_read.c, bt_split.c and rec_write.c) and _cell_check_value_validity (cell_inline.h, which passes no parent so never reaches the comparison).
Points to settle
- Whether callers may pass "not specified" (for example WT_TS_NONE) and fall back to the connection's stable timestamp, or every caller must pass an exact value. The second needs a field on WT_VERIFY_INFO and changes to every __wt_verify_dsk_image caller, and what those diagnostic paths should pass has not been analysed.
- Which timestamp to pass. btree->checkpoint_timestamp is the newest checkpoint's timestamp, so when an older checkpoint is verified the bound is looser than needed. The exact value is the verified checkpoint's own recorded timestamp (__wt_meta_read_checkpoint_timestamp with the checkpoint name); whether a per-checkpoint entry exists for a disaggregated stable checkpoint on a follower has not been checked.
- A checkpoint timestamp of 0 (the leader never set a stable timestamp): today the delta check compares against 0 and fails. Decide whether 0 should mean "skip the comparison", which is a behaviour change.
Expected result
No change in what verify accepts or rejects for existing tests, with the bound chosen by the caller. A prototype of the "not specified falls back" variant touched four source files plus extern.h and passed test_verify_disagg and test_verify_disagg07; it was not kept.
Related: WT-18771 (fix for the false verification failure), WT-18675 (broader verification policy), FIXME-WT-17968 in __verify_page_content_leaf.
- is related to
-
WT-17968 Disaggregated storage checkpoint pick-up pinned-timestamp panic check reads unpopulated metadata (dead code)
-
- Blocked
-
-
WT-18771 Fix false timestamp verification on delta pages with empty parent aggregate
-
- Closed
-
-
WT-18675 Verify on a disaggregated checkpoint should use the checkpoint's own frame of reference, not the connection's live timestamps
-
- Open
-
- related to
-
WT-18771 Fix false timestamp verification on delta pages with empty parent aggregate
-
- Closed
-