[SERVER-40620] Return or log error if an index key is present but the document is not Created: 12/Apr/19 Updated: 29/Oct/23 Resolved: 21/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Justin Seyster |
| Resolution: | Fixed | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Backport Requested: |
v4.2, v4.0
|
||||||||||||||||||||||||
| Sprint: | Query 2019-06-17, Query 2019-07-01, Query 2019-07-15, Query 2019-07-29, Query 2019-08-12, Query 2019-08-26, Query 2019-09-09, Query 2019-09-23, Query 2019-10-07, Query 2019-12-30, Query 2020-01-13, Query 2020-01-27 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||
| Description |
|
If a FETCH follows an IXSCAN, it should be guaranteed that if the index key exists, so does the record. We simply return as if no records exists. No error, no warning. |
| Comments |
| Comment by Githook User [ 17/Jan/20 ] |
|
Author: {'username': 'jseyster', 'name': 'Justin Seyster', 'email': 'justin.seyster@mongodb.com'}Message: If a FETCH_STAGE encounters a record id that does not reference any create mode 100644 jstests/noPassthrough/query_yields_catch_index_corruption.js |
| Comment by Craig Homa [ 12/Nov/19 ] |
|
Moving back to open as the dependent tickets have been completed. |
| Comment by Justin Seyster [ 21/Aug/19 ] |
|
If the solution to |
| Comment by Githook User [ 11/Jul/19 ] |
|
Author: {'name': 'Misha Ivkov', 'email': 'misha.ivkov@10gen.com'}Message: Revert " This reverts commit cf6ffa0d0b72574bf6fee66a46e1b264c0cc6d63. |
| Comment by Githook User [ 11/Jul/19 ] |
|
Author: {'name': 'Misha Ivkov', 'email': 'misha.ivkov@10gen.com'}Message: |
| Comment by Louis Williams [ 30/May/19 ] |
|
Sending back to Query because this involves a little bit more work than initially expected. |
| Comment by David Storch [ 24/May/19 ] |
|
Due to query yielding, it is possible under normal operation for the FETCH stage to fail to find a document. Some query execution stages (e.g. TEXT_OR for $text execution) buffer index keys in the RID_AND_IDX state. These buffered keys may survive a yield, thereby becoming inconsistent with the storage engine snapshot which the read attaches to after recovering from yield. When this happens, the FETCH may find nothing associated with the RecordId. This is perfectly normal, and it would be incorrect to produce an error or a warning in all such cases. Luckily, the WorkingSet tracks which index keys have survived a yield. Before yielding, the PlanExecutor calls WorkingSetCommon::prepareForSnapshotChange(), which flags all index keys in the WorkingSet as "suspicious". If the FETCH stage fails to find a document associated with a "suspicious" key, that's perfectly normal. However, there should be no way for FETCHing a key that is not flagged as suspicious to fail to find a document. louis.williams is going to test this hypothesis by adding a assertion here that the index key is not suspicious. Please send me the code review for any eventual change spawned by this ticket, and add the query team to CC. |