インストール手順

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 15章ソースコードからインストール | 早送り | 次のページ

# 15.5. インストール手順

1. 構成（Configuration）

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

       ./configure

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

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

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

   `--prefix=`PREFIX``

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

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

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

   `--exec-prefix=`EXEC-PREFIX``

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

   `--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``

     いろいろな種類の読み取り専用データファイル用のルートディレクトリを設定します。

   `--datadir=`DIRECTORY``

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

   `--localedir=`DIRECTORY``

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

   `--mandir=`DIRECTORY``

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

   `--docdir=`DIRECTORY``

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

   `--htmldir=`DIRECTORY``

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

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

   `--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-krb5`

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

   `--with-krb-srvnam=`NAME``

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

   `--with-openssl`

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

   `--with-pam`

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

   `--with-ldap`

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

   `--without-readline`

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

   `--with-libedit-preferred`

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

   `--with-bonjour`

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

   `--with-ossp-uuid`

     `contrib/uuid-ossp`を構築する場合はOSSP UUIDライブラリを使用してください。 このライブラリはUUIDを生成する関数を提供します。

   `--with-libxml`

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

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

   `--with-libxslt`

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

   `--disable-integer-datetimes`

     日付時刻および時間間隔の格納に64ビット整数格納方式を無効にし、その代わり浮動小数点で格納します。PostgreSQLリリース8.4以前では日付時刻の浮動小数点格納方式がデフォルトでしたが、`timestamp`値がとる値の全ての範囲でマイクロ秒精度をサポートしないため現在非推奨となりました。しかし、整数ベースの日付時刻格納には64-ビット整数型が必要です。従って、このオプションはこの型が使えない場合での使用、または以前のPostgreSQLバージョン用に書かれたアプリケーションとの互換性を保たなければならない場合に使用します。 詳細は 項8.5を参照してください。

   `--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単位です。８キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は他の値が役立ちます。値は1から32（キロバイト）の範囲の２の乗数でなければなりません。この値の変更はinitdbを必要とすることを覚えておいてください。

   `--with-wal-segsize=`SEGSIZE``

     メガバイト単位でWALセグメント容量を設定します。これはWALログ内のそれぞれ個別のファイルの容量です。この容量を調整することで、WALログ配送の粒度を制御するのに役立ちます。デフォルト容量は16メガバイトです。1から64（メガバイト）の範囲の２の乗数でなければなりません。この値の変更はinitdbを必要とすることを覚えておいてください。

   `--with-wal-blocksize=`BLOCKSIZE``

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

   `--disable-spinlocks`

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

   `--enable-thread-safety`

     クライアントライブラリをスレッドセーフで作成します。 これにより、libpqやECPGプログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御することができます。 このオプションは、オペレーティングシステムで適切なスレッド処理がサポートされていることが必要です。

   `--with-system-tzdata=`DIRECTORY``

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

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

   `--without-zlib`

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

   `--enable-debug`

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

   `--enable-coverage`

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

   `--enable-profiling`

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

   `--enable-cassert`

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

   `--enable-depend`

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

   `--enable-dtrace`

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

     `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' ...

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

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

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

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

   `BISON`

     Bisonプログラムです。

   `CC`

     Cコンパイラです。

   `CFLAGS`

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

   `CPP`

     Cプリプロセッサです。

   `CPPFLAGS`

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

   `DTRACE`

     `dtrace`プログラムの場所です。

   `DTRACEFLAGS`

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

   `FLEX`

     Flexプログラムです。

   `LDFLAGS`

     リンカに渡すオプションです。

   `LDFLAGS_SL`

     共有ライブラリ用のリンカオプションです。

   `MSGFMT`

     多言語サポート（NLS）用の`msgfmt`プログラムです。

   `PERL`

     Perlインタプリタのフルパスです。 これは、PL/Perl構築に関する依存性を決定するために使用されます。

   `PYTHON`

     Pythonインタプリタのフルパスです。 これは、PL/Python構築に関する依存性を決定するために使用されます。

   `TCLSH`

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

   `XML2_CONFIG`

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

2. 構築

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

       gmake

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

       All of PostgreSQL is successfully made. Ready to install.

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

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

       gmake check

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

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

   > 注意: もし既存のシステムのアップグレードをしていて、古いファイルの上から新しいファイルをインストールするという場合は、上記の項15.4で説明したように、確実にデータをバックアップして、処理を進める前に古いサーバをシャットダウンしてください。

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

       gmake install

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

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

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

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

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

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

Windowsにおけるeventlogの登録：. Windows eventlogライブラリをオペレーティングシステムに登録するには、インストール後に以下のコマンドを実行してください。

    regsvr32 pgsql_library_directory/pgevent.dll

これによりイベントビューアで使用されるレジストリ項目が生成されます。

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

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

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

前のページ | ホーム | 次のページ
アップグレード | 上に戻る | インストール後の設定作業