This is necessary in order to register the final index builds that will be built (after filtering ready indexes and index builds) on the Coordinator, and to prevent subsequent index build duplicate request attempts (which get filtered by the index catalog) from being registered on the Coordinator (which considers that an error).
Eventually index build dupe requests will join in-progress index builds, so finalized (filtered) index builds must be correctly registered on the Coordinator synchronously before asynchronously building the index(es).
The logic flow will be
Caller thread into IndexBuildsCoordinator::startIndexBuild
- filter index build requests
- register on the Coordinator
- set up builder in persisted state, MultiIndexBlock::init
All of the above under the coordinator's mutex or a DB X lock, to force synchronization
async thread
- run index build and clean up index build state on success/failure.
- depends on
-
SERVER-38097 Pull the OperationContext out of MultiIndexBlock and instead pass it as a parameter into MultiIndexBlock functions
-
- Closed
-
-
-
- Closed
-
- is depended on by
-
-
- Closed
-
- related to
-
SERVER-30939 Multiple index builds on same collection can livelock on WriteConflictExceptions
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-