Re: Non-Solaris dtrace support is disabled in 8.4!!!? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Non-Solaris dtrace support is disabled in 8.4!!!?
Date
Msg-id 8081.1252185845@sss.pgh.pa.us
Whole thread Raw
In response to Re: Non-Solaris dtrace support is disabled in 8.4!!!?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@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
completelyplatform independent makefile for this :-(
 
* Systemtap will execute "dtrace -G", but apparently it's only for compatibility with Solaris --- the produced file is
anempty 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Non-Solaris dtrace support is disabled in 8.4!!!?
Next
From: Tom Lane
Date:
Subject: Re: Tightening binary receive functions