From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
---|---|
To: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memory leaks |
Date: | 2002-10-22 23:48:12 |
Message-ID: | Pine.LNX.4.21.0210230033440.27989-100000@ponder.fairway2k.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-10-23 01:13:19 | Re: pg_dump and large files - is this a problem? |
Previous Message | Greg Copeland | 2002-10-22 23:30:13 | Re: Memory leaks |