Peter Eisentraut <pete...@gmx.net> writes:
> On fre, 2009-09-04 at 17:49 -0400, Tom Lane wrote:
>> I have just discovered that this commit
>> http://archives.postgresql.org/pgsql-committers/2008-03/msg00316.php
>> which was alleged to improve our dtrace support on non-Solaris operating
>> systems, actually disabled it completely:
> You might want to check with Robert Lor about the details.
After further investigation I've concluded that it wasn't as broken as
it appeared, just desperately underdocumented. The actual situation
seems to be:
* We need probes.o for dtrace on Solaris (or so I would assume, I don't
have this platform to test on).
* On OS X, we don't need it, and in fact dtrace spits up on the command
that tries to generate it. So we can't have a completely platform
independent makefile for this :-(
* Systemtap will execute "dtrace -G", but apparently it's only for
compatibility with Solaris --- the produced file is an empty stub.
(The systemtap problem that I initially thought was caused by omission
of the probes.o file was actually not caused by that.)
Given this, I've reverted to the "ifeq ($(PORTNAME), solaris)" condition
for producing probes.o, but annotated it a bit. It seems likely that
it will need adjustment as more platforms come up with their own
idiosyncratic dtrace implementations. It's possible that what we should
use instead is "ifneq ($(PORTNAME), darwin)", but I'm going to guess for
now that what appears on the BSDen will look more like OSX's
implementation than like Solaris'.
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
