Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-79437

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

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

      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:
            backlog-server-sharding-nyc [DO NOT USE] Backlog - Sharding NYC
            Reporter:
            kshitij.gupta@mongodb.com Kshitij Gupta
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: