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
