Re: Core Dump
От | Ian Harding |
---|---|
Тема | Re: Core Dump |
Дата | |
Msg-id | sd9bfe49.031@mail.tpchd.org обсуждение исходный текст |
Ответ на | Core Dump ("Ian Harding" <ianh@tpchd.org>) |
Ответы |
Re: Core Dump
|
Список | pgsql-general |
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 the lineadded 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. Thank you for looking at this! Ian >>> Tom Lane <tgl@sss.pgh.pa.us> 10/01/02 02:08PM >>> "Ian Harding" <ianh@tpchd.org> writes: > I hacked my pltcl.so the other day, but all has been well up to now. > I added a few SPI_freetuptable() to keep pltcl from hogging all the > memory. I wonder if I hacked it a little wrong. Looks that way. The stack trace doesn't seem completely trustworthy, though, so you might want to consider recompiling with --enable-debug. Note that you seem to be inside a re-entrant use of pltcl (outer function is triggering a trigger also written in pltcl). I'm wondering if your tuptable hacking is not taking account of the possibility of re-entrancy. This might be a bug that had been latent in pltcl all along, and was only exposed when you tried to free stuff ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
В списке pgsql-general по дате отправления: