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

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.4, v4.2
    • Steps To Reproduce:
      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.
    • Sprint:
      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

        1. SERVER-48614.js
          3 kB
          Ralf Strobel

          Issue Links

            Activity

              People

              Assignee:
              david.storch David Storch
              Reporter:
              ralf.strobel Ralf Strobel
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: