[SERVER-33558] Remove read preference from AsyncResultsMerger and $mergeCursors Created: 28/Feb/18  Updated: 29/Oct/23  Resolved: 07/Mar/18

Status: Closed
Project: Core Server
Component/s: Aggregation Framework, Querying
Affects Version/s: None
Fix Version/s: 3.7.3

Type: Task Priority: Major - P3
Reporter: Charlie Swanson Assignee: Charlie Swanson
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Query 2018-03-12
Participants:

 Description   

We believe it is the case that once a cursor is established on a node, the read preference does not play a role. For example, if a read preference "primary" query is sent to the primary and a cursor established, then that cursor can still be iterated if the node steps down between the cursor establishment and the getMore.

This means we no longer have to track the read preference during getMores, except in the specific case of new queries issued during getMores, such as described in SERVER-31665.



 Comments   
Comment by Githook User [ 07/Mar/18 ]

Author:

{'email': 'charlie.swanson@mongodb.com', 'name': 'Charlie Swanson', 'username': 'cswanson310'}

Message: SERVER-33558 Remove readPreference from AsyncResultsMerger
Branch: master
https://github.com/mongodb/mongo/commit/2286d21ea884edf41622d40b068efc92a443b12a

Comment by Charlie Swanson [ 05/Mar/18 ]

Scheduling this for next sprint after discussion in code review.

Comment by Charlie Swanson [ 28/Feb/18 ]

I've made a test that proves you can getMore a read preference "primary" cursor even when the node is no longer the primary.

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