From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
Cc: | PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Memory leaks |
Date: | 2002-10-22 22:09:23 |
Message-ID: | 25790.1035324563@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Copeland <greg(at)CopelandConsulting(dot)Net> writes:
> I've started playing a little with Postgres to determine if there were
> memory leaks running around. After some very brief checking, I'm
> starting[1] to think that the answer is yes. Has anyone already gone
> through a significant effort to locate and eradicate memory leaks?
Yes, this has been dealt with before. Have you read
src/backend/utils/mmgr/README?
AFAIK the major problems these days are not in the backend as a whole,
but in the lesser-used PL language modules (cf recent discussions).
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.
It's fairly difficult to get anywhere with standard leak-tracking tools,
since they don't know anything about palloc. What's worse, it is *not*
a bug for a routine to palloc space it never pfrees, if it knows that
it's palloc'ing in a short-lived memory context. The fact that a
context may be released with much still-allocated memory in it is not a
bug but a feature; but try teaching that to any standard leak checker...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-10-22 22:20:53 | Re: pg_dump and large files - is this a problem? |
Previous Message | Bruce Momjian | 2002-10-22 21:37:39 | Re: pg_dump and large files - is this a problem? |