Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-38069

Plan cache maintenance after rolling back index build mistakenly re-opens WT transaction

XMLWordPrintableJSON

    • Fully Compatible
    • ALL
    • 45

      When building an index we register a rollback handler to notify the CollectionInfoCache that the index was dropped:

              opCtx->recoveryUnit()->onRollback([ this, opCtx, descriptor = descriptorPtr ] {
            // Need to preserve indexName as descriptor no longer exists after remove().
            const std::string indexName = descriptor->indexName();
            _entries.remove(descriptor);
            _collection->infoCache()->droppedIndex(opCtx, indexName);
        });

      This rollback handler can run if the index build is aborted. When it does, we refresh all the discriminators in the plan cache to keep our information up to date about which cache entries can be used by which queries:

      void CollectionInfoCacheImpl::droppedIndex(OperationContext* opCtx, StringData indexName) {
    // Requires exclusive collection lock.
    invariant(opCtx->lockState()->isCollectionLockedForMode(_collection->ns().ns(), MODE_X));

    rebuildIndexData(opCtx);
    _indexUsageTracker.unregisterIndex(indexName);
}

void CollectionInfoCacheImpl::rebuildIndexData(OperationContext* opCtx) {
    clearQueryCache();

    _keysComputed = false;
    computeIndexKeys(opCtx);
    updatePlanCacheIndexEntries(opCtx);
}

      Then, during updatePlanCacheIndexEntries we end up needing to call indexEntryFromCatalogEntry which ends up computing the set of multikey paths. In the case of a wildcard index, this involves opening a cursor on the storage engine.

      james.wahlin tells me that we don't actually need the multi key paths to update the indexability discriminators, so we should figure out some way to avoid this computation on this code path. We brainstormed some ideas about passing information into indexEntryFromCatalogEntry to communicate that you were uninterested in the multikey paths or more generally are unable to open a cursor.

            Assignee:
            jacob.evans@mongodb.com Jacob Evans
            Reporter:
            charlie.swanson@mongodb.com Charlie Swanson
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: