"Nigel J. Andrews" <nandrews@investsystems.co.uk> 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.
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 inplan = plpy.prepare("SELECT " + repr(a))
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.
regards, tom lane
