wal_levelはどれだけの情報がWALに書かれるかを決定します。 デフォルト値はreplicaで、WALアーカイビングおよびレプリケーションをサポートするために十分なデータを書き出し、これにはスタンバイサーバで読み取り専用の問い合わせを実行することも含みます。 minimalはクラッシュまたは即時停止から回復するのに必要な情報を除き、すべてのログを削除します。 最後に、logicalは、更にロジカルデコーディングをサポートするのに必要な情報を追加します。 それぞれのレベルは、下位のレベルのログ出力を含んでいます。 このパラメータはサーバ起動時のみ設定可能です。

minimalレベルでは、永続リレーションを作成あるいは書き換えるトランザクションの差分に関する情報はログされません。 これにより、それらの操作が大幅に高速になります（14.4.7を参照してください）。 この最適化が適用される操作には以下のものがあげられます。

しかしminimal WALはベースバックアップとWALログからデータを再構築するための充分な情報を持ち合わせていません。 したがって、WALアーカイビング（archive_mode）とストリーミングレプリケーションを有効にするには、replica以上を使用しなければなりません。 wal_levelをminimalにすると、以前取得したバックアップがアーカイブリカバリおよびスタンバイサーバに使えなくなり、データロスにつながるかもしれないことに注意してください。

logicalレベルでは、replicaと同じ情報がログされるのに加え、ロジカルチェンジセットをWALから取り出すのに必要な情報が追加されます。 logicalを使うとWALの量が増えます。 とりわけ、多数のテーブルがREPLICA IDENTITY FULLと設定されていて(訳注: ALTER TABLE参照)、多くのUPDATEとDELETE文が実行される場合はこのことが言えます。

9.6よりも前のリリースでは、このパラメータはarchiveとhot_standbyという設定値も可能でした。 引き続きこれらも受け付けられますが、replicaへとマップされます。

このパラメータがオンの場合、PostgreSQLサーバはfsync()システムコールを発行するか、もしくはこれに相当する方法（wal_sync_methodを参照）で、更新が物理的にディスクに確実に書き込まれるように試みます。 これは、オペレーティングシステムもしくはハードウェアがクラッシュした後、データベースクラスタを一貫した状態に復旧させることを確実にします。

fsyncを停止することはしばしば性能上の利益になるとは言っても、停電やクラッシュの際に回復不可能なデータ破壊になることがあります。 従って外部データから全てのデータベースを簡単に再構築できる場合のみfsyncを停止してください。

fsyncを停止しても安全な状況の例としては、以下があげられます。 バックアップファイルから新しいデータベースクラスタにデータの初期読み込みを行う場合、バッチデータの処理のためにデータベースクラスタを使用し、その後データベースを削除して再構築する場合、読み込み専用のデータベースのクローンを頻繁に再作成するが、それをフェイルオーバーに使用しない場合、などです。 高性能なハードウェアであるからと言って、fsyncを停止することは正当性を主張する十分な理由とはなりません。

fsyncを無効(off)から有効(on)に変更したときの信頼できるリカバリのためには、カーネル内の全ての変更されたバッファを恒久的ストレージに強制的に吐き出させることが必要です。 これは、クラスタがシャットダウンしている間、またはfsyncが有効のときに、initdb --sync-onlyを実行する、syncを実行する、ファイルシステムをアンマウントする、またはサーバを再起動することによって可能となります。

多くの場合、重要でないトランザクションに対してsynchronous_commitを無効にすることにより、データ破壊という付随的危険性を伴うことなく、fsyncを無効にすることで得られるであろう性能上のメリットの多くを得ることができます。

fsync はpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。 このパラメータを無効にする場合、full_page_writesも同時に無効にすることを検討してください。

トランザクションのコミットがクライアントに「成功」の報告を返す前に、どれだけのWAL処理を完了しなければならないかを指定をします。 有効な値はremote_apply、on(デフォルト)、remote_write、local、offです。

