Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[DocDB] Advisory lock: Integrate session level advisory locks with wait-queues and deadlock detection #24710

Closed
Tracked by #3642
, #24709
...
yugabyte-ci opened this issue Oct 29, 2024 · 0 comments
Closed
Tracked by #3642
, #24709
...

[DocDB] Advisory lock: Integrate session level advisory locks with wait-queues and deadlock detection #24710

yugabyte-ci opened this issue Oct 29, 2024 · 0 comments
Assignees
@basavaraj29
Labels
area/docdb YugabyteDB core features jira-originated kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue

Comments

@yugabyte-ci
Copy link
Contributor

yugabyte-ci commented Oct 29, 2024 •
edited by rthallamko3
Loading

Jira Link: DB-13786

Using the session level transaction introduced by #24711 and integrate with wait queues (to get the conflict detection and deadlock detection across session level advisory locks).
@yugabyte-ci yugabyte-ci added area/docdb YugabyteDB core features jira-originated kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage labels Oct 29, 2024
@yugabyte-ci yugabyte-ci removed the status/awaiting-triage Issue awaiting triage label Oct 29, 2024
@rthallamko3 rthallamko3 mentioned this issue Oct 29, 2024
Open
18 tasks
@rthallamko3 rthallamko3 changed the title [DocDB] Advisory lock: Deadlock Detection [DocDB] Advisory lock: Deadlock Detection mechanism spanning session level advisory locks Oct 29, 2024
@rthallamko3 rthallamko3 assigned basavaraj29 and unassigned Huqicheng Dec 10, 2024
This was referenced Dec 10, 2024
Closed
Open
@rthallamko3 rthallamko3 mentioned this issue Jan 9, 2025
Closed
1 task
@rthallamko3 rthallamko3 changed the title [DocDB] Advisory lock: Deadlock Detection mechanism spanning session level advisory locks [DocDB] Advisory lock: Deadlock Detection mechanism across session level advisory locks Jan 9, 2025
@rthallamko3 rthallamko3 changed the title [DocDB] Advisory lock: Deadlock Detection mechanism across session level advisory locks [DocDB] Advisory lock: Deadlock detection mechanism across session level advisory locks Jan 9, 2025
@rthallamko3 rthallamko3 changed the title [DocDB] Advisory lock: Deadlock detection mechanism across session level advisory locks [DocDB] Advisory lock: Integrate session level advisory locks with wait-queues and deadlock detection Jan 9, 2025
basavaraj29 added a commit that referenced this issue Jan 10, 2025
@basavaraj29
[#24710] DocDB: Deadlock detection for session advisory locks
e3b6761 
Summary:
https://phorge.dev.yugabyte.com/D40932 introduced a session level docdb transaction that is created and is alive for the duration of the pg session when dealing with session advisory locks.

This diff contains the changes necessary for detecting deadlock cycles containing session advisory lock requests. In brief,
1. Each session level transaction maintains a `uint64_t pg_session_req_version_` at the transaction coordinator, which gets initialized on the first transaction heartbeat from client/transaction.cc
2. Each write rpc corresponding to a session adv lock request caries `pg_session_req_version_` as part of the op metadata, and is passed on to the wait-queue.
3. When a deadlock cycle is detected and consists of session level transactions alone, we process an UpdateTransaction operation essentially incrementing `pg_session_req_version_` of each involved transaction.
4. The next transaction heartbeat errors since `pg_session_req_version` at client/transaction.cc is stale, and therefore updates the value at maintained `YBTransaction`
5. The wait-queue realizes that the op entered with req version as x, but the transaction status responses now have the active request version as x+1, and hence resumes the session adv lock waiter a message indicating potential deadlock.

Note:
1. In the regular case of row-level lock deadlock cycles, we abort the transaction. But session level transactions are different as we need only cancel the last statement introducing the deadlock, and hence shouldn't abort the transaction (essentially holding on to all previous session adv locks acquired so far, until the end of the session itself)
2. Changes required for detecting deadlock cycles spanning session advisory locks, transaction locks, and row level locks will be checked in as part of subsequent diffs.
Jira: DB-13786

**Upgrade/Downgrade safety**
Added new proto fields in a couple of messages which are always checked for existence before usage. The fields are relevant only for session advisory locks feature which is guarded by a preview auto flag.

Test Plan:
Jenkins

./yb_build.sh --cxx-test='TEST_F(PgAdvisoryLockTest, SessionAdvisoryLocksDeadlock) {'
./yb_build.sh --cxx-test='TEST_F(PgAdvisoryLockTest, SessionAdvisoryLockReleaseUnlocksWaiters) {'

Reviewers: yyan, esheng, rthallam

Reviewed By: esheng

Subscribers: yql, ybase

Differential Revision: https://phorge.dev.yugabyte.com/D41048
@rthallamko3 rthallamko3 mentioned this issue Jan 17, 2025
Closed
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@basavaraj29 basavaraj29

Labels
area/docdb YugabyteDB core features jira-originated kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@yugabyte-ci @basavaraj29 @Huqicheng