Re: [HACKERS] Review: DTrace probes (merged version) ver_03

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers