[SERVER-61788] Determine if we can avoid global lock upgrade in dbtest StorageTimestampTest Created: 29/Nov/21  Updated: 29/Oct/23  Resolved: 20/May/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Task Priority: Major - P3
Reporter: Dan Larkin-York Assignee: Yujin Kang Park
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File backtrace.log    
Issue Links:
Depends
is depended on by SERVER-60621 Investigate if we can ban upgrading t... Closed
Related
related to SERVER-66609 Avoid global lock upgrade in storage_... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2022-05-30
Participants:

 Description   

Currently in SecondaryInsertTimes::run(), we take the global lock in IX mode via AutoGetCollection, then later in applyOps, we upgrade the global lock to X mode via Lock::GlobalWrite. Given that it's just the test construct, this probably isn't a real problem, but we are working to ban upgrading the global lock in SERVER-60621, and this test fails as a result.



 Comments   
Comment by Githook User [ 20/May/22 ]

Author:

{'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}

Message: SERVER-61788: Take global write lock in SecondaryInsertTimes to avoid lock upgrade in applyOps
Branch: master
https://github.com/mongodb/mongo/commit/7117730842303f518a50e394b05b2b935bdd24b7

Generated at Thu Feb 08 05:53:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.