All parameter names are case-insensitive. Every parameter takes a value of one of five types: boolean, string, integer, floating point, or enumerated (enum). The type determines the syntax for setting the parameter: 全てのパラメータの名前は大文字と小文字を区別しません。 それぞれのパラメータは、論理値、整数、浮動小数点、文字列、またはenum（列挙型）の5つの型のいずれかの値を取ります。 型はパラメータをセットするための記法を定義します。

The most fundamental way to set these parameters is to edit the file <filename>postgresql.conf</filename><indexterm><primary>postgresql.conf</primary></indexterm>, which is normally kept in the data directory. A default copy is installed when the database cluster directory is initialized. An example of what this file might look like is: これらのパラメータを設定する最も基本的な方法は、postgresql.confファイルを編集することで、これは通常 data ディレクトリに格納されています。 デフォルトのコピーはデータベースクラスタディレクトリが初期化されるときそこにインストールされます。このファイルがどういったものかの例を示します。

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

One parameter is specified per line. The equal sign between name and value is optional. Whitespace is insignificant (except within a quoted parameter value) and blank lines are ignored. Hash marks (<literal>#</literal>) designate the remainder of the line as a comment. Parameter values that are not simple identifiers or numbers must be single-quoted. To embed a single quote in a parameter value, write either two quotes (preferred) or backslash-quote. If the file contains multiple entries for the same parameter, all but the last one are ignored. 1つの行毎に1つのパラメータが指定されます。 名前と値の間の等号は省略可能です。 （引用符付きのパラメータ値内を除き）空白は特に意味を持たず、何もない行は無視されます。 ハッシュ記号（#）はその行の後の表記がコメントであることを意味します。 単純でない識別子、または数値でないパラメータ値は単一引用符で括られなければなりません。 パラメータ値の中に単一引用符を埋め込むには、引用符を2つ（推奨）もしくはバックスラッシュ-引用符を使います。 ファイル中、同じパラメータに対して複数のエントリが指定されている場合は、最後のエントリ以外は無視されます。

Parameters set in this way provide default values for the cluster. The settings seen by active sessions will be these values unless they are overridden. The following sections describe ways in which the administrator or user can override these defaults. この方法によりクラスタに対してデフォルト値が設定されます。 上書きされない限り、アクティブなセッションが見るのはこの値です。 次節以降では、管理者やユーザがこれらのデフォルト値を上書きする方法を説明します。

The configuration file is reread whenever the main server process receives a <systemitem>SIGHUP</systemitem> signal; this signal is most easily sent by running <literal>pg_ctl reload</literal> from the command line or by calling the SQL function <function>pg_reload_conf()</function>. The main server process also propagates this signal to all currently running server processes, so that existing sessions also adopt the new values (this will happen after they complete any currently-executing client command). Alternatively, you can send the signal to a single server process directly. Some parameters can only be set at server start; any changes to their entries in the configuration file will be ignored until the server is restarted. Invalid parameter settings in the configuration file are likewise ignored (but logged) during <systemitem>SIGHUP</systemitem> processing. 設定ファイルは、メインサーバプロセスがSIGHUPシグナルを受け取るたびに再読み込みされます。 このシグナルを手っ取り早く送信するには、コマンドラインからpg_ctl reloadを実行するか、SQL関数のpg_reload_conf()を呼び出します。 メインサーバプロセスは同時にこのシグナルを、現存のセッションが同様に新しい値を入手できるように、全ての現在実行しているサーバプロセスに伝播します(これは現在実行中のクライアントコマンドの処理を完了してから行われます)。 他の手段として、直接単一のサーバプロセスにシグナルを送ることも可能です。 一部のパラメータはサーバの起動時のみ設定されまするので、設定ファイル中のそれらのエントリの変更はすべて、サーバが再起動されるまで無視されます。 設定ファイル内で無効なパラメータが設定された場合も、同じように（ログには残りますが）SIGHUP 処理中は無視されます。

In addition to <filename>postgresql.conf</filename>, a <productname>PostgreSQL</productname> data directory contains a file <filename>postgresql.auto.conf</filename><indexterm><primary>postgresql.auto.conf</primary></indexterm>, which has the same format as <filename>postgresql.conf</filename> but is intended to be edited automatically, not manually. This file holds settings provided through the <link linkend="sql-altersystem"><command>ALTER SYSTEM</command></link> command. This file is read whenever <filename>postgresql.conf</filename> is, and its settings take effect in the same way. Settings in <filename>postgresql.auto.conf</filename> override those in <filename>postgresql.conf</filename>. postgresql.confに加え、PostgreSQLのデータディレクトリには postgresql.auto.confというファイルがあります。 このファイルは postgresql.conf と同じフォーマットですが、手動ではなく自動で編集されることを意図しています。 このファイルはALTER SYSTEMコマンドを使った設定値を保存します。 このファイルはpostgresql.conf が読み込まれるときはいつでも自動的に読み込まれ、同じように設定が反映されます。 postgresql.auto.confは、postgresql.confの設定を上書きします。

External tools may also modify <filename>postgresql.auto.conf</filename>. It is not recommended to do this while the server is running unless <xref linkend="guc-allow-alter-system"/> is set to <literal>off</literal>, since a concurrent <command>ALTER SYSTEM</command> command could overwrite such changes. Such tools might simply append new settings to the end, or they might choose to remove duplicate settings and/or comments (as <command>ALTER SYSTEM</command> will). 外部ツールもpostgresql.auto.confを変更するかも知れません。 ALTER SYSTEMが変更を上書きする可能性があるので、allow_alter_systemがoffに設定されていない限り、サーバが稼働中は外部ツールによる変更は推奨されません。 そのようなツールは、単に新しい設定を最後に追加するか、重複した設定あるいはコメント(ALTER SYSTEMが行います)を削除することを選択するかも知れません。

The system view <link linkend="view-pg-file-settings"><structname>pg_file_settings</structname></link> can be helpful for pre-testing changes to the configuration files, or for diagnosing problems if a <systemitem>SIGHUP</systemitem> signal did not have the desired effects. システムビューのpg_file_settingsは、設定ファイルへの変更を前もってテストしたい場合や、SIGHUPシグナルで望み通りの効果がなかった場合に問題を調査する際に役立ちます。

<productname>PostgreSQL</productname> provides three SQL commands to establish configuration defaults. The already-mentioned <command>ALTER SYSTEM</command> command provides an SQL-accessible means of changing global defaults; it is functionally equivalent to editing <filename>postgresql.conf</filename>. In addition, there are two commands that allow setting of defaults on a per-database or per-role basis: PostgreSQLは3つのSQLコマンドでデフォルト値を設定します。 すでに説明したALTER SYSTEMコマンドは、SQLによってグローバルな設定値を変更する方法を提供します; postgresql.confを編集するのと等価です。これに加え、データベース単位あるいはロール単位で設定するためのコマンドがあります:

Values set with <command>ALTER DATABASE</command> and <command>ALTER ROLE</command> are applied only when starting a fresh database session. They override values obtained from the configuration files or server command line, and constitute defaults for the rest of the session. Note that some settings cannot be changed after server start, and so cannot be set with these commands (or the ones listed below). ALTER DATABASEとALTER ROLEによる設定値は新しくデータベースセッションを開始した時にのみ適用されます。 これらのコマンドは設定ファイルやサーバへのコマンド引数による設定値を上書きし、セッションの以後の状態に適用します。なお、一部の設定はサーバを起動した後では変更できず、これらのコマンドを使っては設定できません(以下に記述するコマンドでも同じことが言えます)。

Once a client is connected to the database, <productname>PostgreSQL</productname> provides two additional SQL commands (and equivalent functions) to interact with session-local configuration settings: クライアントがデータベースに接続すると、PostgreSQLでは更に2つのSQL(そして同等の関数)を使ってセッションローカルの設定変更を行うことができます。

In addition, the system view <link linkend="view-pg-settings"><structname>pg_settings</structname></link> can be used to view and change session-local values: 更にシステムビューのpg_settingsを使ってセッションローカルな値を参照したり変更することができます。

In addition to setting global defaults or attaching overrides at the database or role level, you can pass settings to <productname>PostgreSQL</productname> via shell facilities. Both the server and <application>libpq</application> client library accept parameter values via the shell. グローバルなデフォルト値を設定したりデータベース、ロール単位で上書きを行えるだけでなく、シェル機能を使ってPostgreSQLに設定値を渡すことができます。 サーバもlibpqクライアントライブラリもシェル経由でパラメータ値を受けとることができます。

<productname>PostgreSQL</productname> provides several features for breaking down complex <filename>postgresql.conf</filename> files into sub-files. These features are especially useful when managing multiple servers with related, but not identical, configurations. PostgreSQLは複雑なpostgresql.confファイルを複数の小さなファイルに分割する複数の方法を提供しています。 これは、とりわけお互いに関連しているものの設定が同じではない複数のサーバを管理する際に有用です。

In addition to individual parameter settings, the <filename>postgresql.conf</filename> file can contain <firstterm>include directives</firstterm>, which specify another file to read and process as if it were inserted into the configuration file at this point. This feature allows a configuration file to be divided into physically separate parts. Include directives simply look like: パラメータ設定に加え、postgresql.confファイルにincludeディレクティブを入れることができます。 このようにすると、別のファイルがあたかも設定ファイルのその場所に挿入されているかのごとく読み込まれ、処理されるように指定されます。 この機能により、設定ファイルを物理的に異なる複数のパーツに分解することができます。 Includeディレクティブは単に次のような形式になります。 <programlisting> include 'filename' </programlisting>

include 'ファイル名'

If the file name is not an absolute path, it is taken as relative to the directory containing the referencing configuration file. Inclusions can be nested. ファイル名が絶対パスでない場合、参照する設定ファイルを含むディレクトリからの相対パスであると受け取られます。 Includeコマンドは入れ子にすることができます。

There is also an <literal>include_if_exists</literal> directive, which acts the same as the <literal>include</literal> directive, except when the referenced file does not exist or cannot be read. A regular <literal>include</literal> will consider this an error condition, but <literal>include_if_exists</literal> merely logs a message and continues processing the referencing configuration file. include_if_existsディレクティブもあります。 これは参照ファイルが存在しないか、または読み込むことができない場合の動作を除き、includeディレクティブと同一の動作をします。 通常のincludeはこれをエラーと解釈しますが、include_if_existsはただ単にメッセージをログ出力し、そして参照している設定ファイルの処理を続けます。

The <filename>postgresql.conf</filename> file can also contain <literal>include_dir</literal> directives, which specify an entire directory of configuration files to include. These look like includeする設定ファイルを含むディレクトリ全体を指定するinclude_dirディレクティブを、postgresql.confファイルに含めることもできます。 このような感じです。 <programlisting> include_dir 'directory' </programlisting>

include_dir 'ディレクトリ名'

Non-absolute directory names are taken as relative to the directory containing the referencing configuration file. Within the specified directory, only non-directory files whose names end with the suffix <literal>.conf</literal> will be included. File names that start with the <literal>.</literal> character are also ignored, to prevent mistakes since such files are hidden on some platforms. Multiple files within an include directory are processed in file name order (according to C locale rules, i.e., numbers before letters, and uppercase letters before lowercase ones). 絶対パスではないディレクトリ名はその設定ファイルがあるディレクトリへの相対パスと見なされます。 指定したディレクトリの中で、ディレクトリではないファイルで末尾が.confで終わるファイルだけがincludeされます。 また、文字. で開始するファイル名は一部のプラットフォームでは隠しファイルとされるので、間違いを防止するため無視されます。 includeされるディレクトリにある複数ファイルはファイル名順に処理されます(ファイル名は C ロケール規則で順序付けされます。 つまり、文字より数字、小文字より大文字が先になります)。

Include files or directories can be used to logically separate portions of the database configuration, rather than having a single large <filename>postgresql.conf</filename> file. Consider a company that has two database servers, each with a different amount of memory. There are likely elements of the configuration both will share, for things such as logging. But memory-related parameters on the server will vary between the two. And there might be server specific customizations, too. One way to manage this situation is to break the custom configuration changes for your site into three files. You could add this to the end of your <filename>postgresql.conf</filename> file to include them: includeされるファイルもしくはディレクトリは、大きな単一のpostgresql.confファイルを使う代わりに、データベース設定の一部分を論理的に分離するために使用することが可能です。 異なるメモリ容量を持つ二つのデータベースサーバを所有する会社を考えてみてください。 例えばログ取得のように、二つが共有する設定の要素があると思われます。 しかし、サーバ上のメモリに関連したパラメータは二つの間では異なります。 更に、サーバ特有のカスタマイズも存在することがあります。 この状況に対処する一つの方法として、そのサイトに対するカスタマイズされた設定の変更を三つのファイルにすることです。 それらをincludeするためにはpostgresql.confファイルの最後に以下を追加します。

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

All systems would have the same <filename>shared.conf</filename>. Each server with a particular amount of memory could share the same <filename>memory.conf</filename>; you might have one for all servers with 8GB of RAM, another for those having 16GB. And finally <filename>server.conf</filename> could have truly server-specific configuration information in it. 全てのシステムは同一のshared.confを所有する様になるでしょう。 特定のメモリ容量を所有するそれぞれのサーバは同じmemory.confを共有できます。 RAMが8GBのすべてのサーバには共通のmemory.confを1つ使い、16GBのサーバ群には別のものを使う、ということもできるでしょう。 そして最後のserver.confには、本当にサーバ固有となる設定情報を記載します。

Another possibility is to create a configuration file directory and put this information into files there. For example, a <filename>conf.d</filename> directory could be referenced at the end of <filename>postgresql.conf</filename>: 別の方法として、設定ファイルディレクトリを作成し、この情報をそこのファイルに格納することができます。 たとえば、conf.dディレクトリをpostgresql.confの最後で参照するようにできます。

include_dir 'conf.d'

Then you could name the files in the <filename>conf.d</filename> directory like this: そして、conf.dの中のファイルを以下のような名前にすることができます。

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

This naming convention establishes a clear order in which these files will be loaded. This is important because only the last setting encountered for a particular parameter while the server is reading configuration files will be used. In this example, something set in <filename>conf.d/02server.conf</filename> would override a value set in <filename>conf.d/01memory.conf</filename>. この命名規則により、これらのファイルが読み込まれる順序が明確になります。 サーバが設定を読み込んでいるときに各パラメータについて最後にあった設定だけが使用されるので、このことは重要です。 この例では、conf.d/02server.confでされた指定はconf.d/01memory.confの設定値よりも優先します。

You might instead use this approach to naming the files descriptively: 代わりに以下の方法を使って、ファイルにわかりやすい名前をつけることもできます。

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

This sort of arrangement gives a unique name for each configuration file variation. This can help eliminate ambiguity when several servers have their configurations all stored in one place, such as in a version control repository. (Storing database configuration files under version control is another good practice to consider.) こういった工夫で、設定ファイルのバリエーションに対して固有の名前を付与することができます。 また、バージョン管理リポジトリのリポジトリに複数のサーバの設定ファイルを置く場合に生じる曖昧さを排除することができます。 （データベース設定ファイルをバージョン管理することは、これもまた検討に値するやり方です）。