-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Execution Team 2021-06-28, Execution Team 2021-07-12, Execution Team 2021-07-26
SERVER-46698 invariants that operations which are holding open an oplog hole cannot acquire a storage engine ticket or flow control ticket.
We also attempted to invariant when acquiring a lock, namely in LockerImpl::_lockBegin and LockerImpl::_lockComplete, but discovered that a MODE_IX lock on the session transactions table is acquired while holding open an oplog hole in at least two different code paths.
- In logApplyOpsForTransaction, an oplog hole is opened (via RecoveryUnit::setTimestamp) by logOperation. A MODE_IX lock on the session transactions table is then acquired here by onWriteOpCompleted (via updateSessionEntry in onWriteOpCompletedOnPrimary).
- In OpObserverImpl::onInserts, an oplog hole is opened by repl::logInsertOps. A MODE_IX lock on the session transactions table is then acquired here by onWriteOpCompleted (via updateSessionEntry in onWriteOpCompletedOnPrimary).
The goal of this ticket should be to (a) determine whether acquiring the MODE_IX lock on the session transactions table can actually block in practice (perhaps another thread acquires a MODE_X or MODE_S lock on the session transactions table) and to (b) invariant that operations which are holding open an oplog hole cannot block when acquiring locks.
- depends on
-
SERVER-46698 Invariant that operations which are holding open an oplog hole cannot call blocking functions
- Closed
- is related to
-
SERVER-58243 Investigate transaction_participant.cpp lock acquisitions
- Open
-
SERVER-58222 Investigate op_observer_sharding_impl.cpp lock acquisition
- Backlog
-
SERVER-58223 Investigate shard_server_op_observer.cpp lock acquisitions
- Backlog
-
SERVER-58219 Investigate ViewCatalog::reload() lock acquisition
- Closed