Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-40861

A renameCollection command from a collection to itself should drop the dropTarget if one exists

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.14
    • Affects Version/s: None
    • Component/s: Storage
    • Labels:
    • Fully Compatible
    • ALL
    • Execution Team 2019-06-03
    • 59

      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).


            xiangyu.yao@mongodb.com Xiangyu Yao (Inactive)
            vlad.rachev@mongodb.com Vlad Rachev (Inactive)
            0 Vote for this issue
            9 Start watching this issue


                Error rendering 'slack.nextup.jira:slack-integration-plus'. Please contact your Jira administrators.