| 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: | Whole Thread | Raw Message | 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? |