Thanks for the information.
I must say the involvement of the developers of PostgreSQL is
impressive.
Cheers,
Han Holl
On Sunday 01 December 2002 11:09 pm, tgl@sss.pgh.pa.us wrote:
>
> Okay, it turns out this is indeed an aspect of a known problem, namely
> that SQL-language functions aren't good about cleaning up query-lifespan
> data created by the queries they run. The individual queries really
> ought to be run using a query memory context that's shorter-lived than
> that of the query that's calling the function. But they're not, yet.
>
> I was able to eliminate the memory leak in your example by adding
> "pfree(scanstate);" to the end of ExecEndSeqScan(). However, that's
> not a general solution, since there are comparable leaks in most of
> the other executor node types; and even if we eliminated them all today,
> it would be difficult to prevent new ones from appearing in future.
>
> The right long-term solution is to arrange for all query-lifetime data
> to be allocated in a specific context that can be freed in-toto when
> we end the query. To do this cleanly, we have to fix the executor to
> not scribble on plan trees (executor state nodes should point to plan
> nodes, never vice-versa). I've been intending to do that for awhile,
> but it's not done yet ...
>
> regards, tom lane