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

Commands that don't currently take any LockManager locks must not accept afterClusterTime

    XMLWordPrintable

    Details

    • Type: Question
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.0-rc2
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Sharding 2017-11-13

      Description

      Commands such as currentOp and ping are explicitly intended not to take any LockManager locks; however, they may end up acquiring LockManager locks as part of acquiring a MODE_IS lock on the oplog when afterClusterTime is specified in the readConcern object. I think it would be worth considering have the server reject these commands when an afterClusterTime is specified to preserve this intent.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: