[SERVER-47749] The JournalFlusher should use a WRITE_CONFLICT_RETRY_ONLY YieldPolicy for its oplog read operation Created: 24/Apr/20 Updated: 29/Oct/23 Resolved: 24/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Execution Team 2020-05-04 | ||||
| Participants: | |||||
| Linked BF Score: | 23 | ||||
| Description |
|
The JournalFlusher can hit an EBUSY error while trying to open a WT cursor when the validate cmd is doing WT_SESSION::verify on the same collection, local.oplog.rs. Per this WT documentation, https://source.wiredtiger.com/3.1.0/error_handling.html, indicating that WT_SESSION::verify can run into EBUSY if unable to gain exclusive access, and apparently vice versa for trying to open a cursor while WT_SESSION::verify is running. Our query code will normally turn WCEs into yields, here, but the JournalFlusher is using an query execution plan explicitly with the NO_YIELD setting here. The WRITE_CONFLICT_RETRY_ONLY policy indicates that it will retry on WriteConflictExceptions without releasing locks. It is not desirable to yield locks for the JournalFlusher's oplog query per this comment on the JournalFlusher's lock acquisitions. |
| Comments |
| Comment by Githook User [ 24/Apr/20 ] |
|
Author: {'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}Message: |