[SERVER-49285] Support getMore on snapshot cursor even after unrelated index is created or dropped Created: 02/Jul/20  Updated: 06/Dec/22  Resolved: 09/Oct/20

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

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Storage Execution Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-47866 Secondary readers do not need to reac... Closed
Related
related to SERVER-47866 Secondary readers do not need to reac... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

Creating or dropping an index raises the collection's minimum visible snapshot. This causes a getMore on a snapshot cursor to return a SnapshotUnavailable error response, even if it wouldn't use that index. Longer-running snapshot reads would be more useful if their query plan wasn't impacted by the change to the collection's minimum visible snapshot.

const rst = new ReplSetTest({nodes: 1});
rst.startSet();
rst.initiate();
 
const db = rst.getPrimary().getDB("test");
assert.commandWorked(db.mycoll.insert(Array.from({length: 5}, (_, i) => ({_id: i}))));
const cursor = db.mycoll.find().readConcern("snapshot").batchSize(1);
 
assert.eq({_id: 0}, cursor.next());
assert.eq({_id: 1}, cursor.next());
assert.commandWorked(db.mycoll.createIndex({a: 1}));
// HERE: The getMore command fails with SnapshotUnavailable due to the collection's minimum visible
// snapshot being bumped from creating the {a: 1} index.
assert.eq({_id: 2}, cursor.next());
 
rst.stopSet();



 Comments   
Comment by Louis Williams [ 09/Oct/20 ]

This was fixed by SERVER-47866 in 4.8.0.

This behavior is tested here.

Comment by Louis Williams [ 21/Sep/20 ]

Yes. I will add a test case for this in SERVER-47866.

Comment by Connie Chen [ 21/Sep/20 ]

louis.williams is this related to your current work related to minimum snapshot changes? (SERVER-47866)

Comment by Max Hirschhorn [ 16/Jul/20 ]

Shouldn't the same problem exist when recovering from yield? Does it need to be fixed there as well?

milkie, my casual read of the query yielding code is that we don't re-check the collection's minimum visible snapshot after reacquiring locks and so query yielding isn't impacted by this issue.

Comment by Eric Milkie [ 16/Jul/20 ]

Shouldn't the same problem exist when recovering from yield? Does it need to be fixed there as well?

Comment by Connie Chen [ 02/Jul/20 ]

max.hirschhorn would you consider this to be blocking for PM-1504?

Comment by Louis Williams [ 02/Jul/20 ]

I think this should go to Execution since this has always been a problem.

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