On Thu, 19 Sep 2002, Tom Lane wrote:
> "Ian Harding" <ianh@tpchd.org> writes:
> > It is pltcl [not plpgsql]
>
> Ah. I don't think we've done much of any work on plugging leaks in
> pltcl :-(.
>
> > It hurts when I do this:
>
> > drop function memleak();
> > create function memleak() returns int as '
> > for {set counter 1} {$counter < 100000} {incr counter} {
> > set sql "select ''foo''"
> > spi_exec "$sql"
> > }
> > ' language 'pltcl';
> > select memleak();
>
> Yeah, I see very quick memory exhaustion also :-(. Looks like the
> spi_exec call is the culprit, but I'm not sure exactly why ...
> anyone have time to look at this?
Attached is a patch that frees the SPI_tuptable in all post SPI_exec
non-elog paths in both pltcl_SPI_exec() and pltcl_SPI_execp().
The fault as triggered by the above code has been fixed by this patch but
please read my assumptions below to ensure they are correct.
I have assumed that Tom's comment about this only being required in non-elog
paths is correct, which seems a reasonable assumption to me.
I have also assumed, rather than verified, that freeing the tuptable does
indeed free the tuples as well. Tests with the above function show that the
process does not increase it's memory footprint during it's operation, although
if my assumption here is wrong this could be a feature of selecting
insignificantly sized tuples.
I have not worried about other uses of SPI_exec for selects in pltcl.c on the
basis that those are not under the control of the function writer and the
normal function management will release the storage.
--
Nigel J. Andrews
