Subject: Re: pgsql: Fix memory leak in plpgsql's CALL processing.
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
References: <E1kNHOx-0003xj-TX@gemulon.postgresql.org>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Organization: EnterpriseDB
Message-ID: <f075f7be-c654-9aa8-3ffc-e9214622f02a@enterprisedb.com>
Date: Mon, 28 Dec 2020 10:47:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <E1kNHOx-0003xj-TX@gemulon.postgresql.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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