[DOCS-12375] Document that in 4.2, an index drop will no longer kill a query which is not using the index Created: 17/Jan/19  Updated: 30/Oct/23  Resolved: 01/Mar/19

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: David Storch Assignee: Ravind Kumar (Inactive)
Resolution: Fixed Votes: 0
Labels: docs-query
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-3964 Dropping an index invalidates all cur... Closed
Participants:
Days since reply: 4 years, 49 weeks, 5 days ago
Epic Link: DOCS: 4.2 Server/Tools
Story Points: 0.25

 Description   

Description

In all versions of MongoDB prior to 4.2, dropping an index on a particular collection would cause all active queries against that collection to be killed. See SERVER-3964. Work done by the query team's "all cursors globally managed" project has improved this behavior such that dropping an index only kills concurrent queries whose plan actually relies on that index. We may wish to document this improvement (possibly as part of the 4.2 release notes?). I've left a few additional details on SERVER-3964, but feel free to reach out directly to me if you have any questions or require additional information.

Scope of changes

  • Update dropIndexes and its shell helper with the new behavior
  • Update the release note with the new behavior

 



 Comments   
Comment by Githook User [ 01/Mar/19 ]

Author:

{'name': 'rk-mongo', 'email': 'ravind.kumar@mongodb.com'}

Message: DOCS-12375: dropIndexes only kills queries using dropped index
Branch: master
https://github.com/mongodb/docs/commit/c21ea8329a2c7bc68c98be342de6ab4b08b106a6

Comment by David Storch [ 22/Jan/19 ]

ravind.kumar, actually, I looked more thoroughly at the source code, and it appears that my previous comment was incorrect! Apparently the dropIndexes command does take a MODE_X lock on the entire database, rather than taking a MODE_IX lock on the database and a MODE_X lock on the collection. Therefore, the docs would be correct in asserting that dropIndexes write locks the entire database.

geert.bosch could confirm my reading of the code. Also, he is working on a project to take more granular locks for catalog operations (PM-1242), so he may be changing this soon. Either way, SERVER-3964 did not change any locking behavior, so this conversation does not pertain to the particular documentation requested by this ticket.

Comment by Ravind Kumar (Inactive) [ 18/Jan/19 ]

Thanks David - the current docs simply state that the command write locks the whole database, which does not seem correct. might as well fix that while I'm in there.

Is the locking behavior you're describing generally true for 3.6+? I know we're slightly out of scope here but it was bothering me while reading through the current docs.

Comment by David Storch [ 18/Jan/19 ]

ravind.kumar, the locking behavior of index drops did not change for this project. An index drop operation will take an exclusive lock on the collection not the database. Specifically, it will acquire a MODE_IX ("intent exclusive") global lock, a MODE_IX lock at the database level, and a MODE_X (exclusive) lock on the collection. The MODE_X collection lock will exclude all other readers and writers from the collection. However, the MODE_IX database lock will permit concurrent readers and writers in other collections.

Comment by Ravind Kumar (Inactive) [ 17/Jan/19 ]

david.storch - from reading the epic for global cursors, there are changes to locking behavior. Right now we document that dropping an index take a write lock on the database. Is that still the case?

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