-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Storage
-
Fully Compatible
-
ALL
-
v3.4
-
-
Storage 2017-03-27, Storage 2017-04-17
-
0
Storage engines which use the KVCatalog, but do not support document-level concurrency (such as the ephemeralForTest storage engine) may experience deadlock because of the incompatible acquisition order of the resourceIdCatalogMetadata and the "local" database locks. This bug does not apply to the MMAPv1 or WiredTiger storage engines.
db.getSiblingDB("local").runCommand({listCollections: 1}): HOLD: Global, 1, MODE_IS HOLD: Global, 2, MODE_IS HOLD: Database, local, MODE_S WAIT ON: Metadata, resourceIdCatalogMetadata, MODE_S db.getSiblingDB("CreateDatabase0").runCommand({create: "coll0"}): HOLD: Global, 1, MODE_IS HOLD: Global, 2, MODE_IX HOLD: Database, CreateDatabase0, MODE_X HOLD: Metadata, resourceIdCatalogMetadata, MODE_X WAIT ON: Database, local, MODE_IX
The resourceIdCatalogMetadata lock is acquired when calling KVCatalog::newCollection() as part of Database::createCollection(); however, the lock doesn't get released immediately after returning from there since it was acquired in MODE_X inside a WriteUnitOfWork causing shouldDelayUnlock() to return true. This leads to the client creating a collection to be holding the resourceIdCatalogMetadata lock while attempting to acquire a lock on the "local" database in order to write the corresponding oplog entry at the same time as the client listing collections on the "local" database to be holding a lock on the "local" database while attempting to acquire the resourceIdCatalogMetadata lock to get the individual collection options.
git version: ae04822985f2478c7da1e6821f5fc91b484b9555
- is related to
-
SERVER-21965 Deadlock between drop database and list collection metadata for KVCatalog-based storage engines without document locking
- Closed
-
SERVER-23994 Re-enable the concurrency and fuzzer suites on the ephemeralForTest variant
- Closed