Re: Memory Errors... - Mailing list pgsql-hackers

Ok, below is the original email I sent, which I can not remember seeing come
across the patches list. Please do read the assumptions since they might throw
up problems with what I have done.

I have attached the pltcl patch again, just in case. For the sake of clarity
let's say this patch superscedes the previous one.

I have also attached a patch addressing the similar memory leak problem in
plpython. This includes a slight adjustment of the tests in the source
directory. The patch also includes a cosmetic change to remove a compiler
warning although I think the change makes the code look worse though.

Once again, please read my text below and also take a quick look at the comment
I've added in the plpython patch since it may well show that that
particular change is complete rubbish.

BTW, by my reckoning the memory leak would occur with prepared plans and
without. If that is not the case then I've been barking up the wrong tree.

Of further note, I have not tested for the memory leak in plpython but the
build passes the normal and big checks. However, I have tried testing using the
test.sh script in src/pl/plpython. This seems to be generating errors where
before there were warnings. Can anyone comment on the correctness of this?
Reversing my changes doesn't really help matters so I presume it is something
else that is causing the different behaviour.


--
Nigel J. Andrews


On Fri, 20 Sep 2002, Nigel J. Andrews wrote:

> 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.