"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> On Tue, 22 Oct 2002, Tom Lane wrote:
>> Not everywhere. plpgsql is full of malloc's and I think the other PL
>> modules are too --- and that's not to mention the allocation policies of
>> the perl, tcl, etc, language interpreters...
> I was going to make the suggestion that malloc et al. could be replaced with
> palloc etc but then that raises too many complications without just shooving
> everything into a long lived context anyway. Also I think we've got to rely on,
> i.e. it is sensible to do so, the underlying language handling memory
> correctly.
If the perl/tcl/etc interpreters have internal memory leaks, there's
little we can do about that except file bug reports. What I was
wondering about is whether there isn't deliberate action we need to
take to inform those interpreters when data is no longer required.
An example: when a procedure is updated with CREATE OR REPLACE FUNCTION,
the only thing pltcl does about it is a solitary Tcl_DeleteHashEntry();
it doesn't try to tell Tcl to delete the existing Tcl procedure. That
might happen for free (will we always regenerate the same Tcl procedure
name? not sure), but if the omission causes a leak it's surely not Tcl's
fault. That's on top of our own data structures about the pltcl
function (pltcl_proc_desc and related stuff), which are definitely
leaked in this scenario.
Sticking all the data about a given function into a memory context
that's specific to the function would make it easier to reclaim our own
memory in this scenario, but we'd still have to tell Tcl to clean up
its own memory.
Actually pltcl's internal structures about a function look simple enough
that it may not be worth using a context for them. It would definitely
be useful to do that for plpgsql, though, which builds an extremely
complicated structure for each function (and leaks it all on
function redefinition :-().
regards, tom lane
