Re: shall we have a TRACE_MEMORY mode
От | Qingqing Zhou |
---|---|
Тема | Re: shall we have a TRACE_MEMORY mode |
Дата | |
Msg-id | e7aacp$1qim$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: shall we have a TRACE_MEMORY mode (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
"Alvaro Herrera" <alvherre@commandprompt.com> wrote > > 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. > Agreed. Maybe we should not clutter these trace info in the AllocChunkData. We save them in a separe memory context which is only activated when TRACE_MEMORY is on. Also, recording every __FILE__/__LINE__ seems not neccessary, we merge them and record the count of calls. Once a leak is happened, the usual suspect is the high-count one. So the output of memory context dump will be looks like this: execQual.c 1953 123456 execHash.c 208 12 ... > > #ifdef TRACE_MEMORY > #define lappend(_list_, _elt_) \ > lappend_tracemem(_list_, _elt_, __FILE__, __LINE__) > #endif > This might be the only portable way I could think of. We don't want to redefine all of the functions calling palloc()/MemoryContextAlloc(), we redefine the most suspectable ones like those in heaptuple.c. Regards, Qingqing
В списке pgsql-hackers по дате отправления: