-
Type: Bug
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
ALL
-
v4.2
-
Repl 2019-10-21, Repl 2019-11-04
-
21
DropDatabase or any commands that acquire the global lock in X mode can be blocked by prepared transactions. The enqueued global X lock can block oplog queries which need the global IS lock. If these oplog queries and the data replication are needed by the prepared transaction's write concern, then the prepare transaction cannot make progress. Thus a deadlock occurs.
In reality, the coordinator may time out and decide to abort the transaction, but this could be an issue for testing.
- is depended on by
-
SERVER-43927 Make jstestfuzz_sharded and jstestfuzz_sharded_session suite start shards as replica sets
- Closed
- related to
-
SERVER-45612 Remove the mapReduce + prepare testing in 4.2 concurrency_simultaneous_replication suite
- Closed
- split to
-
SERVER-44026 Remove global X lock for reIndex
- Closed
-
SERVER-44027 Remove global X lock for renameCollection between DBs
- Closed
-
SERVER-44028 Remove global X lock for Cloner
- Closed
-
SERVER-44029 Remove global X lock for replSetResizeOplog
- Closed
-
SERVER-44030 Remove global X lock for mapReduce
- Closed
-
SERVER-44033 Only take the global write lock for applyOps when there are preConditions, multiple DDL commands or nested applyOps
- Closed
-
SERVER-44037 Remove restartCatalog
- Closed
-
SERVER-33272 The DatabaseHolder::close() function no longer requires a global write lock and neither does the dropDatabase command.
- Closed