[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:
Backports
Depends
depends on SERVER-42956 ReadyIndexesIterator::_advance() does... Closed
depends on SERVER-43018 Formalize contract for safely accessi... Closed
Problem/Incident
Related
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: SERVER-40620 uassert and log when fetching dangling index entry

If a FETCH_STAGE encounters a record id that does not reference any
existing documents, that means either the document was deleted since
query execution encountered the index entry or their is corruption
somewhere. If the snapshot id indicates that the query has not yielded
since the time that the index entry was loaded, that leaves corruption
as the only possibility. We return and error and write to the log with
instructions on how to address potentially inconsistent data.

create mode 100644 jstests/noPassthrough/query_yields_catch_index_corruption.js
Branch: master
https://github.com/mongodb/mongo/commit/8e810c9ff48db40e63b3201f8bd4d0bf4fdea8ce

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 SERVER-42956 involves just restoring the isReady() check, we should be able to just un-revert the original change.

Comment by Githook User [ 11/Jul/19 ]

Author:

{'name': 'Misha Ivkov', 'email': 'misha.ivkov@10gen.com'}

Message: Revert "SERVER-40620 fassert during document fetch when there is evidence of index corruption"

This reverts commit cf6ffa0d0b72574bf6fee66a46e1b264c0cc6d63.
Branch: master
https://github.com/mongodb/mongo/commit/95d6412f4d1d150e3027048b27eca07c5dec27be

Comment by Githook User [ 11/Jul/19 ]

Author:

{'name': 'Misha Ivkov', 'email': 'misha.ivkov@10gen.com'}

Message: SERVER-40620 fassert during document fetch when there is evidence of index corruption
Branch: master
https://github.com/mongodb/mongo/commit/cf6ffa0d0b72574bf6fee66a46e1b264c0cc6d63

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.

Generated at Thu Feb 08 04:55:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.