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

clean/fix exception handling in query plan runners



    • Bug
    • Status: Closed
    • Minor - P4
    • Resolution: Fixed
    • 2.0.1, 2.4.8
    • 2.5.5
    • Querying
    • ALL


      We should clean and fix the way query plan runners handle exceptions:

      • An exception that should abort a plan should do so and not set get last error.
      • An exception that should abort a query or an unexpected exception should abort the query, not an individual plan.


      We are running with table scans disabled.

      We are seeing a high number of user assertions. After digging through log files we discovered that the query optimizer starts a table scan for some queries when assessing which query path will be fastest. This then causes a user assertion for that path (due to table scans being disabled) but doesn't actually fail the query.

      The results of the query (and the chosen path) are exactly as expected. The reporting of the user assertion is not. This can make it harder to find real problems.

      When bumping up logging we saw this:

      Mon Feb 13 14:07:05 [conn103509] runQuery called xxx.content { $query: { _id: ObjectId('4f2c4757dc37691ee100078f'), _cls: "Content.Post" } }
      Mon Feb 13 14:07:05 [conn103509]   running multiple plans
      Mon Feb 13 14:07:05 [conn103509] User Assertion: 10111:table scans not allowed:xxx.content
      Mon Feb 13 14:07:05 [conn103509]    used cursor: 0x7f6604064cc0
      Mon Feb 13 14:07:05 [conn103509] query xxx.content ntoreturn:1 nreturned:1 reslen:2089 0ms

      Thread discussing this is in Google Groups: https://groups.google.com/forum/?hl=en&fromgroups#!topic/mongodb-user/CJdPrLmN9zM


        Issue Links



              hari.khalsa@10gen.com hari.khalsa@10gen.com
              colinhowe Colin Howe
              0 Vote for this issue
              4 Start watching this issue