[SERVER-34243] listCollections should not require a MODE_S database lock Created: 30/Mar/18  Updated: 29/Oct/23  Resolved: 21/Apr/18

Status: Closed
Project: Core Server
Component/s: Catalog, Storage
Affects Version/s: 3.7.3
Fix Version/s: 3.7.6, 3.6.21

Type: Bug Priority: Major - P3
Reporter: Geert Bosch Assignee: Geert Bosch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-37408 Add afterClusterTime to initial sync ... Closed
Documented
is documented by DOCS-11642 Docs for SERVER-34243: listCollection... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Sprint: Storage NYC 2018-04-23
Participants:
Case:

 Description   

Currently the listCollections command requires a MODE_S lock on the database it's run on. When any transaction is active on that database, it will generally have a MODE_IX lock on a collection. This will conflict with the MODE_S lock on the database, causing listCollections to block until the transaction is finished or aborted.

It should be sufficient to have the MODE_IS lock on the database, as long as each collection is locked as its details are gathered.



 Comments   
Comment by Githook User [ 25/Sep/20 ]

Author:

{'name': 'Geert Bosch', 'email': 'geert@mongodb.com', 'username': 'GeertBosch'}

Message: SERVER-34243 Use MODE_IS for listCollections

(cherry picked from commit bb148ced1999ffee8ebc58cb0fbefd784ac51a1f)

Conflicts:
jstests/core/txns/list_collections_not_blocked_by_txn.js
src/mongo/db/commands/list_collections.cpp
Branch: v3.6
https://github.com/mongodb/mongo/commit/16b23f3ac57b8bb015088fdb6af1fb5667c47624

Comment by Githook User [ 20/Apr/18 ]

Author:

{'email': 'geert@mongodb.com', 'username': 'GeertBosch', 'name': 'Geert Bosch'}

Message: SERVER-34243 Use MODE_IS for listCollections
Branch: master
https://github.com/mongodb/mongo/commit/bb148ced1999ffee8ebc58cb0fbefd784ac51a1f

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