[SERVER-36354] Show outstanding locks acquired by secondary oplog application in CurrentOp Created: 30/Jul/18  Updated: 27/Oct/23  Resolved: 08/Oct/18

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

Type: Improvement Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   

This was a request that came out of the design for "Prepare Support for Transactions" that will become increasingly useful when locks are held longer on secondaries.



 Comments   
Comment by Gregory McKeon (Inactive) [ 08/Oct/18 ]

In the current design, you will now be able to view locks held by prepared transactions by running currentOp on a secondary, this has gone away.

Comment by Judah Schvimer [ 31/Jul/18 ]

After talking to milkie, this does not impact prepared transactions on secondaries as tess.avitabile explained. This would still be good for generalizing to all lock holders.

Comment by Eric Milkie [ 30/Jul/18 ]

Currently, the currentOp command loops through all Clients with associated CurOp structures, and then it also scans through all idle Sessions, to find all lock holders. Secondary oplog application threads do not use a Client and therefore do not appear in the currentOp list, even though such threads may hold locks.

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