On Sat, 19 Oct 2002, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > The leak is that memory is grabbed in SPI_prepare() for a plan within
> > whatever context is current when it does the palloc(). It may be the
> > caller's or it may be the relevent SPI one. The plan is then copied
> > out of this memory [and context] into a child of the procedure's
> > context and forgotten about, or just plain forgotten.
>
> Au contraire: SPI_prepare builds the plan in its "execCxt", which is
> reset before returning (look at _SPI_begin_call and _SPI_end_call).
> So I see no leak there.
Ah, yes, I see that now.
> I'm not sure where the leak is in your plpython example, but I'd be
> inclined to look to plpython itself, perhaps even just the string
> concatenation expression in
> plan = plpy.prepare("SELECT " + repr(a))
Well it's not that string operation.
> plpgsql used to have terrible intra-function memory leaks, and only by
> dint of much hard work has it been brought to the point where you can
> expect a long loop in a plpgsql function not to chew up memory. AFAIK,
> no one has yet done similar work for the other PL languages.
Hmmm...my test case should boil down to a fairly small number of other calls in
the SPI_prepare wrapper and a quick looks doesn't show anything
interesting. Not sure I've got the time to dedicate to investigating this but
I'll look at it as and when I can.
I'm sending a patch for plpython.c to -patches which fixes a mistake I made in
the previous patch.
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
