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
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 |