Re: Memory leak with PL/Python trigger
От | Haribabu Kommi |
---|---|
Тема | Re: Memory leak with PL/Python trigger |
Дата | |
Msg-id | CAJrrPGcnjrz5pFVLcOwtoCMcgX-Qcv4M2x+cDrR8hCwPpEfmNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Memory leak with PL/Python trigger (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Memory leak with PL/Python trigger
|
Список | pgsql-bugs |
On Fri, Jul 31, 2015 at 7:13 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > On 07/31/2015 11:05 AM, Haribabu Kommi wrote: >>> >>> Thanks for the defect details. >>> I am able to reproduce the issue on Head. >>> >>> This is because of many unnecessary "Expr Context" that are created in >>> function "domain_check_input" >>> using CreateStandaloneExprContext function under TopMemoryContext. >>> >>> This memory context is reset for future use by storing the context >>> pointer >>> in "fcinfo->flinfo->fn_extra". >>> But this pointer always set as NULL for every call. Because of this >>> reason >>> the memory was leaked. >> >> >> Adding to this point, In "PLyObject_ToComposite" function the context >> pointer >> which was allocated earlier is freed without removing the context. >> Because of this >> reason for the next record, it again allocates the context and thus it >> leading to a >> memory leak. > > > Yep. > >> Instead of reset the context in "domain_check_input" function, we can free >> that >> context, which can solve this problem. But I am not sure, is it right fix? >> >> Instead of the above fix, either we need to teach plpython functions to >> taking >> care of reusing the pointer or something? > > > The problem is that perm_fmgr_info() is a crock, as explained in its > comments. That crock leads to this kind of memory leaks. > > I'm not sure why we use that crock. It doesn't seem hard to just use a more > short-lived memory context. I hacked together the attached patch, which > fixes this particular test case, but I just used TopMemoryContext in most > other places so this doesn't plug all the leaks. But I think we want > something like this, but using an appropriate memory context in each > PLy_typeinfo_init call. For some call sites, I think we do need to create a > new memory context that can be easily freed in PLy_typeinfo_dealloc(). > > Would you like to finish up that patch? Thanks for providing details. I find similar perm_fmgr_info() function in both plperl and pltcl modules also. I will check the function impact on those two modules also and finish up the patch. Regards, Hari Babu Fujitsu Australia
В списке pgsql-bugs по дате отправления: