Re: Core Dump - Mailing list pgsql-general

From Ian Harding
Subject Re: Core Dump
Date
Msg-id sd9bfe49.031@mail.tpchd.org
Whole thread Raw
In response to Core Dump  ("Ian Harding" <ianh@tpchd.org>)
Responses Re: Core Dump  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List 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 by date:

Previous
From: "Charles H. Woloszynski"
Date:
Subject: Re: Large databases, performance
Next
From: "Nigel J. Andrews"
Date:
Subject: Re: Core Dump