[SERVER-79437] Providing an explicit atClusterTime with read concern snapshot in a transaction can violate snapshot isolation. Created: 27/Jul/23 Updated: 05/Sep/23 Resolved: 05/Sep/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kshitij Gupta | Assignee: | [DO NOT USE] Backlog - Sharding NYC |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | sharding-nyc-subteam1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||
| Backport Requested: |
v7.1
|
||||||||||||||||
| Sprint: | Sharding NYC 2023-09-04 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 105 | ||||||||||||||||
| Description |
|
Updated title + more context from max.hirschhorn@mongodb.com's comment While the manifestation a --dbg=on build variant would be the for mongos process to crash, in a production system, a client which had specified {readConcern: {level: "snapshot", atClusterTime: T1}} as the transaction read concern would have used a different timestamp T2 > T1 when starting the transaction on later participants. This would result in different participants using different read timestamps for the cross-shard transaction and violate snapshot isolation. |
| Comments |
| Comment by Randolph Tan [ 05/Sep/23 ] |
|
Original crash has been reverted and atClusterTime is being ignored because of SERVER-79766 |