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.
>> The issue is with Apple's dtrace implementation, not Xcode. For more
>> info, please see the link below.
> 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?
> 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
I tested on both Xcode 3.0 & 3.1 and both worked.
Robert Lor Sun Microsystems
Austin, USA http://sun.com/postgresql
In response to
pgsql-hackers by date
|Next:||From: tomas||Date: 2008-07-29 06:05:29|
|Subject: Re: Protocol 3, Execute, maxrows to return, impact?|
|Previous:||From: Tom Lane||Date: 2008-07-29 01:31:44|
|Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution? |