[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: |
|
||||||||||||
| 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: |
| Comment by Eric Milkie [ 13/May/19 ] |
|
For the curious, it looks like it was me |
| 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 |