[SERVER-20909] Allow cursor registration without a PlanExecutor Created: 13/Oct/15  Updated: 06/Dec/22  Resolved: 26/Jul/19

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 3.1.9
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Do Votes: 0
Labels: query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Operating System: ALL
Participants:

 Description   

Currently, a ClientCursor cannot be established without first constructing a PlanExecutor. In a sharded environment, a registered cursor is what prevents the RangeDeleter from deleting migrated documents. A PlanExecutor is allowed to yield during planning, which releases the locks on the collection while yielded. This can lead to the following scenario:

  1. Acquire locks and construct a PlanExecutor.
  2. During construction of a PlanExecutor, the planning machinery yields.
  3. A chunk migration finishes during the yield, where this shard is the donor shard.

Since we have not yet established a ClientCursor, the RangeDeleter is now allowed to delete documents from this chunk, even though the ShardFilterStage thinks that they are owned by this shard. Thus it is possible to miss matching documents.

It should be possible to register a cursor before constructing a PlanExecutor, to prevent this scenario. Note this is not a problem for the find command (it makes a special check to ensure that the shard version hasn't changed during PlanExecutor construction), but it is for other callers of getExecutor, such as the aggregation framework.



 Comments   
Comment by David Storch [ 26/Jul/19 ]

Closing as Won't Do. I don't think the problem described here can happen anymore, since the construction of ClientCursor objects no longer prevent the RangeDeleter from cleaning up migrated documents. Instead, the PlanExecutor has a shard filtering stage which holds a ScopedCollectionMetadata for this purpose:

https://github.com/mongodb/mongo/blob/579aee2ca8affcecf38399e4831933dd2df7c67e/src/mongo/db/exec/shard_filter.h#L75

This obviates the need for pre-registration of a ClientCursor without a PlanExecutor, as suggested by this ticket.

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