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 PostgreSQ=
L
> 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 doma=
in
> 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 Mi=
B
> (~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 Mi=
B
> (~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 confi=
guration
> 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 pointer
in "fcinfo->flinfo->fn_extra".
But this pointer always set as NULL for every call. Because of this reason
the memory was leaked.
Regards,
Hari Babu
Fujitsu Australia