-
Type:
Bug
-
Resolution: Won't Fix
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
3
-
v4.4
While debugging WT-5655 we noticed the following if statement allows one to have an oldest timestamp without a stable timestamp:
/*
* The oldest and stable timestamps must always satisfy the condition that oldest <= stable.
*/
if ((has_oldest || has_stable) && (has_oldest || txn_global->has_oldest_timestamp) &&
(has_stable || txn_global->has_stable_timestamp) && oldest_ts > stable_ts) {
__wt_readunlock(session, &txn_global->rwlock);
WT_RET_MSG(session, EINVAL,
"set_timestamp: oldest timestamp %s must not be later than "
"stable timestamp %s",
__wt_timestamp_to_string(oldest_ts, ts_string[0]),
__wt_timestamp_to_string(stable_ts, ts_string[1]));
}
(gdb) p (*(WT_CONNECTION_IMPL*)session->iface.connection)->txn_global
$17 = {current = 68200, last_running = 68200, oldest_id = 68200, durable_timestamp = 112793, last_ckpt_timestamp = 0, meta_ckpt_timestamp = 0,
oldest_timestamp = 93921, pinned_timestamp = 93921, recovery_timestamp = 0, stable_timestamp = 0, has_durable_timestamp = true,
Instead of fixing this we should use the oldest timestamp as the stable timestamp where possible but not act as if the user has set a stable timestamp.
- is related to
-
WT-9042 commit/durability timestamps can race, perform potentially unnecessary checks
-
- Backlog
-