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

SubplanStage fails to register its MultiPlanStage

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.2.1, 3.3.0
    • Fix Version/s: 3.2.3, 3.3.1
    • Component/s: WiredTiger
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Completed:
    • Steps To Reproduce:
      Hide

      1. Restore the attached dump on an instance using WiredTiger
      2. Run the following query and verify it works fine

      var userId = ObjectId('558c7b28ccb061d504e0692c');
      var queryStart = ISODate('2016-01-14T09:00:00.000-0200');
      var queryEnd = ISODate('2016-01-14T12:00:00.000-0200');
       
      db.bug_test.count({ $or: [
          { userId: userId, end: { $gte: queryStart, $lt: queryEnd } },
          { userId: userId, start: { $gte: queryStart, $lt: queryEnd } },
          { userId: userId, start: { $lt: queryStart }, end: { $gt: queryEnd } }
      ]});
      

      3. Create the following indexes:

      db.bug_test.createIndex({ userId: 1, start: 1 });
      db.bug_test.createIndex({ userId: 1, end: 1 });
      

      4. Run the query used on step 2 again and the bug will be triggered

      Show
      1. Restore the attached dump on an instance using WiredTiger 2. Run the following query and verify it works fine var userId = ObjectId('558c7b28ccb061d504e0692c'); var queryStart = ISODate('2016-01-14T09:00:00.000-0200'); var queryEnd = ISODate('2016-01-14T12:00:00.000-0200');   db.bug_test.count({ $or: [ { userId: userId, end: { $gte: queryStart, $lt: queryEnd } }, { userId: userId, start: { $gte: queryStart, $lt: queryEnd } }, { userId: userId, start: { $lt: queryStart }, end: { $gt: queryEnd } } ]}); 3. Create the following indexes: db.bug_test.createIndex({ userId: 1, start: 1 }); db.bug_test.createIndex({ userId: 1, end: 1 }); 4. Run the query used on step 2 again and the bug will be triggered
    • Sprint:
      Integration F (02/01/16)
    • Case:

      Description

      Issue Status as of Jan 27, 2016

      ISSUE SUMMARY
      Operations where the predicate is a rooted $or use a special execution path in the query optimizer in order to perform query plan selection. A rooted $or is a predicate which consists exclusively of a top-level $or statement (although the subexpressions may be arbitrarily complex). For example,

      {$or: [{a: 1}, {b: 1}]}
      

      is a rooted $or. By contrast,

      {$or: [{a: 1}, {b: 1}], c: 1}
      

      is not a rooted $or due to the implicit AND with the predicate on the c field.

      A bug in the plan selection path for such predicates may cause the server to improperly save index cursor state in preparation for yielding locks or to improperly restore index cursor state when re-acquiring locks after a yield.

      USER IMPACT
      The following commands, if using a rooted $or predicate, are affected:

      • aggregate
      • count
      • delete
      • distinct
      • find
      • findAndModify
      • group
      • mapReduce
      • update

      For servers running the WiredTiger storage engine, this issue could cause poor performance due to suboptimal plan selection for a rooted $or query. The following log message is indicative of this issue:

      WTIndex::updatePosition -- the new key (...) is less than the previous key (...), which is a bug
      

      Servers running MMAPv1 may experience the following symptoms:

      • Poor performance due to suboptimal plan selection for a rooted $or query.
      • Failed rooted $or queries due to breaking internal invariants.
      • In rare cases, reads from freed memory or other undefined behavior may cause the server to abort.

      WORKAROUNDS
      The special execution path for rooted $or queries can be disabled at startup or at runtime via the internalQueryPlanOrChildrenIndependently setParameter. You can disable this parameter from the shell as shown below:

      db.adminCommand({setParameter: 1, internalQueryPlanOrChildrenIndependently: false});
      

      This configuration option should be set with care, as all rooted $or queries will be diverted from their typical execution path, potentially leading to a loss in performance for such queries.

      AFFECTED VERSIONS
      MongoDB 3.2.0 and 3.2.1.

      FIX VERSION
      The fix is included in the 3.2.3 release.

      Original description

      This causes messages such as save, restore, and invalidate to fail to propagate to the subplans if a yield occurs while choosing a plan for subqueries. This can result in incorrect query execution.

      This was introduced by https://github.com/mongodb/mongo/commit/c832bc75#diff-d16091f48e3ffb1cc4c4cc6fd6319c2bR326.

      Original Title and Description:

      WTIndex::updatePosition - the new key is less than the previous key

      When I use a query using compund indexes, the following message is shown several times per second on log:

      2016-01-22T15:21:16.865-0200 I STORAGE  [conn2] WTIndex::updatePosition -- the new key ( 64558C7B28CCB061D504E068AB78800001523FD86A6C042087F1) is less than the previous key (64558C7B28CCB061D504E0692C78800001523FE4DFA40420EED9), which is a bug.
      

      A dump to reproduce the bug is attached.

      If I run the query without creating indexes, it works fine both on MMAPv1 and WiredTiger:

      var userId = ObjectId('558c7b28ccb061d504e0692c');
      var queryStart = ISODate('2016-01-14T09:00:00.000-0200');
      var queryEnd = ISODate('2016-01-14T12:00:00.000-0200');
       
      db.bug_test.count({ $or: [
          { userId: userId, end: { $gte: queryStart, $lt: queryEnd } },
          { userId: userId, start: { $gte: queryStart, $lt: queryEnd } },
          { userId: userId, start: { $lt: queryStart }, end: { $gt: queryEnd } }
      ]});
      

      If I create the following indexes, it works fine on MMAPv1 but triggers the bug on WiredTiger:

      db.bug_test.createIndex({ userId: 1, start: 1 });
      db.bug_test.createIndex({ userId: 1, end: 1 });
      

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: