Details
Description
The issue is that the PlanExecutor::getNextSnapshotted() is continually called while the slowBackgroundIndexBuild failpoint is set without ever calling MultiIndexBlockImpl::insert(). It may be sufficient to set retries=1 before the continue, but I'd be curious if the slowBackgroundIndexBuild failpoint is still necessary after the introduction of the hangBeforeIndexBuildOf and hangAfterIndexBuildOf failpoints as part of SERVER-26387.
|
src/mongo/db/catalog/index_create_impl.cpp |
auto exec =
|
InternalPlanner::collectionScan(_opCtx, _collection->ns().ns(), _collection, yieldPolicy);
|
|
|
Snapshotted<BSONObj> objToIndex;
|
RecordId loc;
|
PlanExecutor::ExecState state;
|
int retries = 0; // non-zero when retrying our last document. |
while (retries || |
(PlanExecutor::ADVANCED == (state = exec->getNextSnapshotted(&objToIndex, &loc))) ||
|
MONGO_FAIL_POINT(hangAfterStartingIndexBuild)) {
|
try { |
if (_allowInterruption) |
_opCtx->checkForInterrupt();
|
|
|
if (!(retries || PlanExecutor::ADVANCED == state) || |
MONGO_FAIL_POINT(slowBackgroundIndexBuild)) {
|
log() << "Hanging index build due to failpoint"; |
invariant(_allowInterruption);
|
sleepmillis(1000);
|
continue; |
}
|
Attachments
Issue Links
- depends on
-
SERVER-38527 Reduce the number of supports*() functions for timestamps in the storage engine API
-
- Closed
-
- is depended on by
-
SERVER-38820 Unjournaled writes should be durable before restarting a secondary node into standalone mode
-
- Closed
-
- is related to
-
SERVER-33377 MultiIndexBlock builder can incorrectly change an InterruptedAtShutdown error into a uassert
-
- Closed
-