]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix memory leak in plpgsql's CALL processing.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 29 Sep 2020 15:18:31 +0000 (11:18 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 29 Sep 2020 15:18:31 +0000 (11:18 -0400)
commitc1e044bb30f26edf54b7d5f668d18b69a0bb3ea6
treeca18c9fe9284a1fed6f6fc8a551ccea8e51eaa2a
parent4d342b9d41533df94b1b637d814333a716ec1050
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
src/pl/plpgsql/src/pl_exec.c