全てのパラメータの名前は大文字と小文字を区別しません。 それぞれのパラメータは、論理値、整数、浮動小数点、文字列、またはenum（列挙型）の5つの型のいずれかの値を取ります。 型はパラメータをセットするための記法を定義します。
論理型:
値は以下のいずれかを取ることができます。
on,
off,
true,
false,
yes,
no,
1,
0
(すべて大文字小文字の区別なし) あるいは、曖昧でなければこれらの先頭から数文字を省略して使うこともできます。
文字列型: 一般に、単一引用符の中に値を入れます。単一引用符を値として使う場合は単一引用符を重ねます。なお、値が単純な数字や識別子である場合は、通常引用符は省略できます。
数値型(整数型と浮動小数点型): 小数点は浮動小数点型のパラメータでのみ使用できます。 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つのパラメータが指定されます。
名前と値の間の等号はオプションです。引用符の中の空白（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の設定を上書きします。
システムビューの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を使うのと同じですが、更に詳細な情報を提供します。
フィルター条件を指定したり他のリレーションと結合ができるので、より柔軟です。
このビューの特定のsetting列に対してUPDATEを実行することは、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はただ
単にログをとり、そして参照している設定ファイルの処理を続けます。
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
こういった工夫で、設定ファイルのバリエーションに対して固有の名前を付与することができます。 また、バージョン管理リポジトリのリポジトリに複数のサーバの設定ファイルを置く場合に生じる曖昧さを排除することができます。 （データベース設定ファイルをバージョン管理することは、これもまた検討に値するやり方です）。