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.

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

[YSQL] No results are returned for yb_lock_status() when UPDATE lock is waiting for another lock #18149

Closed
1 task done
Karvy-yb opened this issue Jul 10, 2023 · 1 comment
Closed
1 task done
Assignees
Labels
area/ysql Yugabyte SQL (YSQL) blocks_automation Issues marked with this label are blocking QA automation and need developer attention asap. kind/bug This issue is a bug priority/high High Priority QA QA filed bugs

Comments

@Karvy-yb
Copy link

Karvy-yb commented Jul 10, 2023

Jira Link: DB-7189

Description

Steps to repro:

1. Create universe with enable_wait_queues, enable_deadlock_detection and enable_pg_locks flags. (Created on custom build)
2. Create database
3. Connect to database
4. create table tb(k int primary key, v int);
5. insert into tb values (1,1), (2,2);
6. txn_1: begin; select * from tb where k=1 for update;
7. On 2nd session: select * from yb_lock_status();
8. Notice that results are returned
9. On another session: update tb set v=11 where k=1; (This will wait for txn_1)
10. On 2nd session: select * from yb_lock_status();
11. Notice that no rows are returned

The issue is only observed when UPDATE lock is waiting for another lock (be it in fastpath or begin/commit transaction)

Warning: Please confirm that this issue does not contain any sensitive information

  • I confirm this issue does not contain any sensitive information.
@Karvy-yb Karvy-yb added kind/bug This issue is a bug area/ysql Yugabyte SQL (YSQL) priority/high High Priority QA QA filed bugs status/awaiting-triage Issue awaiting triage blocks_automation Issues marked with this label are blocking QA automation and need developer attention asap. labels Jul 10, 2023
@yugabyte-ci yugabyte-ci removed the status/awaiting-triage Issue awaiting triage label Jul 10, 2023
@basavaraj29
Copy link
Contributor

Tested it latest master + get lock status patch. I can see an error being returned.

yugabyte=# select * from yb_lock_status(null, null);
ERROR:  While decoding SubDocKey "G\x12\x10H\x80\x00\x00\x01!!J\x80!": Cannot decode value type kGroupEnd from the key encoding format: "!"

there seems to be an issue while decoding a few lock types at the wait-queue level. will look into it.

@basavaraj29 basavaraj29 added this to Needs Triage in Wait-Queue Based Locking via automation Jul 11, 2023
@basavaraj29 basavaraj29 moved this from Needs Triage to Tech-Preview (Due 7/21/23) in Wait-Queue Based Locking Jul 11, 2023
@robertsami robertsami moved this from Tech-Preview (Due 7/21/23) to In progress in Wait-Queue Based Locking Jul 19, 2023
basavaraj29 added a commit that referenced this issue Jul 21, 2023
…in wait-queue

Summary:
While forming locks, we strip `kGroupEnd` char in `DetermineKeysToLock` in docdb.cc. Previously, we used to always append `kGroupEnd` char to the subdockey prefix which lead to decoding error when the subdockey ended with a column id.

This diff addresses the issue by adding `kGroupEnd` only when `DocKey::EncodedSize` fails, i.e the key is partial and doesn't end with a column id.
Jira: DB-7189

Test Plan: ./yb_build.sh --cxx-test pgwrapper_pg_get_lock_status-test --gtest_filter PgGetLockStatusTest.TestWaiterLockContainingColumnId

Reviewers: rsami, tvesely

Reviewed By: rsami

Subscribers: yql, rthallam, ybase

Differential Revision: https://phorge.dev.yugabyte.com/D27042
Wait-Queue Based Locking automation moved this from In progress to Done Jul 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ysql Yugabyte SQL (YSQL) blocks_automation Issues marked with this label are blocking QA automation and need developer attention asap. kind/bug This issue is a bug priority/high High Priority QA QA filed bugs
Projects
Status: Done
Development

No branches or pull requests

7 participants