[SERVER-32388] Invariant if oplog visibility wait is called while holding a lock that blocks oplog writes Created: 18/Dec/17  Updated: 06/Dec/22  Resolved: 05/Jan/18

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

Type: Improvement Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Storage Execution
Participants:

 Comments   
Comment by Ian Whalen (Inactive) [ 05/Jan/18 ]

Closing as per Eric's comment.

Comment by Eric Milkie [ 19/Dec/17 ]

I'm not sure if this will be useful. It sounds like this check boils down to "ensure that dblocks work", which is an odd thing to check in this particular area of the code.
Note that in order for oplog visibility wait to actually block, there needs to be an oplog hole. For there to be an oplog hole, there needs to be an in-progress transaction. For there to be an in-progress transaction, a dblock must be held by that transaction. For a dblock to be held by that transaction, it is impossible for another thread to hold an incompatible dblock and also be in the oplog visibility wait call. QED.

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