synchronous_standby_namesが空文字なら、意味のある設定はonとoffだけです。 remote_apply、remote_write、localはすべてonと同じ同期レベルを提供します。 offモード以外のローカルの振る舞いは、WALがディスクにローカルに吐き出されるのを待ちます。 offモードでは待ちはありません。 ですから、クライアントに成功が報告されてから、トランザクションが後でサーバクラッシュに対して安全が保証されるまでの間に遅延が生じる可能性があります。 （遅延は最大でwal_writer_delayの3倍です。） fsyncと違って、このパラメータをoffにすることでデータベースの一貫性が損なわれるリスクはありません。 オペレーティングシステムやデータベースのクラッシュにより最近コミットされたということになっているトランザクションの一部が失われる可能性がありますが、これらのトランザクションが正常にアボートされた時とデータベースの状態は変わりません。 したがって、synchronous_commitのオフによる調整は、トランザクションの耐障害性を確実にするよりも性能が重要な場合の有用な代替案となるかも知れません。 詳細は30.4を参照してください。

synchronous_standby_namesが空文字でない場合は、synchronous_commitは、WALレコードが、スタンバイサーバに複製されるまでトランザクションコミットを待機するか否かも制御します。

remote_applyに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取って適用し、スタンバイ上で発行されたクエリから見えるようになり、スタンバイ上の永続的な記憶装置に書き込まれたことを報告するまでコミットは待機します。 WALのリプレイを待つので、今までの設定に比べるとこの設定によってずっと大きなコミットの遅延が発生します。 onに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、永続的な記憶装置に吐き出したことを報告するまでコミットは待機します。 このモードでは、プライマリおよびすべての同期スタンバイがデータベース記憶装置の故障を被った場合を除いて、トランザクションが失われないことが保証されます。 remote_writeに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、スタンバイのファイルシステムに書き出したことを報告するまでコミットは待機します。 この設定は仮にPostgreSQLのスタンバイインスタンスがクラッシュしたとしても、データ保護を保証するのに充分です。 しかし、スタンバイがオペレーティングシステムのレベルでクラッシュした場合はこの限りではありません。 データが必ずしもスタンバイの永続的な記憶装置に到達したとは言えないからです。 最後に、local設定は、コミットがローカルにディスクに吐出されるまで待機しますが、レプリケーションされるまでは待機しません。 これは通常同期レプリケーションが使用されている場合は望ましい設定ではありませんが、完全さのために提供されています。

このパラメータはいつでも変更可能です。 どのトランザクションの動作も、コミット時に有効であった設定によって決まります。 したがって、一部のトランザクションのコミットを同期的に、その他を非同期的にすることが可能で、かつ、有用です。 例えば、デフォルトが同期コミットの場合に複数文トランザクションを一つだけ非同期にコミットさせるためには、トランザクション内でSET LOCAL synchronous_commit TO OFFを発行します。

synchronous_commit設定の機能のまとめが表 20.1にあります。

WALの更新をディスクへ強制するのに使用される方法です。 fsyncがオフの場合この設定は役に立ちません。と言うのはWALファイルの更新が全く強制されないからです。取り得る値は以下のものです。

可能ならopen_*オプションもO_DIRECTを使用します。 全てのプラットフォームでこれら全ての選択肢が使えるわけではありません。 デフォルトは、上のリストのプラットフォームでサポートされるものの最初に列挙されているものです。 ただしLinuxとFreeBSDではfdatasyncがデフォルトです。 デフォルトは必ずしも理想的なものではありません。 クラッシュに適応した構成にする、あるいはアーカイブの最適性能を導くためには、この設定あるいはシステム構成の他の部分を変更することが必要かもしれません。 これらの側面は 30.1で解説されます。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

このパラメータが有効の場合、PostgreSQLサーバは、チェックポイントの後にそのページが最初に変更された過程で、ディスクページの全ての内容をWALに書き込みます。 オペレーティングシステムがクラッシュした時に進行中のページ書き込みは途中までしか終わっていない可能性があり、ディスク上のページが古いデータと新しいデータが混在する状態になるため、この機能が必要です。 通常WAL内に保存される行レベルの変更データは、クラッシュ後のリカバリ時にこうしたページを完全に復旧させるには不十分です。 完全なページイメージを保存することにより、ページを正しく復旧できることを保証しますが、その代わりに、WALに書き込まなければならないデータ量が増加することになります。 （WAL再生は常にチェックポイントから始まるため、チェックポイント後のそれぞれのページの最初の変更時にこれを行えば十分です。 従って、完全ページ書き出しのコストを低減する方法の1つは、チェックポイント間隔パラメータを大きくすることです。）

