Re: Review: DTrace probes (merged version) ver_03
От | Robert Lor |
---|---|
Тема | Re: Review: DTrace probes (merged version) ver_03 |
Дата | |
Msg-id | 488EA95D.10906@sun.com обсуждение исходный текст |
Ответ на | Re: Review: DTrace probes (merged version) ver_03 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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. >> 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
В списке pgsql-hackers по дате отправления: