[SERVER-34590] oplog visibility issues with round_to_oldest Created: 20/Apr/18 Updated: 29/Oct/23 Resolved: 27/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage, WiredTiger |
| Affects Version/s: | 3.7.5 |
| Fix Version/s: | 4.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | nyc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Storage NYC 2018-05-07 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 72 | ||||||||||||||||||||
| Description |
|
A frequent build failure has been identified since When The current belief is that the previous synchronization in WiredTigerSnapshotManager preventing opening transactions concurrently was removed. However, this change should be correct without data inconsistency issues. Now that the synchronization for opening transactions on the oplog is gone, we believe there is a latent bug exposed that is preventing this concurrent behavior of opening transactions and then subsequently setting a read timestamp on them. The diff I believe is responsible for this failure:
|
| Comments |
| Comment by Daniel Gottlieb (Inactive) [ 27/Apr/18 ] |
|
This was fixed in the WT drop including |
| Comment by Eric Milkie [ 25/Apr/18 ] |
|
An amendment to my previous comment: It turns out that WiredTiger actually does reset the snapshot on a transaction when setting a read timestamp. The bug is that for round_to_oldest, it is doing the rounding after it sets the snapshot the second time. The fix may be to ensure the rounding occurs prior to setting the snapshot. I filed |
| Comment by Eric Milkie [ 24/Apr/18 ] |
|
I think I figured this out. The problem is that begin_transaction() establishes the snapshot isolation that affects what is visible to the transaction. Later on, a call to timestamp_transaction() adds a read timestamp to the session, which further affects visibility. At the point where timestamp_transaction() runs, there is an ability to change the read timestamp from what was provided to what the current, in-the-moment oldest_timestamp value is ("round_to_oldest" behavior). This is the problematic behavior. I believe round_to_oldest would also be broken when setting the read timestamp inside begin_transaction() itself, but the race window would be a lot smaller. It sounds like using round_to_oldest as currently implemented is not possible, unless we can move its oldest-timestamp-observing behavior to occur before the snapshot isolation is set up for the transaction. |