dropIndexes locking and in-flight query behavior
Parent: Hidden indexes and safe index removal · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for dropIndexes locking and in-flight query behavior. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Waiting for the exclusive collection lock and being killed because an index disappears are separate effects. Inference from the documented scopes: a query that does not use or consider the removed index can still wait for collection access during the drop. (high confidence) [source]
- SERVER-15019 records a separate regression introduced in development version 2.7.4: aggregation executor cancellation did not reach the underlying executor when dropIndexes removed its index. The issue lists 2.7.8 as the fix version. (low confidence) [source]
- MongoDB’s concurrency FAQ says that from version 5.0, lock-free reads such as find, count, distinct, and read-only aggregate are not blocked merely because another operation holds an exclusive collection lock. Aggregations that write require an IX lock and can be blocked. The FAQ does not explicitly resolve how this general rule interacts with every dropIndexes metadata transition, so it does not guarantee uninterrupted reads during index removal. (low confidence) [source]
Problems, failure modes and limitations
- Huawei Cloud DDS documents a reproduction in which a cursor consumes 101 documents, its x_1 index is dropped, and a later getMore fails with code 175, QueryPlanKilled, and an index-dropped message. This is direct evidence for DDS cursor invalidation, not an independent proof of the exact error response in every MongoDB release. (low confidence) [source]
Facts and statements
- MongoDB documents that dropIndexes and db.collection.dropIndex() obtain an exclusive lock on the specified collection for the operation duration. The documented lock scope is the collection; the command reference says subsequent collection operations wait for release, subject to the separately documented lock-free-read qualification. (high confidence) [source]
- The dropIndexes command reference says it kills queries using the index being dropped, potentially including queries considering that index during planning. Therefore an in-flight query depending on the removed index must not be assumed to complete transparently on another plan; this last sentence is an operational inference from the documented termination behavior. (high confidence) [source]
- Mydbops dates the change from an exclusive parent-database lock to an exclusive collection lock to MongoDB 4.2, and says pre-4.2 removal killed all open queries on the collection. Current MongoDB documentation instead describes collection locking and killing only related queries. Treat database-wide locking and indiscriminate query termination as historical descriptions, not current defaults. (medium confidence) [source]
- If the specified index is still building, dropIndexes attempts to stop that build. On a replica set, run the operation on the primary: it stops the build and records abortIndexBuild, which secondaries replicate to stop and discard their build jobs. (high confidence) [source]
- SERVER-14969 records an aggregation/index-drop server-crash defect affecting MongoDB 2.6 production releases through 2.6.4. The issue states that 2.6.5 fixes it by correctly interrupting aggregations using the removed index. (low confidence) [source]
- OneUptime recommends lower-traffic windows for production index drops and characterizes drops as generally fast. Combined with MongoDB's exclusive-lock guarantee, this supports planning for an interruption window, but does not establish any maximum lock duration. (medium confidence) [source]
- Long-running MongoDB operations periodically yield, including to allow index or collection drops to obtain exclusive access. Thus a drop need not wait for every long-running query to finish naturally; the command separately documents killing queries that depend on the removed index. (high confidence) [source]
Children
- No children recorded.