Re: shall we have a TRACE_MEMORY mode

Поиск
Список
Период
Сортировка
Искать
От
Andrew Dunstan
Тема
Re: shall we have a TRACE_MEMORY mode
Дата
Msg-id
1354.24.211.165.134.1150804226.squirrel@www.dunslane.net
Ответ на
Список
Дерево обсуждения
Small overhead run time memory trace (Was Re: shall we have a TRACE_MEMORY mode) "Qingqing Zhou" <zhouqq@cs.toronto.edu>
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 по дате отправления
От: Alvaro Herrera
Дата:
От: Martijn van Oosterhout
Дата:
FAQ