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

Enhance timestamp abort to accept more number of threads

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0.4, 4.1.4, WT3.2.0
    • Component/s: None
    • Labels:
    • Story Points:
      2
    • Sprint:
      Storage Engines 2018-09-24, Storage Engines 2018-10-08

      Description

      The timestamp abort test allows a maximum of 12 threads. We should change it so more threads can be configured. The naive change to do that leads to some test failures when high thread counts are chosen, due to session max being exceeded:

      ...
      test_timestamp_abort: FAILED: thread_run/282: td->conn->open_session(td->conn, NULL, NULL, &session): WT_ERROR: non-specific WiredTiger error[1522032138:76578][12961:0x7f4753fff700], WT_CONNECTION.open_session: out of sessions, configured for 134 (including internal sessions): WT_ERROR: non-specific WiredTiger error
      test_timestamp_abort: FAILED: thread_run/293: td->conn->open_session( td->conn, NULL, NULL, &oplog_session): WT_ERROR: non-specific WiredTiger error
      process aborting
      [1522032138:76770][12961:0x7f4627fff700], WT_CONNECTION.open_session: out of sessions, configured for 134 (including internal sessions): WT_ERROR: non-specific WiredTiger error
      test_timestamp_abort: FAILED: thread_run/293: td->conn->open_session( td->conn, NULL, NULL, &oplog_session): WT_ERROR: non-specific WiredTiger error
      process aborting
       
      process aborting
      Parent: compatibility: false, in-mem log sync: false, timestamp in use: true
      Parent: Create 181 threads; sleep 11 seconds
      CONFIG: test_timestamp_abort -h WT_TEST.timestamp-abort -T 181 -t 11
      test_timestamp_abort: FAILED: Child process 12961 abnormally exited: Invalid argument
      

      We should enhance the code to allow more threads and to error reasonably if a number greater than max is manually configured.

      It would also be interesting to facilitate creating workloads that do a lot of page splits, since they tend to uncover data consistency problems. I've made such a change locally before by making the following code change:

      --- a/test/csuite/timestamp_abort/main.c
      +++ b/test/csuite/timestamp_abort/main.c
      @@ -425,12 +425,13 @@ run_workload(uint32_t nth)
              /*
               * Create all the tables.
               */
      +#define TABLE_FORMAT_SHARED    "key_format=S,value_format=u,internal_page_max=1k,leaf_page_max=1k,memory_page_max=64k,allocation_size=512,"
              testutil_check(session->create(session, uri_collection,
      -               "key_format=S,value_format=u,log=(enabled=false)"));
      +               TABLE_FORMAT_SHARED "log=(enabled=false)"));
              testutil_check(session->create(session,
      -           uri_local, "key_format=S,value_format=u"));
      +           uri_local, TABLE_FORMAT_SHARED));
              testutil_check(session->create(session,
      -           uri_oplog, "key_format=S,value_format=u"));
      +           uri_oplog, TABLE_FORMAT_SHARED));
              /*
               * Don't log the stable timestamp table so that we know what timestamp
               * was stored at the checkpoint.
      
      

      We could do something similar behind a configuration option, or allow the format to be specified on the command line.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                neha.khatri Neha Khatri
                Reporter:
                alexander.gorrod Alexander Gorrod
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: