Обсуждение: 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