Re: Memory leaks - Mailing list pgsql-hackers

From Nigel J. Andrews
Subject Re: Memory leaks
Date
Msg-id Pine.LNX.4.21.0210230033440.27989-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: Memory leaks  (Greg Copeland <greg@CopelandConsulting.Net>)
Responses Re: Memory leaks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 22 Oct 2002, Greg Copeland wrote:

> On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
> 
> > plpgsql has some issues too, I suspect, but not as bad as pltcl etc.
> > Possibly the best answer is to integrate the memory-context notion into
> > those modules; if they did most of their work in a temp context that
> > could be freed once per PL statement or so, the problems would pretty
> > much go away.
> 
> Interesting.  Having not looked at memory management schemes used in the
> pl implementations, can you enlighten me by what you mean by "integrate
> the memory-context notion"?  Does that mean they are not using
> palloc/pfree stuff?

I saw use of a couple of malloc (or Python specific malloc) calls the other day
but I also seem to recall that, after consideration, I decided the memory
needed to survive for the duration of the backend. Should I have created a new
child of the top context and changed these malloc calls?

I was going to ask about thoughts on redirecting malloc etc to palloc etc and
thereby intercepting memory allocation within the languages and automatically
bringing them into the memory context realm. However, that would just be making
life way too awkward, bearing in mind the above paragraph. Can't we get Sir
Mongle (or whatever the name was) to test these things under the auspices of
them being DoS attacks?


-- 
Nigel J. Andrews



pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: Memory leaks
Next
From: Bruce Momjian
Date:
Subject: Re: pg_dump and large files - is this a problem?