18.1. パラメータの設定

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

全てのパラメータの名前は大文字と小文字を区別しません。 それぞれのパラメータは、論理値、整数、浮動小数点、文字列、またはenum(列挙型)の5つの型のいずれかの値を取ります。 型はパラメータをセットするための記法を定義します。

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

これらのパラメータを設定する最も基本的な方法は、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 処理中に無視されます。

postgresql.confに加え、PostgreSQLデータディレクトリには postgresql.auto.confというファイルがあります。このファイルは postgresql.conf と同じフォーマットですが、手動では編集しません。 このファイルは ALTER SYSTEM コマンドを使った設定値を保存します。 このファイルはpostgresql.conf が読み込まれるときはいつでも同時に読み込まれ、同じように設定が反映されます。 postgresql.auto.confは、postgresql.confの設定を上書きします。

18.1.3. SQLを通じたパラメータ操作

PostgreSQLは3つのSQLコマンドでデフォルト値を設定します。 すでに説明したALTER SYSTEMコマンドは、SQLによってグローバルな設定値を変更する方法を提供します; postgresql.confを編集するのと等価です。これに加え、データベース単位あるいはロール単位で設定するためのコマンドがあります:

ALTER DATABASEALTER ROLEによる設定値は新しくデータベースセッションを開始した時にのみ適用されます。 これらのコマンドは設定ファイルやサーバへのコマンド引数による設定値を上書きし、セッションの以後の状態に適用します。なお、一部の設定はサーバを起動した後では変更できず、これらのコマンドを使っては設定できません(以下に記述するコマンドでも同じことが言えます)。

クライアントがデータベースに接続すると、PostgreSQLでは更に2つのSQL(そして同等の関数)を使ってセッションローカルの設定変更を行うことができます。

更にシステムビューのpg_settingsを使ってセッションローカルな変数の値を参照したり変更することができます。

18.1.4. シェルによるパラメータ操作

グローバルなデフォルト値を設定したりデータベース、ロール単位で上書きを行えるだけでなく、シェル機能を使ってPostgreSQLに設定値を渡すことができます。 サーバもlibpqクライアントライブラリもシェル経由でパラメータ値を受けとることができます。

18.1.5. 設定ファイルの内容の管理

PostgreSQLは複雑なpostgresql.confファイルを複数の小さなファイルに分割する複数の方法を提供しています。 これは、とりわけお互いに関連しているものの設定が同じではない複数のサーバを管理する際に有用です。

パラメータ設定に加え、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を持つ全てのサーバ群、他は16GBを持っています。そして最終的に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

こういった工夫で、設定ファイルのバリエーションに対して固有の名前を付与することができます。 また、バージョン管理リポジトリのリポジトリに複数のサーバの設定ファイルを置く場合に生じる曖昧さを排除することができます。 (データベース設定ファイルをバージョン管理することは、これもまた検討に値するやり方です)。