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𽩗
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
