-
Notifications
You must be signed in to change notification settings - Fork 4k
plpgsql: move barrier after outer-join for SQL stmt with INTO clause #156966
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
Conversation
PL/pgSQL routines use barrier expressions to prevent optimizations that would remove side effecting expressions from the query plan. Previously, we would add a barrier below the outer join used to ensure at least one row returned by a SQL statement with an INTO clause. However, this wasn't enough, since after some inlining and projection push-down into the join, the join could be eliminated. This could result in a side-effecting SQL statement being dropped if its target variable(s) weren't referenced. This commit fixes the bug by moving the barrier above the outer-join. This prevents optimizations (like join elimination) that rely on proving that the columns from the null-extended side of the join are not needed. Fixes cockroachdb#147269 Release note (bug fix): Fixed a bug existing since SQL statements with INTO clause were introduced for PL/pgSQL routines in v23.2. The bug could cause a SQL statement with side effects (e.g. INSERT) to be dropped if none of the target variables from the INTO clause were referenced.
yuzefovich
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice find! Worth backporting perhaps all the way to 24.1?
@yuzefovich reviewed 4 of 4 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @mw5h)
mgartner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mgartner reviewed 4 of 4 files at r1, all commit messages.
Reviewable status:complete! 2 of 0 LGTMs obtained (waiting on @mw5h)
michae2
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michae2 reviewed 4 of 4 files at r1, all commit messages.
Reviewable status:complete! 3 of 0 LGTMs obtained (waiting on @mw5h)
mw5h
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mw5h reviewed all commit messages.
Reviewable status:complete! 3 of 0 LGTMs obtained (waiting on @DrewKimball)
|
TFTRs! bors r+ |
156966: plpgsql: move barrier after outer-join for SQL stmt with INTO clause r=DrewKimball a=DrewKimball PL/pgSQL routines use barrier expressions to prevent optimizations that would remove side effecting expressions from the query plan. Previously, we would add a barrier below the outer join used to ensure at least one row returned by a SQL statement with an INTO clause. However, this wasn't enough, since after some inlining and projection push-down into the join, the join could be eliminated. This could result in a side-effecting SQL statement being dropped if its target variable(s) weren't referenced. This commit fixes the bug by moving the barrier above the outer-join. This prevents optimizations (like join elimination) that rely on proving that the columns from the null-extended side of the join are not needed. Fixes #147269 Release note (bug fix): Fixed a bug existing since SQL statements with INTO clause were introduced for PL/pgSQL routines in v23.2. The bug could cause a SQL statement with side effects (e.g. INSERT) to be dropped if none of the target variables from the INTO clause were referenced. Co-authored-by: Drew Kimball <drewk@cockroachlabs.com>
|
Build failed: |
|
Looks like a flake. bors retry |
|
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. 💡 Consider backporting to the fork repo instead of the main repo. See instructions for more details. error creating merge commit from b706af5 to blathers/backport-release-24.3-156966: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch release-24.3 failed. See errors above. 💡 Consider backporting to the fork repo instead of the main repo. See instructions for more details. 💡 Consider backporting to the fork repo instead of the main repo. See instructions for more details. 💡 Consider backporting to the fork repo instead of the main repo. See instructions for more details. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
PL/pgSQL routines use barrier expressions to prevent optimizations that would remove side effecting expressions from the query plan. Previously, we would add a barrier below the outer join used to ensure at least one row returned by a SQL statement with an INTO clause. However, this wasn't enough, since after some inlining and projection push-down into the join, the join could be eliminated. This could result in a side-effecting SQL statement being dropped if its target variable(s) weren't referenced.
This commit fixes the bug by moving the barrier above the outer-join. This prevents optimizations (like join elimination) that rely on proving that the columns from the null-extended side of the join are not needed.
Fixes #147269
Release note (bug fix): Fixed a bug existing since SQL statements with INTO clause were introduced for PL/pgSQL routines in v23.2. The bug could cause a SQL statement with side effects (e.g. INSERT) to be dropped if none of the target variables from the INTO clause were referenced.