Re: [PATCH] dtrace probes for memory manager - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] dtrace probes for memory manager
Date
Msg-id 603c8f070912111747i3d3024e3o66b12f6b9643b1e4@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] dtrace probes for memory manager  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Dec 11, 2009 at 3:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Tom Lane píše v pá 11. 12. 2009 v 15:11 -0500:
>>> If we go this route it would be nice to think about making a facility
>>> that has some usefulness for non-DTrace platforms too.
>
>> Do you mean general facility for switching memory allocator?
>
> No, I was thinking of some sort of memory allocation stats collection
> that doesn't depend on DTrace.  It's amazing to me that we've never
> gone back and improved on the original quick-and-dirty
> MemoryContextStats mechanism.  I certainly find myself using that a
> lot for issues like tracking down memory leaks.  While palloc has a lot
> of advantages, the fact that you can't easily plug in a debug-friendly
> substitute malloc package is not one of them :-(

This might be nice to have, but I don't think it's necessarily a
prerequisite for a committable patch.  For that, I think we just need
something that uses the dispatch mechanism to avoid the overhead in
the normal case.

However, as this is a substantial redesign and there are 4 days left
in the CommitFest, I am going to mark this patch Returned with
Feedback for now.

...Robert


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Adding support for SE-Linux security
Next
From: Robert Haas
Date:
Subject: Re: Adding support for SE-Linux security