Re: SRF memory leaks

On Wed, 2008-02-27 at 15:07 -0500, Tom Lane wrote:
> Negative refcount does not prove that the SRF itself hasn't
> still got a pointer to the tupdesc.

That sounds quite bizarre. The SRF has already finished execution at
this point, so keeping a pointer to the tupledesc around would only make
sense if you wanted to use that tupledesc on a *subsequent* invocation
of the SRF. The SRF would need to store the pointer in a static
variable, too, and it wouldn't have an easy way to distinguish between
repeated calls to the SRF within the same query and in different queries
(since in the latter case the TupleDesc will be long gone anyway). I
can't see why anyone would want to do this.

> Can't we fix it so that the tupdesc is allocated in the new special
> context (at least in the primary code paths), and then no explicit
> free is needed?

As I said earlier, the tupdesc is explicitly allocated in the per-query
context by the SRFs themselves. If by "primary code paths", you mean
"SRFs in the main source tree", then sure, we can make arbitrary changes
to those. That won't help out-of-tree SRFs though.

-Neil