[SERVER-42956] ReadyIndexesIterator::_advance() does not perform isReady() check Created: 21/Aug/19  Updated: 26/Sep/19  Resolved: 23/Aug/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Justin Seyster Assignee: Daniel Gottlieb (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-40620 Return or log error if an index key i... Closed
Related
is related to SERVER-43018 Formalize contract for safely accessi... Closed
Operating System: ALL
Backport Requested:
v4.2
Sprint: Execution Team 2019-08-26
Participants:

 Description   

A change for SERVER-37263 removed a check in ReadyIndexesIterator::_advance() that skips indexes returning false for isReady().

https://github.com/mongodb/mongo/commit/a5ce10b0982c7a0378ba92f1c7d3e02d49d0b18a#diff-d394cc50d8f61537a660446b56f0b5d5L96-L97

Skipping this check may allow a query to scan an index that is not consistent with the current transaction. We believe the fassert() added by SERVER-40620 (since reverted) is tripping as a result of an index getting used that should have been filtered out by an isReady() check. Let me know if you'd like details on how to reproduce that.



 Comments   
Comment by Daniel Gottlieb (Inactive) [ 23/Aug/19 ]

Instead of the proposed fix, I recommend doing SERVER-43018.

The solution proposed here would fix the specific problem the validation in SERVER-40620 catches. However, analyzing this bug showed there's a class of problems related to performing catalog lookups when the in-memory catalog is not appropriately synchronized with the on-disk catalog. These cases are specific to local/majority multi-document transactions, and are admittedly rather contrived.

If SERVER-43018 proves to be difficult, I'm happy to revisit putting in this change as a way to gain the validation introduced in SERVER-40620. It's very valuable for giving confidence to all indexing changes.

FWIW, the sample patch in SERVER-43018 did fix the problem SERVER-40620 discovered. I'm optimistic we'll have a complete fix.

Comment by Justin Seyster [ 22/Aug/19 ]

daniel.gottlieb Yes to both.

Comment by Daniel Gottlieb (Inactive) [ 21/Aug/19 ]

justin.seyster Is this failing specifically in the case where the reader is not using a timestamp? And presumably the reader is concurrent with a background/hybrid index build completing?

Generated at Thu Feb 08 05:01:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.