[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: |
| Comment by Githook User [ 05/Jun/20 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: |
| 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. |
| 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. |