[SERVER-33241] Abort all running transactions on FCV downgrade Created: 09/Feb/18 Updated: 29/Oct/23 Resolved: 11/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2018-04-23 | ||||||||
| Participants: | |||||||||
| Comments |
| Comment by Githook User [ 11/Apr/18 ] |
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: |
| Comment by Tess Avitabile (Inactive) [ 29/Mar/18 ] |
|
spencer, I no longer believe this ticket is required for RC0, since there is no risk of returning incorrect results. From Apologies, I was incorrect. We do not need to worry about what the FCV was at our read timestamp for readConcern level snapshot without atClusterTime. This is because the read timestamp is always chosen at the batch boundary on secondaries, just like for majority reads, so there is no danger of getting an inconsistent view due to a unique index, even if the FCV is 3.6. It is only a danger for atClusterTime, since there is no guarantee that the requested time is at the batch boundary. |