Re: Core Dump
От | Nigel J. Andrews |
---|---|
Тема | Re: Core Dump |
Дата | |
Msg-id | Pine.LNX.4.21.0210031625490.26902-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: Core Dump ("Ian Harding" <ianh@tpchd.org>) |
Ответы |
Re: Core Dump
|
Список | 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 по дате отправления: