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

2002-09-23 Thread Greg Copeland
Well, it looks like it was already taken to the mat. ;) Greg On Thu, 2002-09-19 at 16:58, Joe Conway wrote: > Nigel J. Andrews wrote: > > On Thu, 19 Sep 2002, Joe Conway wrote: > >>I can give it a shot, but probably not until the weekend. > >> > >>I haven't really followed this thread closely

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

2002-09-20 Thread Nigel J. Andrews
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,

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

2002-09-20 Thread Greg Copeland
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 no

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

2002-09-20 Thread Peter Eisentraut
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

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

2002-09-19 Thread Joe Conway
Nigel J. Andrews wrote: > On Thu, 19 Sep 2002, Joe Conway wrote: >>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 pro

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

2002-09-19 Thread Nigel J. Andrews
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,

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

2002-09-19 Thread Tom Lane
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > Why is the pltcl directory called tcl where all the other pls are pl? Consistency? We don't need no steenking consistency! Personally I'd prefer to remove the pl prefix from the other subdirectories of src/pl/ ... it seems redundantly wasted exce

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

2002-09-19 Thread Bruce Momjian
Nigel J. Andrews wrote: > > > "Ian Harding" <[EMAIL PROTECTED]> writes: > > > It is pltcl [not plpgsql] > > Quick, minor point, in the manner of a question: > > Why is the pltcl directory called tcl where all the other pls are pl? I asked the same question a while ago. I asked about changing

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

2002-09-19 Thread Nigel J. Andrews
> "Ian Harding" <[EMAIL PROTECTED]> writes: > > It is pltcl [not plpgsql] Quick, minor point, in the manner of a question: Why is the pltcl directory called tcl where all the other pls are pl? That's in src/pl of course. Also in my anoncvs fetch which is a few weeks old now being from the day

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

2002-09-19 Thread Joe Conway
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,

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

2002-09-19 Thread Tom Lane
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() on

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

2002-09-19 Thread Tom Lane
"Ian Harding" <[EMAIL PROTECTED]> 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 < 10} {incr