dbCheck, which initially only holds IS locks in the global hierarchy (except the FCV lock), upgrades its locks to IX when writing to the oplog.
This causes a deadlock with a concurrent setFCV command and a DDL operation, in this example, dropCollection:
- dbCheck holds all IS locks in the global hierarchy including the IS collection lock, but it doesn't hold the FCV lock, which we only take in exclusive (IX,X) lock modes.
- dropCollection holds an IX FCV lock. It waits on an X collection lock behind dbCheck
- setFCV waits on an S FCV lock behind dropCollection
- dbCheck tries to take an IX FCV lock behind the setFCV
We support lock upgrades in the lock manager. If the dbCheck operation had taken an IS FCV lock, it would have skipped the queue ahead of the waiting setFCV command, and this deadlock did not happen. This is described in this comment.
This ticket will address the deadlock concern by not upgrading the global locks in dbCheck, since this is generally dangerous.
- is related to
SERVER-65821 Deadlock during setFCV when there are prepared transactions that have not persisted commit/abort decision
- related to
SERVER-66145 Identify and fix locations that write while holding read tickets
SERVER-60621 Investigate if we can ban upgrading the global lock