-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
plpgsql: nested blocks are unaware of each other's cursors #121078
Labels
branch-master
Failures and bugs on the master branch.
branch-release-24.1
Used to mark GA and release blockers, technical advisories, and bugs for 24.1
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
GA-blocker
T-sql-queries
SQL Queries Team
Comments
DrewKimball
added
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
GA-blocker
T-sql-queries
SQL Queries Team
24.1
labels
Mar 25, 2024
Hi @DrewKimball, please add branch-* labels to identify which branch(es) this GA-blocker affects. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
michae2
added
the
branch-release-24.1
Used to mark GA and release blockers, technical advisories, and bugs for 24.1
label
Apr 9, 2024
[triage] consequence would be a cursor staying open that should be closed. @DrewKimball to either remove GA-blocker or fix |
craig bot
pushed a commit
that referenced
this issue
Apr 16, 2024
122321: plpgsql: fix exception handling for nested blocks r=DrewKimball a=DrewKimball #### plpgsql: prevent inlining for block-exit continuation This commit prevents inlining for the continuation that transitions out of a PL/pgSQL block with an exception handler. This is necessary to ensure that the statements following the nested block are considered part of the parent block, not the nested block. Otherwise, an error thrown after the nested block might still be caught by the nested block's exception handler, which is incorrect behavior. #### plpgsql: keep track of the subroutine that begins a PL/pgSQL block This commit adds logic to keep track of the PL/pgSQL sub-routine that logically transitions into a PL/pgSQL block with an exception handler. This is necessary to ensure that the state shared between sub-routines within the same block is correctly initialized. Previously, the block state was only initialized once, but this is incorrect for loops, which need to re-initialize the state on each iteration. #### plpgsql: roll back all cursors within a block that handles an exception This commit fixes handling for cursors opened within the scope of a block with an exception handler that has nested blocks or nested routine calls. Previously, if a PL/pgSQL block caught an exception, only the cursors opened directly by that block would be rolled back. Any cursors opened by a nested block or routine call would remain open. Now, the block state tracks the timestamp when the block's execution began. Once an exception is caught, all cursors with a timestamp later than the block's start are rolled back. Fixes #122278 Fixes #121078 Release note: None Co-authored-by: Drew Kimball <[email protected]>
blathers-crl bot
pushed a commit
that referenced
this issue
Apr 16, 2024
This commit fixes handling for cursors opened within the scope of a block with an exception handler that has nested blocks or nested routine calls. Previously, if a PL/pgSQL block caught an exception, only the cursors opened directly by that block would be rolled back. Any cursors opened by a nested block or routine call would remain open. Now, the block state tracks the timestamp when the block's execution began. Once an exception is caught, all cursors with a timestamp later than the block's start are rolled back. Fixes #121078 Release note: None
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
branch-master
Failures and bugs on the master branch.
branch-release-24.1
Used to mark GA and release blockers, technical advisories, and bugs for 24.1
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
GA-blocker
T-sql-queries
SQL Queries Team
A PL/pgSQL block has to be aware of all cursors created within its scope, including those created within nested blocks. Currently, this is not the case, as demonstrated in the following logic test:
Both cursors in the
f(1)
case should have been closed due to the exception, and yet one remains open.Jira issue: CRDB-37056
The text was updated successfully, but these errors were encountered: