[SERVER-35253] `dbHash` can take locks in MODE_S while in a transaction Created: 25/May/18  Updated: 29/Oct/23  Resolved: 29/May/18

Status: Closed
Project: Core Server
Component/s: Storage, Testing Infrastructure
Affects Version/s: 4.0.0-rc0
Fix Version/s: 4.0.0-rc1, 4.1.1

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Max Hirschhorn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
is caused by SERVER-34778 Add support for specifying atClusterT... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Steps To Reproduce:

(function() {
    let rst = new ReplSetTest({nodes: 1});
    rst.startSet();
    rst.initiate();
 
    rst.getPrimary().getDB("test").foo.insert({});
 
    var sess = rst.getPrimary().startSession({causalConsistency: false});
    sess.startTransaction();
    sess.getDatabase("test").runCommand({dbHash: 1});
    sess.getDatabase("test").foo.find().next();
})();

Sprint: TIG 2018-06-04
Participants:
Linked BF Score: 0

 Description   

SERVER-34778 allowed dbHash to be run inside of a multi-statement transaction. Multi-statement transactions convert all lock acquisition of database and collection locks to be MODE_IX (a higher level is used for determining whether the operation may be performed in a transaction).

However, the dbHash only performs lock conversion if the command specifies an atClusterTime as part of its read concern.

Thus a client can now:

  1. Start a transaction
  2. Perform a DBHash without using atClusterTime, taking a MODE_S lock on each database
  3. Perform a CRUD operation which is converted to MODE_IX

The server will crash on the CRUD operation when this invariant fires, noticing the MODE_IX request while the operation context already holds the lock in MODE_S.



 Comments   
Comment by Githook User [ 29/May/18 ]

Author:

{'username': 'visemet', 'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com'}

Message: SERVER-35253 Fix dbHash cmd to acquire IX locks inside multi-stmt txn.

(cherry picked from commit 52976ef70f1fa991c9b30ba5e0e45fb8e2a1a1d8)
(cherry picked from commit 1b3963a81c6cf68519b9ef5e798cf997483cc7b3)
Branch: v4.0
https://github.com/mongodb/mongo/commit/9f4401a7b20be1a4b6bd190f5b04919a6abf5645

Comment by Githook User [ 29/May/18 ]

Author:

{'username': 'visemet', 'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com'}

Message: SERVER-35253 Skip test when snapshot reads isn't supported.
Branch: master
https://github.com/mongodb/mongo/commit/1b3963a81c6cf68519b9ef5e798cf997483cc7b3

Comment by Githook User [ 29/May/18 ]

Author:

{'username': 'visemet', 'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com'}

Message: SERVER-35253 Fix dbHash cmd to acquire IX locks inside multi-stmt txn.
Branch: master
https://github.com/mongodb/mongo/commit/52976ef70f1fa991c9b30ba5e0e45fb8e2a1a1d8

Generated at Thu Feb 08 04:39:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.