> As I follow Relyea Mike's recent post of possible memory leak, I think that
> we are lack of a good way of identifing memory usage. Maybe we should also
> remember __FILE__, __LINE__ etc for better memory usage diagnose when
> TRACE_MEMORY is on?
I find __FILE__ and __LINE__ very helpful
"Alvaro Herrera" <[EMAIL PROTECTED]> 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 clut
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Could we set that as an option for each memory context when we create
>> it? All or nothing seems too extreme for me for most cases.
> What most cases? There is only one case -- there is a big leak and you
> want to find out where
Tom Lane <[EMAIL PROTECTED]> 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 d
On Tue, Jun 20, 2006 at 12:18:32AM -0400, Tom Lane wrote:
> 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
Andrew Dunstan wrote:
> 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 a
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 t
Simon Riggs wrote:
> On Tue, 2006-06-20 at 00:18 -0400, Tom Lane 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
> >
On Tue, 2006-06-20 at 00:18 -0400, Tom Lane 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 wou
On 6/20/06, Tom Lane <[EMAIL PROTECTED]> 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 h
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> About the exact form we'd give the feature: maybe write each
> allocation/freeing to a per-backend file, say /tmp/pgmem.. Also
> memory context creation, destruction, reset. Having the __FILE__ and
> __LINE__ on each operation would be a good tracing t
Qingqing Zhou wrote:
> As I follow Relyea Mike's recent post of possible memory leak, I think that
> we are lack of a good way of identifing memory usage. Maybe we should also
> remember __FILE__, __LINE__ etc for better memory usage diagnose when
> TRACE_MEMORY is on?
Hmm, this would have been a
As I follow Relyea Mike's recent post of possible memory leak, I think that
we are lack of a good way of identifing memory usage. Maybe we should also
remember __FILE__, __LINE__ etc for better memory usage diagnose when
TRACE_MEMORY is on?
Regards,
Qingqing
---(end of b
13 matches
Mail list logo
