Robert Lor <[EMAIL PROTECTED]> 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𽩗 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
