Re: shall we have a TRACE_MEMORY mode

Simon Riggs wrote:
> On Tue, 2006-06-20 at 00:18 -0400, Tom Lane wrote:
>
> > One idea that comes to mind is to have a compile time option to record
> > the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
> > would not be so hard to identify the culprit while trawling through
> > memory. The overhead costs would be so high that you'd never turn it on
> > by default though :-(
>
> 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. You don't have this code turned on all the
time, you must enable it at compile time, so we want it to be as simple
as possible.

On Tue, 2006-06-20 at 00:18 -0400, Tom Lane wrote:

> 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.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support