Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-8444

Update stable lag using cpp test configuration

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: None
    • Labels:
      None
    • Story Points:
      3
    • Sprint:
      Storage - Ra 2021-12-13

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            luke.pearson Luke Pearson
            Reporter:
            etienne.petrel Etienne Petrel
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: