Re: Memory leak with PL/Python trigger

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "Behn, Edward (EBEHN)" <EBEHN(at)arinc(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Memory leak with PL/Python trigger
Date: 2015-08-19 20:18:26
Message-ID: 18770.1440015506@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Greg Stark 2015-08-19 23:08:52 Re: BUG #13559: WAL replay stuck after DROP VIEW
Previous Message Tom Lane 2015-08-19 15:28:52 Re: BUG #13579: Server crashes after executing plpythonu function