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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix memory leak in plpgsql's CALL processing.
Date: 2020-09-29 15:18:47
Message-ID: E1kNHOx-0003xj-TX@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-09-29 17:48:14 pgsql: Fix make_timestamp[tz] to accept negative years as meaning BC.
Previous Message Tom Lane 2020-09-29 13:29:18 Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-29 15:20:35 Re: calling procedures is slow and consumes extra much memory against calling function
Previous Message Dilip Kumar 2020-09-29 15:03:04 Re: Parallel INSERT (INTO ... SELECT ...)