Skip to content

[DocDB][Advisory Locks] Advisory locks queries in active sessions don't fail after database deletion when those queries are already executed before db deletion #26500

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

Open
1 task done
shishir2001-yb opened this issue Mar 23, 2025 · 0 comments
Assignees
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/medium Medium priority issue qa_itest-system Bugs identified in itest-system automation QA QA filed bugs

Comments

@shishir2001-yb
Copy link
Member

shishir2001-yb commented Mar 23, 2025

Jira Link: DB-15866

Description

Version: 2.25.2.0.0-b151

If a database is deleted by a session while other sessions are still connected, all queries from those sessions should fail with the following error:

ERROR: catalog version for database <db_oid> was not found.
HINT: Database might have been dropped by another user

However, this doesn't seem to be the case if an advisory lock query has already been executed in the session. The session appears to continue executing queries without triggering the expected failure.

Session 1                                                     Session 2
                                                               yugabyte=# \c some_db


                                                               some_db=# SELECT pg_advisory_lock(1);

                                                               pg_advisory_lock 
                                                              ------------------
 
                                                              (1 row)


                                                               some_db=# SELECT pg_advisory_unlock(1);
                                                                pg_advisory_unlock 
                                                               --------------------
                                                                t
                                                               (1 row)
                                                              
yugabyte=# drop some_db;

               
                                                              some_db=# SELECT pg_advisory_lock(1); ----------> This query should fail but gets executed

                                                               pg_advisory_lock 
                                                              ------------------
 
                                                              (1 row)


                                                              some_db=# SELECT pg_advisory_unlock(1);----------> This query should fail but gets executed
                                                               pg_advisory_unlock 
                                                              --------------------
                                                               t
                                                              (1 row)     




                                                              some_db=# SELECT pg_advisory_lock_shared(1);-->This query was not executed before drop db hence it doesn't executed and fails
                                                              ERROR:  catalog version for database 16391 was not found.
                                                              HINT:  Database might have been dropped by another user


Issue Type

kind/bug

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

  • I confirm this issue does not contain any sensitive information.
@shishir2001-yb shishir2001-yb added area/docdb YugabyteDB core features QA QA filed bugs qa_itest-system Bugs identified in itest-system automation status/awaiting-triage Issue awaiting triage labels Mar 23, 2025
@yugabyte-ci yugabyte-ci added kind/bug This issue is a bug priority/medium Medium priority issue labels Mar 23, 2025
@yugabyte-ci yugabyte-ci removed the status/awaiting-triage Issue awaiting triage label Mar 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/medium Medium priority issue qa_itest-system Bugs identified in itest-system automation QA QA filed bugs
Projects
None yet
Development

No branches or pull requests

4 participants