Re: Core Dump - Mailing list pgsql-general

From Nigel J. Andrews
Subject Re: Core Dump
Date
Msg-id Pine.LNX.4.21.0210031625490.26902-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: Core Dump  ("Ian Harding" <ianh@tpchd.org>)
Responses Re: Core Dump  (Neil Conway <neilc@samurai.com>)
List pgsql-general
On Thu, 3 Oct 2002, Ian Harding wrote:

> I have finally got a chance to do more looking and you are correct.  It seems the only invocation of SPI_freetuptable
thatis OK (taking into account re-entrancy) is the one in the "If there is no loop body given..." block.  Any time any
ofthe ones in the "There is a loop body..." bit get called, it explodes. 
>
> I assumed the SPI_freetuptable(SPI_tuptable) bit would know to only free the tuple table (whatever that is) from the
mostrecently executed spi_exec.   
>
> To take care of my problem, and not blow up in nested "-array" types of spi_exec constructs, it seems we only need
theline added in the "If there is no loop body given..." blocks.  If there is a loop body, doesn't the memory get freed
whenthe procedure finishes up anyway?  I guess if you had numerous consecutive large loops within a tcl proc you might
gobbleup some memory, but even I don't do that and I am a pretty clumsy programmer.  If they are nested, that should be
allright since the memory bloat was only caused by the innermost (non "-array" call to spi_exec. 

Yes, I think Neil sent a patch that took out this fault but reinserted a
variation of the original leak problem. I know how to fix it I just need to
sort out what has gone on with the source file in the meantime because I can't
see Neil's patch, which did other things as well, in there yet. I will do this
memory problem regardless later tonight or early tomorrow.

(Neil might be Joe, I'll have to look at my saved messages)

--
Nigel J. Andrews


pgsql-general by date:

Previous
From: "Ian Harding"
Date:
Subject: Re: Core Dump
Next
From: "Erwan DUROSELLE"
Date:
Subject: Rép. : newbie