Re: [GENERAL] Memory Errors... - Mailing list pgsql-hackers

From Nigel J. Andrews
Subject Re: [GENERAL] Memory Errors...
Date
Msg-id Pine.LNX.4.21.0209192238150.599-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: [GENERAL] Memory Errors...  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Thu, 19 Sep 2002, Joe Conway wrote:

> Tom Lane wrote:
> > I said:
> > 
> >>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?
> > 
> > 
> > On looking a little more closely, it's clear that pltcl_SPI_exec()
> > should be, and is not, calling SPI_freetuptable() once it's done with
> > the tuple table returned by SPI_exec().  This needs to be done in all
> > the non-elog code paths after SPI_exec has returned SPI_OK_SELECT.
> > pltcl_SPI_execp() has a similar problem, and there may be comparable
> > bugs in other pltcl routines (not to mention other sources of memory
> > leaks, but I think this is the problem for your example).
> > 
> > I have no time to work on this right now; any volunteers out there?
> > 
> 
> I can give it a shot, but probably not until the weekend.
> 
> I haven't really followed this thread closely, and don't know tcl very well, 
> so it would help if someone can send me a minimal tcl function which triggers 
> the problem.


I can probably take a look at this tomorrow, already started by looking at the
pltcl_SPI_exec routine. I think a quick glance at ...init_unknown() also shows
a lack of tuptable freeing.


-- 
Nigel J. Andrews



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: GRANT EXECUTE
Next
From: Tom Lane
Date:
Subject: Re: Beta2 on Friday Morning (Was: Re: Open 7.3 items)