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