Major - P3 Error signature during the execution of search_near_03.cxx:
[INFO]: insert thread: Perform unique index insertions with existing prefix key GQTy7. [2021/11/23 23:41:22.006] [1637710882:6644][92947:0x7f0e304e9700], WT_SESSION.timestamp_transaction: int __wt_txn_set_commit_timestamp(WT_SESSION_IMPL *, wt_timestamp_t), 581: [WT_VERB_DEFAULT][ERROR]: commit timestamp (1637710881, 1012914) is less than the stable timestamp (1637710882, 0): Invalid argument
The stable timestamp is newer than the commit timestamp used by the transaction:
commit timestamp (1637710881, 1012914) stable timestamp (1637710882, 0)
Analysis:
If we look at the search_near_03_default.txt configuration, there is a stable lag:
...
timestamp_manager=
(
stable_lag=30,
),
...
This means that we want to keep a lag of 30 seconds between the latest timestamp and the stable timestamp.
However, looking at the code of the timestamp_manager.cxx, it seems that the stable timestamp does not respect this lag:
/* Timestamps are checked periodically. */
latest_ts_s = get_time_now_s(); /*
* Keep a time window between the latest and stable ts less than the max defined in the
* configuration.
*/
testutil_assert(latest_ts_s >= _stable_ts);
if ((latest_ts_s - _stable_ts) > _stable_lag) {
log_msg = "Timestamp_manager: Stable timestamp expired.";
_stable_ts = latest_ts_s;
config += STABLE_TS + "=" + decimal_to_hex(_stable_ts);
}
Indeed, when the lag is too big, the stable timestamp is set to the latest timestamp:
_stable_ts = latest_ts_s;
It is incorrect, we should set the stable timestamp to the latest timestamp minus the lag required by the configuration.
The correct logic has been implemented for the lag between the stable and oldest timestamps.
Definition of done:
Respect the lag between the stable and latest timestamp as indicated by the configuration.