[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: |
|
||||||||
| 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:
And this is the UUID that gets renamed 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:
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: |
| Comment by Githook User [ 31/May/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}Message: Revert " This reverts commit d47ac2cae5245343c9c3668d59c8faea36e930c5. |
| Comment by Githook User [ 30/May/19 ] |
|
Author: {'name': 'Xiangyu Yao', 'email': 'xiangyu.yao@mongodb.com', 'username': 'xy24'}Message: |
| 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. |