本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に16.2を注意して読んでください。 またリグレッションテスト結果の解釈については第32章を確認してください。
ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。
AIX上でPostgreSQLは動作しますが、6.1より前のAIXのバージョンには様々な問題がありますので、勧められません。
GCCまたは在来のIBMコンパイラxlcが使用できます。
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部分のように、ページングスペース割り当て方式とメモリ不足によるプロセス停止は、これが問題となるのであれば、システム全体またはプロセス全体を基準として設定可能です。
Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築することが可能です。 しかし、この手法はWindowsネイティブビルド(第17章を参照)には及ばないので、もはや推奨されません。
ソースから構築する場合、以下のCygwin特有の差異に注意し、Unix形式のインストール手順に従って進めます（つまり、./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ディレクトリにインストールされます。
最近のmacOSのリリースでは、システムヘッダファイルを見つけるために使われるインクルードスイッチに「sysroot」のパスを埋め込むことが必要です。
これにより、configureでどのSDKのバージョンが使われたかに依存して、configureスクリプトの出力が変わることになります。
これは簡単なシナリオでは問題を引き起こさないでしょうが、サーバのコードが構築されたのとは異なるマシンで拡張を構築するなどのようなことを試みているのだとしたら、異なるsysrootのパスを利用するように強制することが必要です。
そうするには、PG_SYSROOTを設定してください。例えば以下のようにです。
make PG_SYSROOT=/desired/path all
自分のマシンでの適切なパスを見つけるには、以下のようにしてください。
xcodebuild -version -sdk macosx Path
コアサーバを構築するのに使われたのとは異なるsysrootのバージョンを使って拡張を構築することは、実のところ勧められないことに注意してください。最悪の場合、デバッグの難しいABIの不一致を招くかもしれません。
configureにPG_SYSROOTを指定することで、configureの時にデフォルトでないsysrootのパスを選ぶこともできます。
./configure ... PG_SYSROOT=/desired/path
macOSの「System Integrity Protection」 (SIP)機能は、DYLD_LIBRARY_PATHの必要な設定をテスト対象の実行ファイルに渡すのを妨げますので、make checkを壊します。
make checkの前にmake installとすることで回避できます。
ですが、PostgreSQLの開発者はほとんど単にSIPをオフにしています。
Windows用PostgreSQLは、Microsoftオペレーティングシステム用のUnixに似た構築環境であるMinGW、またはMicrosoftのVisual C++コンパイラ一式を使って構築できます。 MinGW版の構築は本章で記述されている通常の構築システムを使用します。Visual C++構築は、第17章で記述するようにまったく異なった動作をします。
ネイティブに移植された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のコンパイラを強く推奨します。
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マニュアルページを参照ください。
SPARCアーキテクチャにおけるコンパイルでは、Sun Studioを強く推奨します。
特筆するような速さのバイナリを生成するため、-xO5最適化フラグを使用してみてください。
浮動小数点演算と、（-fastのような）errno演算を修正するようなフラグはすべて使ってはいけません。
SPARCで64ビットバイナリを使用する理由がないのであれば、32ビット版を選択してください。 64ビット操作はより遅く、64ビットバイナリは32ビット版より遅いのです。 一方で、AMD64 CPUファミリ上の32ビットコードはネイティブではありません。そのため、このCPUファミリでは32ビットコードは非常に低速です。
そのとおりです。DTraceを使うことができます。より詳細な情報は27.5を参照してください。
以下のようなエラーメッセージでpostgres実行形式のリンクが中断することを体験した場合、そのDTraceインストールが静的関数におけるプローブを扱うには古すぎると言うことです。
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