./configure make su make install adduser postgres mkdir -p /usr/local/pgsql/data chown postgres /usr/local/pgsql/data su - postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test
この節の残りで詳細を説明します。
設定
インストール手順の最初のステップは、システムに合わせてソースツリーを設定し、使用するオプションを選択することです。
configureスクリプトを実行することでこれを行います。
デフォルトのインストールを行う場合は、単に以下を入力してください。
./configure
このスクリプトは、各種のシステムに依存した変数の値を決定するために多くのテストを行い、使用中のオペレーティングシステムが持つどんなクセでも検出し、最終的に構築用ツリーに結果を記録するためのファイルをいくつか作成します。
構築用のディレクトリを別の場所にしたい場合は、ソースツリーの外のディレクトリでconfigureを実行することもできます。
この処理はVPATH構築と呼ばれます。
どのように行うかは下記を参照してください。
mkdir build_dircd build_dir/path/to/source/tree/configure [オプションはここに]make
デフォルトの構成では、サーバ、ユーティリティの他に、Cコンパイラだけを必要とするクライアントアプリケーションやインタフェースを構築します。
デフォルトでは、全てのファイルは/usr/local/pgsql以下にインストールされます。
configureにコマンドラインオプションを1つ以上指定することで、構築処理やインストール処理を変更できます。
よくあるのは、インストール位置や構築するオプションの機能の設定を変更することでしょう。
configureには数多くのオプションがあり、それは17.3.3に書かれています。
また、configureは、17.3.4に書かれているように特定の環境変数に対応しています。
これは設定を変更する追加の方法を提供します。
構築
構築作業を開始するには、以下のいずれかを入力してください。
makemake all
（GNU makeを使用することを忘れないでください。） ハードウェアに依存しますが、構築作業には数分かかります。
もし、ドキュメント(HTMLやman)や追加モジュール(contrib)を含め、構築可能なものすべてを構築したい場合、次のように入力します。
make world
もし、追加モジュール(contrib)は含めるがドキュメントを含めずに、構築可能なものすべてを構築したい場合、次のように入力します。
make world-bin
手動で指定するのではなく、別のMakefileから構築をしたい場合には、例えば以下のようにMAKELEVELを削除するか、0に設定しなければなりません。
build-postgresql:
$(MAKE) -C postgresql MAKELEVEL=0 all
上記に失敗すると、通常はヘッダファイルが見つからないという奇妙なエラーメッセージが出る場合があります。
リグレッションテスト
インストールを行う前に、新しく構築したサーバをテストしたい場合、この時点でリグレッションテストを実行できます。 リグレッションテストとは、使用するマシンにおいてPostgreSQLが、開発者の想定通りに動作することを検証するためのテストのまとまりです。 次のように入力します。
make check
（これは root では動作しません。 非特権ユーザとして実行してください。） 第33章にはテスト結果の解釈に関する詳しい情報があります。 同じコマンドを入力することで、後にいつでもテストを繰り返すことができます。
ファイルのインストール
もし既存のシステムのアップグレードをする場合、DBクラスタのアップグレードの解説が記載されている19.6を参照してください。
PostgreSQLをインストールするには、以下を入力してください。
make install
これは、ファイルをステップ 1で指定されたディレクトリにインストールします。 その領域に書き込むための権限を持っていることを確認してください。 通常はこのステップをrootで行う必要があります。 代わりに対象とするディレクトリを前もって作成し、適切に権限を調整することも可能です。
ドキュメント（HTMLやman）をインストールするには、以下を入力してください。
make install-docs
上記のようにすべてを（worldを付けて）構築していた場合には、代わりに以下を入力してください。
make install-world
これによりドキュメントもインストールされます。
上記のようにドキュメントを除くすべてを構築していた場合には、代わりに以下を入力してください。
make install-world-bin
make installの代わりにmake install-stripを使用することで、インストール時に実行可能ファイルやライブラリをストリップ（strip）できます。
これにより、多少の容量を節約できます。
デバッグをサポートするように構築している場合でも、ストリップするとデバッグのサポートは実質、除去されてしまいます。
したがって、これはデバッグが必要なくなった場合にのみ実行すべきです。
install-stripは容量を節約するために適切な作業を行おうとしますが、実行可能ファイルから全ての不必要なバイトを完全にストリップすることはできません。
可能な限りのディスク容量をすべて節約したい場合は、手動で作業を行う必要があります。
この標準的なインストール方法では、クライアントアプリケーションの開発に必要なヘッダファイルと、Cで独自の関数やデータ型を作成するといったサーバ側のプログラムの開発用のヘッダファイルが用意されます。
クライアント側のみのインストール: クライアントアプリケーションとインタフェースライブラリのみをインストールしたい場合、下記のコマンドを使います。
make -C src/bin installmake -C src/include installmake -C src/interfaces installmake -C doc install
src/binにはサーバ用の数個のバイナリがあります。これらは小さなものです。
アンインストール:
インストールを取り消すには、make uninstall コマンドを使います。
しかし、作成済みのディレクトリは削除されません。
クリーニング:
インストールが終わったら、make clean コマンドを使ってソースツリーから構築用のファイルを削除し、ディスク領域を解放できます。
configureプログラムが作るファイルは保持されますので、後でmakeコマンドですべてを再構築できます。
ソースツリーを配布された時の状態に戻したい場合は、make distcleanコマンドを使います。
同じソースツリー内で複数のプラットフォーム向けに構築する場合、これを実行して、それぞれのプラットフォームに対し再構成しなければなりません。
（または、未変更のソースツリーを維持するために、各プラットフォームで別々の構築用ツリーを使用してください。）
構築作業を行った後でconfigure用オプションが間違っていることに気付いた場合や、configureの調査結果に何らかの変更を加えた場合（例えば、ソフトウェアのアップグレードなど）、再設定と再構築の前にmake distcleanを行うことをお勧めします。
さもないと、設定選択肢の変更は、必要なところ全てには反映されない可能性があります。
configureオプション #
configureのコマンドラインオプションを以下で説明します。
この一覧は完全なものではありません（完全なものを得るには./configure --helpを使ってください）。
ここで取り上げていないオプションはクロスコンパイルのような高度なユースケースのためのもので、標準のAutoconfのドキュメントに書かれています。
このオプションはmake installがファイルをどこに置くかを制御します。
たいていの場合--prefixオプションで十分です。
特別な必要があるのであれば、この節に書かれた他のオプションを使用して個々のインストレーションサブディレクトリを変更できます。
しかし、異なるサブディレクトリの相対的な位置を変更した場合、インストレーションは再配置不能になります。つまり、インストールの後にディレクトリを移動できないことに注意してください。
（manとdocの場所はこの制限の影響を受けません。）
再配置可能インストールのために、後述の--disable-rpathを使用しようと考えるかもしれません。
--prefix=PREFIX #
/usr/local/pgsqlではなく、PREFIXディレクトリ以下に全てのファイルをインストールします。
ファイルは実際には様々なサブディレクトリにインストールされ、PREFIXディレクトリの直下にインストールされるファイルはありません。
--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 #
いろいろな種類の読み取り専用データファイル用のルートディレクトリを設定します。
これは後述のオプションの一部についてのデフォルトを設定するだけです。
デフォルトはPREFIX/share
--datadir=DIRECTORY #
インストールプログラムが使用する読み取り専用のディレクトリを設定します。
デフォルトはDATAROOTDIR
--localedir=DIRECTORY #
特にメッセージ翻訳カタログファイルのロケールデータをインストールするディレクトリを設定します。
デフォルトはDATAROOTDIR/locale
--mandir=DIRECTORY #
PostgreSQL付属のマニュアルページがこのディレクトリ以下の、対応するmanサブディレクトリにインストールされます。
デフォルトはxDATAROOTDIR/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以下にも非公開用のサブディレクトリが作成されます。
この節に書かれたオプションは、デフォルトでは構築されないPostgreSQLの様々な機能を構築できるようにするものです。 これらのほとんどは、17.1で説明されているように、追加のソフトウェアが必要なためにデフォルトではないものです。
--enable-nls[=LANGUAGES] #
各国語サポート（NLS）、つまり、英語以外の言語によるプログラムメッセージの表示機能を有効にします。
LANGUAGESはオプションであり、サポートさせたい言語コードを空白で区切ったリストを指定します。例えば、--enable-nls='de fr'などとします。
（指定したリストと実際に用意された翻訳との論理積が自動的に計算されます。）
リストに何も指定しなかった場合、利用可能な翻訳すべてがインストールされます。
このオプションを使用するためには、gettext APIの実装が必要です。
--with-perl #PL/Perlサーバサイド言語を構築します。
--with-python #PL/Pythonサーバサイド言語を構築します。
--with-tcl #PL/Tclサーバサイド言語を構築します。
--with-tclconfig=DIRECTORY #
Tclは、Tclへのインタフェースモジュールを構築するために必要な設定情報を含むtclConfig.shファイルをインストールします。
このファイルは通常、自動的に一般的に知られている場所にありますが、もしTclの別のバージョンを使いたい場合は、tclConfig.shを検索対象のディレクトリを指定することができます。
--with-llvm #LLVMに基づいたJITコンパイル（第32章を参照）のサポートを有効にして構築します。 これには、LLVMライブラリがインストールされている必要があります。 LLVMの要求される最小のバージョンは現在3.9です。
要求されるコンパイルオプションを見つけるためにllvm-configが使われます。
llvm-config、それからサポートされるバージョンすべてのllvm-config-$major-$minorをPATHで探します。
それで正しいバイナリが見つからなければ、正しいllvm-configへのパスを指定するためにLLVM_CONFIGを使ってください。
例えば、以下のとおりです。
./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'
LLVMサポートはclang互換のコンパイラ（必要なら環境変数CLANGで指定してください）と動作するC++コンパイラ（必要なら環境変数CXXで指定してください）を要求します。
--with-lz4 #LZ4圧縮サポートを有効にして構築します。
--with-zstd #Zstandard圧縮サポートを有効にして構築します。
--with-ssl=LIBRARY
#
SSL（暗号化）接続のサポートを有効にして構築します。
サポートされている唯一のLIBRARYはopensslです。
これには、OpenSSLパッケージがインストールされている必要があります。
configureは、処理を進める前にOpenSSLのインストールを確認するために、必要なヘッダファイルとライブラリを検査します。
--with-openssl #
--with-ssl=opensslに相当する古いものです。
--with-gssapi #
GSSAPI認証のサポートを構築します。
GSSAPIを使用するには、MIT Kerberosがインストールされている必要があります。
多くのシステムでは、GSSAPIシステム（通常MIT Kerberosインストレーションの一部）はデフォルトの検索場所（例えば/usr/includeや/usr/lib）にインストールされていません。
そのため、--with-includesと--with-librariesオプションをさらに追加して使わなければいけません。
configureは、処理を進める前にGSSAPIが正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリを検査します。
--with-ldap #
認証および接続パラメータ検索用のLDAPサポートを有効にして構築します。
（詳細は34.18および21.10を参照してください。）
Unixでは、OpenLDAPパッケージがインストールされている必要があります。
WindowsではデフォルトのWinLDAPライブラリが使用されます。
configureは、処理を進める前にOpenLDAPのインストールが十分されているかどうかを確認するために、必要なヘッダファイルとライブラリを検査します。
--with-pam #--with-bsd-auth #BSD認証のサポートを有効にして構築します。 （BSD認証フレームワークは今のところOpenBSDだけで利用可能です。）
--with-systemd #systemdサービス通知のサポートを有効にして構築します。 サーババイナリがsystemdの元で開始する場合には、これは統合を改善しますが、それ以外は影響はありません。詳細は19.3を参照してください。 このオプションを使えるようにするには、libsystemdと関連するヘッダファイルがインストールされている必要があります。
--with-bonjour #Bonjour自動サービス検出のサポートを有効にして構築します。 これには、オペレーティングシステムがBonjourをサポートしていることが必要です。 macOSで推奨します。
--with-uuid=LIBRARY #
指定されたUUIDライブラリを使用して(UUIDを生成する関数を提供する)uuid-osspモジュールをビルドします。
LIBRARYは以下のいずれかでなければなりません。
bsdはFreeBSD、その他のBSD派生システムにあるUUID関数を使います。
e2fsはe2fsprogsプロジェクトで作られたUUIDライブラリを使います。
このライブラリはたいていのLinuxシステムとmacOSにあり、また、その他のプラットフォームでも入手可能です。
osspはOSSP UUIDライブラリを使用します。
--with-ossp-uuid #
--with-uuid=osspに相当する古いものです。
--with-libxml #libxml2を使用して構築し、SQL/XMLサポートを有効にします。 この機能のためにはlibxml2バージョン2.6.23以降が必要です。
pkg-configがインストールされていて、かつそれがlibxml2について知っているようであれば、必要なコンパイラオプション、リンカオプションを検出するために、PostgreSQLはpkg-configに問い合わせます。
そうでなければ、libxml2がインストールするプログラムxml2-configを見つけられれば使用します。
複数アーキテクチャのインストレーションをよりうまく扱えますので、pkg-configを使用する方が好ましいです。
通常以外の場所にインストールしたlibxml2インストレーションを使用するためには、pkg-config関連の環境変数を設定するか（そのドキュメントを参照してください）、環境変数XML2_CONFIGがそのインストレーション用のxml2-configプログラムを指し示すように設定するか、変数XML2_CFLAGSとXML2_LIBSを設定します。
（pkg-configがインストールされていて、libxml2がどこにあるかについてのその認識を覆したいのであれば、XML2_CONFIGを、もしくはXML2_CFLAGSとXML2_LIBSの両方を空でない文字列に設定しなければなりません。）
--with-libxslt #
XMLのXSL変換を行うためにxml2モジュールを有効にしてlibxsltを構築します。
--with-libxmlも指定しなければなりません。
この節に書かれたオプションは、デフォルトでは構築されますが、必要なソフトウェアやシステムの機能が利用可能でない場合にオフにする必要があるPostgreSQLの特定の機能を無効にします。 本当に必要でない限りは、ここのオプションの使用は勧められません。
--without-icu #ICUライブラリをサポートしない構築を行い、ICU照合機能の使用を無効にします（24.2を参照）。
--without-readline #Readlineライブラリ（およびlibedit）の使用を防止します。 このオプションはpsqlでのコマンドライン編集および履歴を無効にします。
--with-libedit-preferred #GPLライセンスのReadlineではなくBSDライセンスのlibeditライブラリを優先して使用します。 このオプションは両方のライブラリがインストールされている場合にのみ重要です。その場合デフォルトでReadlineが使用されます。
--without-zlib #Zlibライブラリの使用を抑制します。 これは、pg_dumpとpg_restoreにおける圧縮アーカイブのサポートを無効にします。
--disable-spinlocks #PostgreSQLがそのプラットフォーム用のCPUスピンロックをサポートしない場合でも、構築に成功するようにします。 スピンロックのサポートの欠落により、性能は悪化します。 したがって、このオプションは、構築が失敗し、その原因が使用するプラットフォームでスピンロックサポートが欠落している場合にのみ使用してください。 使用するプラットフォームにおけるPostgreSQLの構築にこのオプションが必要とされた場合は、PostgreSQL開発者にその問題を報告してください。
--disable-atomics #CPU不可分操作の使用を無効にします。 このオプションはそのような操作のないプラットフォームでは何もしません。 そのような操作のあるプラットフォームでは、これにより性能が低下するでしょう。 このオプションはデバッグや性能比較をする場合にのみ有用です。
--disable-thread-safety #クライアントライブラリのスレッドセーフを無効にします。 これにより、libpqやECPGプログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御できなくなります。 スレッドのサポートに欠陥があるプラットフォームでのみ、これを使ってください。
--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
--with-system-tzdata=DIRECTORY
#
PostgreSQLは、日付時刻に関する操作で必要な、独自の時間帯データベースを持ちます。
実際のところ、この時間帯データベースはFreeBSD、Linux、Solarisなどの多くのオペレーティングシステムで提供されるIANA時間帯データベースと互換性があります。
このため、これを再びインストールすることは冗長です。
このオプションが使用されると、DIRECTORYにあるシステムが提供する時間帯データベースがPostgreSQLソース配布物に含まれるものの代わりに使用されます。
DIRECTORYは絶対パスで指定しなければなりません。
/usr/share/zoneinfoがオペレーティングシステムの一部でよく使われます。
インストール処理が時間帯データの不一致、またはエラーがあることを検知しないことに注意してください。
このオプションを使用する場合、指定した時間帯データがPostgreSQLで正しく動作するかどうかを検証するためにリグレッションテストを実行することが推奨されています。
このオプションは、対象オペレーティングシステムを熟知しているパッケージ配布者を主な対象としたもの。 このオプションを使用する大きな利点は、多くの局所的な夏時間規則の変更があってもPostgreSQLパッケージを更新する必要がないことです。 他の利点として、時間帯データベースファイルをインストール時に構築する必要がありませんので、PostgreSQLのクロスコンパイルをより簡単に行うことができます。
--with-extra-version=STRING #
PostgreSQLバージョン番号にSTRINGを追加します。
これは、例えば、リリースされていないGitスナップショットからビルドしたバイナリや、git describe識別子やディストリビューションパッケージリリース番号のような追加のバージョン文字列のあるカスタムパッチを含むバイナリに印をつけるために使えます。
--disable-rpath #
PostgreSQLの実行ファイルがインストレーションのライブラリディレクトリ（--libdirを参照してください）にある共有ライブラリを探すよう指示する印を付けません。
ほとんどのプラットフォームでは、この印付けはライブラリディレクトリへの絶対パスを利用しますので、後でインストレーションを再配置したときには役に立たないでしょう。
ですので、実行ファイルが共有ライブラリを見つける他の方法を提供する必要があるでしょう。
通常は、オペレーティングシステムの動的リンカがライブラリディレクトリを探すよう設定することが必要です。詳細は17.5.1を参照してください。
デフォルトのポート番号を--with-pgportで調整することは、特にテスト構築のためには、かなり良くあることです。
この節の他のオプションは上級ユーザにのみ勧められます。
--with-pgport=NUMBER #
サーバとクライアントのデフォルトのポート番号をNUMBERに設定します。
デフォルトは5432です。
このポートは後でいつでも変更できますが、ここで指定した場合、サーバとクライアントはコンパイル時に同じデフォルト値を持つようになります。
これは非常に便利です。
通常、デフォルト以外の値を選択すべき唯一の理由は、同じマシンで複数のPostgreSQLを稼働させることです。
--with-krb-srvnam=NAME #
GSSAPIで使用されるKerberosのサービスプリンシパルのデフォルトの名前です。
デフォルトではpostgresです。
これを変える理由はWindows環境のために構築しているのでない限り、特にありません。
Windows環境のために構築している場合は大文字のPOSTGRESに設定する必要があります。
--with-segsize=SEGSIZE #
セグメントサイズをギガバイト単位で指定します。
大規模なテーブルはこのセグメントサイズと同じサイズの複数のオペレーティングシステムのファイルに分割されます。
これにより多くのプラットフォームで存在するファイルサイズ上限に関する問題を防ぎます。
デフォルトのセグメントサイズは1ギガバイトで、サポートされるすべてのプラットフォームで安全です。
使用するオペレーティングシステムが「ラージファイル」をサポートしていれば（最近はほとんどサポートしています）、より大きなセグメントサイズを使用できます。
非常に大規模なテーブルで作業する時のファイル記述子の消費数を減らすために、これが役に立つでしょう。
しかし、プラットフォーム、または使用予定のファイルシステムでサポートされる値以上に大きな値を指定しないように注意してください。
tarなどの、使用したいその他のツールにも使用できるファイルサイズに制限があることがあります。
絶対に必要ではありませんが、この値を2のべき乗にすることを勧めます。
この値を変更するとディスク上でのデータベースの互換性を壊すことに注意してください。すなわち、pg_upgradeを使ってセグメントサイズの異なるビルドにはアップグレードできません。
--with-blocksize=BLOCKSIZE #
キロバイト単位でブロック容量を設定します。
これはテーブル内でのストレージとI/Oの単位です。
8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は他の値が役立ちます。
値は1から32（キロバイト）の範囲の2のべき乗でなければなりません。
この値を変更するとディスク上でのデータベースの互換性を壊すことに注意してください。すなわち、pg_upgradeを使ってブロック容量の異なるビルドにはアップグレードできません。
--with-wal-blocksize=BLOCKSIZE #
キロバイト単位でWALブロック容量を設定します。
これはWALログ内でのストレージとI/Oの単位です。
8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は大きめの値が役立ちます。
値は1から64（キロバイト）の範囲の2のべき乗でなければなりません。
この値を変更するとディスク上でのデータベースの互換性を壊すことに注意してください。すなわち、pg_upgradeを使ってWALブロック容量の異なるビルドにはアップグレードできません。
この節のオプションのほとんどは、PostgreSQLを開発したりデバッグしたりするために重要なものです。
--enable-debugを除いて、実運用での構築には勧められません。--enable-debugはバグに出くわすという不幸な出来事の時に詳細なバグレポートが得られるので有用かもしれません。
DTraceをサポートするプラットフォームでは、--enable-dtraceを実運用で使うことも適当かもしれません。
サーバ内でコードの開発に使われるインストレーションを構築する場合には、少なくともオプション--enable-debugと--enable-cassertを使うことをお勧めします。
--enable-debug #すべてのプログラムとライブラリをデバッグシンボル付きでコンパイルします。 これは、問題を解析するためにデバッガ内でプログラムを実行できることを意味します。 これはインストールする実行形式ファイルのサイズをかなり大きくし、また、GCC以外のコンパイラでは、通常はコンパイラによる最適化が行われなくなりますので、低速になります。 しかし、デバッグシンボルが利用できるということは、発生した問題に対応する時に非常に便利です。 現在のところ、GCC を使用している場合にのみ、稼働用のインストレーションにこのオプションを使用することを推奨します。 しかし、開発作業時やベータ版を実行する時は、常にこれを有効にすべきです。
--enable-cassert #サーバにおける、多くの「あり得ない」状態をテストするアサーションチェックを有効にします。 これは、プログラムの開発のためには測り知れない価値がありますが、このテストによりサーバはかなり低速になります。 また、このテストを有効にしても、サーバの安定性が向上するとは限りません！ アサーションチェックは、重要度によって分類されていませんので、比較的害がないようなバグでも、アサーション失敗をトリガとした、サーバの再起動が行われてしまいます。 稼働用にこのオプションを使用することは推奨されませんが、開発作業時やベータ版を実行する場合は、これを有効にすべきです。
--enable-tap-tests #
Perl TAPツールを使ったテストを有効にします。
これにはPerlのインストールとPerlモジュールIPC::Runが必要です。
詳細は33.4を参照してください。
--enable-depend #自動依存関係追跡を有効にします。 このオプションを使用すると、ヘッダファイルが変更された場合に、影響を受ける全てのオブジェクトファイルが再構築されるように、makefile が設定されます。 これは開発作業時には有用ですが、単に一度コンパイルしインストールするだけであれば、これは無駄なオーバーヘッドです。 現在のところ、GCC でのみ、このオプションは動作します。
--enable-coverage #GCCを使用している場合、すべてのプログラムとライブラリはコードカバレッジテスト機構付きでコンパイルされます。 実行すると、これらは構築用ディレクトリ内にコードカバレッジメトリックを持ったファイルを生成します。 詳細は33.5を参照してください。 このオプションはGCC専用であり、また、開発作業中に使用するためのものです。
--enable-profiling #
GCCを使用する場合、すべてのプログラムとライブラリがプロファイリング可能状態でコンパイルされます。
バックエンドの終了時、プロファイリングに使用するgmon.outファイルを含むサブディレクトリが作成されます。
このオプションはGCCを使用する場合のみ使用でき、開発作業を行う時に使用します。
--enable-dtrace #動的追跡ツールDTraceのサポートを有効にしてPostgreSQLをコンパイルします。 より詳細な情報は28.5を参照してください。
dtraceプログラムを指し示すためにDTRACE環境変数を設定できます。
dtraceは通常、PATH内に存在しない可能性がある/usr/sbin以下にインストールされていますので、この設定はよく必要になります。
さらにdtraceプログラム用のコマンドラインオプションをDTRACEFLAGS環境変数で指定できます。
Solarisで64ビットバイナリでDTraceをサポートするには、DTRACEFLAGS="-64"を指定してください。
例えばGCCコンパイラを使用する場合は以下のようにします。
./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
Sunのコンパイラを使用する場合は以下のようにします。
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
--with-segsize-blocks=SEGSIZE_BLOCKS #
リレーションのセグメントサイズをブロック単位で指定します。
--with-segsizeとこのオプションの両方が指定されている場合、このオプションが優先されます。
このオプションは、セグメント関連のコードをテストする開発者向けです。
configure環境変数 #
上記の通常のコマンドラインオプションに加えて、configureは数多くの環境変数に対応します。
次のようにして、configureコマンドラインに環境変数を指定できます。
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
この使い方では、環境変数はコマンドラインオプションとは少し異なります。 あらかじめそのような変数を設定しておくこともできます。
export CC=/opt/bin/gccexport CFLAGS='-O2 -pipe'./configure
多くのプログラムの設定スクリプトは似たようにこの変数に対応しますので、この使い方は便利でしょう。
これらの環境変数の中で最も一般的に使用されているのは、CCとCFLAGSです。
configureが選ぶものと違うCコンパイラを使いたいという場合には、CC 環境変数をその使用したいプログラムに設定できます。
デフォルトでは、configureは利用できるのであればgccを、利用できなければプラットフォームのデフォルト（通常cc）を選択します。
同様に、デフォルトのコンパイラフラグは必要に応じてCFLAGS変数で上書きすることもできます。
以下は、この方式で設定可能な重要な環境変数の一覧です。
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構築に関する依存性を決定するために使用されます。
設定されていなければ、python3 pythonの順で調べられます。
TCLSH #
Tclインタプリタプログラム。
これは、PL/Tcl構築に関する依存性を決定するために使用され、Tclスクリプト内を置き換えます。
設定されていなければ、以下の順で調べられます。tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84
XML2_CONFIG #
libxml2インストレーションの場所を特定するために使用するxml2-configプログラムです。
configureが選んだコンパイラフラグに対して、事後にフラグを追加することが有用な場合があります。
重要な例は、configureに渡すCFLAGSにgccの-Werrorオプションを含められないことです。なぜなら、そうするとconfigureの組み込みテストの多くが失敗するからです。
そのようなフラグを追加するには、makeを実行する時にCOPT環境変数に含めてください。
configureで設定されたCFLAGSオプションとLDFLAGSオプションの両方に、COPTの内容が追加されます。
例えば、以下のようにします。
make COPT='-Werror'
または
export COPT='-Werror'make
GCCを使う場合、少なくとも-O1レベルの最適化で構築することがベストです。なぜなら、何の最適化もしない(-O0) と、重要なコンパイル警告(初期化されていない変数の使用など)が無効になるからです。
しかし、最適化を行うことでソースコードとコンパイルされたコードのステップは1対1とはならなくなるため、デバッグは複雑になるかもしれません。
最適化されたコードのデバッグに悩まされてしまう場合は、関心のある特定のファイルに対して-O0で再コンパイルしてください。
これを実行するための簡単な方法は、make PROFILE=-O0 file.oのように、make経由でオプションを渡すことです。
COPTとPROFILEの環境変数は、PostgreSQLのmakefileでは実際には全く同一に扱われます。
どちらを使うかは好みの問題ですが、開発者の一般的な習慣では、一時的にフラグを調整するにはPROFILEを使い、永続的に保持するものにはCOPTを使います。