Re: Memory leak with PL/Python trigger

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Memory leak with PL/Python trigger
Дата
Msg-id CAJrrPGc0grzvEcFrMjFzEzE8veVt4A8hyLZrmdCj_XGReWWpQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Memory leak with PL/Python trigger  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Memory leak with PL/Python trigger  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-bugs
On Fri, Jul 31, 2015 at 12:13 PM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
>
>
> On Fri, Jul 31, 2015 at 9:15 AM, Behn, Edward (EBEHN) <EBEHN@arinc.com>
> wrote:
>>
>> I believe that I have discovered a memory leak bug that affects PostgreS=
QL
>> 9.5 Alpha -1. (It also affects 9.4.1.)
>>
>>
>>
>> The leak appears in the server process when a PL/Python trigger function
>> is used to populate a composite type that contains a field that is a dom=
ain
>> type. This leak is worse if the domain type has a constraint.
>>
>> The attached files create a database that has this property (Schema.sql)
>> and add rows to the table causing the leak (Test.py).
>>
>>
>>
>> If the trigger function is implemented in PL/pgSQL, the leak disappears.
>>
>>
>>
>> After 1,000,000 rows, the server process has a memory footprint of 544 M=
iB
>> (~570 bytes/row) if the constraint is present on the domain type.
>>
>>
>>
>> After 1,000,000 rows, the server process has a memory footprint of 144 M=
iB
>> (~150 bytes/row) if the constraint is not present on the domain type.
>>
>>
>>
>> I am running PostgreSQL 9.5 Alpha-1 on Fedora 21. My installation is =E2=
=80=9Cout
>> of the box=E2=80=9D from the YUM repository. I have not altered any conf=
iguration
>> files. I have tested the code as user/role postgres.
>>
>>
>>
>>
>
> 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 pointe=
r
> in "fcinfo->flinfo->fn_extra".
> But this pointer always set as NULL for every call. Because of this reaso=
n
> the memory was leaked.

Adding to this point, In "PLyObject_ToComposite" function the context point=
er
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.

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 tak=
ing
care of reusing the pointer or something?

Regards,
Hari Babu
Fujitsu Australia

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: Memory leak with PL/Python trigger
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Memory leak with PL/Python trigger