Skip site navigation (1) Skip section navigation (2)

Re: Review: DTrace probes (merged version) ver_03

From: Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, jesus(at)omniti(dot)com
Subject: Re: Review: DTrace probes (merged version) ver_03
Date: 2008-07-29 05:23:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.
> 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
> ships.)
I tested on both Xcode 3.0 & 3.1 and both worked.

Robert Lor           Sun Microsystems
Austin, USA

In response to

pgsql-hackers by date

Next:From: tomasDate: 2008-07-29 06:05:29
Subject: Re: Protocol 3, Execute, maxrows to return, impact?
Previous:From: Tom LaneDate: 2008-07-29 01:31:44
Subject: Re: Do we really want to migrate plproxy and citext into PG core distribution?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group