-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: RTS
-
None
-
Storage Engines
The fix in WT-12909 sets the rollback_timestamp to WT_TS_MAX if the timestamp should not be used during RTS, but when RTS still needs to run to take care of its other jobs, i.e., to undo the effects of transactions not in the snapshot and of prepared transactions.
This change has the unfortunate consequence of making our log messages ugly:
[WT_VERB_RTS][DEBUG_1]: [INIT] start rollback to stable with stable_timestamp=(0, 0) and oldest_timestamp=(0, 0) using 4 worker threads [WT_VERB_RTS][DEBUG_1]: [NO_STABLE] the stable timestamp is not set; set the rollback timestamp to the maximum timestamp [WT_VERB_RTS][DEBUG_1]: [RECOVER_CKPT] recovered checkpoint snapshot_min=16, snapshot_max=16, snapshot_count=0 [WT_VERB_RTS][DEBUG_2]: [TREE_OBJECT_LOG] btree object found with newest_start_durable_timestamp=(0, 20), newest_stop_durable_timestamp=(0, 0), rollback_txnid=15, write_gen=3 [WT_VERB_RTS][DEBUG_1]: [TREE] rolling back tree. uri=file:rollback_to_stable44.wt, modified=false, durable_timestamp=(0, 20) > stable_timestamp=(4294967295, 4294967295): false, has_prepared_updates=true, txnid=15 > recovery_checkpoint_snap_min=16: false [WT_VERB_RTS][DEBUG_1]: [WAIT_THREADS] waiting for helper threads
Note that it says things like stable_timestamp=(4294967295, 4294967295); the problem is that the stable timestamp is not actually that value, as we are now using rollback_timestamp, and the large numbers are also hard to read.
We should, therefore:
- Change the instances where it prints stable_timestamp to print rollback_timestamp.
- Instead of printing (4294967295, 4294967295), print something like (MAX).
- Change tools/rts_verifier accordingly.
- has to be done after
-
WT-12909 Inconsistent RTS behavior when stable timestamp = 0
- Closed