このパラメータを無効にすると、通常の操作速度が上がりますが、システム障害後に、回復不能なデータ破損、あるいは警告なしのデータ損壊をもたらすかもしれません。 このリスクは小さいながらfsyncを無効にした場合と似ています。そしてそのfsyncに対して推奨されている同一の状況に基づく限りにおいて停止されなければなりません。

このパラメータを無効にしてもポイントインタイムリカバリ（PITR）用のWALアーカイブの使用に影響ありません（ 26.3を参照してください）。

このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。 デフォルトはonです。

このパラメータがonの場合、PostgreSQLサーバはチェックポイント後にはじめてページを変更する際に、ディスクページの全内容をWALに書き出します。 これは、あまり重要でない、ヒントビットと呼ばれるものに対する変更にさえ当てはまります。

データチェックサムが有効であると、ヒントビットの更新は常にWALにログされ、この設定パラメータは無視されます。この設定パラメータを使って、データチェックサムが有効なときにどれだけのWALログは余計に書きだされるかをテストすることができます。

このパラメータはサーバ起動時のみ設定可能です。 デフォルト値はoffです。

このパラメータがonなら、full_page_writesがonあるいはベースバックアップの際、PostgreSQLサーバはWALに書き出すフルページイメージを圧縮します。 圧縮されたページイメージは、WALリプレイのときに伸張されます。 デフォルト値はoffです。 スーパーユーザだけがこの設定を変更できます。

このパラメータを有効にすると、回復不可能なデータ破壊のリスクを増やすこと無しにWALの量を減らすことができます。 しかし、WALロギングの際の圧縮のため、またWALリプレイの際には伸張のために余分なCPUを使用するというコストが発生します。

このオプションがon（デフォルト）に設定されると、新しいWALファイルはゼロで初期化されます。 システムによっては、このことによってWALレコードを書く必要が出てくる前にスペースが割り当てられることを保証します。 しかし、Copy-On-Write (COW)ファイルシステムではこの技術は利点がないかもしれず、このオプションはスキップできるようになっています。 offに設定すると、ファイルを作る時に期待する大きさになるように最後のバイトだけが書かれます。

このオプションがon（デフォルト）に設定されると、新しくファイルを作るのを避けるために、名前を変えてWALファイルが再利用されます。 COWファイルシステムでは、新しいファイルを作るほうが速いかも知れないので、この挙動を無効にできるようにオプションとなっています。

未だディスクに書き込まれていないWALデータに対して使用される共有メモリ容量です。 デフォルトの設定である-1は、shared_buffersの1/32（約3%）の容量に等しい大きさを選択します。 しかし、64kB未満ではなく、かつ典型的に16MBであるWALセグメントの大きさを越えることはありません。 もし、自動設定による選択が大きすぎたり、小さすぎる場合この値は手作業で設定可能です。 しかし、32kB未満のどんな正の値であっても、32kBとして取り扱われます。 この値が単位なしで指定された場合は、WALブロック単位であるとみなします。すなわち、XLOG_BLCKSZバイト、一般的には8kBです。 このパラメータはサーバ起動時のみ設定可能です。

WALバッファの内容はトランザクションのコミット毎にディスクに書き込まれます。 したがって、極端に大きな値は有意な効果を期待できません。 しかし、この値を数メガバイトに設定することにより、多くのクライアントが同時にコミットするトラフィック量の多いサーバでは書き込み性能が向上します。 デフォルト設定の-1で選択される自動チューニングによると、ほとんどの場合妥当な結果が得られます。

WALライタがWALを吐き出す頻度を時間で指定します。 WALを吐き出したとあと、非同期コミットしているトランザクションに起こされない限り、wal_writer_delayミリ秒待機します。 最後の吐き出しが過去wal_writer_delay以内に行われ、かつそれ以降wal_writer_flush_after相当のWALが生成されている場合は、WALはオペレーティングシステムに書き込まれますが、ディスクには吐出されません。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルト値は200ミリ秒（200ms）です。 多くのシステムでは、待機間隔の実質的な分解能は10ミリ秒です。 10の倍数以外の値をwal_writer_delayに設定しても、その次に大きい10の倍数を設定した場合と同じ結果となります。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

WALライタがWALを吐き出す頻度を量で指定します。 最後の吐き出しが過去wal_writer_delay以内に起こなわれ、かつそれ以降wal_writer_flush_after相当のWALが生成されている場合は、WALはオペレーティングシステムに書き込まれますが、ディスクには吐出されません。 wal_writer_flush_afterが0に設定されている場合は、WALが書かれるたびにWALが吐出されます。 この値が単位なしで指定された場合は、WALブロック単位であるとみなします。すなわち、XLOG_BLCKSZバイト、一般的には8kBです。 デフォルト値は1MBです。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

wal_levelがminimalで、トランザクションのコミットが永続リレーションを作るかあるいは書き換えた場合に、この設定は新しいデータをどのように永続させるかを決定します。 データがこの設定よりも少なければ、WALログに書きます。そうでなければ、影響のあるファイルに対してfsyncを使用します。 そのようなコミットが現在のトランザクションを低速化しているようであれば、使用する記憶装置の特性によってはこの値を増減することが役に立つかも知れません。 この値が単位なしに指定されるとキロバイトであると見なします。 デフォルトは2メガバイト(2MB)です。

commit_delayを設定することにより、WALフラッシュを開始する前の時間遅延が追加されます。 このことにより、もし追加のトランザクションが与えられた時間間隔内でコミットが可能になるほどシステム負荷が充分に高い場合、一回のWALフラッシュでより多くの数のトランザクションをコミットできるようになり、コミット群のスループットを改善できます。 とは言っても、それぞれのWALフラッシュに対して最大commit_delayの待ち時間の増加をきたします。 コミットの準備が完了したトランザクションが他に存在しない場合、遅延は無駄になるため、遅延はフラッシュが開始されようとしている時点で少なくともcommit_siblingsだけのトランザクションが活動している場合にだけ機能します。 同様に、fsyncが無効の場合も遅延は機能しません。 この値が単位なしで指定された場合は、マイクロ秒単位であるとみなします。 デフォルトのcommit_delayはゼロ（遅延無し）です。 この設定はスーパーユーザのみ変更可能です。

9.3より前のPostgreSQLでは、commit_delayの振る舞いは異なっており、あまり効果がありませんでした。 全てのWALフラッシュではなく、コミットだけに影響していました。また、そしてWALフラッシュが早めに完了しても設定された遅延分待機していました。 PostgreSQL 9.3以降では、フラッシュの準備が整った最初のプロセスが設定値分待機し、後続のプロセスは最初のプロセスがフラッシュ操作を完了するまでの間だけ待機をします。

commit_delayの遅延を実行するときに必要とされる同時に開いているトランザクションの最小数です。 より大きい値にすると、遅延周期の間に、少なくとも1つの他のトランザクションのコミットの準備が整う確率が高くなります。 デフォルトは5トランザクションです。

自動的WALチェックポイント間の最大間隔を指定します。 この値が単位なしで指定された場合は、秒単位であるとみなします。 有効な範囲は、30秒から1日の間です。 デフォルトは5分（5min）です。 このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

チェックポイントの間の時間のうち、どの程度の割合を使うかをチェックポイントの完了目標として指定します。 デフォルトは0.9で、可能な限りの間隔のほとんどにチェックポイントを拡散し、かなり一定のI/O負荷をもたらしますが、チェックポイントが完了するにあたってオーバヘッドをもたらします。 チェックポイントの完了を早くするので、このパラメータを小さくするのはお勧めできません。 これにより、チェックポイント中はI/Oの割合が大きくなり、チェックポイントの完了から次のチェックポイントまでの間はより少ないI/Oとなります。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

チェックポイント実行中にこのデータ量よりも多く書く度に、OSが記憶装置に書き込むことを強制しようとします。 このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsyncが実行される際、あるいはOSがバックグラウンドでデータを大きな塊で書き出す際に性能の急激な低下を招く可能性を減らします。 多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。 この設定が無効なプラットフォームがあります。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 有効な設定値は、この強制書き込み機能が無効になる0から、2MBまでです。 デフォルト値は、Linuxでは256kBで、それ以外は0です。 (BLCKSZが8kbでなければ、この設定のデフォルト値と最大値がBLCKSZに比例して変更されます。) このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

WALセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した時間よりも短い間隔で発生したとき、サーバログにメッセージを書き出します （これは、max_wal_sizeを増やす必要があることを示唆しています）。 この値が単位なしで指定された場合は、秒単位であるとみなします。 デフォルトは30秒（30s）です。 零の場合は警告を出しません。 checkpoint_timeoutがcheckpoint_warningより小さい場合は警告を出しません。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

自動WALチェックポイントの際にWALが増加する最大サイズです。 これはソフトリミットです。特別な状況下、たとえば高負荷、archive_commandの失敗、wal_keep_sizeが大きな値に設定されている、などの時には、WALサイズはmax_wal_sizeを超えることがあります。 この値が単位なしで指定された場合は、メガバイト単位であるとみなします。 デフォルトは1GBです。 このパラメータを大きくすると、クラッシュリカバリに必要な時間が長くなります。 このパラメータは、postgresql.confファイルで設定するか、サーバのコマンドラインでのみ指定できます。

この設定以下にWALのディスク使用量が保たれる限り、古いWALファイルは、消去されることなく今後のチェックポイントで使用するために常にリサイクルされます。 この設定は、たとえば大きなバッチジョブを走らせる際のWALの利用スパイクを取り扱うために、十分なWALのスペースが予約されていることを保証するために使用できます。 この値が単位なしで指定された場合は、メガバイト単位であるとみなします。 デフォルトは80MBです。 このパラメータは、postgresql.confファイルで設定するか、サーバのコマンドラインでのみ指定できます。

archive_modeが有効な場合、archive_commandを設定することにより、完了したWALセグメントはアーカイブ格納領域に送信されます。 無効にするためのoffに加え、2つのモードがあります。onとalwaysです。 通常の運用ではこの2つのモードには違いはありませんが、alwaysに設定すると、アーカイブリカバリおよびスタンバイモードでWALアーカイバが有効になります。 alwaysモードでは、アーカイブからリストアされたファイルや、ストリーミングレプリケーションでストリームされたファイルもすべて(再び)アーカイブされます。 詳細は27.2.9を参照してください。

アーカイブモードを抜けることなくarchive_commandを変更できるように、archive_modeとarchive_commandは分離されました。 このパラメータはサーバ起動時のみ設定可能です。 wal_levelがminimalに設定されている場合、archive_modeは有効になりません。

完了したWALファイルセグメントのアーカイブを実行するローカルのシェルコマンドです。 文字列内のすべての%pは、格納されるファイルのパスで置き換えられ、そして、%fはファイル名のみ置換します。 （このパス名はサーバの作業用ディレクトリ、つまり、クラスタのデータディレクトリからの相対パスです。） コマンド内に%文字そのものを埋め込むには%%を使用します。 コマンドが成功した場合にのみ終了ステータスゼロを返すことが重要です。 詳しくは26.3.1を参照ください。

このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。 サーバ起動時にarchive_modeが有効でなければ、これは無視されます。 archive_commandが空文字列（デフォルト）、かつ、archive_modeが有効な場合、WALアーカイブ処理は一時的に無効になりますが、コマンドが後で提供されることを見越して、サーバはWALセグメントの蓄積を続けます。 例えば、/bin/true（WindowsではREM）のように、真を返すだけで何もしないコマンドをarchive_commandに設定すると、実質的にアーカイブ処理が無効になりますが、アーカイブからの復帰に必要なWALファイルの連鎖も同時に断ち切るため、特別な場合のみ使用するようにしなければなりません。

archive_commandは完了したWALセグメントに対してのみ呼び出されます。 従って、サーバのWAL転送量が少ししかない（あるいは処理が少ないなぎの期間がある）場合、トランザクションの完了とアーカイブ格納領域への安全な記録との間に長期にわたる遅延があることになります。 データが未アーカイブのままでいられる期間を制限するために、archive_timeoutを設定して、強制的にサーバを新しいWALセグメントに定期的に切り替えるようにすることができます。 このパラメータが0より大きければ、サーバは前回のセグメントファイル切り替えから指定時間経過し、かつ単一のチェックポイントを含む何らかのデータベース操作が行われた場合、新しいセグメントファイルに切り替えます。 （データベースが活動していなければ、チェックポイントはスキップされます。） 強制切り替えにより早期にクローズされたアーカイブ済みファイルは、完全に完了したファイルと同じ大きさを持つことに注意してください。 そのため、非常に小さなarchive_timeoutを使用することは賢明ではなく、格納領域を膨張させてしまいます。 １分程度のarchive_timeout設定が通常は妥当です。 もしそれより高速にデータをプライマリサーバからコピーをしてしまいたいのであれば、アーカイブするよりストリーミングレプリケーションの選択を検討すべきです。 この値が単位なしで指定された場合は、秒単位であるとみなします。 このパラメータは postgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

