-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
Fully Compatible
-
Execution Team 2023-02-20, Execution Team 2023-02-06
-
169
Upgrading the global lock mode without first releasing the lock held can have bad side effects (namely deadlock and resource exhaustion). We've removed some cases where this can happen (most recently in SERVER-59219). We think we can explicitly ban this behavior in code, as it could help us identify additional bugs we haven't hit yet, and avoid future ones. That said, there are some instances where we currently upgrade the global lock, and we'll need to fix these first.
- depends on
-
SERVER-61601 Determine if global lock upgrade is necessary when implicitly creating collection during createIndexes
- Closed
-
SERVER-61609 Determine if global lock upgrade is necessary in ReplicationCoordinatorExternalStateImpl::_dropAllTempCollections
- Closed
-
SERVER-61733 Determine if global lock upgrade is necessary in transaction_participant.cpp:fetchActiveTransactionHistory
- Closed
-
SERVER-61786 Determine if we can avoid global lock upgrade in IndexBuildsCoordinatorMongod::setCommitQuorum
- Closed
-
SERVER-61788 Determine if we can avoid global lock upgrade in dbtest StorageTimestampTest
- Closed
-
SERVER-61789 Determine if we can avoid global lock upgrade in dbtests/repltests.cpp
- Closed
-
SERVER-66609 Avoid global lock upgrade in storage_timestamp_test.cpp
- Closed
-
SERVER-67695 Remove the write-blocking mode of dbCheck
- Closed
- is depended on by
-
SERVER-73040 Ban all lock upgrades
- Closed
- is related to
-
SERVER-66145 Identify and fix locations that write while holding read tickets
- Closed
-
SERVER-66719 dbCheck FCV lock upgrade causes deadlock with setFCV
- Closed