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 по дате отправления: