[SERVER-75435] Investigate scope of _oplogPinnedByBackupMutex in WiredTigerKVEngine::beginNonBlockingBackupCursor() Created: 29/Mar/23 Updated: 27/Oct/23 Resolved: 05/May/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Jordi Olivares Provencio |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Sprint: | Execution Team 2023-05-01, Execution Team 2023-05-15 | ||||||||
| Participants: | |||||||||
| Description |
|
The _oplogPinnedByBackupMutex is locked and held for the majority of WiredTigerKVEngine::beginNonBlockingBackup() The mutex is locked before the trying to acquire the PBWM lock. We've seen scenarios where minor changes to the oplog applier code path can introduce a deadlock where the oplog applier holds the PBWM lock while trying to check the oldest pinned timestamp. In general, we should try to limit the scope of this mutex, and evaluate if the scope can be reduced to improve code safety. |
| Comments |
| Comment by Jordi Olivares Provencio [ 05/May/23 ] |
|
It seems |