Re: shall we have a TRACE_MEMORY mode

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: shall we have a TRACE_MEMORY mode
Дата
Msg-id 87r71j533r.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: shall we have a TRACE_MEMORY mode  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Another thing to consider is that the proximate location of the palloc
> is frequently *not* very useful.  For instance, if your memory is
> getting eaten by lists, all the palloc traces will point at
> new_tail_cell().  Not much help.  I don't know what to do about that
> ... any ideas?

Well the traditional thing to do is store a backtrace a la Dmalloc, one of the
better debugging malloc libraries out there. It has mostly been superceded by
Purify/Valgrind type tools but it still has a place for handling memory leaks.

It's unfortunate that's impossible to use Dmalloc with Postgres. It would
probably be nigh impossible to merge in Dmalloc code into Postgres's allocator
given the different models. But perhaps it would be possible to steal specific
pieces of it like the backtrace grabbing code.


-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: sync_file_range()
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Generic Monitoring Framework Proposal