Re: shall we have a TRACE_MEMORY mode

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

In response to

Browse pgsql-hackers by date

  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