[SERVER-13566] Using the OplogReplay flag with extra predicates can yield incorrect results Created: 13/Apr/14  Updated: 26/May/23  Resolved: 15/Apr/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.0
Fix Version/s: 2.6.1, 2.7.0

Type: Bug Priority: Critical - P2
Reporter: Steve Briskin (Inactive) Assignee: David Storch
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-29843 Make oplog queries with point equalit... Closed
is related to SERVER-13562 Queries that use tailable cursors do ... Closed
Operating System: ALL
Backport Completed:
Participants:
Linked BF Score: 35

 Description   
Issue Status as of April 17, 2014

ISSUE SUMMARY
The OplogReplay query flag is an internal optimization for queries on the oplog (and other capped collections) using the ts (timestamp) field. Version 2.6.0 introduced a bug whereby a query using the OplogReplay flag with additional predicates not on the ts field could return incorrect results.

USER IMPACT
Internally, replication issues queries with predicates only on the ts field, and thus is unaffected by the bug. Third-party tools or other user implementations to query or tail the oplog can break, if they use the query flag and have additional query predicates.

WORKAROUNDS
A query without the OplogReplay query flag would return correct results but may be less efficient as it would not employ the OplogReplay optimization.

RESOLUTION
The fix restores the behavior to ignore predicates on other fields when walking the collection backwards to find the earliest oplog entry that matches the query. This brings the behavior back in line with that of version 2.4.x. Additionally, validation was added to ensure that the predicate on ts is either $gt or $gte, as the OplogReplay optimization does not work with other operators.

AFFECTED VERSIONS
Version 2.6.0 was affected by this bug.

PATCHES
The patch is included in the 2.6.1 production release.

Original description

Querying the oplog on a 2.6.0 secondary with the oplog replay flag and another predicate in addition to "ts" gives incorrect results vs. a 2.4.8 primary.

The query returns correct results if "ts" is the only predicate in the find.

query: db.oplog.rs.find({ts : {$gte : Timestamp(1397347250,1)}, "o2._id" : ObjectId("52a41544e4b04cb2bcc59814")}).addOption(8).limit(1)

I do not have a 2.4 secondary to test this on now, but I've issued similar queries on 2.4 secondaries in the past and they returned correct results.



 Comments   
Comment by Githook User [ 15/Apr/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13566 oplog start stage uses only 'ts' field as a filter

(cherry picked from commit 29d7dcd55a761cfa6a1a7e1586b80f9d1083b4f4)
Branch: v2.6
https://github.com/mongodb/mongo/commit/12279052c851ae5a1ed43d98433ced9db7682d3a

Comment by Githook User [ 15/Apr/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13566 oplog start stage uses only 'ts' field as a filter
Branch: master
https://github.com/mongodb/mongo/commit/29d7dcd55a761cfa6a1a7e1586b80f9d1083b4f4

Comment by Eric Milkie [ 14/Apr/14 ]

I guess the question is, how can you define incorrect results when we don't define what Oplog_Replay query flag does?

Comment by Thomas Rueckstiess [ 13/Apr/14 ]

not sure if it's exactly the same issue but looks related. SERVER-13562 describes problems with tailable cursors on capped collections using .skip().

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