This change has broken the following test case (reduced from actual
production code):
CREATE OR REPLACE PROCEDURE prc_inout_test_inner(INOUT x integer)
LANGUAGE plpgsql
AS
$procedure$
BEGIN
COMMIT;
x := 2;
END;
$procedure$;
CREATE OR REPLACE PROCEDURE prc_inout_test_main()
LANGUAGE plpgsql
AS
$procedure$
DECLARE
y INTEGER := 1;
BEGIN
CALL prc_inout_test_inner(y);
END;
$procedure$;
CALL prc_inout_test_main();
With the patch, it fails like this:
ERROR: XX000: unsupported target type: 0
CONTEXT: PL/pgSQL function prc_inout_test_main() line 5 at CALL
LOCATION: exec_move_row_from_fields, pl_exec.c:7196
On 2020-09-29 17:18, Tom Lane wrote:
> Fix memory leak in plpgsql's CALL processing.
>
> When executing a CALL or DO in a non-atomic context (i.e., not inside
> a function or query), plpgsql creates a new plan each time through,
> as a rather hacky solution to some resource management issues. But
> it failed to free this plan until exit of the current procedure or DO
> block, resulting in serious memory bloat in procedures that called
> other procedures many times. Fix by remembering to free the plan,
> and by being more honest about restoring the previous state (otherwise,
> recursive procedure calls have a problem).
>
> There was also a smaller leak associated with recalculation of the
> "target" list of output variables. Fix that by using the statement-
> lifespan context to hold non-permanent values.
>
> Back-patch to v11 where procedures were introduced.
>
> Pavel Stehule and Tom Lane
>
> Discussion: https://postgr.es/m/CAFj8pRDiiU1dqym+_P4_GuTWm76knJu7z9opWayBJTC0nQGUUA@mail.gmail.com
>
> Branch
> ------
> master
>
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/a6b1f5365d58356b5d42829e9cd89a6c725d7a0a
>
> Modified Files
> --------------
> src/pl/plpgsql/src/pl_exec.c | 91 ++++++++++++++++++++++++++++++++++----------
> 1 file changed, 70 insertions(+), 21 deletions(-)
>
