[SERVER-30090] mongo shell may inject incompatible readConcern when causal consistency is on Created: 11/Jul/17 Updated: 27/Oct/23 Resolved: 24/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Misha Tyulenev |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | PM-221 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Sharding 2017-08-21 |
| Participants: |
| Description |
|
There could be a conflict between afterClusterTime readConcern injected by shell or driver and internal checks if user wants to specify afterOpTime or different readConcern. 1. A message can not have both afterClusterTime and afterOpTime - it will cause an error. 2. A message can not have linearizable readConcern: 3. If clusterTime gets to the new unsharded cluster it may hit this error: |
| Comments |
| Comment by Misha Tyulenev [ 22/Aug/17 ] |
|
Re #2 it will not hurt to remove it - will do. Re #3 , sorry missed the question when it was posted, but Andy clarified. |
| Comment by Andy Schwerin [ 22/Aug/17 ] |
|
I believe that #3 is about a signed cluster time reaching a standalone replica set in the "clusterTime" field of a message. Standalone replica sets don't need and don't transmit cluster times, because the replica set primary maintains the true clock. So #3 should only happen when a shell connects to a sharded cluster, and then the same shell connects to a replica set. This is something tests might do but that users probably don't. In any event, I would think that if we attach the cluster time tracking to the Mongo object instead of making it a global variable in the shell, this problem would evaporate, possibly replaced by some other problem? RE #2, I agree that a user would probably like to be able to set both linearizable and causal. Perhaps we should just remove that check? |
| Comment by Spencer Brody (Inactive) [ 18/Aug/17 ] |
|
#1 seems fine, afterOpTime read concern was never a public feature anyway. |