Re: Core Dump

From: "Ian Harding" <ianh(at)tpchd(dot)org>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Core Dump
Date: 2002-10-03 15:20:46
Message-ID: sd9bfe49.031@mail.tpchd.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I have finally got a chance to do more looking and you are correct. It seems the only invocation of SPI_freetuptable that is OK (taking into account re-entrancy) is the one in the "If there is no loop body given..." block. Any time any of the 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 most recently 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 line added in the "If there is no loop body given..." blocks. If there is a loop body, doesn't the memory get freed when the procedure finishes up anyway? I guess if you had numerous consecutive large loops within a tcl proc you might gobble up some memory, but even I don't do that and I am a pretty clumsy programmer. If they are nested, that should be all right 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(at)sss(dot)pgh(dot)pa(dot)us> 10/01/02 02:08PM >>>
"Ian Harding" <ianh(at)tpchd(dot)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(at)postgresql(dot)org so that your
message can get through to the mailing list cleanly

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nigel J. Andrews 2002-10-03 15:28:53 Re: Core Dump
Previous Message Wojciech Strzaka 2002-10-03 14:53:26 PL/pgSQL