Re: Memory leaks on SRF rescan

Neil Conway <neilc(at)samurai(dot)com> writes:
> Two different classes of allocations in the EState's per-query context
> are leaked:

> (1) In FunctionNext(), we call ExecMakeTableFunctionResult() to compute
> the result set of the SRF, which allocates the TupleDesc out-parameter
> in the per-query memory context. Since rescan of a function scan (with
> chgParam != NULL) results in taking this code path again, we can leak 1
> TupleDesc for each rescan of a function scan. I think this is plainly a
> bug -- the first attached patch fixes it.

Given your point (2), is this worth fixing by itself?

> (2) In various SRFs, allocations are made in the "multi-call context"
> but are not released before calling SRF_RETURN_DONE.

Yeah. I think it's hopeless to expect these functions to all hew to
the straight and narrow path. It seems to me that the right way is for
the sub-select to somehow run in its own "per-query" context. Not sure
about the implications of that bit of arm-waving ... it might be a bit
tricky since I think we expect the executor state tree to get set up
only once.

regards, tom lane