Re: shall we have a TRACE_MEMORY mode - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: shall we have a TRACE_MEMORY mode
Date
Msg-id 1354.24.211.165.134.1150804226.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: shall we have a TRACE_MEMORY mode  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: shall we have a TRACE_MEMORY mode  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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.

cheers

andrew




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: shall we have a TRACE_MEMORY mode
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Generic Monitoring Framework Proposal