[SERVER-38069] Plan cache maintenance after rolling back index build mistakenly re-opens WT transaction Created: 09/Nov/18  Updated: 29/Oct/23  Resolved: 18/Dec/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Querying, Storage
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Jacob Evans
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-38355 WiredTigerRecoveryUnit::_txnOpen() sh... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 45

 Description   

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.



 Comments   
Comment by Githook User [ 18/Dec/18 ]

Author:

{'email': 'jacob.evans@10gen.com', 'name': 'Jacob Evans'}

Message: SERVER-38069: Ensure WT transactions are not re-opened during plan updates
Branch: master
https://github.com/mongodb/mongo/commit/fc2b0e1525f0bef7ccdea22e5ed3afa43e6693ac

Comment by Githook User [ 15/Dec/18 ]

Author:

{'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'name': 'Gregory Wlodarek'}

Message: Revert "SERVER-38069 Ensure WT transactions are not re-opened during plan updates"

This reverts commit ac39ac47d776bbd0f442f945d4ae6091b73cfb03.
Branch: master
https://github.com/mongodb/mongo/commit/54c2a4560cbcd5b652c3bdc8543404ea6cc2d485

Comment by Githook User [ 14/Dec/18 ]

Author:

{'email': 'jacob.evans@10gen.com', 'name': 'Jacob Evans'}

Message: SERVER-38069 Ensure WT transactions are not re-opened during plan updates
Branch: master
https://github.com/mongodb/mongo/commit/ac39ac47d776bbd0f442f945d4ae6091b73cfb03

Generated at Thu Feb 08 04:47:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.