Re: [PATCH] dtrace probes for memory manager

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] dtrace probes for memory manager
Date: 2009-12-11 19:38:27
Message-ID: 22366.1260560307@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2009-12-11 19:48:24 Re: thread safety on clients
Previous Message Stephen Frost 2009-12-11 19:11:24 Re: Adding support for SE-Linux security