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

Auto-parameterization works incorrectly for indexed regular expression predicates

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Critical - P2 Critical - P2
    • 6.0.0-rc4, 6.1.0-rc0
    • Affects Version/s: 6.0.0-rc2, 6.1.0-rc0
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • v6.0
    • QE 2022-05-02, QE 2022-05-16
    • 132

      Here's a simple repro script, inspired by jstests/core/index_bounds_pipe.js:

      (function() {
      "use strict";
      
      const coll = db.coll;
      coll.drop();
      
      assert.commandWorked(coll.insert({_id: "a"}));
      assert.commandWorked(coll.insert({_id: "b"}));
      assert.commandWorked(coll.insert({_id: "foo"}));
      
      // Run a query which results in an auto-parameterized index scan plan being added to the SBE plan
      // cache.
      assert.eq(coll.find({_id: /^a/}).itcount(), 1);
      
      // This query incorrectly reuses the cached plan, and as a result returns 3 results instead of 2.
      assert.eq(coll.find({_id: /^a|b/}).itcount(), 2);
      }());
      

      Note this this only triggers the problem if you also include the changes for SERVER-64315, since this repro depends on the caching of single solution plans.

      I believe the problem is similar to SERVER-64776 – namely, the bounds tightness of the regex predicate is not correctly incorporated into the plan cache key. The first regex, /^a/, has exact bounds tightness, and therefore the predicate is "trimmed" and not included as an explicit filter in the execution plan. In contrast, /^a|b/ has inexact bounds and the regex must be reapplied to each index key. However, this query reuses a plan that has no filter stage. Consequently, the predicate does not get reapplied and the query returns extra results.

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: