plpgsql: do not drop a CALL statement with unused OUT params #143173
Conversation
DrewKimball
added
backport-24.1.x
|
This change is |
There was a problem hiding this comment.
Nice find!
Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball)
-- commits line 7 at r1:
Roughly speaking, only "volatile" functions can have side effects, and that's why we need to ensure their invocations don't get optimized away via the barrier, right?
pkg/ccl/logictestccl/testdata/logic_test/plpgsql_call line 484 at r1 (raw file):
SELECT * FROM xy; ----
nit: this shouldn't be empty now 😃
This commit fixes a bug that could cause the routine invocation for a PL/pgSQL CALL statement to be dropped if the stored proc had out params that were all unused by the calling routine. The fix is simple - just add an optimization barrier if the called procedure is volatile (and may have side effects). Fixes cockroachdb#143171 Release note (bug fix): Fixed a bug existing since PL/pgSQL CALL statements were introduced in v24.1, where the called procedure could be dropped if it had OUT parameters that were not used by the calling routine.
There was a problem hiding this comment.
TFYR!
Reviewable status:
Previously, yuzefovich (Yahor Yuzefovich) wrote…
Roughly speaking, only "volatile" functions can have side effects, and that's why we need to ensure their invocations don't get optimized away via the barrier, right?
Yes, exactly. I added a bit to the commit message.
pkg/ccl/logictestccl/testdata/logic_test/plpgsql_call line 484 at r1 (raw file):
Previously, yuzefovich (Yahor Yuzefovich) wrote…
nit: this shouldn't be empty now 😃
Done.
This commit fixes a bug that could cause the routine invocation for a PL/pgSQL CALL statement to be dropped if the stored proc had out params that were all unused by the calling routine. The fix is simple - just add an optimization barrier if the called procedure is volatile.
Fixes #143171
Release note (bug fix): Fixed a bug existing since PL/pgSQL CALL statements were introduced in v24.1, where the called procedure could be dropped if it had OUT parameters that were not used by the calling routine.