全てのパラメータの名前は大文字と小文字を区別しません。 それぞれのパラメータは、論理値、整数、浮動小数点、文字列、またはenum(列挙型)の5つの型のいずれかの値を取ります。 型はパラメータをセットするための記法を定義します。
論理型:
値はon
、off
、true
、false
、yes
、no
、1
、0
(すべて大文字小文字の区別なし)、あるいは、曖昧でなければ、これらの先頭から数文字を省略形として使うこともできます。
文字列型: 一般に、単一引用符の中に値を入れます。 単一引用符を値に含める場合は単一引用符を2つ続けます。 なお、値が単純な数字や識別子である場合は、通常は引用符を省略できます。
数値型(整数型と浮動小数点型): 小数点は浮動小数点型のパラメータでのみ使用できます。 1000の位取りの区切り文字は使わないでください。 引用符は必要ありません。
単位付きの数値:
数値型のパラメータによっては暗黙的な単位を持つことがあります。
メモリの量や時間について記述するからです。
単位はキロバイト、ブロック(通常8キロバイト)、ミリ秒、秒、分などです。
修飾無しの数値によるこれらの設定においては、 pg_settings
.unit
からデフォルト値が採用されます。
使い勝手を考えて、たとえば'120 ms'
のように単位を明示的に指定することもできます。
この場合は、実際の単位に変換が行われます。
なお、この機能を使う場合は、引用符付きの文字列として値を指定しなければならないことに注意してください。
単位の名称は大文字小文字を区別します。
また、数値と単位の間に空白があっても構いません。
有効なメモリの単位は kB
(キロバイト),
MB
(メガバイト), GB
(ギガバイト), TB
(テラバイト)です。
メモリ単位の乗数は1024です。1000ではありません。
有効な時間の単位は ms
(ミリ秒)、s
(秒)、min
(分)、h
(時間)、d
(日数) です。
列挙型:
列挙型のパラメータは文字列パラメータと同じように記述します。
ただ、使用できる文字列の種類が決まっているだけです。
使用できる文字列は pg_settings
.enumvals
で定義されています。
列挙型の値は大文字小文字を区別しません。
これらのパラメータを設定する最も基本的な方法は、postgresql.conf
ファイルを編集することで、これは通常 data ディレクトリに格納されています。
デフォルトのコピーはデータベースクラスタディレクトリが初期化されるときそこにインストールされます。このファイルがどういったものかの例を示します。
# This is a comment log_connections = yes log_destination = 'syslog' search_path = '"$user", public' shared_buffers = 128MB
1つの行毎に1つのパラメータが指定されます。
名前と値の間の等号は省略可能です。
(引用符付きのパラメータ値内を除き)空白は特に意味を持たず、何もない行は無視されます。
ハッシュ記号(#
)はその行の後の表記がコメントであることを意味します。
単純でない識別子、または数値でないパラメータ値は単一引用符で括られなければなりません。
パラメータ値の中に単一引用符を埋め込むには、引用符を2つ(推奨)もしくはバックスラッシュ-引用符を使います。
この方法によりクラスタに対してデフォルト値が設定されます。 上書きされない限り、アクティブなセッションが見るのはこの値です。 次節以降では、管理者やユーザがこれらのデフォルト値を上書きする方法を説明します。
設定ファイルは、メインサーバプロセスが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
の設定を上書きします。
システムビューのpg_file_settings
は、設定ファイルへの変更を前もってテストしたい場合や、SIGHUPシグナルで望み通りの効果がなかった場合に問題を調査する際に役立ちます。
PostgreSQLは3つのSQLコマンドでデフォルト値を設定します。
すでに説明したALTER SYSTEMコマンドは、SQLによってグローバルな設定値を変更する方法を提供します; postgresql.conf
を編集するのと等価です。これに加え、データベース単位あるいはロール単位で設定するためのコマンドがあります:
ALTER DATABASEコマンドはデータベース単位でグローバルな設定値を上書きします。
ALTER ROLEコマンドはグローバルと、データベース単位の両方をユーザ固有の設定値で上書きします。
ALTER DATABASE
とALTER ROLE
による設定値は新しくデータベースセッションを開始した時にのみ適用されます。
これらのコマンドは設定ファイルやサーバへのコマンド引数による設定値を上書きし、セッションの以後の状態に適用します。なお、一部の設定はサーバを起動した後では変更できず、これらのコマンドを使っては設定できません(以下に記述するコマンドでも同じことが言えます)。
クライアントがデータベースに接続すると、PostgreSQLでは更に2つのSQL(そして同等の関数)を使ってセッションローカルの設定変更を行うことができます。
更にシステムビューのpg_settings
を使ってセッションローカルな値を参照したり変更することができます。
このビューを問い合わせるのは、SHOW ALL
を使うのと同じですが、更に詳細な情報を提供します。
フィルター条件を指定したり他のリレーションと結合ができるので、より柔軟です。
このビューに対してUPDATEを実行する、具体的にはsetting
列を更新することは、SET
コマンドを実行するのと同等です。
たとえば、
SET configuration_parameter TO DEFAULT;
は
UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';
と同じです。
グローバルなデフォルト値を設定したりデータベース、ロール単位で上書きを行えるだけでなく、シェル機能を使ってPostgreSQLに設定値を渡すことができます。 サーバもlibpqクライアントライブラリもシェル経由でパラメータ値を受けとることができます。
サーバ起動時に、-c
コマンドラインパラメータを使ってパラメータ設定値をpostgres
に渡すことができます。たとえば、
postgres -c log_connections=yes -c log_destination='syslog'
このようにして渡された設定値は、postgresql.conf
やALTER SYSTEM
による設定を上書きします。
したがってサーバを再起動しない限りこれらの設定値をグローバルに変更することはできません。
libpqを使ってクライアントセッションを開始するときにPGOPTIONS
環境変数を使って設定値を指定できます。
このようにして渡された設定値はセッションのデフォルトとなりますが、他のセッションには影響を与えません。
歴史的な理由により、PGOPTIONS
の形式はpostgres
を起動するときのものと似ています。たとえば、-c
フラグを指定しなければならない点です。
env PGOPTIONS="-c geqo=off -c statement_timeout=5min" psql
他のクライアントやライブラリではそれぞれ固有の方法でシェルなどを経由して、SQLコマンドを直接使わずにセッションの設定を変更することができるかもしれません。
PostgreSQLは複雑なpostgresql.conf
ファイルを複数の小さなファイルに分割する複数の方法を提供しています。
これは、とりわけお互いに関連しているものの設定が同じではない複数のサーバを管理する際に有用です。
パラメータ設定に加え、postgresql.conf
ファイルにincludeディレクティブを入れることができます。
このようにすると、別のファイルがあたかも設定ファイルのその場所に挿入されているかのごとく読み込まれ、処理されるように指定されます。
この機能により、設定ファイルを物理的に異なる複数のパーツに分解することができます。
Includeディレクティブは単に次のような形式になります。
include 'ファイル名'
ファイル名が絶対パスでない場合、参照する設定ファイルを含むディレクトリからの相対パスであると受け取られます。 Includeコマンドは入れ子にすることができます。
include_if_exists
ディレクティブもあります。
これは参照ファイルが存在しないか、または読み込むことができない場合の動作を除き、include
ディレクティブと同一の動作をします。
通常のinclude
はこれをエラーと解釈しますが、include_if_exists
はただ単にメッセージをログ出力し、そして参照している設定ファイルの処理を続けます。
includeする設定ファイルを含むディレクトリ全体を指定するinclude_dir
ディレクティブを、postgresql.conf
ファイルに含めることもできます。
このような感じです。
include_dir 'ディレクトリ名'
絶対パスではないディレクトリ名はその設定ファイルがあるディレクトリへの相対パスと見なされます。
指定したディレクトリの中で、ディレクトリではないファイルで末尾が.conf
で終わるファイルだけがincludeされます。
また、文字.
で開始するファイル名は一部のプラットフォームでは隠しファイルとされるので、間違いを防止するため無視されます。
includeされるディレクトリにある複数ファイルはファイル名順に処理されます(ファイル名は C ロケール規則で順序付けされます。
つまり、文字より数字、小文字より大文字が先になります)。
includeされるファイルもしくはディレクトリは、大きな単一のpostgresql.conf
ファイルを使う代わりに、データベース設定の一部分を論理的に分離するために使用することが可能です。
異なるメモリー容量を持つ二つのデータベースサーバを所有する会社を考えてみてください。
例えばログ取得のように、二つが共有する設定の要素があると思われます。
しかし、サーバ上のメモリに関連したパラメータは二つの間では異なります。
更に、サーバ特有のカスタマイズも存在することがあります。
この状況に対処する一つの方法として、そのサイトに対するカスタマイズされた設定の変更を三つのファイルにすることです。
それらをincludeするためにはpostgresql.conf
ファイルの最後に以下を追加します。
include 'shared.conf' include 'memory.conf' include 'server.conf'
全てのシステムは同一のshared.conf
を所有する様になるでしょう。
特定のメモリー容量を所有するそれぞれのサーバは同じmemory.conf
を共有できます。
RAMが8GBのすべてのサーバには共通のmemory.conf
を1つ使い、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
こういった工夫で、設定ファイルのバリエーションに対して固有の名前を付与することができます。 また、バージョン管理リポジトリのリポジトリに複数のサーバの設定ファイルを置く場合に生じる曖昧さを排除することができます。 (データベース設定ファイルをバージョン管理することは、これもまた検討に値するやり方です)。