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 обсуждение исходный текст |
Ответ на | Re: shall we have a TRACE_MEMORY mode (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: shall we have a TRACE_MEMORY mode
|
Список | 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 по дате отправления: