Re: Review: DTrace probes (merged version) ver_03 - Mailing list pgsql-hackers

From Robert Lor
Subject Re: Review: DTrace probes (merged version) ver_03
Date
Msg-id 488EA95D.10906@sun.com
Whole thread Raw
In response to Re: Review: DTrace probes (merged version) ver_03  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> By "break" I meant "fail to function usefully".  Yes, it would still
> compile, but if you don't have the fork number available then you won't
> be able to tell what's really happening in the buffer pool.  You might
> as well not pass any of the buffer tag as pass only part of it.
>   

Got it.

>> The issue is with Apple's dtrace implementation, not Xcode. For more 
>> info, please see the link below.
>> http://www.opensolaris.org/jive/thread.jspa?messageID=252503&#252503
>>     
>
> I think what this is complaining about is whether allegedly built-in
> typedefs like uintptr_t work.

This is the message I tried to convey with the comment in probe.d, but I 
guess it was not clear.
>   What we care about is different: can
> we write an explicit typedef in the .d file? 

Yes.

>  I do not know if that
> worked in XCode 3.0 or not, but it seems to work fine in the version
> of dtrace shipped in 3.1.  (And I'm perfectly fine with telling people
> that they can't compile Postgres dtrace support with less than the most
> recent tool set, especially since it'll be fairly old by the time 8.4
> ships.)
>   
I tested on both Xcode 3.0 & 3.1 and both worked.


-- 
Robert Lor           Sun Microsystems
Austin, USA          http://sun.com/postgresql



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?
Next
From: tomas@tuxteam.de
Date:
Subject: Re: Protocol 3, Execute, maxrows to return, impact?