本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に項15.2を注意して読んでください。 またリグレッション試験結果の解釈については第29章を確認してください。
ここで触れられていないプラットフォームはプラットフォーム特有のインストール問題がありません。
AIX上でPostgreSQLは動作しますが、適切にインストールをやり遂げるのは挑戦でもあります。AIXバージョン4.3.3から6.1はサポートされていると考えられます。GCCまたは在来のIBMコンパイラxlcが使用できます。一般的に、最新のAIXとPostgreSQLバージョンを使用することが手助けになります。どのバージョンのAIXが動くと知られているかについての最新情報をビルドファームで見てください。
次のconfigureフラグに 次のconfigureフラグをその他の使用目的に沿ったフラグに加え、インストール済のreadlineまたはlibzが存在すればにそこに追加します。 --with-includes=/usr/local/include --with-libraries=/usr/local/lib
PowerPCではない、またはGCCを使用しない場合は幾何に関するリグレッション試験で丸めに違いがでる可能性があります。 おそらく0.0/0.0という除算や重複シンボルに関する警告がありますが、無視しても問題ありません。
その他のプラットフォームで見慣れたものとは、AIXのツールのいくつかは"ちょっと違う"かも知れません。 lddのバージョンを探すのであればどのオブジェクトコードがどのライブラリに依存しているかを見つけ出す手助けとして、以下のURLが参考になるでしょう。 http://www.faqs.org/faqs/aix-faq/part4/section-22.html http://www.han.de/~jum/aix/ldd.c
表15-1は各種のAIXバージョンに対する最低限推奨される修正レベルを示しています。私用している修正レベルをチェックするには、AIX 4.3.3 から AIX 5.2 ML 7 まではoslevel -r、またはそれ以降のバージョンではoslevel -sを使用します。
表 15-1. 最低限推奨のAIX修正レベル
| AIXバージョン | 修正レベル |
|---|---|
| AIX 4.3.3 | 保守レベル 11 + ML11 バンドル以降 |
| AIX 5.1 | 保守レベル 9 + ML9 バンドル以降 |
| AIX 5.2 | 技術レベル 10 サービスパック 3 |
| AIX 5.3 | 技術レベル 7 |
| AIX 6.1 | 基本レベル |
AIX 5.3でGCCを使ってPostgreSQLがコンパイルし実行するためには幾つかの問題点があります。
特にパッケージ済みバージョンを使用している場合、3.3.2以降のバージョンのGCCの使用が望まれるかもしれません。4.0.1では旨く行っています。より早期のバージョンによる諸問題は、GCCの実際問題というよりもIBMのパッケージ済みGCCの現状により関連性があるように見えます。従い、GCCを自身でコンパイルするのであれば、より早期のGCCバージョンの方が成功しやすいでしょう。
AIX 5.3にはsockaddr_storageが十分大きく定義されていないという問題があります。 バージョン5.3でIBMはUnixドメインソケットのアドレス構造体であるsockaddr_unのサイズを増やしましたが、対応するsockaddr_storageのサイズを増やしませんでした。 この結果、PostgreSQLでUnixドメインソケットを使用しようとすると、libpqでデータ構造体がオーバーフローするようになります。 Unixドメインソケットを除くTCP/IP接続の動作は正常です。 これはリグレッションテストの動作を妨害します。
この問題はIBMに報告済みでバグ報告PMR29657として記録されています。 メンテナンスレベル5300-03以降に更新していれば、この修正が含まれています。 すぐに解決させたければ、/usr/include/sys/socket.h内で_SS_MAXSIZEを1025に変更してください。 どちらの場合でも、ヘッダファイルを修正した後でPostgreSQLを再コンパイルしてください。
PostgreSQLはlisten_addresses、pg_hba.conf、その他の中のIPアドレスを構文解釈するのにシステムのgetaddrinfo関数に頼ります。旧バージョンのAIXにはこの関数にさまざまなバグがあります。これら設定に関係した問題に遭遇した場合、表15-1に示されている適切な修正レベルに更新することが問題解決になります。
あるユーザの報告です。
PostgreSQLバージョン8.1をAIX 5.3で実装している時、統計情報コレクタが"不思議なことに"正常に起動しないという問題が周期的に起こりました。 これは、IPv6の実装における想定外の動作という結果で出現します。 当時はAIXでPostgreSQLとIPv6を一緒にうまく動作しないように見えました。
以下のどれかの対応でこの問題が"解決できます"。
localhostに対するIPv6アドレスを削除します。
(as root) # ifconfig lo0 inet6 ::1/0 delete
ネットサービスからIPv6を削除します。AIXの/etc/netsvc.confファイルは大まかに言ってSolaris/Linuxの/etc/nsswitch.confと同等です。AIXのデフォルトは、以下のようになっています。
hosts=local,bind
これを次で置き換えます。
hosts=local4,bind4
そうすると、IPv6アドレスの検索が解除されます。
AIXはメモリ管理手法の観点から見ると多少独特です。 ギガバイト単位のRAMが空いているサーバがあっても、アプリケーションを実行している時にメモリ不足やアドレス空間エラーが発生することがあります。 こうした例の1つが、見慣れないエラーによるcreatelangの失敗です。 例えば、PostgreSQLインストレーションの所有者として実行してみます。
-bash-3.00$ createlang plpgsql template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the address space for the process.
PostgreSQLインストレーションの処理グループ内の所有者以外として実行してみます。
-bash-3.00$ createlang plpgsql template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": Bad address
他の実例は、PostgreSQLサーバログ中のメモリ不足エラーで、256 MB以上もしくはその近辺で全てのメモリ割り当てが失敗します。
これら問題のすべての総合原因は、サーバプロセスで使用されるデフォルトのビット割当とメモリモデルです。 デフォルトでは、AIXで構築されたすべてのバイナリは32ビットです。 これは使用中のハードウェアの種類やカーネルに依存しません。 これらの32ビットプロセスは、数個のモデルの1つを使用して256メガバイトのセグメントで割りつけられた4ギガバイトメモリに制限されます。 デフォルトでは、スタックで1つのセグメントとして共有されるものとしてヒープ内の256メガバイト未満の領域が許されます。
上記、createlang例の場合において、PostgreSQLインストレーションにおけるバイナリのumaskとパーミッションをチェックしてください。例に関与したバイナリは32-ビットであり、755ではなく750モードでインストールされました。このような形式で設定されたパーミッションのため、所有者もしくはグループ所有のメンバーのみライブラリを読み込めます。それは誰もが読み取り可能ではないため、ローダは、そうでない場合に配置される共有ライブラリセグメントにではなく、オブジェクトをプロセスのヒープに配置します。
これに対しての"理想的な"解決策はPostgreSQLの64-ビットビルドを使うことですが、32-ビットプロセッサのシステムでは64-ビットバイナリをビルドできますが実行できないので、常に実務的ではありません。
32-ビットバイナリを要求する場合、PostgreSQLサーバを起動する前にLDR_CNTRLをMAXDATA=0xn0000000に設定します。ここで、1 <= n <= 8です。そして異なる値とpostgresql.conf設定で満足に稼動する構成を見つけ出します。 このLDR_CNTRL使用するとAIXに対して、サーバがヒープにかかわらず、256 MBセグメントに割り当てられたMAXDATAバイトセットを持つようにさせたい意図を表明します。稼動する構成を見つけたとき、意図したヒープ容量をデフォルトで使用するようにldeditを使用してバイナリを変更することができます。同じ効果を得るため、PostgreSQLはconfigure LDFLAGS="-Wl,-bmaxdata:0xn0000000"を渡して再構築することもできます。
64-ビット構築に対し、OBJECT_MODEを64に設定し、configureにCC="gcc -maix64" とLDFLAGS="-Wl,-bbigtoc"を渡します。（xlcに対するオプションは異なるかもしれません。）OBJECT_MODEのexportを省略すると、構築はリンカーエラーで失敗することがあります。OBJECT_MODEが設定された場合、ar、as、およびldのようなAIXの構築ユーティリティにどの種類のオブジェクトがデフォルトで対応されるのかを伝えます。
デフォルトで、ページングスペースのオーバーコミットが起こることがあります。これが起こることを経験したことが無いとは言っても、AIXはメモリを使い切って、オーバーコッミットがアクセスされたときにプロセスをkillします。システムが別のプロセスに対する十分なメモリがないと判断する理由で、フォークが失敗するというこれとよく似たことを見てきました。多くのほかのAIX部分のように、ページングスペース割り当て方式とメモリ不足killは、これが問題となるのであれば、システムまたはプロセス全般基盤で設定可能です。
"Large Program Support", AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
"Program Address Space Overview", AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
"Performance Overview of the Virtual Memory Manager (VMM)", AIX Documentation: Performance Management Guide.
"Page Space Allocation", AIX Documentation: Performance Management Guide.
"Paging-space thresholds tuning", AIX Documentation: Performance Management Guide.
Developing and Porting C and C++ Applications on AIX, IBM Redbook.
Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築することが可能です。しかし、この手法はWindowsネイティブビルド、(第16章を参照)には及ばないので、もはや推奨されません。
ソースから構築する場合、以下のCygwin特有の差異に注意し、通常のインストール手順に従って進めます（つまり、./configure; make; など）。
Windowsユーティリティの前で、使用するCygwin bin ディレクトリのパスを設定します。コンパイルにおける問題を回避する助けになります。
GNU make コマンドは"gmake"ではなく、"make"と呼ばれます。
adduserコマンドはサポートされていません。Windows NT、2000、またはXP上の適切なユーザ管理アプリケーションを使用してください。そうでなければ、この手順を飛ばします。
suコマンドはサポートされていません。Windows NT、2000、またはXP上でsuをシミュレートするため、sshを使用します。そうでなければ、この手順を飛ばします。
OpenSSLはサポートされていません。
共有メモリサポートのためにcygserverを開始します。行うためには、コマンド/usr/sbin/cygserver &を入力します。このプログラムはPostgreSQLサーバを起動するとき、または（initdbで）データベースクラスタを初期化するときときはいつでも必要です。システム資源が欠けていることによるPostgreSQLの失敗を避けるため、デフォルトのcygserver設定は（例えばSEMMNSを増加させることで）変更される必要があります。
同時実行回帰試験（make check）は、エラーまたはハングアップで拒否された接続の原因となるlisten()バックログキューのオーバフローにより、誤った回帰試験失敗を生成する可能性があります。make 変数MAX_CONNECTIONSを使用して、最大接続数を制限できます。つまり次のようにします。
make MAX_CONNECTIONS=5 check
（いくつかのシステムでは、同時接続を10まで広げられます。）
Windows NTサービスとしてcygserverとPostgreSQLサーバをインストールすることができます。これを実現する方法は、CygwinのPostgreSQLバイナリパッケージに含まれるREADME文書を参照してください。それは/usr/share/doc/Cygwinディレクトリにインストールされます。
PostgreSQL 7.3以上は、適切なシステムパッチレベルと構築ツールが与えられているとして、HP-UX 10.Xまたは11.Xが稼動するSeries 700/800 PA-RISCコンピュータで動作します。少なくとも１つの開発者が定期的にHP-UX 10.20で試験を行っており、HP-UX 11.00と11.11上へのインストールが成功していることの報告を受けています。
PostgreSQLのソース配布物は別として、GNU make（HPのmakeは通りません）と、GCCもしくはHPのANSI Cコンパイラの全部いずれかが必要です。配布物tarボールではなくCVSソースから構築を行う時は、Flex（GNU lex）とBison（GNU yacc）も必要です。同時に、正確に最新のHPパッチが当たっていることの確認を推奨します。HP-UX 11.11上で64ビット構築を行うのであれば最小限、PHSS_30966 (11.11)またはその後継パッチが必要です。さもないと、initdbがハングアップします。以下を参考にしてください。
PHSS_30966 s700_800 ld(1) and linker tools cumulative patch
一般原則として、HPのCコンパイラを使用する場合、libcとld/dldパッチとコンパイラパッチが最新版でなければなりません。それらの最新パッチの無償コピーについては、http://itrc.hp.comおよび ftp://us-ffs.external.hp.com/のHPサポートサイトを見てください。PA-RISC 2.0装置上でGCCを使用して64-ビットバイナリを構築したい場合、GCC 64-ビット版を使用しなければなりません。HP-UX PA-RISCとItanium用のバイナリはhttp://www.hp.com/go/gccから入手できます。同時にbinutilsも入手しインストールすることを忘れないでください。
PA-RISC 2.0装置上での構築で、PA-RISC 1.1装置で稼動するコンパイル済みのバイナリが必要な場合、CFLAGSで+DAportableを指定する必要があります。
HP-UX Itanium装置上で構築するのであれば、依存するパッチまたはその後継のパッチが当たった最新のHP ANSI Cコンパイラが必要です。以下です。
PHSS_30848 s700_800 HP C Compiler (A.05.57)
PHSS_30849 s700_800 u2comp/be/plugin library Patch
HPのCコンパイラとGCCの２つが存在するとき、configure実行時に明示的に使用するコンパイラを指定したい場合、HPのCコンパイラでは、
./configure CC=cc
または、GCCの場合は、
./configure CC=gcc
のようにします。この設定を省略すると、選択できる場合にはconfigureはgccを選びます。
デフォルトのインストール対象配置場所は/usr/local/pgsqlで、/optのような場所に変更したい場合もあると思われます。そうであれば、--prefixスイッチをconfigureします。
回帰試験において、幾何試験で下位ビット桁の差異があるかもしれません。これはどのコンパイラを使用しているか、使用している数学ライブラリのバージョンは何かに依存し、変化します。その他のエラーは原因を疑ってください。
PostgreSQLは無事に、MIPSProコンパイラのバージョン 7.30、7.3.1.2m、7.3、および7.4.4mが有効なIRIX 6.5.5m、6.5.12、6.5.13、および6.5.26が稼動するMIPS r8000、r10000（ip25とip27の双方)、およびr12000（ip35）演算処理装置での実行が報告されています。
MIPSProの完全なANSI C コンパイラが必要です。GCCで構築しようとするとき問題があります。それは、ある種類の構造を返す関数の使用に関連した、知られているGCCのバグ（バージョン3.0時点で修正されていない）です。バグはinet_ntoa、inet_lnaof、inet_netof、inet_makeaddr、およびsemctlのような関数に影響します。libgccでのそれらの関数にコードのリンクを強制して修正ができそうですが、未だ検証されていません。
MIPSProコンパイラのバージョン7.4.1mは不正なコードを生成することが知られています。症状はデータベースを開始する際、"invalid primary checkpoint record（無効な主チェックポイントレコード）"となることです。バージョン7.4.4mは大丈夫ですが、その中間にあるバージョンは不明確です。
次のようなコンパイル問題があるかもしれません。
cc-1020 cc: ERROR File = pqcomm.c, Line = 427
The identifier "TCP_NODELAY" is undefined.
if (setsockopt(port->sock, IPPROTO_TCP, TCP_NODELAY,幾つかのバージョンはTCP定義をsys/xti.hに含みますので、src/backend/libpq/pqcomm.cとsrc/interfaces/libpq/fe-connect.cに#include <sys/xti.h>を加える必要があります。これに遭遇した場合、報告してもらえると適切な修正を開発できます。
回帰試験の中で、これは使用しているFPUに依存し、幾何試験で下位ビット桁の差異があるかもしれません。その他のエラーは原因を疑ってください。
Windows用PostgreSQLは、Unixのような構築環境であるMinGW、またはMicrosoftのVisual C++コンパイラ一式を使って構築できます。 MinGW構築形式はこの章で記述されている通常の構築システムを使用します。 Visual C++構築は、第16章で 記述されたように全く異なった働きをします。それは完全にネイティブ構築で、MinGWのような追加ソフトウェアを使用しません。 既製のインストーラファイルがメインのPostgreSQLウェブサイトから入手できます。
ネイティブWindows移植には、Windows 2000以降の32ビットもしくは64ビット版Windowsが必要です。より早期のオペレーティングシステムは充分な構造基盤を所有していません（但し、Cygwinはそれら上で使える可能性があります）。Unixのような構築ツールであるMinGWと、configureのようなシェルスクリプトを実行するのに必要なUnixツールの収集であるMSYSは、http://www.mingw.org/からダウンロード可能です。結果としてのバイナリ実行にはどれも必要なく、バイナリ作成のためのみ必要になります。
全てをインストールした後、MSYSコンソールはデータを一時的にメモリに保存しておくバッファリングに問題があるので、CMD.EXE下でpsqlを実行することを推奨します。
PostgreSQLはSCO UnixWare 7 と SCO OpenServer 5上で構築できます。OpenServerについて、OpenServer Development Kit または the Universal Development Kitのいずれかが使用できます。しかし、以下に記載するような微調整が必要です。
SCO Skunkware CDの複写がどこにあるかを知る必要が有ります。Skunkware CDはUnixWare 7 と 現在バージョンのOpenServer 5に含まれています。Skunkwareは、Internetで入手可能な数多くのよく知られているプログラムの直ぐインストールできるようにプリペアドバージョンを含んでいます。例えば、gzip、gunzip、GNU Make,、Flex、およびBisonは全て含まれています。UnixWare 7.1に対しては、このCDは現在"Open License Software Supplement"のように名称付けられています。このCDを持っていない場合、その中にあるソフトウェアはhttp://www.sco.com/skunkware/から入手できます。
SkunkwareはUnixWare と OpenServer用に異なったバージョンがあります。以下に注意書きされている点を除き、オペレーティングシステムに対して適切なバージョンをインストールしたことを確認してください。
UnixWare 7.1.3とそれ以降上で、GNU MakeそのものとしてUDK CDの中にGCCコンパイラが含まれます。
GNU Makeプログラムを使用する必要があり、それはSkunkware CDの中にあります。デフォルトでは/usr/local/bin/makeとしてインストールします。SCO makeプログラムとの混乱を避けるため、GNU makeをgmakeと名称変更した方が便利かもしれません。
UnixWare 7.1.3およびそれ以上で、GNU MakeプログラムはUDK CDのOSTK部分で、/usr/gnu/bin/gmakeにあります。
ReadlineライブラリはSkunkware CDにあります。しかし、UnixWare 7.1 Skunkware CDにはありません。もしUnixWare 7.0.0 または 7.0.1 Skunkware CDを所有していれば、そこからインストールできます。そうでない場合、ftp://ftp.sco.com/skunkwareを試してください。
デフォルトでReadlineは/usr/local/lib と /usr/local/includeにインストールします。しかし、PostgreSQL のconfigureプログラムは援助無しにそこにあることを見つけません。Readlineをインストールしたなら、configureで以下のオプションを使ってください。
./configure --with-libraries=/usr/local/lib --with-includes=/usr/local/include
もしOpenServer上で新規のUniversal Development Kit (UDK) コンパイラを使用しているのであれば、以下のようにUDKライブラリの場所を指定する必要があります。
./configure --with-libraries=/udk/usr/lib --with-includes=/udk/usr/include
Putting these together with the Readline options from above:
./configure --with-libraries="/udk/usr/lib /usr/local/lib" --with-includes="/udk/usr/include /usr/local/include"
デフォルトで、PostgreSQLマニュアルページは/usr/local/pgsql/manにインストールされます。デフォルトで、UnixWareはマニュアルページとしてその場所を見ません。マニュアルページを読めるようにするには、以下の例のように、/etc/default/manのMANPATH変数を変更します。
MANPATH=/usr/lib/scohelp/%L/man:/usr/dt/man:/usr/man:/usr/share/man:scohelp:/usr/local/man:/usr/local/pgsql/man
OpenServerについてマニュアルページが使用できるようにするため幾つかの追加研究が注ぎ込まれる必要があります。その理由はマニュアルシステムは他のプラットフォームとは多少異なるからです。現在、PostgreSQLはそれら全てをインストールしません。
将来追補7.1.1bを含んだOpenUNIX 8.0.0（UnixWare 7.1.2）と共にリリースされたものより早期のコンパイラに対して、CFLAGSまたはCC環境変数で-Xbを指定する必要があります。これが指摘するところは、インライン関数を参照するtuplesort.cをコンパイルするエラーです。明らかに、これは7.1.2(8.0.0)とそれ以降のコンパイラで変更されています。
configureオプションの--enable-thread-safetyを使用するのであれば、全てのlibpq-使用プログラム上で-Kpthreadを使用しなければなりません。libpqはpthread_*呼び出しを使用しますが、-Kpthread/-Kthreadフラグを伴わないと有効ではありません。
PostgreSQLはSolaris上でとても良くサポートされています。オペレーティングシステムが更新されればされる程、問題点の遭遇は少なくなります。以下に詳細を示します。
PostgreSQLはSolaris 10（update 2から）のセットになっています。公式パッケージは同時にhttp://pgfoundry.org/projects/solarispackages/から入手できます。Solarisのより古いバージョン（8、9）のパッケージは、http://www.sunfreeware.com/もしくは http://www.blastwave.org/から入手できます。
GCCもしくはSunのコンパイラ一式により構築できます。より良いコード最適化のため、SunのコンパイラはSPARC構造上においては、強調して推奨されます。Sunのコンパイラを使用するのであれば、/usr/ucb/ccを選択せず、/opt/SUNWspro/bin/ccを使用するように注意してください。
http://developers.sun.com/sunstudio/downloads/からSun Studioをダウンロードできます。数多くのGNUツールがSolaris 10に統合されていて、さもなくばSolaris companion CDの中にあります。Solarisのより古いバージョンに対するパッケージを好むのであれば、それらのツールはhttp://www.sunfreeware.com もしくはhttp://www.blastwave.orgにあります。ソースの方が良いという方はhttp://www.gnu.org/order/ftp.htmlを覗いてみてください。
OpenSSLサポート付きでPostgreSQLを構築するとき、以下に示したファイルでコンパイルエラーを受け取ることがあります。
src/backend/libpq/crypt.c
src/backend/libpq/password.c
src/interfaces/libpq/fe-auth.c
src/interfaces/libpq/fe-connect.c
これは標準/usr/include/crypt.hヘッダファイルとOpenSSLから供給されるヘッダファイル間での名前空間衝突によるものです。
OpenSSLインストレーションを0.9.6aに更新することでこの問題は解決されます。Solaris 9とそれ以降のバージョンは、より新しいOpenSSLバージョンを持っています。
もしconfigureが失敗したテストプログラムについてエラーを出す場合、たぶん実行時のリンカーがlibz、libreadline、またはlibsslのような非標準のライブラリを見つけ出せないことによります。それを正しい場所に指し示すため、configureコマンドラインでLDFLAGS環境変数を以下のように設定します。
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
より詳細な情報はldマニュアルページを参照ください。
Solaris 7以前の64bit版のlibcにはバグのあるvsnprintfルーチンがあり、それはPostgreSQLのエラーコアダンプに繋がります。
既知の最も単純な回避策は、ライブラリの複写ではなく、自身のvsnprintfバージョンを使うように仕向けることです。
これを行うためには、configureを実行した後、configureで生成されたファイルを編集します。
つまり、src/Makefile.globalの以下の行
LIBOBJS =
を次のように変更します。
LIBOBJS = snprintf.o
（この変数に既に他のファイルが列挙されているかもしれません。その順序は関係ありません。）その後、通常通りに構築してください。
SPARC構造においては、コンパイルするためにSun Studioを強く推奨します。特筆するような速さのバイナリを生成するため、-xO5最適化フラグを使用してみてください。浮動小数点演算と、（-fastのような）errno演算を修正するどんなフラグも使ってはいけません。それらのフラグはdate/time演算を例にするように、PostgreSQLの標準ではない動作をさせることがあります。
SPARCで64-バイナリの使用をおこなう理由がないのであれば、32-バージョンを選択してください。64-ビット操作はより遅いのと、64-バイナリは32-ビット変異体より遅いのです。そして別の見地から、 AMD64 CPUファミリー上の32-ビットコードはネイティブでなく、そしてなぜ32-ビットコードがこのCPU一族上で余りにも遅いのかの理由でもあります。
幾つかのPostgreSQLとSolarisを調整する秘訣はhttp://www.sun.com/servers/coolthreads/tnb/applications_postgresql.jspにあります。この論文はT2000ぷラットフォームに主として焦点が当てられていますが、その他のハードウェア上でも同様に有用なアドバイスになるでしょう。
そのとおりです。DTraceを使うことができます。より詳細な情報は 項26.4を参照してください。更に進んだ情報をhttp://blogs.sun.com/robertlor/entry/user_level_dtrace_probes_in文書で見つけることもできます。
以下のようなエラーメッセージでpostgres実行形式のリンクがアボートするのを体験した場合、そのDTraceインストールが静的関数におけるプローブを扱うには古すぎると言うことです。Solaris 10u4もしくはそれより新しいものが必要です。
Undefined first referenced symbol in file AbortTransaction utils/probes.o CommitTransaction utils/probes.o ld: fatal: Symbol referencing errors. No output written to postgres collect2: ld returned 1 exit status gmake: *** [postgres] Error 1