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

XMLWordPrintableJSON

    • Type: Question
    • Resolution: Fixed
    • Priority: Major - P3
    • 3.6.0-rc2
    • Affects Version/s: None
    • Component/s: Sharding
    • None
    • Fully Compatible
    • Sharding 2017-11-13
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

              Assignee:
              Misha Tyulenev (Inactive)
              Reporter:
              Max Hirschhorn
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: