memory leak in date_part() function in v7.1beta3 ?
Hello Developers,
at first, thank you for the wonderful work you did on the excellent
database.
I was experimenting with the 7.1beta3 release. When I use the
date_part() function in one query several thousand times (in updates for
example) the postmaster consumes all available memory, until it dies,
with a "no memory left error". If I execute the same queries without
date_part() functions everything runs smooth.
It assume that date_part() has a serious memory leak.
If you like a can reproduce some queries that fail on my machine and
send them to you with a second email.
--
--->
----> doj / cubic
-----> http://www.cubic.org
-----> http://llg.cubic.org
doj <doj@cubic.org> writes:
It assume that date_part() has a serious memory leak.
If you like a can reproduce some queries that fail on my machine and
send them to you with a second email.
Yes, we need to see the exact sequence of queries ...
regards, tom lane
doj <doj@cubic.org> writes:
I was experimenting with the 7.1beta3 release. When I use the
date_part() function in one query several thousand times (in updates for
example) the postmaster consumes all available memory, until it dies,
with a "no memory left error". If I execute the same queries without
date_part() functions everything runs smooth.
It turns out this is not specific to date_part(date); in fact, *all*
SQL-language functions were leaking memory. I have fixed the leaks
exposed by this example and some related ones, but I suspect that
some complex queries inside SQL functions will still leak a small
amount of memory per execution. We really need to reconsider how
per-query data structures are allocated ... perhaps as part of the
long-threatened querytree redesign.
regards, tom lane