Fix assert indexes racing with oplog applier in index build tests

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • Hide

      diff --git a/src/mongo/db/repl/oplog.cpp b/src/mongo/db/repl/oplog.cpp
      index fbf4eb586b0..bc86a85debf 100644
      — a/src/mongo/db/repl/oplog.cpp
      +++ b/src/mongo/db/repl/oplog.cpp
      @@ -1016,6 +1016,7 @@ const StringMap<ApplyOpMetadata> kOpsMap = {
      }
      IndexBuildsCoordinator::get(opCtx)->applyStartIndexBuild(
      opCtx, applicationMode, swOplogEntry.getValue());
      + sleep(1);
      return Status::OK();
      },
      {ErrorCodes::IndexAlreadyExists,

      Show
      diff --git a/src/mongo/db/repl/oplog.cpp b/src/mongo/db/repl/oplog.cpp index fbf4eb586b0..bc86a85debf 100644 — a/src/mongo/db/repl/oplog.cpp +++ b/src/mongo/db/repl/oplog.cpp @@ -1016,6 +1016,7 @@ const StringMap<ApplyOpMetadata> kOpsMap = { } IndexBuildsCoordinator::get(opCtx)->applyStartIndexBuild( opCtx, applicationMode, swOplogEntry.getValue()); + sleep(1); return Status::OK(); }, {ErrorCodes::IndexAlreadyExists,
    • Execution Team 2023-04-17
    • 35
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      In some of our tests, there is a race between the index builder thread completing setup and reaching hangAfterInitializingIndexBuild, and the oplog applier thread waking up after setup is complete and marking the entry as applied, thus advancing the operationTime. In that case, the operation time will be less than the startIndexBuild entry timestamp, and the catalog will not contain the index.

            Assignee:
            Yujin Kang Park
            Reporter:
            Yujin Kang Park
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: