Re: Memory leak in vac_update_relstats ?

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Personally I've been thinking of mounting an effort to get rid of
> unnecessary pfree's wherever possible. Particularly in user-defined
> functions, "cleaning up" at the end is a waste of code space and
> cycles too, because they're typically called in contexts that are
> going to be reset immediately afterward.

It seems like the impact of this is self-limiting though. The worst-case is
going to be something which executes an extra pfree for every tuple. Or
perhaps one for every expression in a complex query involving lots of
expressions. Saving a few extra pfrees per tuple isn't really going to buy
many cpu cycles.

> In the case of vac_update_relstats, it's called only once per
> transaction, so there's certainly no point in being a neatnik.
> Stuff you need to worry about is functions that might be called
> many times in the same memory context.

Fwiw there are user-space functions that can't leak memory. I'm sure everyone
knows about btree operators, but pgsql also assumes that type input and output
functions don't leak memory too (or else assignment leaks memory in the
function scope memory context and in a loop...).

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com