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

Using removeExistingIndexes in conjunction with createIndexesOnEmptyCollection results in out of order index fields.

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 4.3.3
    • None
    • Index Maintenance
    • None
    • Fully Compatible
    • ALL
    • Execution Team 2019-12-16
    • 47

    Description

      There are several places in the code base that call into IndexBuildsCoordinator's static createIndexesOnEmptyCollection function to create an index, as opposed to going through the IndexBuildsCoordinator itself. To prepare the index specs for creation, these callers use IndexCatalog::removeExistingIndexes. However, these index specs result in out-of-order fields compared to index builds that use the IndexBuildsCoordinator, because the IndexCatalog::prepareSpecForCreate function, which is called via MultiIndexBlock, re-orders the fields. Even though IndexCatalog::removeExistingIndexes does call IndexCatalog::prepareSpecForCreate, the spec objects returned by prepareSpecForCreate are unused.

      The implication of this bug is the oplog entries for different index builds will have a different ordering of subfields inside the "o" field.

      Using the return result of prepareSpecForCreate in the return result of removeExistingIndexes should address the ordering inconsistency.

      Attachments

        Activity

          People

            maria.vankeulen@mongodb.com Maria van Keulen
            maria.vankeulen@mongodb.com Maria van Keulen
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: