Re: pgsql: Fix memory leak in plpgsql's CALL processing.

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(-)
>