-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: 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