[SERVER-41090] remove noop oplog entry DB X lock acquisition Created: 10/May/19  Updated: 29/Oct/23  Resolved: 13/May/19

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: 4.1.12

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: prepare_locking
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-39372 Make secondary lock acquisition for D... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2019-05-20
Participants:
Linked BF Score: 13

 Description   

This lock seems unnecessary (and causes deadlocks), and at least should be acquired at a lower level if it's needed.

I think this is here from when noop and index build oplog entry application were together and index builds needed this lock (https://github.com/mongodb/mongo/commit/188fcbc3bf1ad7ff7f8114c33412fd9e27295c79). When those two code paths were separated noops inherited this lock as well to be safe.



 Comments   
Comment by Githook User [ 13/May/19 ]

Author:

{'name': 'Judah Schvimer', 'username': 'judahschvimer', 'email': 'judah@mongodb.com'}

Message: SERVER-41090 remove noop oplog entry DB X lock acquisition
Branch: master
https://github.com/mongodb/mongo/commit/1c15dffa313e6b2ab49284ad0d93c206e14cd054

Comment by Eric Milkie [ 13/May/19 ]

For the curious, it looks like it was me back in 2012:
https://github.com/mongodb/mongo/commit/bdded78e9f2ba6c703811a7e20e0b90adfc0d5b3#diff-04e89e83a90f31c93b1c3563db63c9c4R76

Comment by Eric Milkie [ 13/May/19 ]

I did some code archeology and this lock dates all the way back to when we first added DB level locking. It fell out of the code logic and was not originally intentional for no-ops specifically. Therefore, unless we can think of an assumption that a current use is making regarding this lock, I believe it's safe to remove.

Comment by Andy Schwerin [ 13/May/19 ]

I wonder if this was here to support metadata-stable backup of sharded clusters the way it worked in ops manager prior to 4.2? That's my only guess for why it could have been intentional. Not relevant for 4.2 or later, I think.

Edit the above can't be right, since that would have been a reason to lock on primary nodes, not secondary.

Comment by Randolph Tan [ 10/May/19 ]

judah.schvimer I don't think so. The secondaries should be doing nothing when "applying" the no-op oplog entries generated by retryable-writes.

Comment by Judah Schvimer [ 10/May/19 ]

benety.goh, do you have any insight into if this lock is required, since you authored the above commit?

renctan or jack.mulrow, do you know if retryable writes oplog application relies on this lock?

xiangyu.yao, did this come up at all in investigating SERVER-39372?

Generated at Thu Feb 08 04:56:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.