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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.6
    • Component/s: Replication
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.0
    • Sprint:
      Repl 2018-12-03

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: