From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: shall we have a TRACE_MEMORY mode |
Date: | 2006-06-20 14:11:20 |
Message-ID: | 87r71j533r.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Another thing to consider is that the proximate location of the palloc
> is frequently *not* very useful. For instance, if your memory is
> getting eaten by lists, all the palloc traces will point at
> new_tail_cell(). Not much help. I don't know what to do about that
> ... any ideas?
Well the traditional thing to do is store a backtrace a la Dmalloc, one of the
better debugging malloc libraries out there. It has mostly been superceded by
Purify/Valgrind type tools but it still has a place for handling memory leaks.
It's unfortunate that's impossible to use Dmalloc with Postgres. It would
probably be nigh impossible to merge in Dmalloc code into Postgres's allocator
given the different models. But perhaps it would be possible to steal specific
pieces of it like the backtrace grabbing code.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-06-20 14:19:37 | Re: Generic Monitoring Framework Proposal |
Previous Message | Tom Lane | 2006-06-20 13:59:06 | Re: sync_file_range() |