From: | Han Holl <han(dot)holl(at)prismant(dot)nl> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Memory leak with palloc |
Date: | 2002-12-02 15:54:16 |
Message-ID: | 200212021654.16976.han.holl@prismant.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2002-12-02 16:11:33 | Re: The old "not using index" question |
Previous Message | Mikael Carneholm | 2002-12-02 15:48:20 | Re: Shema functionality in 7.3 |