[SERVER-48499] Biggie record store hides uncommitted oplog entries from wuow that added them Created: 29/May/20  Updated: 29/Oct/23  Resolved: 05/Jun/20

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

Type: Bug Priority: Major - P3
Reporter: Henrik Edin Assignee: Henrik Edin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2020-06-15
Participants:

 Comments   
Comment by Githook User [ 05/Jun/20 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-48499 Biggie cursor cleanup, store reference to record store instead of copying several of its members
Branch: master
https://github.com/mongodb/mongo/commit/b8f0f575c5f75975291f742abca0b9eb182d1075

Comment by Githook User [ 05/Jun/20 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-48499 Biggie reverse cursors should not hide oplog entries
Branch: master
https://github.com/mongodb/mongo/commit/50a77a9d5ce58047bf521c9fb7db65cfc4c1f356

Comment by Daniel Gottlieb (Inactive) [ 01/Jun/20 ]

Ahh, this doesn't use a forward scanning cursor so "oplog visibility" rules don't apply. I suspect a forward scanning cursor in WT couldn't see the entries. That's implemented at a different layer (for reasons).

Comment by Henrik Edin [ 01/Jun/20 ]

I discovered it when enabling unittests to run with this storage engine. We are in a multi-document transaction so I think it would work fine with WT.

https://github.com/mongodb/mongo/blob/82fd62e031f46a2c0e919f512df70c4de0b0d151/src/mongo/db/op_observer_impl_test.cpp#L2282

Comment by Daniel Gottlieb (Inactive) [ 30/May/20 ]

Is there an associated test failure with this? I'm curious if you observed a symptom that was caused by this.

I agree reading ones own writes is important, but I'm unsure if our WT implementation does this outside some specific circumstances. I would expect something that tries writing to the oplog and then reading from the oplog in the same transaction would fail this invariant.

Generated at Thu Feb 08 05:17:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.