Re: [HACKERS] [GENERAL] Memory Errors...

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Re: [HACKERS] [GENERAL] Memory Errors...
Date: 2002-09-20 11:38:42
Message-ID: Pine.LNX.4.21.0209201226330.599-200000@ponder.fairway2k.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Thu, 19 Sep 2002, Tom Lane wrote:

> "Ian Harding" <ianh(at)tpchd(dot)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

Attachment Content-Type Size
pltcl.patch text/plain 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ricardo Fogliati 2002-09-20 12:08:51 SCSI Error
Previous Message Curt Sampson 2002-09-20 09:56:42 Re: PGXLOG variable worthwhile?

Browse pgsql-patches by date

  From Date Subject
Next Message Hannu Krosing 2002-09-20 13:17:10 Re: DROP COLUMN misbehaviour with multiple inheritance
Previous Message Kris Jurka 2002-09-20 05:19:46 Re: JDBC Driver - Schema Awareness