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