構成 (Configuration)
インストール手順の最初のステップは、システムに合わせてソースツリーを設定し、使用するオプションを選択することです。 configure スクリプトを実行することで行います。 デフォルトのインストールを行う場合は、単に以下を入力して下さい。
./configure
このスクリプトは、各種のシステムに依存した変数の値を推定するために多くの試験を行い、使用中のオペレーティングシステムが持つ奇癖を検出し、最終的に構築用ツリーに結果を記録するためのファイルをいくつか作成します。 (構築用のディレクトリを別の場所にしたい場合は、ソースツリーの外のディレクトリで configure を実行することもできます。)
デフォルトの構成では、サーバ、ユーティリティの他に、C コンパイラだけを必要とするクライアントアプリケーションやインタフェースを構築します。 デフォルトでは、全てのファイルは /usr/local/pgsql 以下にインストールされます。
configure に以下のコマンドラインオプションを 1 つ以上指定することで構築処理やインストール処理を変更することができます。
/usr/local/pgsql ではなく、PREFIX ディレクトリ以下に全てのファイルをインストールします。 ファイルは実際には様々なサブディレクトリにインストールされ、PREFIX ディレクトリの直下にインストールされるファイルはありません。
特別な必要性があるのであれば、以下のオプションを使用して個々のサブディレクトリを変更することもできます。
アーキテクチャ依存のファイルを PREFIX の設定とは別の接頭詞 EXEC-PREFIX 以下にインストールすることができます。 ホスト間でアーキテクチャ非依存のファイルを共有する場合に便利です。 省略した場合、EXEC-PREFIX は PREFIX と同じに設定され、アーキテクチャに依存するファイルも非依存なファイルも同じツリー以下にインストールされます。 ほとんどの場合、これが望まれています。
実行可能プログラム用のディレクトリを指定します。 デフォルトでは EXEC-PREFIX/bin であり、通常、/usr/local/pgsql/bin となります。
インストールされたプログラムで使用される、読み取り専用データファイルのディレクトリを指定します。 デフォルトは PREFIX/share です。 これはデータベースファイルを格納する場所とは全く関係がないことに注意して下さい。
各種設定ファイル用のディレクトリです。 デフォルトでは PREFIX/etc です。
ライブラリや動的ロード可能モジュールをインストールする場所です。 デフォルトは EXEC-PREFIX/lib です。
C および C++ のヘッダファイルをインストールするディレクトリです。 デフォルトは PREFIX/include です。
"マニュアル" ページを除く文書ファイルがこのディレクトリにインストールされます。 デフォルトは PREFIX/doc です。
PostgreSQL 付属のマニュアルページがこのディレクトリ以下の、対応する manx サブディレクトリにインストールされます。 デフォルトは PREFIX/man です。
注意: (/usr/local/include といった) 共用のインストール場所に、システムの他の名前空間に影響を与えることなく PostgreSQL をインストールすることができるような配慮がなされています。 まず、完全に展開したディレクトリ名に "postgres" か "pgsql" という文字列が含まれていない場合、"/postgresql" という文字列が自動的に datadir、sysconfdir、docdir に追加されます。 例えば、PREFIX として /usr/local を使用する場合、文書は /usr/local/doc/postgresql にインストールされますが、PREFIX が /opt/postgres の場合は /opt/postgres/doc にインストールされます。 クライアントインタフェース用の外部向け C ヘッダファイルは includedir にインストールされ、名前空間の問題はありません。 内部向けヘッダファイルやサーバ用ヘッダファイルは、includedir 以下の非公開ディレクトリにインストールされます。 各インタフェース用のヘッダファイルを取り出す方法についての情報は、そのインタフェースの文書を参照して下さい。 最後に、適切であれば、動的ロード可能モジュール用に libdir 以下にも非公開用のサブディレクトリが作成されます。
DIRECTORIES には、コンパイラがヘッダファイルを検索するディレクトリのリストをコロンで区切って指定します。 (GNU Readline などの) オプションのパッケージが非標準的な場所にインストールされている場合、このオプションと、おそらく対応する --with-libraries オプションを使用する必要があります。
例: --with-includes=/opt/gnu/include:/usr/sup/include.
DIRECTORIES には、ライブラリを検索するディレクトリのリストをコロンで区切って指定します。 パッケージが非標準的な場所にインストールされている場合は、おそらくこのオプション (と対応する--with-includes オプション) を使用する必要があります。
例: --with-libraries=/opt/gnu/lib:/usr/sup/lib.
各国語サポート (NLS)、つまり、英語以外の言語によるプログラムメッセージの表示機能を有効にします。 LANGUAGES にはサポート予定言語のコードのリストを空白で区切って指定します。 例えば、--enable-nls='de fr' などとします (指定したリストと実際に用意された翻訳との論理積が自動的に計算されます)。 リストに何も指定しなかった場合、利用可能な翻訳全てがインストールされます。
このオプションを使用するためには、gettext API の実装が必要です。 上記を参照してください。
サーバとクライアントのデフォルトのポート番号を NUMBER に設定します。 デフォルトは 5432 です。 このポートは後でいつでも変更することができますが、ここで指定した場合、サーバとクライアントはコンパイル時に同じデフォルト値を持つようになります。 これは非常に便利です。 通常、デフォルト以外の値を選択すべき唯一の理由は、同じマシンで複数の PostgreSQL を稼働させることです。
PL/Perl サーバサイド言語を構築します。
PL/Python サーバサイド言語を構築します。
Tcl/Tk を必要とするコンポーネント、libpgtcl、pgtclsh、pgtksh、PL/Tcl を構築します。 --without-tk については下記を参照してください。
--with-tcl とこのオプションを指定した場合は、Tk を必要とするプログラム (つまり pgtksh) は除外されます。
Tcl/Tk は、Tcl または Tk のインタフェースモジュールを構築するために必要な設定情報を含むファイル tclConfig.sh と tkConfig.sh をインストールします。 これらのファイルは通常、自動的に一般的に知られている場所にインストールされますが、もし Tcl か Tk の別のバージョンを使いたい場合は、インストールしたいディレクトリを指定できます。
JDBC ドライバと関連する Java パッケージを構築します。
Kerberos 認証のサポートを構築します。 Kerberos のバージョンは 4 か 5 のどちらかを使うことができますが、両方使うことはできません。 DIRECTORY 引数には、インストールされた Kerberos のトップディレクトリを指定します。 /usr/athena がデフォルトとして仮定されます。 もし関係するヘッダファイルとライブラリが共通の親ディレクトリの下になければ、--with-includes と --with-libraries オプションをさらに追加して使わなければいけません。 一方、もし必要とされるファイルがデフォルトで検索される場所 （たとえば /usr/lib） にある場合、引数はなくても構いません。
configure は、処理を進める前に Kerberos が正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリをチェックします。
Kerberos のサービスプリンシパルの名前です。 デフォルトは "postgres" です。 これを変える理由は特にありません。
SSL (暗号化) 接続のサポートを有効にして構築します。 これには、OpenSSL パッケージがインストールされていなければなりません。 DIRECTORY 引数には、OpenSSL をインストールしたトップディレクトリを指定します。 デフォルトは /usr/local/ssl です。
configure は、処理を進める前に OpenSSL のインストールを確認するために、必要なヘッダファイルとライブラリをチェックします。
Readline ライブラリの使用を防止します。 これにより psql でのコマンドライン編集および履歴が無効となるため、推奨されません。
Rendezvousサポートを有効にして構築します。
PostgreSQLがそのプラットフォーム用のCPUスピンロックをサポートしない場合でも、構築に成功するようにします。 スピンロックのサポートの欠落により、性能は悪化します。 従って、このオプションは、構築が失敗し、その原因が使用するプラットフォームでスピンロックサポートが欠落している場合にのみ使用して下さい。
クライアントライブラリをスレッドセーフで作成します。 これにより、libpq や ECPG プログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御することができます。
Zlibライブラリの使用を抑制します。 これは、pg_dumpにおける圧縮サポートを無効にします。 このオプションは、このライブラリが利用できないごく少数のシステム向けだけのものです。
全てのプログラムとライブラリをデバッグシンボル付きでコンパイルします。 これは、問題を解析するためにデバッガを使用してプログラムを実行できることを意味します。 これはインストールする実行形式ファイルのサイズをかなり大きくし、また、GCC 以外のコンパイラでは、通常はコンパイラによる最適化が行われなくなりますので、低速になります。 しかし、デバッグシンボルが利用できるということは、発生した問題に対応する時に非常に便利です。 現在のところ、GCC を使用している場合にのみ、稼働用のインストレーションにこのオプションを使用することを推奨します。 しかし、開発作業時やベータ版を実行する時は、常にこれを有効にすべきです。
サーバにおける、多くの"あり得ない"状態をテストする アサーション チェックを有効にします。 これは、プログラムの開発のためには測り知れない価値がありますが、このテストにより多少低速になります。 また、このテストを有効にすると、サーバの安定性を向上させるとは限りません! アサーションチェックは、重要度によって分類分けされていませんので、比較的害がないようなバグでも、アサーション失敗をトリガとした、サーバの再起動が行われてしまいます。 現在のところ、稼働用にこのオプションを使用することは推奨されませんが、開発作業時やベータ版を実行する場合は、これを有効にすべきです。
自動依存関係追跡を有効にします。 このオプションを使用すると、ヘッダファイルが変更された場合に、影響を受けるすべてのオブジェクトファイルが再構築されるように、makefile が設定されます。 これは開発作業時には有用ですが、単に一度コンパイルしインストールするだけであれば、これは無駄なオーバーヘッドです。 現在のところ、GCC を使用している場合にのみ、このオプションは動作します。
configure が選ぶものと違う C コンパイラを使いたいという場合には、CC 環境変数を、その使用したいプログラムに設定することができます。 デフォルトでは、configure はプラットフォームにおいて不適切でないかぎり、gcc を選択します。 同様に、デフォルトのコンパイラフラグは CFLAGS 変数で上書きすることもできます。
次のようにして、configure コマンドラインに環境変数を指定することができます。
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
構築
構築作業を開始するには、以下を入力して下さい。
gmake
(GNU make を使用することを忘れないで下さい)。 ハードウェアに依存しますが、構築作業には、5 分から 30 分くらいかかります。 最後に以下のような行が表示されるはずです。
All of PostgreSQL is successfully made. Ready to install.
リグレッションテスト
インストールを行う前に、新しく構築したサーバをテストしたい場合、この時点でリグレッションテストを実行することができます。 リグレッションテストとは、使用するマシンにおいて PostgreSQL が、開発者の想定どおりに動作することを検証するためのテストのまとまりです。 次のように入力します。
gmake check
(これは root では動作しません。 非特権ユーザとして実行して下さい)。 第26章にはテスト結果の表示に関する詳しい情報があります。 同じコマンドを入力することで、後にいつでもテストを繰り返すことができます。
ファイルのインストール
注意: もし既存のシステムのアップグレードをしていて、古いファイルの上から新しいファイルをインストールするという場合は、上記の 項14.4 で説明したように、データをバックアップして、古いサーバをこの段階でシャットダウンしなければなりません。
PostgreSQL をインストールするには、以下を入力して下さい。
gmake install
これは、ファイルを ステップ1 で指定されたディレクトリにインストールします。 その領域に書き込むための権限を持っていることを確認してください。 通常はこのステップは root で行う必要があります。 代わりに対象とするディレクトリを前もって作成し、適切に権限を調整することも可能です。
gmake install の代わりに gmake install-strip を使用することで、インストール時に実行可能ファイルやライブラリをストリップ (strip) することができます。 これにより、多少の容量を節約できます。 デバッグをサポートするように構築している場合、ストリップすることでデバッグのサポートも除去されます。 したがって、これはデバッグが必要なくなった場合にのみ実行すべきです。 install-strip は容量を節約するために適切な作業を行おうとしますが、実行可能ファイルからすべての不必要なバイトを完全にストリップすることはできません。 可能な限りのディスク容量をすべて節約したい場合は、手動で作業を行う必要があります。
この標準的なインストール方法では、クライアントアプリケーションの開発に必要なヘッダファイルのみが用意されます。 (Cで作成した独自の関数やデータ型など)サーバ側のプログラムの開発を計画している場合、PostgreSQL のインクルードツリー全体を対象のインクルードディレクトリにインストールしなければなりません。 そのためには以下を行なって下さい。
gmake install-all-headers
これにより、1,2メガバイトインストール先に追加されます。 また、これは、ソースツリー全体を参照するために保持する予定がない場合にのみ有用です。 (保持していれば、サーバ側のソフトウエアを構築する時にそのソース内のインクルードディレクトリを使用すればよいのです。)
クライアント側のみのインストール. クライアントアプリケーションとインタフェースライブラリのみをインストールしたい場合、下記のコマンドを使います。
gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install
アンインストール. インストールを取り消すには、gmake uninstall コマンドを使います。しかし、作成済みのディレクトリは削除されません。
クリーニング. インストールが終わったら、gmake clean コマンドを使ってソースツリーから構築用のファイルを削除し、ディスクの領域を空けることができます。 これはconfigureプログラムが作るファイルを保持するので、後で gmake コマンドですべてを再構築できます。 ソースツリーを配布された時の状態に戻したい場合は、gmake distclean コマンドを使います。 もし同じソースツリーから複数のプラットフォーム向けに構築する場合、構築する度に、これを実行しconfigureをし直さなければいけません。
構築作業を行った後でconfigure用オプションが間違っていることに気づいた場合や、configureの調査結果に何らかの変更を加えた場合 (例えば、ソフトウェアのアップグレードなど)、再設定と再構築の前に gmake distclean を行うことをお勧めします。 さもないと、設定選択肢の変更は、必要なところ全てに反映されない可能性があります。