-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Concurrency
-
None
-
Fully Compatible
-
Execution Team 2022-02-21, Execution Team 2022-03-07
-
161
Callers typically acquire a MODE_X lock to exclude all readers and writers and a MODE_S lock to exclude all writers. Allowing query yielding, hybrid index building, etc. to release and later reacquire these locks can invalidate assumptions about what these internal callers thought acquiring a strong lock meant within the system because it enables other readers and writers to act on the collection.
We should consider making it a programmer error to use Locker::saveLockStateAndUnlock() and/or Locker::restoreLockState() to yield and reacquire MODE_X and MODE_S locks, or consider making it a programmer error to use PlanYieldPolicy::YieldPolicy::YIELD_AUTO while holding a MODE_X or MODE_S lock. Note: The caller could instead set PlanYieldPolicy::YieldPolicy::NO_YIELD or similar with an intent lock to reflect their intention to not see the effects of other writers if they actually wanted the effects of what yielding and reacquiring strong locks would imply for some reason.
- is depended on by
-
SERVER-62172 Fix failure to handle stepDown within IndexBuildsCoordinator::createIndex
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
- related to
-
SERVER-57358 Build config.chunks indexes on background in FCV upgrade/downgrade
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-