Neil Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
