本節はPostgreSQLのインストールと設定に関する追加のプラットフォーム固有の問題について説明します。 インストール手順、特に17.1を注意して読んでください。 またリグレッションテスト結果の解釈については第31章を確認してください。
ここで触れられていないプラットフォームは、インストールに関してプラットフォーム特有の問題がありません。
Windowsに対するLinux的環境である、Cygwinを使ってPostgreSQLを構築できます。 しかし、この手法はWindowsネイティブビルドには及ばないので、もはや推奨されません。
ソースから構築する場合、以下の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を使って構築できます。 MinGW版の構築は本章で記述されている通常の構築システムを使用します。
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を使うことができます。より詳細な情報は27.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以降が必要です。
ほとんどのユーザには、PostgreSQLウェブサイトのhttps://www.postgresql.org/download/からグラフィカルインストーラパッケージとして入手可能なWindows用のバイナリ配布物をダウンロードすることを推奨します。 ソースからの構築は、PostgreSQLそのもの、もしくはその拡張の開発者のみを対象としています。
Visual Studioを使用したWindowsのPostgreSQLは、17.4で説明されているように、Mesonを使用して構築できます。 ネイティブWindowsポートには、Windows 10以降の32または64ビットバージョンが必要です。
psqlのネイティブビルドはコマンドライン編集をサポートしていません。 Cygwinによる構築はコマンドライン編集をサポートしているので、Windows上でpsqlを対話形式で使用する必要がある場合は、こちらを使うことが推奨されます。
PostgreSQLは、MicrosoftのVisual C++コンパイラ一式を使って構築できます。 これらのコンパイラは、Visual Studio、Visual Studio Express、またはMicrosoft Windows SDKのいくつかのバージョンから入手できます。 Visual Studio環境をまだ設定していない場合、最も簡単な方法は、Visual Studio 2022のコンパイラか、Microsoftから無料でダウンロードできるWindows SDK 10のコンパイラを使用することです。
Microsoftコンパイラ一式で、32ビットと64ビットの両方のビルドが可能です。 PostgreSQLの32-ビットビルドは、Visual Studio 2015からVisual Studio 2022、およびスタンドアローンWindows SDKリリース10以降で可能です。 PostgreSQLの64-ビットビルドは、Microsoft Windows SDKバージョン10以降またはVisual Studio 2015以降でサポートされています。
お使いのビルド環境にサポートされているMicrosoft Windows SDKのバージョンが同梱されていない場合は、https://www.microsoft.com/downloadからダウンロード可能な最新版（現在はバージョン10）にアップグレードすることを推奨します。
SDKのWindows Headers and Librariesを常にインクルードしなければなりません。 Visual C++ Compilersを含むWindows SDKをインストールしている場合、構築のためにVisual Studioは必要ありません。 バージョン8.0aでは、Windows SDKは完全なコマンドライン構築環境を提供していないことに注意してください。
WindowsでPostgreSQLを構築するには、以下のソフトウェアパッケージが必要です。
ビルド生成スクリプトを実行するには、ActiveState Perlが必要です。 MinGWまたはCygwinのPerlは動作しません。 また、PATHに存在する必要があります。 バイナリはhttps://www.activestate.comからダウンロードできます（注:バージョン5.14以降が必要です。 無料の標準配布で十分です）。
BisonとFlexが必要です。 Bisonのバージョン2.3以降のみが動作します。 Flexはバージョン2.5.35以降でなければなりません。
BisonおよびFlexの両方が、MinGWコンパイラ一式の一部としてhttp://www.mingw.org/wiki/MSYSから入手できる、msysツール一式に含まれています。
flex.exeとbison.exeを含むディレクトリをPATH環境変数に追加する必要があります。
MinGWの場合、ディレクトリはMinGWインストールディレクトリの\msys\1.0\binサブディレクトリです。
GnuWin32のBisonディストリビューションでは、C:\Program Files\GnuWin32の様に名前に空白を持つディレクトリにインストールされると正常に機能しないというバグがあります。
代わりにC:\GnuWin32へのインストール、または、PATH環境設定におけるGnuWin32へのNTFSショートネームパスの使用（例えばC:\PROGRA~1\GnuWin32）を検討してください。
次の追加製品は、開始するために必要ではありませんが、完全なパッケージを構築するために必要です。
PL/Tclを構築する時に必要です（注意：バージョン8.4が必要です。 無料の標準配布で十分です）。
リグレッションテストを実行するにはdiffが必要です。 http://gnuwin32.sourceforge.netからダウンロードできます。
NLSサポート付きで構築する場合はgettextが必要です。 http://gnuwin32.sourceforge.netからダウンロードできます。 バイナリ、依存物、開発用ファイルすべてが必要であることに注意してください。
GSSAPI認証をサポートする場合に必要です。 MIT Kerberosはhttps://web.mit.edu/Kerberos/dist/index.htmlからダウンロードできます。
XMLサポートのために必要です。 バイナリはhttps://zlatkovic.com/pub/libxmlから、ソースはhttp://xmlsoft.orgからダウンロードできます。 libxml2はiconvを必要とすることに注意してください。 同じ場所からダウンロードできます。
LZ4圧縮方式のサポートのために必要です。 バイナリとソースはhttps://github.com/lz4/lz4/releasesからダウンロードできます。
Zstandard圧縮方式のサポートのために必要です。 バイナリとソースはhttps://github.com/facebook/zstd/releasesからダウンロードできます。
SSLサポートのために必要です。 バイナリはhttps://slproweb.com/products/Win32OpenSSL.htmlから、ソースはhttps://www.openssl.orgからダウンロードできます。
UUID-OSSPサポート（contribのみ）で必要です。 ソースはhttp://www.ossp.org/pkg/lib/uuid/からダウンロードできます。
PL/Pythonを構築する場合に必要です。 バイナリはhttps://www.python.orgからダウンロードできます。
pg_dumpおよびpg_restoreにおける圧縮をサポートするために必要です。 バイナリはhttps://www.zlib.netからダウンロードできます。
64ビット版Windowsにおいてx64アーキテクチャのみPostgreSQLを構築できます。
同じ構築用ツリーで32ビット版と64ビット版を混在させることはサポートされません。 構築システムは32ビット環境で動作しているか64ビット環境で動作しているかを自動的に検出し、それにしたがってPostgreSQLを構築します。 このため構築作業を始める前に正しいコマンドプロンプトを開始することが重要です。
PythonやOpenSSLなどのサーバサイドのサードパーティ製ライブラリを使用するためには、ライブラリも64ビット版である必要があります。 64ビット版のサーバで32ビット版のライブラリをロードすることはサポートされていません。 PostgreSQLがサポートするサードパーティ製のライブラリで32ビット版しか利用できないものが複数あります。 こうした場合、64ビット版のPostgreSQLで使用することはできません。
もしWindows上のPostgreSQLがクラッシュした場合、Unixにおけるコアダンプと似た、クラッシュの原因を追跡するために使用できるminidumpsを生成できます。
このダンプはWindows Debugger ToolsやVisual Studioを使うことで解析できます。Windowsにてダンプを生成できるように、crashdumpsという名前のサブディレクトリをデータベースクラスタディレクトリの中に作成します。
ダンプは、クラッシュ時の現在時間と原因となったプロセスの識別子を元にした一意な名前としてこのディレクトリの中に生成されます。