[SERVER-31404] getMore commands should return an error when the caller specifies a read concern Created: 05/Oct/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | gm-ack, query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 0 | ||||||||||||
| Description |
|
It is not generally meaningful for client drivers to attach a readConcern argument to getMore commands. The purpose of readConcern is to set the isolation and consistency behavior for a newly issued query, and the purpose of getMore is to fetch a batch of documents from a cursor established by a previously issued query. Furthermore, the getMore command is an implementation detail of the driver and servers, rather than an interface presented to client applications. As such, mongodb servers must either ignore readConcern on getMore commands or reject getMore commands with readConcern arguments as malformed when such commands come from external clients. Returning an error is less subject to misinterpretation by driver authors, and so is the suggested approach. |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 26/Jan/18 ] |
|
Sending to Query for triage. |
| Comment by Charlie Swanson [ 05/Oct/17 ] |
|
spencer see the conversation on the BF, there was an idea to allow it exclusively from mongos to mongod. |
| Comment by Spencer Brody (Inactive) [ 05/Oct/17 ] |
|
schwerin, this change would preclude our current plan to use afterClusterTime readConcern to decrease change stream latency in the presence of an idle shard, by using the afterClusterTime machinery to generate no-op writes (SERVER-29258). |