Re: Memory leak with PL/Python trigger

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Memory leak with PL/Python trigger
Дата
Msg-id 18770.1440015506@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Memory leak with PL/Python trigger  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Memory leak with PL/Python trigger
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #13579: Server crashes after executing plpythonu function
Следующее
От: Greg Stark
Дата:
Сообщение: Re: BUG #13559: WAL replay stuck after DROP VIEW