本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に17.1を注意して読んでください。 またリグレッションテスト結果の解釈については第33章を確認してください。
ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。
GCCまたは在来のIBMコンパイラxlc
を使用して、AIX上でPostgreSQLを構築できます。
AIX 7.1より前のバージョンは、PostgreSQLコミュニティではテストもサポートもされていません。
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です。そして異なる値とn
0000000postgresql.conf
設定で満足に稼働する構成を見つけ出します。
このようにLDR_CNTRL
を使用すると、AIXに対してサーバがヒープにかかわらず、256 MBセグメントに割り当てられたMAXDATA
バイトセットを持つようにさせたい意図を表明します。
稼働する構成を見つけたとき、意図したヒープ容量をデフォルトで使用するようにldedit
を使用してバイナリを変更できます。
同じ効果を得るため、configure LDFLAGS="-Wl,-bmaxdata:0x
を渡してPostgreSQLを再構築することもできます。
n
0000000"
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ネイティブビルド(第18章を参照)には及ばないので、もはや推奨されません。
ソースから構築する場合、以下のCygwin特有の差異に注意し、Unix形式のインストール手順に従って進めます(つまり、./configure;make
; など)。
Windowsユーティリティの前に使用するCygwinのbinディレクトリのパスを設定します。 コンパイルにおける問題を回避する助けになります。
adduser
コマンドはサポートされていません。
Windowsでは適切なユーザ管理アプリケーションを使用してください。
そうでない場合は、このステップをスキップしてください。
su
コマンドはサポートされていません。
Windows上で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をmacOSでソースから構築するには、Appleのコマンドライン開発ツールをインストールすることが必要で、次のようにすれば行えます
xcode-select --install
(確認のためGUIダイアログウィンドウが現れることに注意してください)。 Xcodeもインストールして構いませんし、しなくても構いません。
最近のmacOSのリリースでは、システムヘッダファイルを見つけるために使われるインクルードスイッチに「sysroot」のパスを埋め込むことが必要です。
これにより、configureでどのSDKのバージョンが使われたかに依存して、configureスクリプトの出力が変わることになります。
これは簡単なシナリオでは問題を引き起こさないでしょうが、サーバのコードが構築されたのとは異なるマシンで拡張を構築するなどのようなことを試みているのだとしたら、異なるsysrootのパスを利用するように強制することが必要です。
そうするには、PG_SYSROOT
を設定してください。例えば以下のようにです。
make PG_SYSROOT=/desired/path
all
自分のマシンでの適切なパスを見つけるには、以下のようにしてください。
xcrun --show-sdk-path
コアサーバを構築するのに使われたのとは異なるsysrootのバージョンを使って拡張を構築することは、実のところ勧められないことに注意してください。最悪の場合、デバッグの難しいABIの不一致を招くかもしれません。
configureにPG_SYSROOT
を指定することで、configureの時にデフォルトでないsysrootのパスを選ぶこともできます。
./configure ... PG_SYSROOT=/desired/path
これは主に他のバージョンのmacOS用にクロスコンパイルするのに有用でしょう。 結果として作られる実行ファイルが現在のホストで動作する保証はありません。
-isysroot
オプションを完全に抑制するには、以下のようにします(存在しないパス名であればどのようなものであっても動作します)。
./configure ... PG_SYSROOT=none
これはApple製でないコンパイラで構築するのに有用かもしれませんが、この状況はPostgreSQLの開発者がテストもサポートもしていないことに注意してください。
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++構築は、第18章で記述するようにまったく異なった動作をします。
ネイティブに移植されたWindows版ではWindows 2000以降の32ビットまたは64ビット版が必要です。
これより前のオペレーティングシステムには十分な構造基盤がありません(ただし、Cygwinはそれら上で使える可能性があります)。
Unixに似た構築ツールであるMinGWと、configure
のようなシェルスクリプトを実行するために必要なUnixツール群であるMSYSは、http://www.mingw.org/からダウンロード可能です。
作成されたバイナリの実行にはいずれも必要ありません。バイナリの作成のためのみ必要です。
MinGWを使って64ビット版バイナリをビルドするためには、https://mingw-w64.org/から64ビット用のツールを入手してインストールし、PATH
にあるbinディレクトリへそれらを入れ、そして--host=x86_64-w64-mingw32
オプション付きで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
を使用するように注意してください。
https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/からSun Studioをダウンロードできます。 数多くのGNUツールがSolaris 10に統合、もしくはSolaris companion CDの中にあります。 Solarisのより古いバージョンに対するパッケージが必要であれば、それらのツールはhttp://www.sunfreeware.comにあります。 ソースの方が良いという方はhttps://www.gnu.org/prep/ftpを参照してください。
もし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を使うことができます。より詳細な情報は28.5を参照してください。
もしpostgres
の実行形式をリンクして作ろうとした時に、以下のようなメッセージが出て中断した場合は、
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
DTraceのインストールが古すぎて、静的関数でプローブを処理できません。 DTraceを使用するには、Solaris 10u4以降が必要です。