From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(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 13:42:01 |
Message-ID: | 27435.1150810921@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Simon Riggs wrote:
>> Could we set that as an option for each memory context when we create
>> it? All or nothing seems too extreme for me for most cases.
> What most cases? There is only one case -- there is a big leak and you
> want to find out where.
There's a more significant reason why not, which is that all AllocChunks
must have the same header, else pfree doesn't know what to do.
>> That seems mostly the hard way to me, because our memory management
>> scheme is *not* based around "thou shalt free() what thou malloc()ed".
>> You'd need a tool that understood about resetting memory contexts
>> (recursively) to get anywhere at all in analyzing such a trace.
> Of course. It's not difficult to do that; just tedious. I wrote such a
> tool to debug a Mammoth Replicator problem (I don't think I've kept it
> though). The logging code must emit messages about context creation,
> destruction and reset, and have the alloc message indicate what context
> is the chunk being created on.
Well, the logging approach would definitely be less intrusive to the
system's runtime behavior, and would (maybe) not require gdb to use.
If you can resurrect that tool it'd be interesting to look at. Maybe
it's on a backup tape somewhere?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-20 13:52:24 | Re: sync_file_range() |
Previous Message | Martijn van Oosterhout | 2006-06-20 13:14:09 | Re: shall we have a TRACE_MEMORY mode |