[SERVER-40861] A renameCollection command from a collection to itself should drop the dropTarget if one exists Created: 26/Apr/19  Updated: 29/Oct/23  Resolved: 31/May/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.14

Type: Bug Priority: Major - P3
Reporter: Vlad Rachev (Inactive) Assignee: Xiangyu Yao (Inactive)
Resolution: Fixed Votes: 0
Labels: isfz
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2019-06-03
Participants:
Linked BF Score: 59

 Description   

We have a renameCollection command that runs against the primary such as this:

renameCollectionForCommand: rename db1.coll1 to db1.coll2 and drop db1.coll2.

And this is the UUID that gets renamed to db1.coll2:

renameCollection: renaming collection 63a88ea2-5ba3-45e1-8470-5e6ad880d9d5 from db1.coll1 to db1.coll2

During initial sync, in the clone phase of initial sync, we clone the updated db1.coll2 (63a88ea2-5ba3-45e1-8470-5e6ad880d9d5). Then, in the apply phase, we apply that renameCollection command from before. But because we've already cloned 63a88ea2-5ba3-45e1-8470-5e6ad880d9d5 instead of the previous collection at that namespace, the renameCollection command looks like this:

renameCollectionForApplyOps: rename db1.coll2 (63a88ea2-5ba3-45e1-8470-5e6ad880d9d5) to db1.coll2 and drop ac241f2c-c977-402e-9d65-c0aefbae2c99

In doing so, we hit this codepath: https://github.com/mongodb/mongo/blob/497264f15c41e708f6700f65826212519b9a576c/src/mongo/db/catalog/rename_collection.cpp#L218-L220.

Since the sourceColl and targetColl are the same, we correctly don't need to do the rename. But we still need to check if there is a dropTarget and perform the drop (rather than noop-ing completely).

 



 Comments   
Comment by Githook User [ 31/May/19 ]

Author:

{'name': 'Xiangyu Yao', 'email': 'xiangyu.yao@mongodb.com', 'username': 'xy24'}

Message: SERVER-40861 renameCollectionForApplyOps from a collection to itself should still drop the target
Branch: master
https://github.com/mongodb/mongo/commit/b901a8eb48a54a5ecdbd28842639656145ab7421

Comment by Githook User [ 31/May/19 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: Revert "SERVER-40861 renameCollectionForApplyOps from a collection to itself should still drop the target"

This reverts commit d47ac2cae5245343c9c3668d59c8faea36e930c5.
Branch: master
https://github.com/mongodb/mongo/commit/7133f9d15e46f998e600f2410d144a1342b3594e

Comment by Githook User [ 30/May/19 ]

Author:

{'name': 'Xiangyu Yao', 'email': 'xiangyu.yao@mongodb.com', 'username': 'xy24'}

Message: SERVER-40861 renameCollectionForApplyOps from a collection to itself should still drop the target
Branch: master
https://github.com/mongodb/mongo/commit/d47ac2cae5245343c9c3668d59c8faea36e930c5

Comment by Eric Milkie [ 16/May/19 ]

After implementation, we should consider if this should be backported.

Comment by Eric Milkie [ 13/May/19 ]

Ok I think I understand this now and I believe Vlad's suggestion is the correct thing to do.

Comment by Eric Milkie [ 02/May/19 ]

We should look into ways of fixing this BF.

Comment by Judah Schvimer [ 29/Apr/19 ]

I'm interested why the initial sync jscore passthrough never caught this. I suspect the operation ordering necessary for this does not appear in any jscore tests. As part of this ticket's testing we should add a jscore test that exercises this particular operation ordering. While the initial sync fuzzer will catch initial sync problems here, other components may have similar bugs.

Generated at Thu Feb 08 04:56:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.