[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:
Related
related to SERVER-75107 Deadlock with oplog application and o... Closed
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 SERVER-65974 has removed the code that takes the GlobalLock. As a result it is now only trivially used to perform non-deadlockable actions. Closing as Gone Away

Generated at Thu Feb 08 06:30:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.