From: | "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: shall we have a TRACE_MEMORY mode |
Date: | 2006-06-20 08:02:26 |
Message-ID: | 65937bea0606200102k541c5d22vb8ab5d9c443b94d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/20/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> One idea that comes to mind is to have a compile time option to record
> the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
> would not be so hard to identify the culprit while trawling through
> memory. The overhead costs would be so high that you'd never turn it on
> by default though :-(
Will adding 8 bytes, that too as a compile-time option, be a big
overhead? 4 for __FILE__'s char* and 4 for __LINE__'s int; this,
assuming 32 bit arch, and that no duplicates of __FILE__ string for
each file are stored in the binary by the compiler, also called
'Enable string Pooling' in VS.Net
(http://msdn2.microsoft.com/en-us/library/s0s0asdt.aspx)
> 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?
We can consider such utility functions equivalent to palloc, hence the
caller's __FILE__ and __LINE__ will passed in to these functions, and
these functions will use the same to call the palloc (or the palloc's
#define expanded). So, in effect, in the log files, allocation will
seem to have been done from the location which called the utility
function.
Regards,
Gurjeet.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2006-06-20 08:09:55 | Re: CVS HEAD busted on Windows? |
Previous Message | Albe Laurenz | 2006-06-20 08:01:27 | Re: PAM auth |