-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
The GlobalLock is supposed to synchronize operations from accessing the storage engine during shutdown and rollback, as those are the only places where a Global X lock is taken.
Unfortunately, this is not enforced, respected, or sufficient in all code paths. These bugs were all caused by operations accessing the storage engine without a lock:
In these cases, we were holding onto storage engine resources in an uninterruptible state without a lock:
In addition to those problems, the lock is a bit heavy-handed for a very infrequent event.
Ideally, we would do the following:
- On shutdown and rollback, kill all operations
- Allow operations to run to completion as long as they are interruptible
- Operations that can block for indefinite periods of time must do so in an interruptible state
- Operations can always safely perform some non-blocking rollback after being killed
- is depended on by
-
SERVER-90800 Remove the usage of UninterruptibleLockGuard in MultiIndexBlock
-
- Blocked
-
- is related to
-
SERVER-60335 Wait for all user operations to be killed before executing WT Rollback To Stable
-
- Closed
-
- related to
-
SERVER-66556 Prevent potential race when releasing cursors during shutdown
-
- Closed
-
-
SERVER-70338 Query yield accesses the storage engine without locks during shutdown and rollback
-
- Closed
-
-
SERVER-74809 Yield call into storage engine after releasing global lock
-
- Closed
-
-
SERVER-88838 The WiredTigerRecoveryUnit Destructor can access null fields of a WT Session
-
- Closed
-
-
SERVER-58311 MongoDB calls WT RTS API while holding an open cursor on _mdb_catalog
-
- Closed
-
-
SERVER-60334 Avoid caching the cursor and session in WiredTigerSizeStorer
-
- Closed
-