Re: Memory leak with palloc

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

Browse pgsql-general by date

  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