-
Type: Bug
-
Resolution: Done
-
Priority: Minor - P4
-
Affects Version/s: 2.0.1, 2.4.8
-
Component/s: 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
- is duplicated by
-
SERVER-5016 last error incorrectly set when an in memory sort assertion occurs during a query but results returned correctly from another plan
- Closed
- is related to
-
SERVER-10026 New query system
- Closed
-
SERVER-666 query optimizer introspection
- Closed
- related to
-
SERVER-4669 query optimizer refactoring after migration to query optimizer cursor
- Closed