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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] [GENERAL] Memory Errors...
Date: 2002-09-23 01:46:14
Message-ID: 200209230146.g8N1kEW17923@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------

Nigel J. Andrews wrote:
> 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

Content-Description:

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-09-23 01:51:55 Re: Monitoring a Query
Previous Message Bruce Momjian 2002-09-23 01:46:04 Re: ECPG

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-09-23 01:47:09 Re: fix for buglet
Previous Message Bruce Momjian 2002-09-23 01:38:07 Re: contrib/cube & contrib/seg regression fixes