Re: Memory leak with PL/Python trigger

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Behn, Edward (EBEHN)" <EBEHN(at)arinc(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Memory leak with PL/Python trigger
Date: 2015-07-31 09:13:55
Message-ID: 55BB3C53.2030603@iki.fi
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

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?

- Heikki

Attachment Content-Type Size
fix-plpython-typeinfo-leaks-1.patch application/x-patch 10.3 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Haribabu Kommi 2015-07-31 12:54:57 Re: Memory leak with PL/Python trigger
Previous Message Haribabu Kommi 2015-07-31 08:05:00 Re: Memory leak with PL/Python trigger