★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

17.7. プラットフォーム特有の覚書

本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に17.2を注意して読んでください。 またリグレッションテスト結果の解釈については第33章を確認してください。

ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。

17.7.1. AIX

GCCまたは在来のIBMコンパイラxlcを使用して、AIX上でPostgreSQLを構築できます。

AIX 7.1より前のバージョンは、PostgreSQLコミュニティではテストもサポートもされていません。

17.7.1.1. メモリ管理

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_CNTRLMAXDATA=0xn0000000に設定します。ここで、1 <= n <= 8です。そして異なる値とpostgresql.conf設定で満足に稼働する構成を見つけ出します。 このようにLDR_CNTRLを使用すると、AIXに対してサーバがヒープにかかわらず、256 MBセグメントに割り当てられたMAXDATAバイトセットを持つようにさせたい意図を表明します。 稼働する構成を見つけたとき、意図したヒープ容量をデフォルトで使用するようにldeditを使用してバイナリを変更できます。 同じ効果を得るため、configure LDFLAGS="-Wl,-bmaxdata:0xn0000000"を渡してPostgreSQLを再構築することもできます。

64-ビット構築に対し、OBJECT_MODEを64に設定し、configureCC="gcc -maix64"LDFLAGS="-Wl,-bbigtoc"を渡します。 (xlcに対するオプションは異なるかもしれません。) OBJECT_MODEのexportを省略すると、構築はリンカエラーで失敗することがあります。 OBJECT_MODEが設定された場合、aras、およびldのようなAIXの構築ユーティリティにどの種類のオブジェクトがデフォルトで対応されるのかを伝えます。

デフォルトで、ページングスペースのオーバーコミットが起こることがあります。 これが起こることを経験したことはありませんが、AIXはメモリを使い切って、オーバーコミットがアクセスされたときにプロセスをkillします。 システムが別のプロセスに対する十分なメモリがないことを判断したためにフォークが失敗するという、これとよく似たことは経験したことがあります。 多くの他のAIX部分のように、ページングスペース割り当て方式とメモリ不足によるプロセス停止は、これが問題となるのであれば、システム全体またはプロセス全体を基準として設定可能です。

17.7.2. Cygwin

Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築できます。 しかし、この手法はWindowsネイティブビルド第18章を参照)には及ばないので、もはや推奨されません。

ソースから構築する場合、以下の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ディレクトリにインストールされます。

17.7.3. macOS

PostgreSQLmacOSでソースから構築するには、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の不一致を招くかもしれません。

configurePG_SYSROOTを指定することで、configureの時にデフォルトでないsysrootのパスを選ぶこともできます。

./configure ... PG_SYSROOT=/desired/path

これは主に他のバージョンのmacOS用にクロスコンパイルするのに有用でしょう。 結果として作られる実行ファイルが現在のホストで動作する保証はありません。

-isysrootオプションを完全に抑制するには、以下のようにします(存在しないパス名であればどのようなものであっても動作します)。

./configure ... PG_SYSROOT=none

これはApple製でないコンパイラで構築するのに有用かもしれませんが、この状況はPostgreSQLの開発者がテストもサポートもしていないことに注意してください。

macOSSystem Integrity Protection (SIP)機能は、DYLD_LIBRARY_PATHの必要な設定をテスト対象の実行ファイルに渡すのを妨げますので、make checkを壊します。 make checkの前にmake installとすることで回避できます。 ですが、PostgreSQLの開発者はほとんど単にSIPをオフにしています。

17.7.4. MinGW/ネイティブWindows

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を実行することを推奨します。

17.7.4.1. Windows上でのクラッシュダンプの収集

もしWindows上のPostgreSQLがクラッシュした場合、Unixにおけるコアダンプと似た、クラッシュの原因を追跡するために使用できるminidumpsを生成できます。 このダンプはWindows Debugger ToolsVisual Studioを使うことで解析できます。Windowsにてダンプを生成できるように、crashdumpsという名前のサブディレクトリをデータベースクラスタディレクトリの中に作成します。 ダンプは、クラッシュ時の現在時間と原因となったプロセスの識別子を元にした一意な名前としてこのディレクトリの中に生成されます。

17.7.5. Solaris

PostgreSQLはSolaris上でとても良くサポートされています。 オペレーティングシステムが更新されればされる程、問題点の遭遇は少なくなります。

17.7.5.1. 必要なツール

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を参照してください。

17.7.5.2. 失敗したテストプログラムについてconfigureが出すエラー

もしconfigureが失敗したテストプログラムについてエラーを出す場合、おそらく実行時のリンカがlibz、libreadline、またはlibsslのような非標準のライブラリを見つけ出せないことによります。 それを正しい場所に指し示すため、configureコマンドラインでLDFLAGS環境変数を例えば以下のように設定します。

configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"

より詳細な情報はldマニュアルページを参照してください。

17.7.5.3. 最適性能を得るためのコンパイル

SPARCアーキテクチャにおけるコンパイルでは、Sun Studioを強く推奨します。 特筆するような速さのバイナリを生成するため、-xO5最適化フラグを使用してみてください。 浮動小数点演算と、(-fastのような)errno演算を修正するようなフラグはすべて使ってはいけません。

SPARCで64ビットバイナリを使用する理由がないのであれば、32ビット版を選択してください。 64ビット操作はより遅く、64ビットバイナリは32ビット版より遅いのです。 一方で、AMD64 CPUファミリ上の32ビットコードはネイティブではありません。そのため、このCPUファミリでは32ビットコードは非常に低速です。

17.7.5.4. PostgreSQLをトレースするためのDTrace使用

そのとおりです。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以降が必要です。