本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に16.2を注意して読んでください。 またリグレッションテスト結果の解釈については第32章を確認してください。
ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。
AIX上でPostgreSQLは動作しますが、適切にインストールをやり遂げるのは挑戦でもあります。
AIXバージョン4.3.3から6.1はサポートされていると考えられます。
GCCまたは在来のIBMコンパイラxlcが使用できます。
一般的に、最新のAIXとPostgreSQLバージョンを使用することが手助けになります。
どのバージョンのAIXが動くと知られているかについての最新情報をビルドファームで見てください。
サポートされるAIXバージョンに対する最低限推奨される修正レベルを示します。
保守レベル 11 + ML11 バンドル以降
保守レベル 9 + ML9 バンドル以降
技術レベル 10 サービスパック 3
技術レベル 7
基本レベル
使用している修正レベルをチェックするには、AIX 4.3.3 から AIX 5.2 ML 7 まではoslevel -r、またはそれ以降のバージョンではoslevel -sを使用します。
もし、/usr/localにインストール済のreadlineやライブラリがある場合は、次のconfigureフラグを加えて下さい。
--with-includes=/usr/local/include
--with-libraries=/usr/local/lib
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にはこの関数にさまざまなバグがあります。
これら設定に関係した問題に遭遇した場合、上記に示されている適切な修正レベルへ更新することが問題解決になります。
あるユーザの報告です。
PostgreSQLバージョン8.1をAIX 5.3で実装している時、統計情報コレクタが「不思議なことに」正常に起動しないという問題が周期的に起こりました。 これは、IPv6の実装における想定外の動作という結果で出現します。 そのため、AIX5.3上では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アドレスの検索が解除されます。
これは、実際には未熟なIPv6サポートに関連する問題の回避策です。AIX5.3のリリースから、IPv6サポートが目に見えて改善されています。 この回避策はAIX5.3上で動きはしますが、この問題に対しての良い解決方法ではありません。 AIX6.1ではIPv6サポートがさらに改善されたため、この対策は不必要になっただけでなく、問題を引き起こすことが報告されています。
AIXはメモリ管理手法の観点から見ると多少独特です。 ギガバイト単位のRAMが空いているサーバがあっても、アプリケーションを実行している時にメモリ不足やアドレス空間エラーが発生することがあります。 こうした例の1つが、見慣れないエラーによる拡張のロードの失敗です。 例えば、PostgreSQLインストレーションの所有者として実行してみます。
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
PostgreSQLインストレーションの処理グループ内の所有者以外として実行してみます。
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
他の実例は、PostgreSQLサーバログ中のメモリ不足エラーで、256 MB以上もしくはその近辺で全てのメモリ割り当てが失敗します。
これら問題のすべての総合原因は、サーバプロセスで使用されるデフォルトのビット割当とメモリモデルです。 デフォルトでは、AIXで構築されたすべてのバイナリは32ビットです。 これは使用中のハードウェアの種類やカーネルに依存しません。 これらの32ビットプロセスは、数個のモデルの1つを使用して256メガバイトのセグメントで割りつけられた4ギガバイトメモリに制限されます。 デフォルトでは、スタックで1つのセグメントとして共有されるものとしてヒープ内の256メガバイト未満の領域が許されます。
上記、plperlの例の場合において、PostgreSQLインストレーションにおけるバイナリのumaskとパーミッションをチェックしてください。
例に関与したバイナリは32-ビットであり、755ではなく750モードでインストールされました。
このような形式で設定されたパーミッションのため、所有者もしくはグループ所有のメンバーのみライブラリを読み込めます。
それは誰もが読み取り可能ではないため、ローダは、そうでない場合に配置される共有ライブラリセグメントにではなく、オブジェクトをプロセスのヒープに配置します。
これに対しての「理想的な」解決策はPostgreSQLの64-ビットビルドを使うことですが、32-ビットプロセッサのシステムでは64-ビットバイナリをビルドできますが実行できないので、常に実務的ではありません。
32-ビットバイナリを要求する場合、PostgreSQLサーバを起動する前にLDR_CNTRLをMAXDATA=0xに設定します。ここで、1 <= n <= 8です。そして異なる値とn0000000postgresql.conf設定で満足に稼動する構成を見つけ出します。
このようにLDR_CNTRLを使用すると、AIXに対してサーバがヒープにかかわらず、256 MBセグメントに割り当てられたMAXDATAバイトセットを持つようにさせたい意図を表明します。
稼動する構成を見つけたとき、意図したヒープ容量をデフォルトで使用するようにldeditを使用してバイナリを変更することができます。
同じ効果を得るため、configure LDFLAGS="-Wl,-bmaxdata:0xを渡してPostgreSQLを再構築することもできます。
n0000000"
64-ビット構築に対し、OBJECT_MODEを64に設定し、configureにCC="gcc -maix64"とLDFLAGS="-Wl,-bbigtoc"を渡します。
（xlcに対するオプションは異なるかもしれません。）
OBJECT_MODEのexportを省略すると、構築はリンカエラーで失敗することがあります。
OBJECT_MODEが設定された場合、ar、as、およびldのようなAIXの構築ユーティリティにどの種類のオブジェクトがデフォルトで対応されるのかを伝えます。
デフォルトで、ページングスペースのオーバーコミットが起こることがあります。 これが起こることを経験したことはありませんが、AIXはメモリを使い切って、オーバーコミットがアクセスされたときにプロセスをkillします。 システムが別のプロセスに対する十分なメモリがないことを判断したためにフォークが失敗するという、これとよく似たことは経験したことがあります。 多くの他のAIX部分のように、ページングスペース割り当て方式とメモリ不足によるプロセス停止は、これが問題となるのであれば、システム全体またはプロセス全体を基準として設定可能です。
「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ネイティブビルド(第17章を参照)には及ばないので、もはや推奨されません。
ソースから構築する場合、以下のCygwin特有の差異に注意し、通常のインストール手順に従って進めます（つまり、./configure;make; など）。
Windowsユーティリティの前に使用するCygwinのbinディレクトリのパスを設定します。 コンパイルにおける問題を回避する助けになります。
adduserコマンドはサポートされていません。Windows NT、2000、またはXP上の適切なユーザ管理アプリケーションを使用してください。
そうでなければ、この手順を飛ばします。
suコマンドはサポートされていません。Windows NT、2000、またはXP上でsuをシミュレートするため、sshを使用します。
そうでなければ、この手順を飛ばします。
OpenSSLはサポートされていません。
共有メモリサポートのためにcygserverを開始します。
これを行うためには、コマンド/usr/sbin/cygserver&を入力します。
このプログラムはPostgreSQLサーバを起動するとき、または（initdbで）データベースクラスタを初期化するときはいつでも必要です。
システム資源が欠けていることによるPostgreSQLの失敗を避けるため、デフォルトのcygserver設定を（例えばSEMMNSを増やすなど）変更する必要があるかもしれません。
いくつかのシステムでは、Cロケール以外を使っている場合に構築が失敗するかもしれません。
これに対処するためには、構築前にexport LANG=C.utf8を実施してロケールをCに設定し、PostgreSQLのインストール後に以前の設定に戻してください。
並行リグレッションテスト（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-UX10.20で試験を行っており、HP-UX11.00と11.11上へのインストールが成功していることの報告を受けています。
PostgreSQLのソース配布物の他に、GNU make（HPのmakeは通りません）と、GCCもしくはHPのANSI Cコンパイラの全部いずれかが必要です。
配布物tarボールではなくGitソースから構築を行う時は、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パッチとコンパイラパッチが最新版でなければなりません。 それらの最新パッチの無償コピーについては、ftp://us-ffs.external.hp.com/のHPサポートサイトを見てください。
PA-RISC 2.0マシン上でGCCを使用して64-ビットバイナリを構築したい場合、GCC 64-ビット版を使用しなければなりません。
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のような場所に変更したい場合もあります。
そのような時は、configureで--prefixスイッチを使用します。
リグレッションテストにおいて、幾何試験で下位ビット桁の差異があるかもしれません。これはどのコンパイラを使用しているか、使用している数学ライブラリのバージョンは何かに依存し、変化します。 その他のエラーは原因を疑ってください。
Windows用PostgreSQLは、Microsoftオペレーティングシステム用のUnixに似た構築環境であるMinGW、またはMicrosoftのVisual C++コンパイラ一式を使って構築できます。 MinGW版の構築は本章で記述されている通常の構築システムを使用します。Visual C++構築は、第17章で記述するようにまったく異なった動作をします。 それは完全にネイティブな構築で、MinGWのような追加ソフトウェアを使用しません。既製のインストーラがPostgreSQLのメインウェブサイトから入手できます。
ネイティブに移植されたWindows版ではWindows 2000以降の32ビットまたは64ビット版が必要です。
これより前のオペレーティングシステムには充分な構造基盤がありません（ただし、Cygwinはそれら上で使える可能性があります）。
Unixに似た構築ツールであるMinGWと、configureのようなシェルスクリプトを実行するために必要なUnixツール群であるMSYSは、http://www.mingw.org/からダウンロード可能です。
作成されたバイナリの実行にはいずれも必要ありません。バイナリの作成のためのみ必要です。
MinGWを使って64ビット版バイナリをビルドするためには、http://mingw-w64.sourceforge.net/から64ビット用のツールを入手してインストールし、PATHにあるbinディレクトリへそれらを入れ、そして--host=x86_64-w64-mingwオプション付きでconfigureを実施します。
MSYSコンソールはバッファリングに問題があるので、すべてをインストールした後にCMD.EXE下でpsqlを実行することを推奨します。
もしWindows上のPostgreSQLがクラッシュした場合、Unixにおけるコアダンプと似た、クラッシュの原因を追跡するために使用できるminidumpsを生成することができます。
このダンプはWindows Debugger ToolsやVisual Studioを使うことで解析できます。Windowsにてダンプを生成できるように、crashdumpsという名前のサブディレクトリをデータベースクラスタディレクトリの中に作成します。
ダンプは、クラッシュ時の現在時間と原因となったプロセスの識別子を元にした一意な名前としてこのディレクトリの中に生成されます。
PostgreSQLはSolaris上でとても良くサポートされています。 オペレーティングシステムが更新されればされる程、問題点の遭遇は少なくなります。 以下に詳細を示します。
GCCもしくはSunのコンパイラ一式により構築できます。
より良いコード最適化のため、SPARCアーキテクチャではSunのコンパイラを強く推奨します。
GCC 2.95.1を使用する場合に問題があったと報告を受けています。GCC 2.95.3以降を勧めます。
Sunのコンパイラを使用するのであれば、/usr/ucb/ccを選択せず、/opt/SUNWspro/bin/ccを使用するように注意してください。
http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/からSun Studioをダウンロードできます。 数多くのGNUツールがSolaris 10に統合、もしくはSolaris companion CDの中にあります。 Solarisのより古いバージョンに対するパッケージを好むのであれば、それらのツールはhttp://www.sunfreeware.comにあります。 ソースの方が良いという方はhttp://www.gnu.org/order/ftp.htmlを参照してください。
もし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ビットコードはネイティブではありません。これが、このCPUファミリで32ビットコードが非常に低速な理由です
そのとおりです。DTraceを使うことができます。より詳細な情報は28.5を参照してください。
以下のようなエラーメッセージで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 make: *** [postgres] Error 1