一連のWALファイルからアーカイブセグメントを取り出すために実行するローカルのシェルコマンドです。 このパラメータはアーカイブリカバリでは必須ですが、ストリーミングレプリケーションではオプションです。 文字列中の%fはアーカイブから取り出すファイルの名前に置換され、%pはサーバ上のコピー先のパス名に置換されます。 （パス名は現在の作業ディレクトリの相対パス、つまりクラスタのデータディレクトリです。） %rは有効な最後のリスタートポイントを含むファイル名に置換されます。 これはリストアが再開可能であるために維持しなければならない最古のファイルで、現在のリストアからの再開をサポートするのに最小限必要なアーカイブを残して切り詰めるのに必要な情報として利用できます。 %rは通常ウォームスタンバイ構成でのみ使用されます。 （27.2参照。） %文字自体を埋め込むには%%と書いてください。

コマンドは、成功した時のみ終了コードのゼロを返却することが重要です。 コマンドはアーカイブにないファイル名を聞かれることになります。 その場合には、非ゼロの値を返却しなければなりません。以下に例を示します。

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

例外は、データベースサーバのシャットダウンの一部として、SIGTERM以外のシグナルでコマンドが終了させられたり、シェルによってエラーが発生した（コマンドが見つからない場合など）場合で、その場合はリカバリは中断され、サーバはスタートアップしなくなります。

このパラメータはpostgresql.confファイル、またはサーバのコマンドラインでのみ設定可能です。

オプションのパラメータは、すべてのリスタートポイントで実行されるシェルコマンドを指定します。 archive_cleanup_commandの目的は、スタンバイサーバにとって必要とされない古いアーカイブWALファイルをクリーンアップする仕組みを提供することです。 %rは最後の有効なリスタートポイントを含むファイル名に置換されます。 これはリストアが再開可能であるために保持しなければならない最古のファイルで、%rよりも前のすべてのファイルは安全に削除できます。 これは現在のリストアからの再開をサポートするのに最小限必要なアーカイブを残して切り詰めるのに必要な情報として利用できます。 単一のスタンバイ構成用のarchive_cleanup_commandで、たとえば

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

のようにして、しばしばpg_archivecleanupモジュールが使われます。 だたし、複数のスタンバイサーバが同じアーカイブディレクトリからリストアしている場合は、どのサーバにおいてももはや必要がなくなるまでWALファイルが削除されることのないようにする必要があることに留意してください。 archive_cleanup_commandは通常ウォームスタンバイ構成で使用されます。 （27.2参照。） %文字自体を埋め込むには%%と書いてください。

コマンドが非ゼロの終了ステータスを返した場合、警告ログメッセージが出力されます。 例外は、コマンドがシグナルで終了されたとき、あるいはシェルがエラーを起こしたとき（コマンドが見つからないなど）で、その場合致命的エラーが生じます。

このパラメータは postgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

このパラメータは、リカバリの終了時に一度だけ起動されるシェルコマンドを指定します。 このパラメータはオプションです。 recovery_end_commandの目的はレプリケーションあるいはリカバリの後のクリーンアップのための機構を提供することにあります。 %rは、archive_cleanup_commandと同じように、有効な最後のリスタートポイントを含むWALファイル名に置換されます。

コマンドが非ゼロの終了ステータスを返した場合、警告ログメッセージが出力されますが、データベースはスタートアップ処理を続けます。 例外は、コマンドがシグナルによって終了させられたか、シェルによってエラーが発生した（そのようなコマンドは見つからない）場合で、その場合はデータベースはスタートアップ処理を継続させません。

このパラメータは postgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

