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

AutoGetCollection doesn't need to call getPointInTimeReadTimestamp for non snapshot read concern levels

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.6
    • Affects Version/s: None
    • Component/s: Replication
    • Labels:
      None
    • Fully Compatible
    • ALL
    • v4.0
    • Repl 2018-12-03

      Inside AutoGetCollection, we have a special block to check for pending catalog changes if the read concern level is kSnapshotReadConcern. We make a call to RecoveryUnit::getPointInTimeReadTimestamp before checking for snapshot read concern. This means that we may call this when trying to acquire a collection lock but the read concern is non-snapshot. This is problematic if a command that uses a non snapshot read concern tries to set a read timestamp source on the recovery unit before calling AutoGetCollection. In WiredTiger, for example, we will invariant that a read timestamp has already been set. When we take a collection lock, the read timestamp may not have been set, but this is fine. We shouldn't invariant in this case. It should be simple enough to move the call inside that if statement, so that we only call it if we are sure we have snapshot read concern.

            Assignee:
            william.schultz@mongodb.com William Schultz (Inactive)
            Reporter:
            william.schultz@mongodb.com William Schultz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: