-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.0.10, 5.3.3, 6.0.0-rc11, 6.1.0-rc0
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Sharding EMEA 2022-06-27, Sharding EMEA 2022-07-11
The RenameCollectionCoordinator does the following:
- Disallow all other DDL operations (excluding create) for the same db
- Check that the options are valid (e.g. make sure that the target collection does not exist if dropTarget = true).
- If checks are passing, the coordinator is not flagged as "complete on error".
- Rename participant commandss are invoked on each shard, the critical section is acquired for both collections.
This flow is faulty because if an explicit/implicit create sneaks in between bullets 2 and 3, this causes the rename participant that is executing on the shard primary to hang indefinitely.
- causes
-
SERVER-73385 RenameCollectionCoordinator wrongly releases critical section for destination ns.
- Closed
- is related to
-
SERVER-67845 Acquire critical section in rename "check preconditions" phase only if target not sharded
- Closed