Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Duplicate
-
None
-
None
-
None
-
ALL
Description
If after the end of the clone phase, we have on the syncing node
collection_a: UUID_1
collection_b: UUID_2
collection_c: UUID_3
and we replay a renameCollection opcode renaming UUID_1 to collection_b with dropTarget: UUID_3, we will correctly rename UUID_2 to a temporary name, but also incorrectly drop UUID_3. When we then go to create UUID_3 in a later oplog entry, it may be in drop_pending state and refuse to be re-created.
Attachments
Issue Links
- duplicates
-
SERVER-33956 A sequence of rename and create collections that do not arrive at the correct end state
-
- Closed
-
- is related to
-
SERVER-33087 Fix the use of dropTarget in renameCollection
-
- Closed
-