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

Plan cache key computation for wildcard indexes with partialIndexFilter is incorrect, leading to incorrect query results

    XMLWordPrintable

Details

    • Fully Compatible
    • ALL
    • v4.4, v4.2
    • Hide

      Run attached reproduction script.

      Note that the script loops over the relevant steps until the error occurs, since the problem does not seem to be entirely deterministic but may have some sort of timing sensitivity.

      Also note the rather specific setup steps. We could only reproduce the issue if the wildcard index is defined with a partialFilterExpression and when a second non-wildcard index is present. But we are not sure if either of these aspects are causally relevant.

      Show
      Run attached reproduction script. Note that the script loops over the relevant steps until the error occurs, since the problem does not seem to be entirely deterministic but may have some sort of timing sensitivity. Also note the rather specific setup steps. We could only reproduce the issue if the wildcard index is defined with a partialFilterExpression and when a second non-wildcard index is present. But we are not sure if either of these aspects are causally relevant.
    • Query 2020-06-15, Query 2020-06-29

    Description

      We had an issue where a query on a collection containing a wildcard index seemingly randomly returned zero results, even though matching objects existed. The issue first arose one days after introducing wildcard indexes, so a causal relation seemed likely.

      The problem seems to arise if a first query successfully filters for a non-null value using the wildcard index...

      filter: { value1: 1.0, value2: 1.0, value3: 1.0, deleted: null }
      planSummary: IXSCAN { $_path: 1, value3: 1 }
      

      And then a second nearly identical query filters for null on the same field...

      filter: { value1: 1.0, value2: 1.0, value3: null, deleted: null }
      planSummary: IXSCAN { $_path: 1, value3: 1 }
      

      Seemingly, the query planner simply reuses the plan from the first query, not realizing that the wildcard index is sparse by definition.

      Attachments

        Issue Links

          Activity

            People

              david.storch@mongodb.com David Storch
              ralf.strobel Ralf Strobel
              Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: