Re: Curing plpgsql's memory leaks for statement-lifespan values

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 22 July 2016 at 13:24, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> I suggest that in cassert builds, or maybe just CACHE_CLOBBER_ALWAYS, the
>> context is reset after each call even when not cleaning up after an error.
>> That'll help catch mistakes and leaks.

> That is, after each statement.

Well, the issue is with nested statements: if some outer statement has
data in such a context, you can't just clobber it because of a failure in
an inner statement. To make that work, you need a new context for each
nesting level. Once we've gone to that much trouble, I'm inclined to
think we should just do the resets always (ie, not only in debug builds).
That will let us get rid of retail pfree's and buy back at least some of
the added cost.

I've not done any detail work on this idea yet, but at least some of
plpgsql's loop control statements don't have any pass-by-ref local data;
exec_stmt_fori, for example. So it seems possible for that function not
to bother with creating a new context for its child statements. That
would save some more cycles, at the cost of a possibly-confusing-and-
fragile difference in the way different kinds of loops work.

In any case, I'm thinking this is too invasive, relative to its value,
for a back-patch; but it might be okay to sneak it into beta4 if I can
get it done soon. Or we could let it slide till 9.7^H^H^H10. Comments?

regards, tom lane