There is an apparent thread-safety error which can occur if a listDatabases command is running concurrently with a renameCollection command. This is closely related to the problem observed in SERVER-34531. As described in SERVER-34531, the listDatabases command takes a GlobalLock in MODE_IS. The renameCollection command acquires a GlobalLock in MODE_IX and a MODE_X database lock on the database on which it is performing the rename. Global locks of type IX and IS do not conflict, so the listDatabases command and renameCollection command are allowed to run concurrently.
The listDatabases command reads from KVDatabaseCatalogEntryBase::_collections, a std::map which is not thread-safe, in order to check whether the database is empty. At the same time, the renameCollection may be writing to the _collections map in order to represent the rename in the catalog data structures.
As far as I can tell, the fix for SERVER-34531 ensured that listDatabases would not fail to report a database due to a concurrent rename, but it did not prevent concurrent access to the _collections map.
- depends on
-
SERVER-33272 The DatabaseHolder::close() function no longer requires a global write lock and neither does the dropDatabase command.
-
- Closed
-
-
-
- Closed
-
- is related to
-
SERVER-34531 listDatabases command can miss a database if a collection in that database is renamed concurrently
-
- Closed
-