Re: Memory leak with PL/Python trigger - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Memory leak with PL/Python trigger
Date
Msg-id 18770.1440015506@sss.pgh.pa.us
Whole thread Raw
In response to Re: Memory leak with PL/Python trigger  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: Memory leak with PL/Python trigger  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-bugs
Haribabu Kommi <kommi.haribabu@gmail.com> writes:
> Here I attached updated patch with a context allocation in
> "PLy_procedure_create" function and the same context is reset
> in every function call of "PLy_procedure_get" for all PLY types.

This isn't really going in the direction I had in mind.

I think what we want is to get rid of *all* of plpython's retail
allocations in TopMemoryContext.  All the long-lived data about
a given procedure, starting with its PLyProcedure struct and
certainly including all the associated PLyTypeInfo stuff, ought
to be in a per-procedure context, similarly to the way plpgsql
manages it.  Then you can just delete that context if the procedure
definition changes, and not need any retail cleanup.

Also, you can't just reset the context being used as fn_mcxt
without any regard for the possibility that functions have
stored pointers into that space (probably in their fn_extra).
Really you ought to redo fmgr_info() if you do that.  That
means that this approach is fundamentally giving up the ability
to cache type lookup data across calls at all, which is surely
not what we want.

I would envision the PLyTypeInfo structs as usually living in the
per-procedure context, and that's where fn_mcxt would point as well.
There might be some cases where we have to have shorter-lived
PLyTypeInfos, but the normal case ought to work like that.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #13579: Server crashes after executing plpythonu function
Next
From: Greg Stark
Date:
Subject: Re: BUG #13559: WAL replay stuck after DROP VIEW