[SERVER-37948] Linearizable read concern is not satisfied by getMores on a cursor Created: 06/Nov/18 Updated: 29/Oct/23 Resolved: 14/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Replication |
| Affects Version/s: | 4.1.4 |
| Fix Version/s: | 4.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Jason Chan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2019-01-14, Repl 2019-02-11, Repl 2019-02-25 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
When a cursor is opened with "linearizable" read concern, we guarantee that any data returned will reflect all successful majority-acknowledged writes that completed prior to the start of the read operation. If we do subsequent getMore operations on this cursor, however, we do not satisfy this linearizability guarantee. I believe this bug is caused by the fact that when we wait for linearizable read concern here, we check the read concern arguments on the OperationContext of the running command. getMore commands, however, do not include a read concern directly. Their read concern is stored on the cursor object they are associated with. Since we only check the read concern from the OperationContext, we will presumably just return local read concern, bypassing the logic to satisfy the linearizability guarantee. |
| Comments |
| Comment by Githook User [ 14/Feb/19 ] |
|
Author: {'name': 'Jason Chan', 'email': 'jason.chan@10gen.com'}Message: |
| Comment by Githook User [ 14/Feb/19 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: Revert " This reverts commit 0cdb86f3cf2bbabe448669598c32297f5ec8214f. |
| Comment by Githook User [ 13/Feb/19 ] |
|
Author: {'name': 'Jason Chan', 'email': 'jason.chan@10gen.com'}Message: |
| Comment by Charlie Swanson [ 03/Jan/19 ] |
|
Just a little query perspective weighing in here - I think a getMore should be thought of as an implementation detail to get around the 16MB limit really. If you're doing a find, followed by something else, then followed by a getMore, you generally cannot expect to see that something else in your getMore. I don't think linearizable reads should be any exception. Requiring intervening writes to be visible in a subsequent getMore prevents the server from implementations which batch results or eagerly request more, both of which are things we sometimes do on mongos. |
| Comment by Gregory McKeon (Inactive) [ 12/Nov/18 ] |
|
We don't think we can ban getMores on cursors with "linearizable" set or queries with batchSize of 0 because of scatter-gather queries. We could do the write on the getMore. We should fix this because sharded queries are broken with this. |
| Comment by Judah Schvimer [ 07/Nov/18 ] |
|
I personally think that getMores should error if "linearizable" is set on the cursor. Linearizable cursors should probably also be required to contain a 'limit: 1', but that is already a documented requirement for safe linearizability. |
| Comment by Charlie Swanson [ 07/Nov/18 ] |
|
Also note some code we have on mongos to set up the read preference on the OpCtx from the cursor object. Perhaps we should do this for read concern as well, and also on mongod? The motivation for the read preference was to make it so that a change stream's "updateLookup" operations from mongos will obey the read preference. |
| Comment by Max Hirschhorn [ 06/Nov/18 ] |
|
Does Andy's argument for the getMore command not accepting a read concern in
|