Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Unresolved
Priority: Major - P3
Fix Version/s: None
Affects Version/s: None
Component/s: None
Labels:
None

Assigned Teams:

Query Execution
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

If users have specified a batch size and the number of the documents in the final batch exactly matches the number of documents, returned by a cursor, we are left with a cursor that will return EOF next time it is called.

An example of this happening would be if find command have a limit and an equal batchSize.

Calling getNext() on a PlanExecutor can cause an unbounded amount of work to happen, so the suggested solution is to use PlanExecutor::isEOF() that should be O(1) check.

Additionally, we need to ensure that PlanExecutorPipeline and PlanExecutorSBE::isEOF() return `true` if a limit has been reached.

depends on

SERVER-111689 On router, close the cursor when it is obvious that there is no more documents

Needs Scheduling

is duplicated by

SERVER-108846 Cursors remain open when batchSize equals limit with in-memory sort

Closed

is related to

SERVER-57067 [SBE] Find command unexpectedly returns cursorId when final batch size aligns with result set size

Closed

SERVER-80713 ID on exhausted cursor no longer 0

Closed

SERVER-83077 Check one getNext beyond batchSize for EOF so we only return a cursor if there are more results

Closed

related to

SERVER-108846 Cursors remain open when batchSize equals limit with in-memory sort

Closed

(1 related to)

Assignee:: Ivan Fefer
Reporter:: Ivan Fefer
Participants:: Ivan Fefer
Votes:: 0 Vote for this issue
Watchers:: 9 Start watching this issue

Created:: Nov 04 2024 03:13:05 PM UTC
Updated:: Sep 30 2025 01:25:30 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates