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

18.1. パラメータの設定

18.1.1. パラメータ名とその値

全てのパラメータの名前は大文字と小文字を区別しません。 それぞれのパラメータは、論理値、整数、浮動小数点、文字列、またはenum(列挙型)の5つの型のいずれかの値を取ります。 論理値は、onofftruefalseyesno10、または、これらとすぐに推測できるどんな接頭文字でも記述することができます(全て大文字小文字の区別はありません)。

一部の設定では、メモリや時刻に関する値を指定します。 それぞれは暗黙的な単位を持ちます。キロバイト、ブロック(通常8キロバイト)、ミリ秒、秒、分などです。 デフォルトの単位はpg_settings.unitを参照することで調べることができます。 便宜上、別の単位を明示的に指定することができます。 メモリに関する単位では、kB (キロバイト)、MB (メガバイト)、GB(ギガバイト)が有効です。 時刻に関する単位ではms(ミリ秒)、s (秒)、min (分)、h (時間)、d (日数)が有効です。 メモリ単位の乗数は1000ではなく1024であることに注意してください。

"enum(列挙)"型のパラメータは文字列パラメータと同様の方法で指定されますが、限定された値の集合に制限されます。 有効な値はpg_settings.enumvalsにあります。 列挙型パラメータ値には大文字小文字の区別がありません。

18.1.2. 設定ファイルによるパラメータの設定

これらのパラメータを設定する1つの方法は、postgresql.confファイルを編集することで、これは通常 data ディレクトリに格納されています。 (デフォルトのコピーはデータベースクラスタディレクトリが初期化されるときそこにインストールされます。)このファイルがどういったものかの例を示します。

# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB

1つの行毎に1つのパラメータが指定されます。 名前と値の間の等号はオプションです。空白(white space)は特に意味を持たず、何もない行は無視されます。何処にあってもハッシュ記号(#)はその行の後の表記が注釈であることを意味します。単純でない識別子、または数値でないパラメータ値は単一引用符で括られなければなりません。パラメータ値の中に単一引用符を埋め込む場合、二重引用符(推奨)もしくは逆引用符で括ります。

設定ファイルはメインサーバプロセスがSIGHUP信号を受け取る時は何時でも 再読み込みされます。手っ取り早く行なうには、コマンドラインからpg_ctl reload を実行するか、SQL関数のpg_reload_conf()を呼び出します。 メインサーバプロセスは同時にこの信号を、現存のセッションが同様に新しい値を入手できるように、全ての現在実行しているサーバプロセスに伝播します。 他の手段として、直接単一のサーバプロセスを送出することも可能です。いくつかのパラメータはサーバの起動時のみ設定されます。設定ファイル中のそれらのエントリのいかなる変更も、サーバが再起動されるまで無視されます。 設定ファイル内で無効なパラメータが設定された場合はこのように(ログには残りますが)SIGHUP 処理中に無視されます。

18.1.3. パラメータ設定を行う他の手段

これら設定パラメータを設定する第二の方法は、以下のようにpostgresコマンドに対してコマンドラインオプションとして与えます。

postgres -c log_connections=yes -c log_destination='syslog'

コマンドラインオプションはpostgresql.confにある、どんな矛盾した設定をも上書きします。 これが意味することは、postgresql.confを編集するだけでは、値をすぐに変更できず、従ってコマンドラインによる方法は便利とは言っても、後に柔軟性に犠牲を払う羽目に陥ることを覚えておいてください。

場合によっては、1つの特定セッションのみにコマンドラインオプションを与えることが便利です。 環境変数 PGOPTIONSはこの目的のためにクライアント側で使用できます。

env PGOPTIONS='-c geqo=off' psql

(これは、単にpsqlだけではなく、全てのlibpqに基づいたクライアントアプリケーションに対して有効です。) これは、サーバが起動された時に修正されたパラメータ、または、postgresql.confで指定されなければならないパラメータに対しては効果がないことを覚えておいてください。

更に、ユーザもしくはデータベースにパラメータ設定のひとそろいを割り当てることができます。 セッションが開始された時はいつでも、ユーザとデータベースに関連したデフォルトの設定が読み込まれます。 ALTER USERおよびALTER DATABASEコマンドは、それぞれこれらの設定を設定するために用いられます。 データベース毎の設定は、postgresコマンドライン、または設定ファイルから受け取った何によっても上書きされます。 そして順次ユーザ毎の設定が上書きします。 これらは共にセッション毎の設定で上書きされます。

個別のSQLセッションのいくつかのパラメータはSETコマンドで変更可能です。例えば:

SET ENABLE_SEQSCAN TO OFF;

SETが使える場合には、そのパラメータに対して設定された値が上書きされます。 いくつかのパラメータは SET では変更できません。 例えば、そのパラメータがPostgreSQLサーバ全体を再起動しなければ変更できない動作を制御している場合です。 さらに、いくつかのパラメータはSETまたはALTERによる修正にスーパユーザ権限を必要とします。

18.1.4. パラメータ設定の検証

SHOWコマンドで全てのパラメータの現在値を調査することができます。

仮想テーブルpg_settingsもセッション実行時パラメータの表示と更新を可能にします。 異なった変数型と、いつそれらが変更可能かについての詳細と説明は 項47.66 を参照してください。 pg_settingsSHOWSETと等価です。 しかし、他のテーブルとの結合や、目的とする条件を指定した検索ができるので、より使い勝手に優れています。 更にそれぞれのパラメータについてSHOWよりも多くの情報が入っています。

18.1.5. 設定ファイルの Include

パラメータ設定に加え、postgresql.confファイルにinclude コマンド を書くことができます。 このようにすると、別のファイルがあたかもその時点で設定ファイルに挿入されているごとく読み込まれ、 処理されように指定されます。 この機能は設定ファイルが物理的に異なる全体の一部に分割されたようにします。 Includeコマンドは次のように単純です。

include 'ファイル名'

もしファイル名が絶対パスにない場合、参照する設定ファイルを含むディレクトリに相対的であると 受け取られます。Includeコマンドは入れ子にすることができます。

include_if_existsコマンドもあります。これは参照ファイルが存在しないか、または 読み込むことができない場合の動作を除き、 includeコマンドと同一の動作をします。 通常のincludeはこれをエラーと解釈しますが、include_if_existsはただ 単にログをとり、そして参照している設定ファイルの処理を続けます。

postgresql.confファイルは同時にinclude_dirコマンドを 持つことが可能で、includeする設定ファイルを含むディレクトリ全体を指定します。 同様にして以下のように書きます。

 include_dir 'ディレクトリ名'
 

絶対パスが定義されていない諸ディレクトリ名はコマンドを含め単独ファイルに対しての同じ規則に従います。 それらは参照している設定ファイルを含んだディレクトリに対して相対的です。 そのディレクトリ内ではその名前の末尾が.confで終結する絶対パスが定義されていないファイルのみincludeされます。 . 符号で開始するファイル名も幾つかのプラットフォームでは隠しファイルとされるので、判断違いを防止するため同じように考慮されません。 includeされるディレクトリにある複数ファイルはファイル名順に処理されます。ファイル名は C ロケール規則で順位付けされます。つまり、文字より数字、小文字より大文字が優先されます。

includeされるファイルもしくはディレクトリは、大きな単一のpostgresql.confファイルを使うのではなくデータベース設定の一部分を論理的に分離するために使用することが可能です。 異なるメモリー容量を持つ二つのデータベースサーバを所有する会社を考えてみてください。 例えばログ取得のように、二つが共有する設定の要素があると思われます。しかし、サーバ上のメモリに関連したパラメータは二つの間では異なります。更に、サーバ特有のカスタマイズも存在することがあります。 この状況に対処する一つの方法として、そのサイトに対するカスタマイズされた設定の変更を三つのファイルにすることです。 そのためにはpostgresql.confファイルの最後に以下をincludeのため追加します。

 include 'shared.conf'
 include 'memory.conf'
 include 'server.conf'
 

全てのシステムは同一のshared.confを所有する様になるでしょう。 特定のメモリー容量を所有するそれぞれのサーバは同じmemory.confを共有できます。 一つは8GBのRAMを持つ全てのサーバ群、他は16MBを持っています。そして最終的にserver.confで厳密にサーバ特有の設定情報を記載します。

別の可能性として、設定ファイルディレクトリを作成し、その情報をそこのファイルに格納します。 たとえば、conf.dディレクトリはpostgresql.confの最後で参照されます。

 include_dir 'conf.d'
 

そうすると、以下のようにconf.dの中にファイルを列挙できます。

 00shared.conf
 01memory.conf
 02server.conf
 

これはこれらのファイルが読み込まれる順序を明確に示しています。 サーバがその設定を読み込んだ時点で最後の宣言文のみ使用されるので重要です。 この例のconf.d/02server.confで何らかの指定がなされたことがconf.d/01memory.confにより上書きされます。

むしろそれより、これらのファイルをより記述的に名前を付ける時点でこの設定ディレクトリの手法を使用することができます。

 00shared.conf
 01memory-8GB.conf
 02server-foo.conf
 

この種のお膳立ては、変化に富むそれぞれの設定ファイルに固有の名前を与えます。 バージョン管理レポジトリにおいてのように、複数のサーバが一か所にそれぞれの設定ファイル 全てを置く場合の曖昧性を排除するのに役立ちます(データベース設定ファイルをバージョン管理の基に格納することは、検討すべき価値のある演習です)。