-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
Execution Team 2022-09-05
An InterruptibleLockGuard will ensure that there is no active UninterruptibleLockGuard on the stack.
Since ClientCursors are holding storage cursors now, we need to ensure there's never a deadlock between replication rollback (holding a global X lock) and interrupted read operations trying to acquire a lock while a ClientCursor is already pinned (pinning occurs without a lock).
- is depended on by
-
SERVER-69143 CursorManager no longer needs to handle ClientCursor::dispose() outside of mutexes
- Open
- is duplicated by
-
SERVER-68874 Consider making waitAfterPinningCursorBeforeGetMoreBatch only hang instead of also fiddling with locks (while-loop taking and releasing locks)
- Closed
- is related to
-
SERVER-69506 An InterruptibleLockGuard should be placed in the PlanExecutorSBE class as a private member if the use cases are expanded beyond the find/agg/getMore commands while the UninterruptibleLockGuard still exists
- Backlog
-
SERVER-69406 Place InterruptibleLockGuards in the find and aggregation command paths
- Closed
- related to
-
SERVER-35321 Make renameCollection uninterruptible
- Closed