Re: Review: DTrace probes (merged version) ver_03

Robert Lor <Robert(dot)Lor(at)Sun(dot)COM> writes:
> Tom Lane wrote:
>> * The probes that pass buffer tag elements are already broken by the
>> pending "relation forks" patch: there is soon going to be another field
>> in buffer tags.

> I'm not familiar with this pending patch, but why would it break when
> another field is added?

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.

>> Furthermore the comment is
>> wrong, at least according to my tests with XCode 3.1. Typedefs seem to
>> work fine.

> 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. What we care about is different: can
we write an explicit typedef in the .d file? 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.)

regards, tom lane