-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
CAR Team 2025-02-17
-
200
-
1
The method attempts to take locks in source -> tmp collection order.
However, a subsequent rename may take locks in tmp -> source order if the ResourceId order says so.
Ideally locks should always be taken in ResourceId order to avoid deadlocks like these from occurring. Note that the likelihood of an actual issue here is quite low since it requires the random intermediate collection name to flip order based on the ResourceId and it has a very small window of possibility for other actors to target them.
- is related to
-
SERVER-100046 Disable lock runtime ordering checks in convertToCapped
-
- Closed
-
- related to
-
-
- Blocked
-
-
-
- Closed
-
-
SERVER-99150 Make threads always acquire locks with strict ordering
-
- Closed
-