データベースシステムの動作に影響する設定パラメータはたくさんあります。 この節ではそれらの設定方法を述べ、節の残りで1つ1つについて説明します。
全てのパラメータ名は大文字/小文字を区別しません。 それぞれのパラメータは、ブーリアン（論理）、整数、浮動小数点、文字列の4つの型のいずれかの値を持ちます。 ブーリアンの値はON、OFF、TRUE、FALSE、YES、NO、1、0と記述することができます（全て大文字/小文字の区別はありません）。 また、曖昧でなければ、これらの頭文字でも構いません。
これらのパラメータを設定するための1つの方法として、postgresql.confファイルを編集することがあります。 通常、このファイルはデータディレクトリに格納されています(initdbはデフォルトのコピーをここにインストールします)。 このファイルがどのようになっているかについて、例を以下に示します。
# This is a comment log_connections = yes log_destination = 'syslog' search_path = '$user, public'
パラメータは1行につき1つです。 名前と値の間の等号記号はなくても構いません。 空白は意味を持たず、空行は無視されます。 ハッシュ記号（"#"）はどこにあってもコメントを意味します。 単純な識別子や数値ではないパラメータ値は、単一引用符で囲む必要があります。
この設定ファイルはpostmasterがSIGHUPシグナルを受けるたびに再読み込みされます (これは、pg_ctl reload による方法が最も簡単です)。 また、postmasterはこのシグナルを、実行中のセッションが新しい値を取得するように、現在稼働中の全てのサーバプロセスにも伝えます。 なお、シグナルを単一のサーバプロセスのみに直接送ることもできます。 パラメータの中にはサーバ起動時にのみ設定できるものがあります。 設定ファイル内のそうした項目を変更したとしても、サーバが再起動されるまで無視されます。
これらの設定パラメータを指定する2番目の方法として、下記のようにpostmasterにコマンドラインオプションとして渡す方法があります。
postmaster -c log_connections=yes -c log_destination='syslog'
コマンドラインオプションはpostgresql.confの中の重複する設定を上書きします。 これは、postgresql.confを変更しただけで値が変更できるわけではないことを意味し、従って、コマンドラインによる方法は便利ではあるけれども、後で柔軟性を損なうことになることに注意してください。
コマンドラインオプションを1つの特定のセッションのみに渡すことが有用な場合があります。 これは下記のように、クライアント側でPGOPTIONS環境変数を使用することによって可能となります。
env PGOPTIONS='-c geqo=off' psql
(これは、psqlのみならず、libpqベースのあらゆるクライアントアプリケーションで使用することができます。) サーバ起動時に固定されるパラメータやpostgresql.confで指定する必要があるパラメータでは使用できないことに注意してください。
更に、ユーザやデータベースに対してオプション設定群を割り当てることも可能です。 セッションが起動する度に、呼び出したユーザのデフォルトとデータベースのデフォルトの設定が読み込まれます。 ALTER USERコマンドとALTER DATABASEコマンドがそれぞれ、これらの設定のために使用されます。 データベース毎の設定は、postmasterのコマンドラインや設定ファイルに由来する設定を上書きします。 その次に、ユーザ毎の設定によって上書きされます。 そして更に、両者ともセッション毎のオプションによって上書きされます。
いくつかのパラメータは個別のSQLセッションの中でSETコマンドを使って変更することができます。 例えば下記のようになります。
SET ENABLE_SEQSCAN TO OFF;
SETが許される場合、その設定は他の手段により設定されたパラメータ値を上書きします。 一部のパラメータはSETで変更することができません。 例えば、理論上PostgreSQLの再起動を行なければその動作を制御できないパラメータなどです。 またパラメータの中にはスーパーユーザのみがSETコマンドやALTERコマンドで変更でき、一般ユーザでは変更できないものもあります。
SHOWコマンドにより、全てのパラメータの現在値を確認することができます。
また、(項41.35で説明する)pg_settings仮想テーブルによって、セッションの実行時パラメータを表示、更新することができます。 これは、SHOWとSETと等価ですが、他のテーブルと結合することや任意の希望選択条件を設定して選択することができ、より便利です。
上で説明したpostgresql.confファイル以外に、PostgreSQLは2つの設定ファイルを使用します。 これらは手作業で編集するものであり、クライアント認証を制御します。 (使用方法については、第19章で説明します。) デフォルトでは、3つの設定ファイルは全てデータベースクラスタのデータディレクトリに格納されます。 本小節で説明するオプションにより、この設定ファイルを別の場所に格納することができます。 (これにより管理をし易くできます。 具体的には、設定ファイルを分けて保持することで、設定ファイルの適切なバックアップを確実に行うことが容易になります。)
データ格納用に使用されるディレクトリを指定します。 このオプションはサーバ起動時にのみ設定可能です。
主サーバ設定ファイル（慣習的にpostgresql.confと呼ばれます）を指定します。 このオプションはpostmasterコマンドラインでのみ設定可能です。
ホストベース認証(HBA)用のファイルを指定します。 (慣習的な名前はpg_hba.confです。) このオプションはサーバ起動時にのみ設定可能です。
ident認証用の設定ファイルを指定します。 (慣習的な名前はpg_ident.confです。) このオプションはサーバ起動時にのみ設定可能です。
postmasterがサーバ管理用プログラムでの使用のために作成する、補助的なプロセスID(PID)ファイルを指定します。 このオプションはサーバ起動時にのみ設定可能です。
デフォルトのインストレーションでは、上述のオプションはいずれも明示的な設定がありません。 その代わりに、データディレクトリは-DコマンドラインオプションやPGDATA環境変数で指定され、全ての設定ファイルはこのデータディレクトリに格納されます。
設定ファイルをデータディレクトリ以外の場所に格納したいのであれば、必ず-Dコマンドラインオプション、もしくは、PGDATA環境変数で設定ファイルを格納するディレクトリを指し示し、そして、必ず実際のデータディレクトリのある場所を示すように、postgresql.conf内（もしくはコマンドラインで）data_directoryを設定します。 データディレクトリの場所についてはdata_directoryが-DとPGDATAを上書きし、設定ファイルの場所については上書きしないことに注意してください。
望むならば、オプションconfig_file、hba_file、ident_file、もしくはこの全てのオプションを使用して、設定ファイルの名前と場所を個々に指定することもできます。 config_fileはpostmasterコマンドラインでのみ指定可能ですが、他は主設定ファイル内で設定可能です。 この3オプションとdata_directoryが明示的に設定されていた場合は、-DやPGDATAを指定する必要はありません。
これらのオプションのいずれかを設定する時、相対パスはpostmasterを起動したディレクトリから見た相対パスとして解釈されます。
サーバがクライアントアプリケーションからの接続を監視するTCP/IPアドレスを指定します。 この値は、カンマ区切りのホスト名かIPアドレスもしくはその両方のリストという形を取ります。 *という特別な項目は利用可能な全てのIPインタフェースに対応します。 このリストが空の場合、サーバはIPインタフェースの監視を全く行いません。 この場合は接続にUnixドメインソケットのみが使用されます。 デフォルト値はlocalhostであり、ローカルな"ループバック"接続のみが可能です。 このパラメータはサーバ起動時のみ設定可能です。
サーバが監視するTCPポートです。 デフォルトは5432です。 サーバが監視する全てのIPアドレスで同一ポート番号が使用されることに注意してください。 このパラメータはサーバ起動時のみ設定可能です。
データベースサーバへの同時接続の最大数を決定します。 デフォルトは通常100ですが、カーネル設定がサポートしていない場合はもっと少なくなります。 (これはinitdb時に決定されます。) このパラメータはサーバ起動時にのみ設定することができます。
このパラメータを増加させることで、PostgreSQLは、使用中のオペレーティングシステムのデフォルト設定が許可する量よりも多くのSystem V共有メモリやセマフォを要求する可能性があります。 必要ならば、これらのパラメータの調整方法について項16.5.1を参照してください。
PostgreSQLスーパーユーザによる接続用に予約される接続"スロット"の数を設定します。 最大でmax_connectionsの数までの接続を同時にアクティブにすることができます。 アクティブな同時接続の数がmax_connectionsからsuperuser_reserved_connectionsを引いた数以上の時ならばいつでも、スーパーユーザアカウントからの新規接続のみが受け入れられます。
デフォルト値は2です。 この値は、max_connectionsの値よりも小さくなければなりません。 このパラメータはサーバ起動時にのみ設定することができます。
サーバがクライアントアプリケーションからの接続を監視するUnixドメインソケットのディレクトリを指定します。 デフォルトは通常/tmpですが、構築時に変更することができます。 このパラメータはサーバ起動時にのみ設定可能です。
Unixドメインソケットを所有するグループを設定します。 (ソケットを所有するユーザは常に、サーバを起動するユーザです。) UNIX_SOCKET_PERMISSIONSオプションと一緒に使うと、Unixドメイン接続の追加アクセス制御機構として使うことができます。 デフォルトでは空文字列で、現在のユーザのデフォルトグループを使います。 このオプションはサーバの起動時にのみ設定できます。
Unixドメインソケットのアクセス権限を設定します。 Unixドメインソケットは通常のUnixファイルシステム権限の設定を使います。 このオプション値はchmodとumaskシステムコールが受け付ける数値のモード指定を想定しています(通常使われる8進数書式を使うためには0(ゼロ)で始まらなくてはいけません）。
デフォルトの権限は、誰でも接続できる0777になっています。 変更するならば0770（ユーザとグループのみです。UNIX_SOCKET_GROUPも参照してください）や0700（ユーザのみ）が適切です。 （実際、Unixドメインソケットでは書き込み権限だけが問題です。 そのため、読み込み権限や実行権限を設定または解除する意味はありません。）
このアクセス制御機構は第19章で説明するものから独立しています。
このオプションはサーバの起動時にのみ設定できます。
Rendezvousブロードキャスト名を指定します。 デフォルトでは、''と指定された時と同様、コンピュータ名が使用されます。 このオプションは、Rendezvousサポートを付けずにコンパイルされたサーバでは無視されます。 このオプションはサーバ起動時にのみ設定可能です。
クライアント認証の完了までの最大時間を秒数で表したものです。 クライアントがこの最大時間までに認証プロトコルを完了できなかったとすると、サーバは接続を中断します。 これは、ハングしたクライアントによって接続が永遠に残ってしまうことを防止します。 このオプションはサーバの起動時、もしくは、postgresql.confファイル内で設定可能です。 デフォルトは60です。
SSL接続を有効にします。 これを使用する前に項16.8を読んでください。 デフォルトは無効です。 このパラメータはサーバ起動時にのみ設定可能です。
ENCRYPTEDもしくはUNENCRYPTEDの指定無しにCREATE USERもしくはALTER USERでパスワードが指定された場合、このオプションがパスワードの暗号化を行なうかどうかを決定します。 デフォルトは有効(パスワードを暗号化する)です。
Kerberosサーバキーファイルの場所を設定します。 詳細は項19.2.3を参照してください。
データベース毎のユーザ名を許可します。 デフォルトでは無効です。
これが有効な場合、username@dbnameとしてユーザを作成しなければなりません。 usernameが接続中のクライアントから渡された場合、@とデータベース名がユーザ名に追加され、サーバによってそのデータベース固有のユーザ名が検索されます。 SQL環境下で@を含むユーザ名を作成する時には、ユーザ名を引用符で括る必要があることに注意してください。
このオプションを有効にしていても、通常のグローバルなユーザを作成することができます。 ユーザ名をクライアントで指定する時に、単に@を付けてください。 @は、サーバによってユーザ名が検索される前に除去されます。
注意: この機能は、完全な解決方法が見つかるまでの一時的な手法として意図されています。 見つかったら、このオプションは削除されます。
データベースサーバで使用される共有メモリバッファの数を設定します。 デフォルトは、通常1000ですが、使用するカーネル設定がサポートしていなければ、より少なくなります。 (これはinitdb時に決まります。) BLCKSZをサーバを構築した時に変更していない限り、各バッファは8192バイトです。 この設定は少なくとも16でなければなりません。 また、同時に、少なくともmax_connectionsの2倍でなければなりません。 しかし、通常はこの最小よりもかなり大きめに設定することが性能の向上のために必要です。 実運用のインストレーションでは数千程度の値を推奨します。 このオプションはサーバ起動時のみ設定可能です。
この値を増加すると、PostgreSQLは、オペレーティングシステムのデフォルト設定が許可する数よりも多くのSystem V共有メモリを要求する可能性があります。 必要ならば、このパラメータの調整方法の情報について項16.5.1を参照してください。
一時ディスクファイルへの切替えを行う前に、内部ソート操作とハッシュテーブルで使われるメモリの量を指定します。 この値はキロバイト単位で指定し、そのデフォルトは1024キロバイトです (1MB)。 複雑な問い合わせでは、いくつかのソート操作やハッシュ操作が並行して実行される可能性があり、その場合それぞれがデータを一時ファイルに書き出す前にこの値が指定した量のメモリを使うことが許されます。 また、それぞれの稼働中のセッションが同時にこうした操作をしている可能性があります。 従って、使用されるメモリの合計はwork_memの値の何倍にもなり得ます。 この値を検討する際には常にこのこと注意する必要があります。 ソート操作は、ORDER BY、DISTINCT、マージ結合で使用されます。 ハッシュテーブルはハッシュ結合、ハッシュを基にした集約、ハッシュを基に処理するIN副問い合わせで使用されます。
VACUUMやCREATE INDEX、ALTER TABLE ADD FOREIGN KEYなどの保守作業で使用される最大メモリ量を指定します。 この値はキロバイト単位で指定し、デフォルトは16384キロバイト（16MB）です。 1つのデータベースセッションでは、1度に1つしか上記操作はできませんし、通常インストレーションでこうした操作が同時に非常に多く発生することはありませんので、これをwork_memよりもかなり多めの値にしても安全です。 多めに設定することで、バキューム処理やデータベースダンプのリストアの性能が向上します。
サーバの実行スタックの安全な最大サイズを指定します。 このパラメータの理想設定値は、カーネルにより強制される実スタックサイズ上限（ulimit -sもしくは相当コマンドの設定）から1メガバイト程度の安全マージン分差し引いたものです。 再帰処理される可能性がある一部の処理、例えば式の評価、を除き、サーバの各処理にてスタックサイズの検査を行っていませんので、この安全マージンが必要です。 このパラメータをカーネルの実スタックサイズ上限よりも大きくすることは、過多な再帰処理により個々のバックエンドがクラッシュすることを意味します。 デフォルトの設定は2048KB（2MB）で、かなり低くクラッシュの危険性が無い値です。 しかし、複雑な関数を実行するには小さすぎるかもしれません。
空き領域が共有空き領域マップ内で追跡される、ディスクページの最大数を設定します。 共有メモリの6バイトが各ぺージスロットで消費されます。 この設定は16 * max_fsm_relationsよりも大きくなければなりません。 デフォルトは20000です。 このオプションはサーバ起動時にのみ設定できます。
空き領域が共有空き領域マップ内で追跡される、リレーション(テーブルとインデックス)の最大数を設定します。 共有メモリのおおよそ50バイトが各スロットで消費されます。 デフォルトは1000です。 このオプションはサーバ起動時にのみ設定できます。
各サーバ子プロセスで同時にオープンできるファイルの最大数を設定します。 デフォルトは1000です。 カーネルが安全のためにプロセス当たりの制限を強制している場合は、この設定を気にする必要はありません。 しかし、プラットフォームによっては(特にほとんどのBSDシステムでは)、非常に多くのプロセス全てが多くのファイルを開こうとした時に、カーネルは個々のプロセスがシステムが実際にサポートできるファイル数より多くを開くことを許しています。 もし"Too many open files"というエラーが発生したら、この設定を減少させてください。 このオプションはサーバの起動時にのみ設定できます。
この変数は、サーバ起動時点であらかじめ読み込む1つ以上の共有ライブラリを指定します。 各ライブラリについて、オプションとしてパラメータのない初期化関数を呼び出すことができます。 そのように指定するには、コロンとその初期化関数名をライブラリ名の後に付けてください。 例えば'$libdir/mylib:mylib_init'は、mylibをあらかじめ読み込み、mylib_initを実行します。 複数のライブラリを読み込む場合は、カンマでその名前を区切ってください。
指定したライブラリや初期化関数が存在しない場合、サーバの起動に失敗します。
PostgreSQL手続き言語ライブラリはこの方法であらかじめ読み込まれます。 通常は'$libdir/plXXX:plXXX_init'という構文を使用し、ここで、XXXはpgsql、perl、tcl、pythonです。
共有ライブラリを事前に読み込むこと(および、適切ならば初期化すること)で、最初にライブラリを使用する時のライブラリの起動時間を省くことができます。 しかし、新しいサーバプロセスがライブラリを全く使用しない場合でも、そのプロセスの起動に要する時間は僅かに増加します。 従って、多くのセッションで使用されるはずのライブラリの場合にのみ、このオプションを推奨します。
VACUUMおよびANALYZEの実行中、システムは実行される各種I/O操作の推定コストの履歴記録を保持する内部カウンタを管理します。 実施されたコストが（vacuum_cost_limitで指定される）上限に達した時、操作を実行するプロセスはしばらく（vacuum_cost_delayで指定される期間）休止します。 その後、このカウンタはリセットされ、実行を継続します。
この機能の目的は、管理者によってこれらのコマンドと同時に実行されるデータベース活動のI/Oに与える影響を軽減できるようにすることです。 VACUUMやANALYZEといったコマンドが即座に終了するため、これが大して重要でない状況が多いでしょう。 しかし、通常は、これらのコマンドによって他のデータベース操作を実施するシステムの活動を阻害させないことが非常に重要です。 コストベースのバキューム遅延は、これを実現する手段を提供します。
この機能はデフォルトで無効です。 有効にするためにはvacuum_cost_delayに0以外の値を設定してください。
コストの上限を超えた時にプロセスが休止する、ミリ秒単位の期間です。 デフォルト値は0であり、コストベースのバキューム遅延機能が無効であることを意味します。 正の値はコストベースのバキューム遅延機能を有効にします。 多くのシステムでは、休止遅延時間の実精度は10ミリ秒であることに注意してください。 vacuum_cost_delayの1の位を変更しても結果は変わりません。 変更するためには10以上の位を設定してください。
共有バッファキャッシュにあるバッファをバキュームする際の推定コストです。 バッファプールをロックするコスト、共有ハッシュテーブルを検索するコスト、および、ページの内容を走査するコストを表します。 デフォルト値は1です。
ディスクから読み取られるバッファをバキュームする際の推定コストです。 バッファプールをロックする作業、共有ハッシュテーブルを検索する作業、および、ディスクから対象ブロックを読み取り、その内容を走査する作業を表します。 デフォルト値は10です。
整理済みのブロックをバキューム処理が変更する際に課せられる推定コストです。 変更したブロックをディスクに再度吐き出すために必要となる余計なI/Oを表します。 デフォルト値は20です。
バキューム処理プロセスが休止することになる、累積コストです。 デフォルト値は200です。
注意: 重大なロックを保持する操作があり、その操作は可能な限り高速に完了させなければなりません。 コストベースのバキューム遅延はそうした操作時には起こりません。 従って、コストを累積した時に指定した上限をかなり超えることがあります。 こうした場合に不要に長期間の遅延が起こらないように、実遅延はvacuum_cost_delay * accumulated_balance / vacuum_cost_limitで計算され、最大でもvacuum_cost_delay * 4です。
PostgreSQL 8.0からサーバプロセスとは別にバックグランドライタというプロセスが存在します。 このプロセスの機能は、"ダーティ"共有バッファ（ディスクに未書き込みの変更済みバッファ）の書き込み処理を行うことです。 この目的は、バックグランドライタが代行することにより、ユーザの問い合わせを扱うサーバプロセスが書き込み待ち状態にほぼならないようにすることです。 また、これを設置することで、チェックポイントに関する性能への束縛を低減させることができます。 各チェックポイントにてそれまでのダーティバッファをまとめて扱うのではなく、チェックポイント時刻に達した時に強制的に書き出さなければならないページが数個程度になるように、バックグランドライタは断続的にダーティページをディスクに書き出します。 しかし、繰り返し変更されるページでは、これまではチェックポイント間隔に一度書き出されていましたが、バックグランドライタは同じ間隔内で複数回書き出しますので、全体としてのI/O負荷は多くなります。 ほとんどの場合、定期的にピークがある負荷よりも継続的に低い負荷の方が好まれます。 しかし、本節で説明したこのパラメータはサイト独自の必要に応じて動作を変更することに使用できます。
バックグランドライタの動作周期の遅延時間を指定します。 各周期で、ライタはダーティバッファの一部の書き込みを行います。（後述のパラメータで制御可能です。） 選択されたバッファは常に現在の変更済みバッファ内で最も最古に使用されたものになります。 そして、bgwriter_delayミリ秒休止し、その後これを繰り返します。 デフォルト値は200です。 多くのシステムでは、休止遅延時間の実精度は10ミリ秒であることに注意してください。 bgwriter_delayの1の位を変更しても結果は変わりません。 変更するためには10以上の位を設定してください。 このオプションはサーバ起動時、もしくは、postgresql.confファイル内でのみ設定可能です。
各周期では、現在のダーティバッファの内ここで指定した割合以上のバッファを書き出しません。 （端数は次のバッファ数まで切り上げられます。） デフォルト値は1です。 このオプションはサーバ起動時、もしくは、postgresql.confファイル内でのみ設定可能です。
各周期では、ここで指定した数以上のダーティバッファを書き出しません。 デフォルトは100です。 このオプションはサーバ起動時、もしくは、postgresql.confファイル内でのみ設定可能です。
bgwriter_percentとbgwriter_maxpagesの値を小さくすることで、バックグランドライタで発生する余計なI/O負荷を低減することができます。 しかし、その分チェックポイント時点の作業が多くなります。 チェックポイント時点の負荷のピークを低減するには、この値を大きくしてください。 バックグランドライタの処理を完全に無効するためには、bgwriter_percentやbgwriter_maxpages、もしくは、この両方をゼロに設定してください。
WALの調整についての詳細は 項25.2 を参照してください。
このオプションが有効な場合、PostgreSQLサーバはfsync()システムコールを様々な場所で使用し、確実に更新内容を物理的にディスクに書き込みます。 これにより、オペレーティングシステムやハードウェアクラッシュの後、確実にデータベースクラスタを一貫した状態に復旧させることができます。
しかし、fsync()の使用は性能を悪化させます。 トランザクションのコミット時、PostgreSQLはオペレーティングシステムが先行書き込みログをディスクに書き出すまで待機しなければなりません。 fsync()が無効ならば、オペレーティングシステムは最大限バッファに保持し、順序変更や、書き込みを遅延させることができます。 これにより、かなり性能が向上することになります。 しかし、システムがクラッシュした場合、最後の数個のコミットしたトランザクションは、一部あるいは完全に消えてしまう可能性があります。 最悪の場合、復旧できないデータの破損が発生します。 (これはデータベースサーバ自体のクラッシュとは関係しません。 オペレーティングシステムレベルのクラッシュのみが破損の危険性を持ちます。)
この危険性のため、fsyncについて共通的な正しい設定はありません。 常にfsyncを無効にする管理者もいますし、失敗したとしても再実行時点が明確な、大量のロードの時のみ無効にする管理者もいます。 常にfsyncを有効にする管理者もいます。 信頼性を最大にするために、デフォルトでfsyncは有効です。 オペレーティングシステム、ハードウェア、付属設備(バッテリバックアップなど)が信頼できる場合、fsyncを無効にしても構いません。
このオプションはサーバ起動時、もしくは、postgresql.confファイルでのみ設定できます。
強制的にWALをディスクに更新させるために使用される方法です。 取り得る値は fsync (コミットの度にfsync()を呼び出します。)、 fdatasync (コミットの度に fdatasync() を呼び出します。)、 fsync_writethrough (Windows上でコミットの度に_commit()を呼び出します。), open_sync (O_SYNCオプション付きのopen() でWALファイルを書き出します。)、 open_datasync (O_DSYNCオプション付きのopen() でWALファイルを書き出します。) これら全てが全てのプラットフォームで利用できるわけではありません。 fsyncが無効であっても、この設定は関係ありません。 このオプションはサーバ起動時、もしくは、postgresql.confファイルでのみ設定できます。
共有メモリ内に割り当てられた、WALデータ用のディスクページバッファ数です。 デフォルトは8です。 この設定は、1つの典型的なトランザクションで生成されるWALデータの量を保持できる分の容量のみが必要です。 このオプションはサーバの起動時にのみ設定できます。
コミットされたレコードをWALバッファに書き出してから、そのバッファをディスクに吐き出すまでの遅延時間です。 単位はマイクロ秒です。 システム負荷が高く、指定期間内にコミット準備ができたトランザクションが複数存在した場合、非0の遅延時間により複数のトランザクションを一度のfsync()システムコールのみでコミットすることができます。 しかし、この遅延時間は、他にコミット準備ができたトランザクションがなければ、ただの無駄です。 従って、この遅延は、サーバプロセスがそのコミットレコードを書き出す時に、少なくともcommit_siblings個のトランザクションが他に有効な場合にのみ行われます。 デフォルトは0（遅延なし）です。
commit_delay遅延の実行前に必要となる、同時に開いているトランザクションの最小数です。 値をより大きくすることは、この遅延期間内に少なくとも1つ、他のトランザクションのコミット準備が整ったことをより確実にします。 デフォルトは5です。
自動WALチェックポイントの間の最大距離を、ログファイルセグメントの数 （それぞれのセグメントは通常16Mバイトです）で指定します。 デフォルトは3です。 このオプションはサーバ起動時かpostgresql.confファイルでのみ設定できます。
自動WALチェックポイント同士の間隔を秒で指定します。 デフォルトは300秒です。 このオプションはサーバ起動時かpostgresql.confファイルでのみ設定できます。
チェックポイントセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した秒数よりも頻繁に発生する場合、サーバログにメッセージを書き出します。 デフォルトは30秒です。 ゼロはこの警告を無効にします。
一連のWALファイルの完成したセグメントをアーカイブするために実行されるシェルコマンドです。 これが空文字（デフォルト）の場合、WALアーカイブ処理は無効です。 文字列内の%pは全てアーカイブするファイルの絶対パスに置換され、%fはファイル名部分のみに置換されます。 コマンドに%文字を埋め込む場合は%%を使用してください。 詳細は項22.3.1を参照してください。 このオプションはサーバ起動時かファイルpostgresql.confでのみ設定できます。
このコマンドが成功した時にのみ0終了ステータスを返すようにすることが重要です。 以下に例を示します。
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
これらの設定パラメータは、問い合わせオプティマイザが選択する問い合わせ計画に影響する粗野な手法を提供します。 特定の問い合わせでオプティマイザが選択するデフォルトの計画が最適ではない場合、一時的な解法を、これらの設定パラメータの1つを使用して強制的にオプティマイザが異なる計画を選択することで見つけられる場合があります。 しかし、これらのパラメータのいずれかをずっと無効にしておくことはあまり勧められません。 オプティマイザが選択する計画の質を改良する他の方法として、プランナコスト定数の設定を行なうこと、より頻繁にANALYZEを行なうこと、default_statistics_target設定パラメータを増加させること、ALTER TABLE SET STATISTICSを使用して特定列に関して収集する統計情報の量を増加させることがあります。
問い合わせプランナがハッシュされた集約計画型を選択することを有効、あるいは、無効にします。 デフォルトは有効です。
問い合わせプランナがハッシュ結合計画型を選択することを有効、あるいは、無効にします。 デフォルトは有効です。
問い合わせプランナがインデックススキャン計画型を選択することを有効、あるいは、無効にします。 デフォルトは有効です。
問い合わせプランナがマージ結合計画型を選択することを有効、あるいは、無効にします。 デフォルトは有効です。
問い合わせプランナが入れ子状ループ結合計画型を選択することを有効、あるいは、無効にします。 完全に入れ子状ループ結合を抑制することはできません。 しかし、この変数を無効にすることで、もし他の方法が利用できるのであれば、プランナはその使用を行なわないようになります。 デフォルトは有効です。
問い合わせプランナがシーケンシャルスキャン計画型を選択することを有効、あるいは、無効にします。 完全にシーケンシャルスキャンを抑制することはできません。 しかし、この変数を無効にすることで、もし他の方法が利用できるのであれば、プランナはその使用を行なわないようになります。 デフォルトは有効です。
問い合わせプランナが明示的なソート段階を選択することを有効、あるいは、無効にします。 完全に明示的なソートを抑制することはできません。 しかし、この変数を無効にすることで、もし他の方法が利用できるのであれば、プランナはその使用を行なわないようになります。 デフォルトは有効です。
問い合わせプランナがTIDスキャン計画型を選択することを有効、あるいは、無効にします。 デフォルトは有効です。
注意: 残念ながら、後述の"コスト"変数系列の理想的な値を決定する既知の方法はありません。 実験と発見の共有を激励されています。
単一インデックススキャンで利用できるディスクキャッシュの実効サイズに関するプランナの推測を設定します これはインデックスの利用コストの推測に関する要因となります。 より高い値により、よりインデックススキャンが利用されます。逆により低い値により、よりシーケンシャルスキャンが利用されます。 このパラメータを設定する時は、PostgreSQLの共有バッファとPostgreSQLデータファイルで使用されるカーネルのディスクキャッシュの割合の両方を考慮しなければなりません。 また、利用可能な領域を共有しますので、異なるインデックスを使用する問い合わせの想定同時実行数も検討してください。 このパラメータはPostgreSQLにより割り当てられる共有メモリのサイズには影響を与えませんし、カーネルのディスクキャッシュを確保することも行いません。 推測のためだけに使用されます。 これは、通常は一単位8192バイトのディスクページを基準に評価されます。 デフォルトは1000です。
プランナの順不同に取りだされたディスクページのコストの概算を設定します。 これは順ページ取り出しコストの倍数で評価されます。 より高い値を設定すると、シーケンシャルスキャンがより使用されるようになります。 より低い値を設定すると、インデックススキャンがより使用されるようになります。 デフォルトは4です。
プランナが問い合わせの間にそれぞれの行を処理するコストを設定します。 これは順ページ取り出しのコストとの比率で評価されます。 デフォルトは0.01です。
プランナがインデックススキャンの間にそれぞれのインデックス行を処理するコストの概算を設定します。 これは順ページ取り出しのコストとの比率で評価されます。 デフォルトは0.001です。
プランナがWHERE句の中のそれぞれの演算子を処理するコストの概算を設定します。 これは順ページ取り出しのコストとの比率で評価されます。 デフォルトは0.0025です。
問い合わせプランナがしらみつぶしの検索を行うことなく問い合わせ計画を作成するアルゴリズムである、遺伝的問い合わせ最適化の使用を有効または無効にします。 デフォルトは有効です。 geqo_threshold変数は、問い合わせの特定のクラスでGEQOを無効にするためのより細かな方法を提供します。
少なくともこれだけの数のFROM句の項目を含む問い合わせを計画する場合には、遺伝的問い合わせ最適化を使用します （外部JOIN構文は1つのFROM句として数えられます）。 デフォルトは12です。 もっと単純な問い合わせでは、決定論的でしらみつぶし検索プランナを使うのが最適でしょう。 しかし、多くのテーブルを持つ問い合わせでは、決定論的なプランナは非常に時間がかかります。
GEQOにおける計画時間と問い合わせ計画効率との間のトレードオフを制御します。 この変数は1から10までの間の整数でなければなりません。 デフォルト値は5です。 値を大きくすると、問い合わせ計画作成により多くの時間を費やすことになりますが、より効率的な問い合わせ計画が選択される可能性が増加します。
実際geqo_effortは直接何も行いません。 GEQOの振舞いに影響を与える他の変数（後述）のデフォルト値を計算するために使用されるのみです。 好み次第ですが、直接他のパラメータを設定してもかまいません。
GEQOで使用されるプールサイズを制御します。 プールサイズとは遺伝的個体群内の個体数です。 最低でも2なければならず、よく100から1000までの値が使用されます。 これを0に設定（デフォルトの設定）すると、適切なデフォルト値がgeqo_effortと問い合わせ内のテーブル数に基づいて選択されます。
GEQOで使用される世代数を制御します。 世代数はアルゴリズムの反復数を指定するものです。 最低でも1なければならず、よくプールサイズと同じ範囲の値が使用されます。 これを0に設定（デフォルトの設定）すると、適切なデフォルト値がgeqo_effortに基づいて選択されます。
GEQOにおける選択の偏りを制御します。 選択の偏りは個体群内の選択圧力です。 値は1.50から2.00までの値をとることができ、2.00がデフォルトです。
ALTER TABLE SET STATISTICS経由で列指定の対象を持たないテーブル列についてのデフォルトの統計情報対象を設定します。 値をより大きくすると、ANALYZEの実行に要する時間が増加しますが、プランナの推定の質が向上する可能性があります。 デフォルトは10です。 PostgreSQL問い合わせプランナによる統計情報の利用についての詳細は項13.2を参照してください。
最終的なFROMリストがこの値以上多くない場合、プランナは副問い合わせを上位問い合わせにマージします。 値を小さくすると、計画作成時間は減少しますが、劣った問い合わせ計画を生成する可能性があります。 デフォルトは8です。 通常、これをgeqo_thresholdよりも小さくしておく方が良いでしょう。
最終的にリストがこの値以下になる時、プランナは、明示的な内部JOIN構文をFROM項目のリストに直します。 PostgreSQL 7.4以前では、JOIN式で指定された結合は問い合わせプランナで順序の変更は行われませんでした。 その後問い合わせプランナが改良され、この形式で記述された内部結合が順序変更できるようになりました。 この設定パラメータは、この順序変更を実施するかどうかの程度を制御します。
注意: 現時点では、JOIN式で指定された外部結合の順序は問い合わせプランナによって調整されません。 従ってjoin_collapse_limitはこの動作に影響を与えません。 今後のPostgreSQLのリリースでは、プランナは外部結合のいくつかのクラスの順序変更ができるように改良される可能性があります。
デフォルトでは、この変数はfrom_collapse_limitと同値に設定されています。 これはほとんどの場合に適切な値です。 1に設定すると、内部JOINの順序変更は行われなくなります。 従って、問い合わせにおいて明示的に指定された結合順序がリレーションを結合する実際の順序となります。 問い合わせプランナが常に最適な結合順序を選択するとは限りません。 高度なユーザは一時的にこの変数を1に設定し、好みの結合順序を明示的に指定することができます。 この変数を1に設定することで他にも、問い合わせプランナがよりPostgreSQL 7.3の問い合わせプランナのような振舞いを行うという効果を得ることができます。 後方互換性という理由から有用と考えるユーザもいます。
この変数を1からfrom_collapse_limitまでの値に設定することは、計画作成時間と選択される計画の質とのトレードオフに役に立ちます。 （値を大きくすることでより良い計画が生成されます。）
PostgreSQLでは、stderrやsyslogなど、複数のサーバログのログ手段をサポートします。 Windowsでは、eventlogもサポートされています。 このオプションを好みのログ出力先をカンマ区切りのリストとして設定してください。 デフォルトはstderrへのログのみです。 このオプションはサーバ起動時かpostgresql.conf設定ファイルでのみ設定できます。
このオプションにより、stderrに送られるメッセージを取り出し、ログファイルにリダイレクトすることができます。 このオプションとstderrへのログとの組み合わせはsyslogへのログよりもしばしば有用です。 メッセージの一部の種類がsyslogでは出力されない可能性があるためです。 （一般的な例として、ダイナミックリンカのエラーメッセージがあります。） このオプションはサーバ起動時のみ設定可能です。
redirect_stderrが有効な場合、このオプションはログファイルを生成するディレクトリを決定します。 絶対パスで指定することも、クラスタのデータディレクトリからの相対パスを指定することもできます。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイルでのみ設定可能です。
redirect_stderrが有効な場合、このオプションは生成されるログファイルのファイル名を設定します。 この値はstrftimeのパターンとして扱われます。 ですので、%エスケープを使用して、時刻によって変動するファイル名を指定することができます。 %エスケープが無い場合、PostgreSQLはログファイルを開いた時点のエポックを追加します。 例えば、log_filenameがserver_logであったとすると、2004年8月29日(日)19:02:33 MSTに開始されたログファイルの名前として server_log.1093827753が選択されます。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイルでのみ設定可能です。
redirect_stderrが有効な場合、このオプションは個々のログファイルの最大存続時間を決定します。 ここで指定した時間（分単位）経過すると、新しいログファイルが生成されます。 ゼロに設定することで、時間に基づいた新しいログファイルの生成は無効になります。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイルでのみ設定可能です。
redirect_stderrが有効な場合、このオプションは個々のログファイルの最大サイズを決定します。 ここで指定したキロバイト分ログファイルに出力された後、新しいログファイルが生成されます。 ゼロに設定することで、サイズに基づいた新しいログファイルの生成は無効になります。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイルでのみ設定可能です。
redirect_stderrが有効な場合、このオプションにより、PostgreSQLは既存の同名のファイルに追加するのではなく、そのファイルを切り詰める（上書きする）ようになります。 しかし、切り詰めは時間を元にしたローテーションのために新規にファイルが開かれた時にのみ発生し、サーバ起動時やサイズを元にしたローテーションでは発生しません。 偽の場合、全ての場合において既存のファイルは追記されます。 例えば、このオプションをpostgresql-%H.logのようなlog_filenameと組み合わせて使用すると、24個の時別のログファイルが生成され、それらは周期的に上書きされることになります。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイルでのみ設定可能です。
例: 7日間のログを保持、一日おきにserver_log.Mon、server_log.Tueといった名前のログファイルを作成、先週のログが今週のログで自動的に上書きされるように設定するには、log_filenameをserver_log.%aに、log_truncate_on_rotationをtrueに、log_rotation_ageを1440としてください。
例: 24時間のログを保持、1時間おきに1つのログファイルを作成、ただし、ログファイルのサイズが1GBを超えそうな場合は即座に回転させるようにするには、log_filenameをserver_log.%H%Mに、log_truncate_on_rotationをtrueに、log_rotation_ageを60に、log_rotation_sizeを1000000としてください。 log_filenameに%Mを含めることにより、元の時別のファイル名と異なる名前を選択する可能性がある、サイズを元にしたローテーションを行うことができます。
このオプションはsyslogによるロギングが有効な時にsyslog"ファシリティ"を決定します。 LOCAL0、LOCAL1、LOCAL2、LOCAL3、LOCAL4、LOCAL5、LOCAL6、LOCAL7 の中から選ぶことができ、デフォルトはLOCAL0です。 使用しているシステムのsyslogデーモンの文書も参照してください。 このオプションはサーバ起動時のみ設定可能です。
このオプションは、syslogのロギングが有効な場合にsyslogログの中のPostgreSQLメッセージを識別するために使われるプログラム名を指定します。 デフォルトはpostgresです。 このオプションはサーバ起動時のみ設定可能です。
どのメッセージレベルをクライアントに送信するかを制御します。 有効な値はDEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、LOG、NOTICE、WARNING、ERRORです。 各レベルには、そのレベル以下の全てが含まれます。 レベルを低くするほど、送信されるメッセージはより少なくなります。 デフォルトはNOTICEです。 ここでのLOGの優先順位がlog_min_messagesの場合と異なることに注意してください。
どのメッセージレベルをサーバログに書き込むかを制御します。 有効な値は、DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、ERROR、LOG、FATAL、PANIC です。 各レベルには、そのレベル以下の全てが含まれます。 レベルを低くするほど、ログに送られる情報が少なくなります。 デフォルトは NOTICE です。 ここでのLOGの優先順位がclient_min_messagesの場合と異なることに注意してください。 スーパーユーザのみがこの設定を変更することができます。
ログされる各メッセージについて、サーバログに書き出す詳細度を制御します。 有効な値はTERSE、DEFAULT、VERBOSEであり、それぞれ表示するメッセージのフィールドが追加されていきます。 スーパーユーザのみがこの設定を変更することができます。
エラー条件の原因となったSQL文をサーバログに記録するかを制御します。 設定したレベル以上のエラーを発生させた全てのSQL文がログに記録されます。 デフォルトは PANICです (実質、通常の使用ではこのオプションは無効になっています)。 有効な値は、DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、ERROR、FATAL、PANICです。 例えば、これをERRORに設定すると、エラー、致命的なエラー、またはパニックを引き起こした全てのSQL文がログに記録されます。 このオプションを有効にすると、サーバログに書き出されたエラー発生元を追跡することが容易になります。 スーパーユーザのみがこのオプションを変更することができます。
ログをとる文について、その最小の文実行時間を(ミリ秒単位で)設定します。 指定された時間以上かかって実行した全てのSQL文がその経過時間と共に記録されます。 これをゼロにすると、全ての問い合わせとその経過時間が表示されます。 -1（デフォルト値）に設定すると、この機能は無効になります。 例えば、250に設定したとすると、250ms以上実行にかかったSQL文が全て記録されます。 このオプションを有効にすると、アプリケーション内で最適化されていない問い合わせを見つけ出す時に役に立ちます。 スーパーユーザのみがこれを変更することができます。
サーバをメッセージ出力無しで実行します。 このオプションを設定すると、サーバは自動的にバックグランドで起動し、制御端末を切り離します。 (postmasterの -Sオプションと同じです。) サーバの標準出力や標準エラーは/dev/nullにリダイレクトされ、つまり、出力されたメッセージは全て喪失します。 syslogロギングを有効にしていない、あるいは、redirect_stderrを有効にしていない限り、エラーメッセージを確認することができなくなりますので、このオプションの使用は勧められません。
以下に、これらの設定で使用される各種メッセージの重要度レベルの一覧を示します。
開発者によって使用される情報を提供します。
ユーザによって暗黙的に要求された情報を提供します。 例えばVACUUM VERBOSE処理中。
ユーザに有用であろう情報を提供します。 例えば、長い識別子の切り詰めやプライマリキーの一部としてのインデックスの作成。
ユーザに対する警告を提供します。 例えば、トランザクションブロック外部でのCOMMIT。
現在のコマンドを中断させる原因となったエラーを報告します。
管理者に有用な情報を報告します。 例えば、チェックポイントの活動。
現在のセッションを中断させる原因となったエラーを報告します。
全てのセッションを中断させる原因となったエラーを報告します。
これらのオプションは、生成される各種のデバッグ出力を有効にします。 実行された問い合わせそれぞれに対して、最終的なパースツリー、問い合わせ書き換え器の出力、実行計画を出力します。 debug_pretty_printはより読み易くその表示をインデントしますが、出力書式がより長くなります。 client_min_messagesもしくはlog_min_messagesはそれぞれ、実際に出力をクライアントもしくはサーバログに送信するために、DEBUG1以下にしなければなりません。 デフォルトでは、これらのオプションは無効です。
これは、成功した接続それぞれの詳細をサーバログに1行追加します。 デフォルトでは、これは無効ですが、おそらく非常に有用です。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイル内でのみ設定することができます。
これはlog_connections同様の出力をサーバログに行い、更に加えて、セッション終了時にセッションの期間も出力します。 デフォルトではこれは無効です。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイル内でのみ設定することができます。
log_statementのログ取得条件を満たす文の場合、完了した文それぞれについて、その経過時間をログするようにします。 このオプションを使用する時には、文とプロセスIDもしくはセッションIDを使用した経過時間とを結び付けられるように、もしsyslogを使用していないのであれば、log_line_prefixを使用してPIDもしくはセッションIDをログに残すことを推奨します。 デフォルトは無効です。 スーパーユーザのみがこの設定を変更することができます。
これは、各ログ行の先頭に出力するprintfの書式文字列です。 デフォルトは空文字列です。 認識可能なエスケープは後述の通りに置換されます。 この他のエスケープは無視されます。 他の文字はそのままログ行に出力されます。 エスケープの中には、セッションプロセスによってのみ認識可能なものがあり、これらはpostmasterなどのバックグランドプロセスには適用されません。 Syslogは独自に時刻とプロセスID情報を出力しますので、Syslogを使用している場合はおそらく、対応するエスケープを使用しようとは思わないでしょう。 このオプションはサーバ起動時、もしくは、postgresql.conf設定ファイル内でのみ設定することができます。
| エスケープ | 効果 | セッションのみ |
|---|---|---|
| %u | ユーザ名 | ○ |
| %d | データベース名 | ○ |
| %r | リモートホスト名もしくはIPアドレス、およびリモートポート | ○ |
| %p | プロセスID | × |
| %t | 時刻 | × |
| %i | コマンドタグ。このログ行を生成したコマンドです。 | ○ |
| %c | セッションID。 各セッションに対する一意な識別子です。 これは2つの4バイト16進数の番号をドットで区切ったものです。（先頭に0は付きません。） この番号はセッションの開始時刻とプロセスIDです。 ですので、これらの項目の出力を省略して出力行を短くするためにも使用することができます。 | ○ |
| %l | 各プロセスのログ行の番号。1から始まります。 | × |
| %s | セッション開始時刻 | ○ |
| %x | トランザクションID | ○ |
| %q | 何も出力しません。 非セッションプロセスではこのエスケープ以降の出力を停止します。 セッションプロセスでは無視されます。 | × |
| %% | %文字そのもの | × |
どのSQL文をログに記録するかを制御します。 有効な値は、none、ddl、mod、および、allです。 ddlは、CREATE、ALTER、および、DROPといった、データ定義コマンドを全てログに記録します。 modは、全てのddl文に加え、INSERT、UPDATE、DELETE、TRUNCATE、および、COPY FROMをログに記録します。 PREPAREとEXPLAIN ANALYZEコマンドも、そこに含まれるコマンドが適切な種類であればログが取られます。
デフォルトはnoneです。 管理者により設定された場合は、スーパーユーザのみがこの設定を変更することができます。
注意: EXECUTE文はddl文ともmod文ともみなされていません。 ログに記録される時には、準備済み文の名前のみが報告され、実際に準備された文は報告されません。
PL/pgSQLサーバサイド言語で定義された関数の場合、その関数で実行される問い合わせは、特定セッション内で最初に呼び出された関数における問い合わせのみが記録されます。 PL/pgSQLは、関数内のSQL文に対して生成された問い合わせ計画のキャッシュを保持しているためです。
デフォルトでは、接続ログメッセージには接続ホストのIPアドレスのみが表示されます。 このオプションを有効にすることで、ホスト名もログに表示されるようになります。 ホスト名解決の設定次第で、無視できないほどの性能の悪化が課せられることに注意してください。 このオプションはサーバ起動時、またはpostgresql.confファイル内でのみ設定することができます。
各問い合わせについて、対応するモジュールの性能統計情報をサーバログに書き出します。 これは粗野なプロファイリング機能です。 log_statement_statsは文全体の統計情報を、他はモジュール単位の統計情報を報告します。 log_statement_statsはモジュール単位のオプションと一緒に有効にすることはできません。 デフォルトでは、これらのオプションは全て無効です。 スーパーユーザのみがこれらのオプションを変更することができます。
サーバが統計情報収集子プロセスを起動するかどうかを制御します。 デフォルトでは有効です。 しかし、統計情報の収集に興味がなければ無効にすることができます。 このオプションはサーバ起動時にのみ設定することができます。
各セッションで現在実行中のコマンドに関して、そのコマンドが実行した時点の時刻と一緒に統計情報の収集を有効にします。 デフォルトで、このオプションは無効です。 有効にしたとしても、この情報は全てのユーザには参照することができません。 スーパーユーザとその報告を行なったセッションを所有するユーザのみが見ることができます。 そのため、セキュリティ上の危険性は存在しません。 このデータはpg_stat_activityシステムビューを介してアクセスすることができます。 詳細は第23章を参照してください。
データベースの活動についてのブロックレベルの統計情報の収集を有効にします。 このオプションはデフォルトで無効です。 このオプションが有効な場合、生成されるデータはシステムビューのpg_statとpg_statio系列を介してアクセスすることができます。 詳細は第23章を参照してください。
データベースの活動についての行レベルの統計情報の収集を有効にします。 このオプションはデフォルトで無効です。 このオプションが有効な場合、生成されるデータはシステムビューのpg_statとpg_statio系列を介してアクセスすることができます。 詳細は第23章を参照してください。
有効な場合、収集された統計情報はサーバが再起動するとゼロにされます。 無効な場合、統計情報はサーバの再起動を跨って貯められます。 デフォルトでは有効です。 このオプションはサーバ起動時のみ設定することができます。
この変数は、オブジェクト(テーブル、データ型、関数など)がスキーマ部を含まない単純な名前で参照されている場合に、スキーマを検索する順番を指定します。 異なるスキーマに同じ名前のオブジェクトがある場合、検索パスで最初に見つかったものが使用されます。 検索パス内のどのスキーマにも存在しないオブジェクトを参照するには、修飾名(ドット付き)でそのオブジェクトが含まれるスキーマを指定する必要があります。
search_pathの値は、スキーマの名前をカンマで区切った一覧でなければなりません。 一覧内の項目の1つが特別な値である$userの場合、SESSION_USERと同じ名前をもつスキーマがあれば、そのスキーマが置換されます。 (このような名前空間が無い場合は $userは無視されます。)
システムカタログのスキーマであるpg_catalogは、パスでの指定の有無に関わらず、常に検索されます。 パスで指定されている場合は、指定された順序で検索されます。 pg_catalogがパスに含まれていない場合、パスに含まれる項目を検索する前に検索が行われます。 一時テーブルのスキーマであるpg_temp_nnnについても、パス内の項目が検索される前に暗黙的に検索されることに注意してください。
対象となる特定のスキーマを指定せずにオブジェクトが作成された場合、それらのオブジェクトは検索パスで最初に指定されているスキーマに配置されます。 検索パスが空の場合、エラーが報告されます。
このパラメータのデフォルト値は'$user, public'です(publicという名前のスキーマが存在しない場合、2 つ目の部分は無視されます)。 これにより、データベースの共有(どのユーザも非公開のスキーマを持たず、全員がpublicを共有)、ユーザごとの非公開のスキーマ、および、これらの組み合わせがサポートされます。 デフォルトの検索パスの設定を全体的またはユーザごとに変更することで、その他の効果を得ることもできます。
current_schemas() SQL関数によって、検索パスの現在の有効な値を調べることができます。 これは、search_path の値を調べるのとは異なります。 current_schemas()は、search_pathに現れる要求がどのように解決されたかを表すからです。
スキーマの処理に関する詳細については、項5.8を参照してください。
この変数は、CREATEコマンドで明示的にテーブル空間を指定していない場合にオブジェクトの作成先となるデフォルトのテーブル空間を指定します。
値はテーブル空間名、もしくは、現在のデータベースのデフォルトのテーブル空間を使用することを意味する空文字列です。 この値が既存のテーブル空間名と一致しない場合、PostgreSQLは自動的に現在のデータベースのデフォルトのテーブル空間を使用します。
テーブル空間の詳細については項18.6を参照してください。
このパラメータは通常真です。 偽に設定した場合、CREATE FUNCTION中の関数本体文字列の検証が無効になります。 検証を無効にすることは、ダンプから関数定義をリストアする時の前方参照といった問題を防ぐことができ、場合によっては有用です。
SQLトランザクションはそれぞれ、"read uncommitted"、"read committed"、"repeatable read"、または、"serializable"のいすれかの隔離レベルを持ちます。 このパラメータは各新規トランザクションのデフォルトの隔離レベルを制御します。 デフォルトは"read committed"です。
詳しくは、第12章とSET TRANSACTIONの説明を参照してください。
読み取りのみのSQLトランザクションでは、非一時的テーブルを変更することができません。 このパラメータは、各新規トランザクションのデフォルトの読み取りのみ状況を制御します。 デフォルトは偽(読み書き)です。
詳しくは、SET TRANSACTIONを参照してください。
指定ミリ秒数を越えた行を全て中断します。 ゼロという値(デフォルト値)はこの制限を無効にします。
日付時刻値の表示書式を設定し、曖昧な日付入力の解釈規則を設定します。 歴史的な理由により、この変数には2つの依存した要素が含まれています。 出力書式指定(ISO、Postgres、SQL、German) と年/月/日の順序の入出力指定(DMY、MDY、YMD)です。 これらは分けて設定することもまとめて設定することもできます。 EuroおよびEuropeanキーワードはDMYの同義語であり、US、NonEuro、NonEuropeanはMDYの同義語です。 詳細は項8.5を参照してください。 デフォルトは、ISO, MDYです。
表示用およびタイムスタンプ解釈用の時間帯を設定します。 デフォルトは'unknown'で、システム環境で時間帯として指定したものを使用します。 詳細は項8.5を参照してください。
真の場合、ACST、CST、EST、SATは北/南アメリカのタイムゾーンと土曜日ではなく、オーストラリアの時間帯として解釈されます。 デフォルトは偽です。
このパラメータは、float4、float8、幾何データ型などの浮動小数点値の表示桁数を調整します。 パラメータ値が標準的な桁数(FLT_DIG もしくは DBL_DIGどちらか適切な方)に追加されます。 この値は、部分有効数を含めるために2まで設定することができます。 これは基本的に、正確にリストアする必要がある浮動小数点データをダンプするために有用です。 もしくは、不要な桁を抑制するために負の値を設定することもできます。
クライアント側の符号化方式(文字セット)を設定します。 デフォルトでは、データベース符号化方式を使用します。
メッセージが表示される言語を設定します。 使用可能な値はシステムに依存します。 詳細については項20.1を参照してください。 この変数が空に設定された場合 (これがデフォルトです)、値はシステムに依存する方法でサーバの実行環境から継承されます。
システムによっては、このロケールのカテゴリが存在しません。 この変数を設定することはできますが、実効性はありません。 また、指定の言語に翻訳されたメッセージが存在しないこともあります。 その場合は、引き続き英語のメッセージが表示されます。
通貨書式で使用するロケールを設定します。 例えば、to_char()系の関数で使用します。 使用可能な値はシステムに依存します。 詳細については 項20.1 を参照してください。 この変数が空に設定された場合 (これがデフォルトです)、値はシステムに依存する方法でサーバの実行環境から継承されます。
数字の書式で使用するロケールを設定します。 例えば、to_char系の関数で使用します。 使用可能な値はシステムに依存します。 詳細については 項20.1 を参照してください。 この変数が空に設定された場合 (これがデフォルトです)、値はシステムに依存する方法でサーバの実行環境から継承されます。
日付と時間の書式で使用するロケールを設定します。 (現在この設定に意味はありませんが、将来的には意味をもつ可能性があります。) 使用可能な値はシステムに依存します。 詳細については 項20.1 を参照してください。 この変数が空に設定された場合 (これがデフォルトです)、値はシステムに依存する方法でサーバの実行環境から継承されます。
EXPLAIN VERBOSEが問い合わせツリーの詳細表示にインデント表示するかしないかを決定します。 デフォルトは有効です。
オープンする必要がある動的ロード可能なモジュールについて、そのCREATE FUNCTIONやLOADコマンドで指定されたファイル名にディレクトリ要素がなく(つまり、名前にスラッシュが含まれずに)指定された場合、システムは必要なファイルをこのパスから検索します。
dynamic_library_pathの値は、絶対パスのディレクトリ名をコロン(Windowsの場合はセミコロン)を区切った一覧です。 この一覧の要素が特別な$libdirという値から始まる場合、コンパイルされたPostgreSQLパッケージのライブラリディレクトリで$libdirは置換されます。 ここには、PostgreSQLの標準配布物により提供されるモジュールがインストールされます。 (このディレクトリ名を表示するには、pg_config --pkglibdir を使用してください)。 例を以下に示します。
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
Windowsの場合は以下のようになります。
dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
このパラメータのデフォルト値は '$libdir' です。 この値が空に設定された場合、自動的なパス検索は無効になります。
このパラメータはスーパーユーザによって実行時に変更することができますが、この方法での設定は、そのクライアント接続が終わるまでしか有効になりません。 ですので、この方法は開発目的でのみ使用すべきです。 推奨方法はこのパラメータをpostgresql.conf 設定ファイル内で設定することです。
これは、デッドロック状態があるかどうかを調べる前にロックを待つ時間をミリ秒で計算したものです。 デッドロックのチェックは比較的遅いので、サーバはロックを待つ度にこれを実行するわけではありません。 （楽天的ですが）デッドロックは実用レベルのアプリケーションでは頻繁に発生しないと仮定し、デッドロックのチェックを開始する前にしばらくはロック待ちをします。 この値を増やすことにより必要のないデッドロックのチェックで無駄にされる時間は減りますが、本当にデッドロックがあった場合の報告が遅れます。 デフォルトは1000（つまり1秒）で、おそらく実用の際にはこれ以上は必要でしょう。 負荷の大きいサーバではもっと必要かもしれません。 理想としてはこの設定は通常のトランザクションにかかる時間を越えているべきです。 そうすればロック待ちトランザクションがデッドロックのチェックをする前にロックが解除される可能性が改善されます。
共有ロックテーブルの大きさは、最大max_locks_per_transaction * max_connections個の個別のオブジェクトがある時点でロックされているという仮定で決定されます。 (このパラメータ名は混乱を招きます。これは、任意の1トランザクションで取得できるロックの上限を表すものではなく、平均値の最大を表すものです。) デフォルトの64は歴史的に十分な値であると証明されたものですが、多くの異なるテーブルを1つのトランザクションで使用するクライアントがある場合、この値を上げる必要があるかもしれません。 このオプションはサーバの起動時にのみ設定できます。
trueの場合、問い合わせで参照されるテーブルは、もし存在しなければ、自動的にFROM句に追加されます。 デフォルトはFROMで、以前のPostgreSQLリリースと互換性があります。 しかし、この振舞いは標準SQLではなく、また、多くのユーザは失敗(別名を参照しなければならないところをテーブルを参照するなど)を隠すことになるためこれを嫌います。 FROMに存在しないテーブルを参照することを禁じる標準SQLの振舞いのためには、falseと設定してください。
正規表現の"種類"は、advanced、extended、basicのいずれかに設定することができます。 デフォルトはadvancedです。 正確に7.4より前のPostgreSQLリリースと後方互換を持たせるためにはextended が有用です。 詳細は項9.7.3.1を参照してください。
これは継承のセマンティクス、特にサブテーブルを各種コマンドでデフォルトで含めるべきかどうか、を制御します。 これらは7.1以前のバージョンには含まれていませんでした。 もし古いバージョンの動作をさせたい場合はこの変数を無効にできますが、長い目で見ればアプリケーションがサブテーブルを排除するためにONLYキーワードを使うようにするほうがよいでしょう。 継承に関する詳細は、項5.5を参照してください。
これは、WITH OIDSやWITHOUT OIDSが指定されていないCREATE TABLEおよびCREATE TABLE ASが新しいテーブルを作成する際にOIDを含めるかどうかを制御します。 また、SELECT INTOで生成されるテーブルにOIDを含めるかどうかも決定します。 PostgreSQL 8.0.4では、default_with_oidsのデフォルトは真です。 また、PostgreSQLの過去のバージョンと同じ振舞いです。 しかし、テーブルがデフォルトでOIDを持つことを仮定することは勧めません。 このオプションのデフォルトは将来のPostgreSQLのリリースで偽になる可能性があります。
OIDを使用するアプリケーションの互換性を高めるために、このオプションは有効のままにしておくべきです。 将来のバージョンのPostgreSQLとの互換性を高めるためにはこのオプションを無効にし、あるテーブルにOIDを必要とするアプリケーションでは、問題のテーブルを作成する際に、明示的にWITH OIDSを指定するようにすべきです。
有効にした場合、expr = NULL(またはNULL = expr)という形の式はexpr IS NULLとして扱われます。 つまり、exprの評価がNULL値の場合、真を、さもなくば偽を返します。 expr = NULLのSQL仕様に基づいた正しい動作は常にNULL(未知)を返すことです。 そのため、このオプションはデフォルトで無効です。
しかし、Microsoft Accessのフィルタ形式はNULL値を検査するためにexpr = NULLを使用する問い合わせを生成しますので、そのインタフェースを使用してデータベースにアクセスする場合は、このオプションを有効にする方が良いでしょう。 expr = NULLという形の式は(正しい解釈を使用した結果)常にNULL値を返しますので、通常のアプリケーションでは意味がほとんどなく、滅多に使用されません。 ですので、このオプションは実際は害はありません。 しかし、慣れていないユーザはしばしばNULL値に関する式の意味に戸惑いますので、デフォルトでこのオプションは有効になっていません。
このオプションは= NULLという形式にのみ影響することに注意してください。 他の比較演算子や等価演算子を呼び出す他の(INのような)式と計算する上で等価となる式には影響を与えません。 従って、このオプションは間違ったプログラミングの汎用的な問題解決をおこないません。
関連する情報については、項9.2を参照してください。
以下の"パラメータ"は読み取りのみで、PostgreSQLのコンパイル時、もしくは、インストール時に決定されます。 そのため、これらはpostgresql.confのサンプルから除かれています。 このオプションは、特定のアプリケーション、特に管理用フロントエンドによって注目される可能性があるPostgreSQLの様々な部分の振舞いを報告します。
ディスクブロックのサイズを表示します。 これはサーバの構築時のBLCKSZの値によって決定されます。 デフォルトは8192バイトです。 設定変数（shared_buffersなど）の中にはblock_sizeによってその意味に影響を受けるものがあります。 詳細は項16.4.3を参照してください。
PostgreSQLが64ビット整数の日付時間をサポートするように構築されているかどうかを表示します。 これは、PostgreSQLの構築時に--enable-integer-datetimesが設定されたかどうかで決定されます。 デフォルト値は offです。
テキストデータのソート時に使用されるロケールを表示します。 詳細は項20.1を参照してください。 この値はデータベースクラスタの初期化の際に決定されます。
文字クラス分類を決定するロケールを表示します。 詳細は項20.1を参照してください。 この値はデータベースクラスタの初期化時に決定されます。 通常、これはlc_collateと同じですが、特殊なアプリケーションでは異なる値に設定している可能性があります。
関数引数の最大数を表示します。 これはサーバ構築時のFUNC_MAX_ARGSの値によって決定します。 デフォルト値は32です。
識別子の最大長を表示します。 これはサーバ構築時のNAMEDATALENから1引いた値として決定されます。 NAMEDATALENのデフォルト値は64ですので、max_identifier_lengthのデフォルト値は63です。
インデックスキーの最大数を表示します。 これは、サーバ構築時のINDEX_MAX_KEYSの値によって決定されます。 デフォルト値は32です。
データベース符号化方式（文字セット）を表示します。 これはデータベースが生成される時に決定されます。 通常、クライアントはclient_encodingの値についてのみ注意する必要があります。
サーバのバージョン番号を表示します。 これは、サーバ構築時のPG_VERSIONの値により決定されます。
この機能は、通常のPostgreSQLでは認識できない、追加モジュール（手続き言語など）で追加されるオプションを設定できるように設計されました。 これにより追加モジュールは標準的な方法で設定することができます。
postgresql.confで独自変数を設定する際に難しい点は、このファイルが追加モジュールがロードされる前に読み取られなければならず、そのため独自変数は普通未知のものとして拒絶されてしまう点です。 custom_variable_classesが設定されている場合、サーバは指定されたクラス内の任意の変数定義を受け付けるようになります。 これらの変数はプレースホルダとして扱われ、変数を定義したモジュールがロードされるまで何も機能を持ちません。 指定クラス用のモジュールがロードされると、そのクラス名に対する適切な変数定義を追加し、プレースホルダの値をその定義に従って変換します。 また、そのクラス用のプレースホルダが（おそらくは設定変数の書き間違いのために）残っていた場合に警告を発します。
以下に独自変数を含むpostgresql.confの例を示します。
custom_variable_classes = 'plr,pljava' plr.path = '/usr/lib/R' pljava.foo = 1 plruby.bar = true # 未知のクラス名のためエラーになります。
以下のオプションは、PostgreSQLのソースに対する作業用のものです。 中には深刻に損傷したデータベースの復旧に役立つものもあります。 実運用のデータベースでこれらを設定する理由はないはずです。 従って、これらはサンプルのpostgresql.confからは除外されています。 これらのオプションの多くは、それを動作させるために特殊なソースコンパイルを必要としていることに注意してください。
様々なアサーションチェックを有効にします。 これはデバッグ用の道具です。 もし奇妙な問題やクラッシュが発生した場合は有効にすると、プログラムの間違いが明らかになるかもしれません。 このオプションを使うためには、PostgreSQLを構築する時にUSE_ASSERT_CHECKINGマクロが定義されていなければなりません （configureコマンドの--enable-cassertオプションで行います）。 アサーションを有効にしてPostgreSQLを構築すると、debug_assertionsはデフォルトで有効になります。
バッファ空きリスト報告の周期秒数です。 0より大きな値に設定された場合、空きリスト統計情報が指定した秒数毎に発行されます。 0（デフォルト）は報告を無効にします。
非ゼロの場合、ここで指定した秒数分の遅延が新しくサーバプロセスがforkした後、認証プロセスにはいる前に発生します。 これは、認証における誤動作を追跡するために、デバッガを使用してサーバプロセスに接続する機会を提供することを目的としたものです。
LISTENとNOTIFYコマンドのための大量なデバッグ出力を生成します。 この出力をクライアントもしくはサーバログに送信するためには、それぞれ、client_min_messagesもしくはlog_min_messagesはDEBUG1 以下でなければなりません。
その他の各種のコードを追跡しデバッグするオプションです。
真の場合、WAL関連のデバッグ出力が有効になります。 このオプションは、PostgreSQLのコンパイル時にWAL_DEBUGマクロが定義されている場合にのみ利用可能です。
ページヘッダの障害が分かると、通常PostgreSQLはエラーの報告を行ない、現在のコマンドを中断させます。 zero_damaged_pagesを真に設定することにより、システムは代わりに警告を報告し、障害のあるページをゼロで埋め、処理を継続します。 この動作により、障害のあったページ上にある全ての行のデータを破壊されます。 しかし、これによりエラーを無視し、正常なページに存在するテーブル内の行を取り出すことができます。 従って、ハードウェアまたはソフトウェアのエラーによって破損が発生した場合のデータの復旧時に有用です。 障害のあるページからのテーブルのデータの復旧をあきらめた場合を除き、通常はこれを真にしてはいけません。 デフォルトは無効であり、スーパーユーザのみ変更可能です。
利便性のため、パラメータの中には単一文字のコマンドラインオプションスイッチが利用できるものがあります。 表16-1にそれらを示します。
表 16-1. Short option key
| 短いオプション | 同義 |
|---|---|
| -B x | shared_buffers = x |
| -d x | log_min_messages = DEBUGx |
| -F | fsync = off |
| -h x | listen_addresses = x |
| -i | listen_addresses = '*' |
| -k x | unix_socket_directory = x |
| -l | ssl = on |
| -N x | max_connections = x |
| -p x | port = x |
| -fi, -fh, -fm, -fn, -fs, -ft[a] | enable_indexscan = off, enable_hashjoin = off, enable_mergejoin = off, enable_nestloop = off, enable_seqscan = off, enable_tidscan = off |
| -s[a] | log_statement_stats = on |
| -S x[a] | work_mem = x |
| -tpa, -tpl, -te[a] | log_parser_stats = on, log_planner_stats = on, log_executor_stats = on |
| 注意: a. 歴史的な理由から、これらのオプションはpostmasterの-oオプションを使用して個々のサーバプロセスに渡される必要があります。 例えば、 $ postmaster -o '-S 1024 -s'
のようなコマンド、もしくは上述のようにクライアント側からのPGOPTIONSを使います。
| |