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

From Zdenek Kotala
Subject Re: [PATCH] dtrace probes for memory manager
Date
Msg-id 1260562071.2642.68.camel@localhost
Whole thread Raw
In response to Re: [PATCH] dtrace probes for memory manager  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] dtrace probes for memory manager
List pgsql-hackers
Tom Lane píše v pá 11. 12. 2009 v 14:38 -0500:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I thought we had an idea of using the AllocSet dispatch mechanism to
> > make this zero-overhead in the case where the probes are not enabled.
> > What happened to that notion?
> 
> I must have missed that discussion, but +1 --- should be possible to get
> to zero-overhead-when-off that way.  The trick is to figure out
> what/where enables the alternate implementation.  The current design
> assumes that the callers of FooContextCreate choose the implementation,
> but we don't want that here.

I thought about it. I think we can use GUC variable (e.g. dtraced_alloc)
and hook switch pointers to dtraced AsetFunctions. The problem is how to
distribute to all backend.
Zdenek




pgsql-hackers by date:

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