From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
---|---|
To: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
Cc: | PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] Memory Errors... |
Date: | 2002-09-20 18:17:47 |
Message-ID: | Pine.LNX.4.21.0209201915200.599-100000@ponder.fairway2k.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On 20 Sep 2002, Greg Copeland wrote:
> I'll try to have a look-see by the end of the weekend. Any code that
> can reproduce it or is it ANY code that uses SPI?
>
> Greg
>
>
> On Fri, 2002-09-20 at 11:39, Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > 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.
> >
> > There's a note in the PL/Python documentation that it's leaking memory if
> > SPI plans are used. Maybe that's related and someone could take a look at
> > it.
I've added the call to free the tuptable just as in the pltcl patch I submited
earlier (which I can't remember if I've seen in the list so I may well resend).
However, the comments in the code imply there might be another leak with
prepared plans. I'm looking into that so I won't be sending this patch just
yet.
--
Nigel J. Andrews
From | Date | Subject | |
---|---|---|---|
Next Message | Jean-Luc Lachance | 2002-09-20 18:22:37 | Getting acces to MVCC version number |
Previous Message | Bruce Momjian | 2002-09-20 18:07:23 | Re: PGXLOG variable worthwhile? |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-09-20 19:06:43 | fix for buglet |
Previous Message | Greg Copeland | 2002-09-20 17:57:34 | Re: [GENERAL] Memory Errors... |