このパラメータは、リカバリが一貫した状態になり次第、すなわちできるだけ早く終了することを指定します。 オンラインバックアップからリストアした場合、これはバックアップが終了した時点を意味します。

技術的にはこれは文字列型のパラメータですが、現時点では'immediate'だけが許容されている値です。

このパラメータは、指定した（pg_create_restore_point()により作成された）名前付きリストアポイントまでリカバリを進行させます。

このパラメータは、指定したタイムスタンプまでリカバリを進行させます。 正確な停止点はrecovery_target_inclusiveにも影響されます。

（timezone_abbreviations変数が設定ファイルで先に設定されていない限り）時間帯略語を使えないことを除けば、このパラメータの値はtimestamp with time zoneデータ型が受け付けるのと同じ形式のタイムスタンプです。 おすすめの形式はUTCからのオフセットか、EESTではなくEurope/Helsinkiのような完全な時間帯名です。

このパラメータは、指定したトランザクションIDまでリカバリを進行させます。 トランザクションIDはトランザクション起動時に順番に割り当てられますが、トランザクションは数字順によらず完了することがあることに留意してください。 リカバリされるトランザクションは、指定されたものよりも前 (オプションによっては指定されたものも含まれる) にコミットされたものになります。 正確な停止点はrecovery_target_inclusiveにも影響されます。

このパラメータは、指定した先行書き込みログ(WAL)の場所のLSNまでリカバリを進行させます。 正確な停止点は、recovery_target_inclusiveの影響も受けます。 このパラメータは、 システムデータ型pg_lsnを使用して解析されます。

指定したリカバリ対象のちょうど後に停止するか(on)、ちょうどその前に停止するか(off)を指定します。 recovery_target_lsn、recovery_target_time、又はrecovery_target_xidが指定されている場合は適用されます。 この設定は、指定した対象のWALの場所(LSN)、コミット時刻、あるいはトランザクションIDが、それぞれ正確に一致するトランザクションをリカバリに含めるかどうかを制御します。 デフォルトはonです。

リカバリが作成する個別のタイムラインを指定します。 値は数値のタイムラインIDか、特殊な値です。 currentでは、ベースバックアップが取得されたときにカレントだったタイムラインに沿ってリカバリします。 latestでは、アーカイブ時に見つけた最新のタイムラインにリカバリします。これはスタンバイサーバで有用です。 デフォルトはlatestです。

通常このパラメータの設定が必要となるのは、ポイントインタイムリカバリの実施後に到達した状態に戻す場合など、複雑なリカバリの状況のみです。 この論考については26.3.5を参照してください。

リカバリ対象に到達した場合に、サーバがする動作を指定します。 デフォルトはpauseで、リカバリを休止することを意味します。 promoteは、リカバリの過程が終われば、サーバは接続の受け付けを始めることを意味します。 最後に、shutdownは、リカバリ対象に到達した後にサーバを停止します。

pauseの設定の意図した使い方は、このリカバリ対象がリカバリのための最も望ましいポイントかどうかチェックするために、データベースに対して問い合わせを実行できるようにすることです。 休止された状態は、pg_wal_replay_resume()(表 9.89参照)の使用により再開することができます。 その後、それはリカバリを終了させます。 このリカバリ対象が希望の止まるポイントでない場合、サーバをシャットダウンし、リカバリ対象の設定をより後の対象に変更し、リカバリを継続するために再起動してください。

shutdownの設定はインスタンスを正確に望ましい再生ポイントで準備するのに有用です。 インスタンスはさらに多くのWALレコードを再生できます(実際、次に起動するときには最後のチェックポイントからWALレコードを再生しなければなりません)。

recovery.signalはrecovery_target_actionがshutdownに設定されていると削除されないことに留意してください。 設定が変更されるか、recovery.signalが手動で削除されない限り、以降起動しても直ちに停止されてしまいます。

この設定はリカバリ対象が設定されていない場合には効果がありません。 hot_standbyが有効になっていない場合、pauseの設定はshutdownと同じように動作します。 昇格中にリカバリ対象に到達した場合は、pauseはpromoteと同じように働きます。

どのような場合でも、リカバリ対象が設定されていて、アーカイブリカバリがそのリカバリ対象に到達する前に終了すると、サーバはフェイタルエラーで停止します。