他のバージョンの文書 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

16.4. インストール手順

  1. 構成

    インストール手順の最初のステップは、システムに合わせてソースツリーを設定し、使用するオプションを選択することです。 configureスクリプトを実行することでこれを行います。 デフォルトのインストールを行う場合は、単に以下を入力してください。

    ./configure
    

    このスクリプトは、各種のシステムに依存した変数の値を決定するために多くの試験を行い、使用中のオペレーティングシステムが持つどんなクセでも検出し、最終的に構築用ツリーに結果を記録するためのファイルをいくつか作成します。構築用のディレクトリを別の場所にしたい場合は、ソースツリーの外のディレクトリでconfigureを実行することもできます。この処理はVPATHの構築も呼び出します。どのように行うかは下記を参照して下さい。

    mkdir build_dir
    cd build_dir
    
    /path/to/source/tree/configure [オプションはここに]
    make
    

    デフォルトの構成では、サーバ、ユーティリティの他に、Cコンパイラだけを必要とするクライアントアプリケーションやインタフェースを構築します。 デフォルトでは、全てのファイルは/usr/local/pgsql以下にインストールされます。

    configureに以下のコマンドラインオプションを1つ以上指定することで、構築処理やインストール処理を変更することができます。

    --prefix=PREFIX

    /usr/local/pgsqlではなく、PREFIXディレクトリ以下に全てのファイルをインストールします。 ファイルは実際には様々なサブディレクトリにインストールされ、PREFIXディレクトリの直下にインストールされるファイルはありません。

    特別な必要性があるのであれば、以下のオプションを使用して個々のサブディレクトリを変更することもできます。 しかし、これらをそのまま使用した場合、インストレーションは位置再変更可能になります。 つまり、インストールの後にディレクトリを移動することができます (mandocの場所はこの影響を受けません。)

    インストールの位置再変更のために、configure--disable-rpathを使用しようと考えるかもしれません。 その場合は、オペレーティングシステムにその共有ライブラリの場所を通知する必要があるでしょう。

    --exec-prefix=EXEC-PREFIX

    アーキテクチャ依存のファイルをPREFIXの設定とは別の接頭辞EXEC-PREFIX以下にインストールすることができます。 ホスト間でアーキテクチャ非依存のファイルを共有する場合に便利です。 省略した場合、EXEC-PREFIXPREFIXと同じに設定され、アーキテクチャに依存するファイルも非依存なファイルも同じツリー以下にインストールされます。 ほとんどの場合、これが望まれています。

    --bindir=DIRECTORY

    実行可能プログラム用のディレクトリを指定します。 デフォルトではEXEC-PREFIX/binであり、通常/usr/local/pgsql/binとなります。

    --sysconfdir=DIRECTORY

    各種設定ファイル用のディレクトリを設定します。 デフォルトではPREFIX/etcです。

    --libdir=DIRECTORY

    ライブラリや動的ロード可能モジュールをインストールする場所を設定します。 デフォルトはEXEC-PREFIX/libです。

    --includedir=DIRECTORY

    CおよびC++のヘッダファイルをインストールするディレクトリを設定します。 デフォルトはPREFIX/includeです。

    --datarootdir=DIRECTORY

    いろいろな種類の読み取り専用データファイル用のルートディレクトリを設定します。 これは後述のオプションの一部についてのデフォルトを設定するだけです。 デフォルトはPREFIX/shareです。

    --datadir=DIRECTORY

    インストールプログラムが使用する読み取り専用のディレクトリを設定します。 デフォルトはDATAROOTDIRです。 これはインストールするデータベースファイルがどこに設置されるかとは関係ないことを覚えておいてください。

    --localedir=DIRECTORY

    特にメッセージ翻訳カタログファイルのロケールデータをインストールするディレクトリを設定します。 デフォルトはDATAROOTDIR/localeです。

    --mandir=DIRECTORY

    PostgreSQL付属のマニュアルページがこのディレクトリ以下の、対応するmanxサブディレクトリにインストールされます。 デフォルトはDATAROOTDIR/manです。

    --docdir=DIRECTORY

    manページを除いた、ドキュメント一式ファイルをインストールするルートディレクトリを設定します。 これは以下のオプションのデフォルトのみを設定します。 このオプションのデフォルト値はDATAROOTDIR/doc/postgresqlです。

    --htmldir=DIRECTORY

    PostgreSQLのHTML形式化文書一式はこのディレクトリの下にインストールされます。デフォルトはDATAROOTDIRです。

    注記

    /usr/local/includeといった)共用のインストール場所に、システムの他の名前空間に影響を与えることなくPostgreSQLをインストールすることができるような配慮がなされています。 まず、完全に展開したディレクトリ名にpostgrespgsqlという文字列が含まれていない場合、/postgresqlという文字列が自動的にdatadirsysconfdirdocdirに追加されます。 例えば、接頭辞として/usr/localを使用する場合、文書は/usr/local/doc/postgresqlにインストールされますが、接頭辞が/opt/postgresの場合は/opt/postgres/docにインストールされます。 クライアントインタフェース用の外部向けCヘッダファイルはincludedirにインストールされ、名前空間の問題はありません。 内部向けヘッダファイルやサーバ用ヘッダファイルは、includedir以下の非公開ディレクトリにインストールされます。 各インタフェース用のヘッダファイルにアクセスする方法についての情報は、そのインタフェースの文書を参照してください。 最後に、適切であれば、動的ロード可能モジュール用にlibdir以下にも非公開用のサブディレクトリが作成されます。

    --with-extra-version=STRING

    PostgreSQLバージョン番号にSTRINGを追加します。 これは、例えば、リリースされていないGitスナップショットからビルドしたバイナリや、git describe識別子やディストリビューションパッケージリリース番号のような追加のバージョン文字列のあるカスタムパッチを含むバイナリに印をつけるために使えます。

    --with-includes=DIRECTORIES

    DIRECTORIESには、コンパイラがヘッダファイルを検索するディレクトリのリストをコロンで区切って指定します。 (GNU Readlineなどの)オプションのパッケージが非標準的な場所にインストールされている場合、このオプションと、おそらく対応する--with-librariesオプションを使用する必要があります。

    例: --with-includes=/opt/gnu/include:/usr/sup/include

    --with-libraries=DIRECTORIES

    DIRECTORIESには、ライブラリを検索するディレクトリのリストをコロンで区切って指定します。 パッケージが非標準的な場所にインストールされている場合は、おそらくこのオプション(と対応する--with-includesオプション)を使用する必要があります。

    例: --with-libraries=/opt/gnu/lib:/usr/sup/lib

    --enable-nls[=LANGUAGES]

    各国語サポート(NLS)、つまり、英語以外の言語によるプログラムメッセージの表示機能を有効にします。 LANGUAGESはオプションであり、サポートさせたい言語コードを空白で区切ったリストを指定します。例えば、--enable-nls='de fr'などとします (指定したリストと実際に用意された翻訳との論理積が自動的に計算されます)。 リストに何も指定しなかった場合、利用可能な翻訳すべてがインストールされます。

    このオプションを使用するためには、gettext APIの実装が必要です。 上記を参照してください。

    --with-pgport=NUMBER

    サーバとクライアントのデフォルトのポート番号をNUMBERに設定します。 デフォルトは5432です。 このポートは後でいつでも変更することができますが、ここで指定した場合、サーバとクライアントはコンパイル時に同じデフォルト値を持つようになります。 これは非常に便利です。 通常、デフォルト以外の値を選択すべき唯一の理由は、同じマシンで複数のPostgreSQLを稼働させることです。

    --with-perl

    PL/Perlサーバサイド言語を構築します。

    --with-python

    PL/Pythonサーバサイド言語を構築します。

    --with-tcl

    PL/Tclサーバサイド言語を構築します。

    --with-tclconfig=DIRECTORY

    Tclは、Tclへのインタフェースモジュールを構築するために必要な設定情報を含むtclConfig.shファイルをインストールします。 このファイルは通常、自動的に一般的に知られている場所にありますが、もしTclの別のバージョンを使いたい場合は、検索対象のディレクトリを指定することができます。

    --with-gssapi

    GSSAPI認証のサポートを構築します。 多くのシステムでは、GSSAPIシステム(通常Kerberosインストレーションの一部)はデフォルトの検索場所(例えば/usr/include/usr/lib)にインストールされていません。 そのため、--with-includes--with-librariesオプションをさらに追加して使わなければいけません。 configureは、処理を進める前にGSSAPIが正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリを検査します。

    --with-krb-srvnam=NAME

    GSSAPIで使用されるKerberosのサービスプリンシパルのデフォルトの名前です。 デフォルトではpostgresです。 これを変える理由はWindows環境がない限り、特にありません。 Windows環境がある場合は大文字のPOSTGRESに設定する必要があります。

    --with-llvm

    LLVMに基づいたJITコンパイル (第32章を参照)のサポート有効にして構築します。 これには、LLVMライブラリがインストールされていることが必要です。 LLVMの要求される最小のバージョンは現在3.9です。

    要求されるコンパイルオプションを見つけるためにllvm-configが使われます。 llvm-config、それからサポートされるバージョンすべてのllvm-config-$major-$minorPATHで探します。 それで正しいバイナリが見つからなければ、正しいllvm-configへのパスを指定するためにLLVM_CONFIGを使ってください。 例えば、以下の通りです。

    ./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'
    

    LLVMサポートはclang互換のコンパイラ(必要なら環境変数CLANGで指定してください)と動作するC++コンパイラ(必要なら環境変数CXXで指定してください)を要求します。

    --with-icu

    ICUライブラリのサポートを有効にして構築します。 これには、ICU4Cパッケージがインストールされていることが必要です。 ICU4Cの要求される最小のバージョンは現在4.2です。

    デフォルトでは、pkg-configが必要なコンパイルオプションを見つけるのに使われます。 これはICU4Cバージョン4.6またはそれ以降でサポートされています。 より古いバージョンの場合やpkg-configが使えない場合には、以下の例のように、変数ICU_CFLAGSICU_LIBSconfigureに指定できます。

    ./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'
    

    (ICU4Cがコンパイラのデフォルトの検索パスにあるのなら、pkg-configの使用を避けるため、例えばICU_CFLAGS=' 'のような空でない文字列を指定することも必要です。)

    --with-openssl

    SSL(暗号化)接続のサポートを有効にして構築します。 これには、OpenSSLパッケージがインストールされていることが必要です。 configureは、処理を進める前にOpenSSLのインストールを確認するために、必要なヘッダファイルとライブラリを検査します。

    --with-pam

    PAM(プラガブル認証モジュール)のサポートを有効にして構築します。

    --with-bsd-auth

    BSD認証のサポートを有効にして構築します。 (BSD認証フレームワークは今のところOpenBSDだけで利用可能です。)

    --with-ldap

    認証および接続パラメータ検索用のLDAPサポートを有効にして構築します。 (詳細は34.17および20.10を参照してください。) Unixでは、OpenLDAPパッケージがインストールされていることが必要です。 WindowsではデフォルトのWinLDAPライブラリが使用されます。 configureは、処理を進める前にOpenLDAPのインストールが十分されているかどうかを確認するために、必要なヘッダファイルとライブラリを検査します。

    --with-systemd

    systemdサービス通知のサポートを有効にして構築します。 サーババイナリがsystemdの元で開始する場合には、これは統合を改善しますが、それ以外は影響はありません。詳細は18.3を参照してください。 このオプションを使えるようにするには、libsystemdと関連するヘッダファイルをインストールすることが必要です。

    --without-readline

    Readlineライブラリ(およびlibedit)の使用を防止します。 これによりpsqlでのコマンドライン編集および履歴が無効となるため、推奨されません。

    --with-libedit-preferred

    GPLライセンスのReadlineではなくBSDライセンスのlibeditライブラリを優先して使用します。 このオプションは両方のライブラリがインストールされている場合にのみ重要です。 この場合デフォルトでReadlineが使用されます。

    --with-bonjour

    Bonjourサポートを有効にして構築します。 これには、オペレーティングシステムがBonjourをサポートしていることが必要です。 macOSでは推奨します。

    --with-uuid=LIBRARY

    指定されたUUIDライブラリを使用して(UUIDを生成する関数を提供する)uuid-osspモジュールをビルドします。 LIBRARYは以下のいずれかでなければなりません。

    • bsdはFreeBSD、NetBSD、その他のBSD派生システムにあるUUID関数を使います。

    • e2fse2fsprogsプロジェクトで作られたUUIDライブラリを使います。 このライブラリはたいていのLinuxシステムとmacOSにあり、また、その他のプラットフォームでも入手可能です。

    • OSSP UUIDライブラリを使用します。

    --with-ossp-uuid

    --with-uuid=osspに相当する古いものです。

    --with-libxml

    libxmlを使用して構築します(SQL/XMLサポートが有効になります)。 この機能のためにはlibxmlバージョン2.6.23以降が必要です。

    libxmlがインストールするxml2-configプログラムを使用して、必要なコンパイラオプション、リンクオプションを検出することができます。 PostgreSQLは、見つけられればこのプログラムを使用します。 通常以外の場所にインストールしたlibxmlインストレーションを指定するためには、環境変数XML2_CONFIGがそのインストレーション用のxml2-configプログラムを指し示すように設定してください。 または、--with-includesおよび--with-librariesを使用してください。

    --with-libxslt

    xml2モジュールを構築する場合はlibxsltを使用してください。 xml2はXMLのXSL変換を行うために、このライブラリに依存します。

    --disable-float4-byval

    float4値の渡しを無効にし、参照渡しで渡すようにします。 このオプションは性能に関するコストがかかりますが、C言語で開発された古いユーザ定義の関数との互換性を保持する場合やversion 0呼び出し規約を使用する場合に必要になります。 長期的に見てより良い解決方法はこうした関数を更新して、version 1呼び出し規約を使用するようにすることです。

    --disable-float8-byval

    float8値の渡しを無効にし、参照渡しで渡すようにします。 このオプションは性能に関するコストがかかりますが、C言語で開発された古いユーザ定義の関数との互換性を保持する場合やversion 0呼び出し規約を使用する場合に必要になります。 長期的に見てより良い解決方法はこうした関数を更新して、version 1呼び出し規約を使用するようにすることです。 このオプションはfloat8に影響するだけではなく、int8やタイムスタンプなど一部の関連した型についても影響することに注意してください。 32ビットプラットフォームでは、--disable-float8-byvalがデフォルトで--enable-float8-byvalを選択することはできません。

    --with-segsize=SEGSIZE

    セグメントサイズをギガバイト単位で指定します。 大規模なテーブルはこのセグメントサイズと同じサイズの複数のオペレーティングシステムのファイルに分割されます。 これにより多くのプラットフォームで存在するファイルサイズ上限に関する問題を防ぎます。 デフォルトのセグメントサイズは1ギガバイトで、サポートされるすべてのプラットフォームで安全です。 使用するオペレーティングシステムがラージファイルをサポートしていれば(最近はほとんどサポートしています)、より大きなセグメントサイズを使用することができます。 非常に大規模なテーブルで作業する時のファイル記述子の消費数を減らすために、これが役に立つでしょう。 しかし、プラットフォーム、または使用予定のファイルシステムでサポートされる値以上に大きな値を指定しないように注意してください。 tarなどの、使用したいその他のツールにも使用できるファイルサイズに制限があることがあります。 絶対に必要ではありませんが、この値を2のべき乗にすることを勧めます。 この値の変更にはinitdbが必要であることに注意してください。

    --with-blocksize=BLOCKSIZE

    キロバイト単位でブロック容量を設定します。 これはテーブル内でのストレージとI/Oの単位です。 8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は他の値が役立ちます。 値は1から32(キロバイト)の範囲の2のべき乗でなければなりません。 この値の変更はinitdbを必要とすることを覚えておいてください。

    --with-wal-blocksize=BLOCKSIZE

    キロバイト単位でWALブロック容量を設定します。 これはWALログ内でのストレージとI/Oの単位です。 8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は大きめの値が役立ちます。 値は1から64(キロバイト)の範囲の2のべき乗でなければなりません。 この値の変更はinitdbを必要とすることを覚えておいてください。

    --disable-spinlocks

    PostgreSQLがそのプラットフォーム用のCPUスピンロックをサポートしない場合でも、構築に成功するようにします。 スピンロックのサポートの欠落により、性能は悪化します。 したがって、このオプションは、構築が失敗し、その原因が使用するプラットフォームでスピンロックサポートが欠落している場合にのみ使用してください。 使用するプラットフォームにおけるPostgreSQLの構築にこのオプションが必要とされた場合は、PostgreSQL開発者にその問題を報告してください。

    --disable-strong-random

    そのプラットフォーム上でPostgreSQLが強い乱数のサポートを受けられない場合でも、構築には成功するようにします。 乱数源は、一部の認証プロトコルやpgcryptoモジュール内の一部のルーチンで必要です。 --disable-strong-randomは暗号論的に強い乱数を必要とする機能を無効にして、認証のソルト値や問い合わせのキャンセル鍵の生成を弱い疑似乱数生成器で置き換えます。 それにより認証はより安全ではなくなるでしょう。

    --disable-thread-safety

    クライアントライブラリのスレッドセーフを無効にします。 これにより、libpqECPGプログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御できなくなります。

    --with-system-tzdata=DIRECTORY

    PostgreSQLは、日付時刻に関する操作で必要な、独自の時間帯データベースを持ちます。 実際のところ、この時間帯データベースはFreeBSD、Linux、Solarisなどの多くのオペレーティングシステムで提供されるIANA時間帯データベースと互換性があります。 このため、これを再びインストールすることは冗長です。 このオプションが使用されると、DIRECTORYにあるシステムが提供する時間帯データベースがPostgreSQLソース配布物に含まれるものの代わりに使用されます。 DIRECTORYは絶対パスで指定しなければなりません。 /usr/share/zoneinfoがオペレーティングシステムの一部でよく使われます。 インストール処理が時間帯データが一致しない、またはエラーがあることを検知しないことに注意してください。 このオプションを使用する場合、指定した時間帯データがPostgreSQLで正しく動作するかどうかを検証するためにリグレッションテストを実行することが推奨されています。

    このオプションは、対象オペレーティングシステムを熟知しているパッケージ配布者を主な対象としたもの。 このオプションを使用する大きな利点は、多くの局所的な夏時間規則の変更があってもPostgreSQLパッケージを更新する必要がないことです。 他の利点として、時間帯データベースファイルをインストール時に構築する必要がありませんので、PostgreSQLのクロスコンパイルをより簡単に行うことができます。

    --without-zlib

    Zlibライブラリの使用を抑制します。 これは、pg_dumppg_restoreにおける圧縮アーカイブのサポートを無効にします。 このオプションは、このライブラリが利用できないごく少数のシステム向けだけのものです。

    --enable-debug

    全てのプログラムとライブラリをデバッグシンボル付きでコンパイルします。 これは、問題を解析するためにデバッガ内でプログラムを実行できることを意味します。 これはインストールする実行形式ファイルのサイズをかなり大きくし、また、GCC以外のコンパイラでは、通常はコンパイラによる最適化が行われなくなりますので、低速になります。 しかし、デバッグシンボルが利用できるということは、発生した問題に対応する時に非常に便利です。 現在のところ、GCC を使用している場合にのみ、稼働用のインストレーションにこのオプションを使用することを推奨します。 しかし、開発作業時やベータ版を実行する時は、常にこれを有効にすべきです。

    --enable-coverage

    GCCを使用している場合、すべてのプログラムとライブラリはコードカバレッジ試験機構付きでコンパイルされます。 実行すると、これらは構築用ディレクトリ内にコードカバレッジメトリックを持ったファイルを生成します。 詳細は33.5を参照してください。 このオプションはGCC専用であり、また、開発作業中に使用するためのものです。

    --enable-profiling

    GCCを使用する場合、すべてのプログラムとライブラリがプロファイリング可能状態でコンパイルされます。 バックエンドの終了時、プロファイリングに使用するgmon.outファイルを含むサブディレクトリが作成されます。 このオプションはGCCを使用する場合のみ使用でき、開発作業を行う時に使用します。

    --enable-cassert

    サーバにおける、多くのあり得ない状態をテストするアサーションチェックを有効にします。 これは、プログラムの開発のためには測り知れない価値がありますが、このテストによりサーバはかなり低速になります。 また、このテストを有効にしても、サーバの安定性が向上するとは限りません! アサーションチェックは、重要度によって分類されていませんので、比較的害がないようなバグでも、アサーション失敗をトリガとした、サーバの再起動が行われてしまいます。 稼働用にこのオプションを使用することは推奨されませんが、開発作業時やベータ版を実行する場合は、これを有効にすべきです。

    --enable-depend

    自動依存関係追跡を有効にします。 このオプションを使用すると、ヘッダファイルが変更された場合に、影響を受ける全てのオブジェクトファイルが再構築されるように、makefile が設定されます。 これは開発作業時には有用ですが、単に一度コンパイルしインストールするだけであれば、これは無駄なオーバーヘッドです。 現在のところ、GCC でのみ、このオプションは動作します。

    --enable-dtrace

    動的追跡ツールDTraceのサポートを有効にしてPostgreSQLをコンパイルします。より詳細な情報は28.5を参照してください。

    dtraceプログラムを指し示すためにDTRACE環境変数を設定することができます。 dtraceは通常、検索パス内に存在しない可能性がある/usr/sbin以下にインストールされていますので、この設定はよく必要になります。

    さらにdtraceプログラム用のコマンドラインオプションをDTRACEFLAGS環境変数で指定することができます。 Solarisで64ビットバイナリでDTraceをサポートするには、DTRACEFLAGS="-64"をconfigureに指定してください。 例えばGCCコンパイラを使用する場合は以下のようにします。

    ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
    

    Sunのコンパイラを使用する場合は以下のようにします。

    ./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
    

    --enable-tap-tests

    Perl TAPツールを使ったテストを有効にします。 これにはPerlのインストールとPerlモジュールIPC::Runが必要です。 詳細は33.4を参照してください。

    configureが選ぶものと違うCコンパイラを使いたいという場合には、CC 環境変数をその使用したいプログラムに設定することができます。 デフォルトでは、configureは利用できるのであればgccを、利用できなければプラットフォームのデフォルト(通常cc)を選択します。 同様に、デフォルトのコンパイラフラグは必要に応じてCFLAGS変数で上書きすることもできます。

    次のようにして、configureコマンドラインに環境変数を指定することができます。

    ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
    

    以下は、この方式で設定可能な重要な環境変数の一覧です。

    BISON

    Bisonプログラム。

    CC

    Cコンパイラ。

    CFLAGS

    Cコンパイラに渡すオプション。

    CLANG

    --with-llvmでコンパイルされた場合、ソースコードのインライン展開を処理するために使われるclangプログラムへのパス。

    CPP

    Cプリプロセッサ。

    CPPFLAGS

    Cプリプロセッサに渡すオプション。

    CXX

    C++コンパイラ。

    CXXFLAGS

    C++コンパイラに渡すオプション。

    DTRACE

    dtraceプログラムの場所。

    DTRACEFLAGS

    dtraceプログラムに渡すオプション。

    FLEX

    Flexプログラム。

    LDFLAGS

    実行ファイルや共有ライブラリにリンクする場合に使用するオプション。

    LDFLAGS_EX

    実行ファイルのリンク時のみに追加されるオプション。

    LDFLAGS_SL

    共有ライブラリのリンク時のみに追加されるオプション。

    LLVM_CONFIG

    LLVMインストレーションの場所を特定するために使用するllvm-configプログラム。

    MSGFMT

    多言語サポート(NLS)用のmsgfmtプログラム。

    PERL

    Perlインタプリタプログラム。 これは、PL/Perl構築に関する依存性を決定するために使用されます。 デフォルトはperlです。

    PYTHON

    Pythonインタプリタプログラム。 これは、PL/Python構築に関する依存性を決定するために使用されます。 またここでPython 2または3を指定するかどうかで(あるいは暗黙的に選択されます)、どちらのPL/Python言語が利用可能になるかも決まります。 46.1を参照してください。 設定されていなければ、python python3 python2の順で調べられます。

    TCLSH

    Tclインタプリタプログラム。 これは、PL/Tcl構築に関する依存性を決定するために使用され、Tclスクリプト内を置き換えます。

    XML2_CONFIG

    libxmlインストレーションの場所を特定するために使用するxml2-configプログラムです。

    configureが選んだコンパイラフラグに対して、事後にフラグを追加することが有用な場合があります。 重要な例は、configureに渡すCFLAGSgcc-Werrorオプションを含められないことです。なぜなら、そうするとconfigureの組み込みテストの多くが失敗するからです。 そのようなフラグを追加するには、makeを実行する時にCOPT環境変数に含めてください。 configureで設定されたCFLAGSオプションとLDFLAGSオプションの両方に、COPTの内容が追加されます。 例えば、以下のようにします。

    make COPT='-Werror'
    

    または

    export COPT='-Werror'
    make
    

    注記

    サーバ内部のコード開発を行う場合、--enable-cassert(多数の実行時エラーチェックを有効にする)オプションと--enable-debug(デバッグツールの利便性を向上させる)オプションの使用を推奨します。

    GCCを使う場合、少なくとも-O1レベルの最適化で構築することがベストです。なぜなら、何の最適化もしない(-O0) と、重要なコンパイル警告(初期化されていない変数の使用など)が無効になるからです。 しかし、最適化を行うことでソースコードとコンパイルされたコードのステップは1対1とはならなくなるため、デバッグは複雑になるかもしれません。 最適化されたコードのデバッグに悩まされてしまう場合は、関心のある特定のファイルに対して-O0で再コンパイルしてください。 これを実行するための簡単な方法は、make PROFILE=-O0 file.oのように、make経由でオプションを渡すことです。

    COPTPROFILEの環境変数は、PostgreSQLのmakefileでは実際には全く同一に扱われます。 どちらを使うかは好みの問題ですが、開発者の一般的な習慣では、一時的にフラグを調整するにはPROFILEを使い、永続的に保持するものにはCOPTを使います。

  2. 構築

    構築作業を開始するには、以下のいずれかを入力してください。

    make
    make all
    

    GNU makeを使用することを忘れないでください。) ハードウェアに依存しますが、構築作業には数分かかります。 最後に以下のような行が表示されるはずです。

    All of PostgreSQL successfully made. Ready to install.
    

    もし、ドキュメント(HTMLやman)や追加モジュール(contrib)を含め、構築可能なもの全てを構築したい場合、次の様に実施します。

    make world
    

    最終行は次のように表示されるはずです。

    PostgreSQL, contrib, and documentation successfully made. Ready to install.
    

    手動で指定するのではなく、別のMakefileから構築をしたい場合には、例えば以下のようにMAKELEVELを削除するか、0に設定しなければなりません。

    build-postgresql:
            $(MAKE) -C postgresql MAKELEVEL=0 all
    

    上記に失敗すると、通常はヘッダファイルが見つからないという奇妙なエラーメッセージが出る場合があります。

  3. リグレッションテスト

    インストールを行う前に、新しく構築したサーバをテストしたい場合、この時点でリグレッションテストを実行することができます。 リグレッションテストとは、使用するマシンにおいてPostgreSQLが、開発者の想定通りに動作することを検証するためのテストのまとまりです。 次のように入力します。

    make check
    

    (これは root では動作しません。 非特権ユーザとして実行してください。) 第33章にはテスト結果の表示に関する詳しい情報があります。 同じコマンドを入力することで、後にいつでもテストを繰り返すことができます。

  4. ファイルのインストール

    注記

    もし既存のシステムのアップグレードをする場合、DBクラスタのアップグレードの解説が記載されている18.6を参照してください。

    PostgreSQLをインストールするには、以下を入力してください。

    make install
    

    これは、ファイルをステップ 1で指定されたディレクトリにインストールします。 その領域に書き込むための権限を持っていることを確認してください。 通常はこのステップはrootで行う必要があります。 代わりに対象とするディレクトリを前もって作成し、適切に権限を調整することも可能です。

    ドキュメント(HTMLやman)をインストールするには、以下を入力して下さい。

    make install-docs
    

    先にすべてを(worldを付けて)構築していた場合には、代わりに以下を実行してください。

    make install-world
    

    これによりドキュメントもインストールされます。

    make installの代わりにmake install-stripを使用することで、インストール時に実行可能ファイルやライブラリをストリップ(strip)することができます。 これにより、多少の容量を節約できます。 デバッグをサポートするように構築している場合でも、ストリップするとデバッグのサポートは実質、除去されてしまいます。 したがって、これはデバッグが必要なくなった場合にのみ実行すべきです。 install-stripは容量を節約するために適切な作業を行おうとしますが、実行可能ファイルから全ての不必要なバイトを完全にストリップすることはできません。 可能な限りのディスク容量を全て節約したい場合は、手動で作業を行う必要があります。

    この標準的なインストール方法では、クライアントアプリケーションの開発に必要なヘッダファイルと、Cで独自の関数やデータ型を作成するといったサーバ側のプログラムの開発用のヘッダファイルが用意されます (PostgreSQL 8.0より前まででは、後で別途make install-all-headersコマンドが必要でした。しかし、この手順は標準のインストールに含まれるようになりました)。

    クライアント側のみのインストール:  クライアントアプリケーションとインタフェースライブラリのみをインストールしたい場合、下記のコマンドを使います。

    make -C src/bin install
    make -C src/include install
    make -C src/interfaces install
    make -C doc install
    

    src/binにはサーバ用の数個のバイナリがあります。これらは小さなものです。

アンインストール:  インストールを取り消すには、make uninstall コマンドを使います。しかし、作成済みのディレクトリは削除されません。

クリーニング:  インストールが終わったら、make clean コマンドを使ってソースツリーから構築用のファイルを削除し、ディスク領域を解放することができます。 configureプログラムが作るファイルは保持されますので、後でmakeコマンドですべてを再構築できます。 ソースツリーを配布された時の状態に戻したい場合は、make distcleanコマンドを使います。 同じソースツリー内で複数のプラットフォーム向けに構築する場合、これを実行して、それぞれのプラットフォームに対し再構成しなければなりません。 (または、未変更のソースツリーを維持するために、各プラットフォームで別々の構築用ツリーを使用してください。)

構築作業を行った後でconfigure用オプションが間違っていることに気付いた場合や、configureの調査結果に何らかの変更を加えた場合(例えば、ソフトウェアのアップグレードなど)、再設定と再構築の前にmake distcleanを行うことをお勧めします。 さもないと、設定選択肢の変更は、必要なところ全てには反映されない可能性があります。