[SERVER-3964] Dropping an index invalidates all cursors on that collection, not just ones using that index. Created: 27/Sep/11  Updated: 17/Jan/19  Resolved: 17/Jan/19

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Spencer Brody (Inactive) Assignee: David Storch
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-12375 Document that in 4.2, an index drop w... Closed
Duplicate
is duplicated by SERVER-21061 Killing one index build interrupts an... Closed
is duplicated by SERVER-8975 Deleting non-existent indexes on a co... Closed
Related
related to SERVER-13626 dropping an index aborts other bg ind... Closed
is related to DOCS-1236 document cursor lifecycle Closed
is related to SERVER-37451 Move all cursor ownership to the glob... Closed
Sprint: Query 2019-01-28
Participants:
Case:
Linked BF Score: 4

 Description   

When you drop an index, we invalidate all open cursors on the collection that that index was on. It would be better if we could detect which cursors are using the index and only invalidate those cursors.

Per SERVER-8975 this occurs even if the index to be dropped does not exist.



 Comments   
Comment by David Storch [ 17/Jan/19 ]

As of commit de2a803ca49 under SERVER-37451, which was the culmination of a sequence of changes to how cursors are killed by invalidating DDL operations, this issue has been resolved. In versions >= 4.1.7, an index drop will only cause a concurrent query to die if that query is using the index.

Queries that are considering an index for planning purposes may still get killed when a seemingly unrelated index is dropped, as that index is required to stay alive for the planning process to complete successfully. This is only true when the index is dropped during the MULTI_PLAN, SUBPLAN, or CACHED_PLAN trial period. Correcting this limitation is left as future work.

ravind.kumar, I could not flag this ticket for documentation changes, since its resolution is not "Fixed". (I resolved the ticket as "Gone Away" since it had no commits assigned to it, and rather was fixed by a sequence of related changes under other tickets.) Please let me know if there are any other details you need for the documentation. I filed DOCS-12375 to track the docs work.

Comment by David Storch [ 31/Oct/18 ]

ravind.kumar, for now I've just marked as "Documentation Changes: Needed". Thanks for the heads up. When this is implemented, I'll be sure to provide any technical details that may be relevant to the docs team.

Comment by Ravind Kumar (Inactive) [ 29/Oct/18 ]

Given that this isn't currently documented behavior, please mark this as Documentation Needed so we can fix this up moving forward. 

Comment by Alex Piggott [ 13/Mar/13 ]

For when this gets assigned: what are your thoughts on how the Java driver handles this exception (and presumably similar ones) - see SERVER-8975? Is that worthy of a new issue under the Java driver?

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