Providing an explicit atClusterTime with read concern snapshot in a transaction can violate snapshot isolation.

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Cannot Reproduce
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Sharding NYC
    • v7.1
    • Sharding NYC 2023-09-04
    • 105
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

              Assignee:
              [DO NOT USE] Backlog - Sharding NYC
              Reporter:
              Kshitij Gupta (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: