Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 9 Apr 2009 02:57:53 +0000 (02:57 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 9 Apr 2009 02:57:53 +0000 (02:57 +0000)
commitf0a2b4fda6938e50c9873e8fb32a4fbfc281042d
tree5d12b9b578b2002010dd7d981f01a22e89132156
parenta0586ac306e22577d67bdf8bdb5226e36decbef1
Fix the plpgsql memory leak exhibited in bug #4677.  That leak was introduced
by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates:
since we re-prepared any expression tree when the current subtransaction ID
changed, we'd accumulate more and more leaked expression state trees in the
outermost subtransaction if the same function was executed at multiple levels
of subtransaction nesting.  To fix, go back to the previous scheme where
there was only one EState per transaction for simple plpgsql expressions.
We really only need an ExprContext per subtransaction, not a whole EState,
so it's possible to keep prepared expression state trees in the one EState
throughout the transaction.  This should be more efficient as well as not
leaking memory for cases involving lots of subtransactions.

The added regression test is the case that inspired the 2007-01-28 patch in
the first place, just to make sure we didn't go backwards.  The current
memory leak complaint is unfortunately hard to test for in the regression
test framework, though manual testing shows it's fixed.

Although this is a pre-existing bug, I'm not back-patching because I'd like to
see this method get some field testing first.  Consider back-patching if it
gets through 8.4beta unscathed.
src/pl/plpgsql/src/pl_exec.c
src/pl/plpgsql/src/plpgsql.h
src/test/regress/expected/plpgsql.out
src/test/regress/sql/plpgsql.sql