Craig Ringer <cr...@2ndquadrant.com> writes: > On 22 July 2016 at 13:24, Craig Ringer <cr...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers