-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
ALL
-
Repl 2019-05-06
The following deadlock can occur:
1) A transaction goes in prepare in oplog application
2) A user operation acquires a lock in mode S and then blocks on a prepare conflict with the prepared transaction.
3) The commit of the prepared transaction attempts to reacquire (since the lock was yielded) an IX lock that conflicts with the mode S lock and blocks.
Possible solutions:
1) Do not yield locks for prepared transactions on secondaries.
2) Say such a user operation is illegal. We do not think they can occur today.
3) Yield locks in prepare conflicts
- is related to
-
SERVER-39096 Prepared transactions and DDL operations can deadlock on a secondary, if a reader blocks on a prepared document
- Closed
-
SERVER-39372 Make secondary lock acquisition for DDL operations consistent with behavior on primary
- Closed
-
SERVER-40705 Stepdown with prepared transaction that performed text search triggers invariant
- Closed
-
SERVER-37199 Yield locks of transactions in secondary application
- Closed
-
SERVER-38588 Hybrid index builds do not work when applied concurrently with prepared transactions on secondaries
- Closed
-
SERVER-37988 recover locks on step up at the beginning of the state transition rather than at the end
- Closed
- related to
-
SERVER-41888 Shutting down with prepared transaction can invariant during collection validation
- Closed
- split to
-
SERVER-40936 add an invariant that we do not get a prepare conflict while holding a global, database, or collection MODE_S lock
- Closed
-
SERVER-40937 remove the secondary DB lock acquisition for multikey updates
- Closed
-
SERVER-40938 Add tests that dbhash and map-reduce do not accept a read concern
- Closed