-
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
-