-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
Fully Compatible
-
v4.4, v4.2, v4.0, v3.6
-
Query 2020-08-24, Query 2020-09-07
-
(copied to CRM)
When determining whether a node's oplog has sufficient history to correctly resume a stream, we first try to retrieve the initial result from the resumed stream. This is because the result may be enough for us to determine that the stream is resumable, without doing any additional work. If the result does not conclusively prove that the stream is resumable, either because it is EOF or chronologically after the resume point, then we must perform a separate, internal query on the oplog via _assertOplogHasEnoughHistory to determine whether its first entry is earlier than the resume point.
However, if there are no matching entries in the oplog and we supply a resume point that has already fallen off, our attempt to retrieve the first entry will scan through the entire oplog until it reaches EOF, only to then call _assertOplogHasEnoughHistory and throw an exception. If the oplog is large, then this pointless scan can be quite disruptive. We should instead unconditionally call _assertOplogHasEnoughHistory to check the oplog's history before attempting to pull the first result from the stream.
- is related to
-
SERVER-50903 No error when change stream's startAtOperationTime is not in oplog
- Closed
- related to
-
SERVER-49691 Change streams may be subject to spurious "CappedPositionLost" when resuming
- Closed
-
SERVER-49896 Allow aggregate command to fail if minTs oplog cursor has fallen off the oplog
- Closed
-
SERVER-50580 SBE should obey ASSERT_MIN_TS_HAS_NOT_FALLEN_OFF_OPLOG flag
- Closed