全てのパラメータの名前は大文字と小文字を区別しません。 それぞれのパラメータは、論理値、整数、浮動小数点、文字列、またはenum（列挙型）の5つの型のいずれかの値を取ります。 型はパラメータをセットするための記法を定義します。
論理型:
値はon、off、true、false、yes、no、1、0（すべて大文字小文字の区別なし）、あるいは、曖昧でなければ、これらの先頭から数文字を省略形として使うこともできます。
文字列型: 一般に、単一引用符の中に値を入れます。 単一引用符を値に含める場合は単一引用符を２つ続けます。 なお、値が単純な数字や識別子である場合は、通常は引用符を省略できます。 （使用する場所によっては、SQLキーワードと一致する値に引用符が必要になることがあります。）
数値型(整数型と浮動小数点型):
数値パラメータには通常の整数と浮動小数点型が使用できます。
パラメータが整数型なら、小数値はもっとも近い整数に丸められます。
加えて整数型パラメータは16進数入力（0xで始まります）と8進数入力（0で始まります）を受け付けます。
しかし、これらの形式では小数点以下は使えません。
1000の位取りの区切り文字は使わないでください。
16進数入力を除き引用符は必要ありません。
単位付きの数値:
数値型のパラメータによっては暗黙的な単位を持つことがあります。
メモリの量や時間について記述するからです。
単位はバイト、キロバイト、ブロック（通常8キロバイト）、ミリ秒、秒、分などです。
修飾無しの数値によるこれらの設定においては、 pg_settings.unit からデフォルト値が採用されます。
使い勝手を考えて、たとえば'120 ms'のように単位を明示的に指定することもできます。
この場合は、実際の単位に変換が行われます。
なお、この機能を使う場合は、引用符付きの文字列として値を指定しなければならないことに注意してください。
単位の名称は大文字小文字を区別します。
また、数値と単位の間に空白があっても構いません。
有効なメモリの単位はB (バイト) kB (キロバイト)、MB (メガバイト)、 GB (ギガバイト), TB (テラバイト)です。
メモリ単位の乗数は1024です。1000ではありません。
有効な時間の単位は us (マイクロ秒)、ms (ミリ秒)、s (秒)、min (分)、h (時間)、d (日数) です。
単位に添えて小数点以下が指定された場合、より小さな単位が存在すれば、値はその小さな単位の積に丸められます。
たとえば、30.1 GBは32319628902 Bではなく30822 MBに変換されます。
整数型のパラメータでは、単位変換の後で最終的な整数への丸めが行われます。
列挙型:
列挙型のパラメータは文字列パラメータと同じように記述します。
ただ、使用できる文字列の種類が決まっているだけです。
使用できる文字列は 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の設定を上書きします。
外部ツールもpostgresql.auto.confを変更するかも知れません。
ALTER SYSTEMが変更を上書きする可能性があるので、サーバが稼働中は外部ツールによる変更は推奨されません。
そのようなツールは、単に新しい設定を最後に追加するか、重複した設定あるいはコメント(ALTER SYSTEMが行います)を削除することを選択するかも知れません。
システムビューのpg_file_settingsは、設定ファイルへの変更を前もってテストしたい場合や、SIGHUPシグナルで望み通りの効果がなかった場合に問題を調査する際に役立ちます。
PostgreSQLは3つのSQLコマンドでデフォルト値を設定します。
すでに説明したALTER SYSTEMコマンドは、SQLによってグローバルな設定値を変更する方法を提供します; postgresql.confを編集するのと等価です。これに加え、データベース単位あるいはロール単位で設定するためのコマンドがあります:
ALTER DATABASEコマンドはデータベース単位でグローバルな設定値を上書きします。
ALTER ROLEコマンドはグローバルと、データベース単位の両方をユーザ固有の設定値で上書きします。
ALTER DATABASEとALTER ROLEによる設定値は新しくデータベースセッションを開始した時にのみ適用されます。
これらのコマンドは設定ファイルやサーバへのコマンド引数による設定値を上書きし、セッションの以後の状態に適用します。なお、一部の設定はサーバを起動した後では変更できず、これらのコマンドを使っては設定できません(以下に記述するコマンドでも同じことが言えます)。
クライアントがデータベースに接続すると、PostgreSQLでは更に2つのSQL(そして同等の関数)を使ってセッションローカルの設定変更を行うことができます。
SHOWコマンドを使ってすべてのパラメータの現在の値を調べることができます。
対応する関数はcurrent_setting(setting_name text)です（9.27.1を参照してください）。
SETコマンドでセッション内でローカルに変更できるパラメータの値を変更することができます。他のセッションには影響がありません。
多くのパラメータはすべてのユーザがこの方法で設定できますが、スーパーユーザか、そのパラメータのSET権限が与えられたユーザだけが設定できるものもあります。
対応するSQL関数はset_config(setting_name, new_value, is_local)です。
（9.27.1を参照してください）。
更にシステムビューの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
こういった工夫で、設定ファイルのバリエーションに対して固有の名前を付与することができます。 また、バージョン管理リポジトリのリポジトリに複数のサーバの設定ファイルを置く場合に生じる曖昧さを排除することができます。 （データベース設定ファイルをバージョン管理することは、これもまた検討に値するやり方です）。