Re: shall we have a TRACE_MEMORY mode

Andrew Dunstan wrote:
> Alvaro Herrera said:
> 
> >
> >> 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.
> 
> Could we tag each context with its name? Then we could centralise a lot of
> this, ISTM, and the overhead involved in setting the tag at context creation
> doesn't seem like a heavy price to pay.

Each context already keeps track of its own name.

But the problem (or at last a part of the problem) is not what context
each chunk is allocated in, but where did a given chunk come from (where
was it allocated), Which is why saving __FILE__/__LINE__ is useful.

Regarding stuff allocated by lappend(), makeNode() or other functions
which centralizedly allocate in the name of the caller, maybe we could
enhance the prototypes to get __FILE__ and __LINE__ from their caller.
That would help pinpoint the true source of allocation.  Something like

#ifdef TRACE_MEMORY
#define lappend(_list_, _elt_) \lappend_tracemem(_list_, _elt_, __FILE__, __LINE__)
#endif

etc.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.