<varname>wal_level</varname> determines how much information is written to the WAL. The default value is <literal>replica</literal>, which writes enough data to support WAL archiving and replication, including running read-only queries on a standby server. <literal>minimal</literal> removes all logging except the information required to recover from a crash or immediate shutdown. Finally, <literal>logical</literal> adds information necessary to support logical decoding. Each level includes the information logged at all lower levels. This parameter can only be set at server start. wal_levelはどれだけの情報がWALに書かれるかを決定します。 デフォルト値はreplicaで、WALアーカイビングおよびレプリケーションをサポートするために十分なデータを書き出し、これにはスタンバイサーバで読み取り専用の問い合わせを実行することも含みます。 minimalはクラッシュまたは即時停止から回復するのに必要な情報を除き、すべてのログを削除します。 最後に、logicalは、更にロジカルデコーディングをサポートするのに必要な情報を追加します。 それぞれのレベルは、下位のレベルのログ出力を含んでいます。 このパラメータはサーバ起動時のみ設定可能です。

The <literal>minimal</literal> level generates the least WAL volume. It logs no row information for permanent relations in transactions that create or rewrite them. This can make operations much faster (see <xref linkend="populate-pitr"/>). Operations that initiate this optimization include: minimalレベルでは、最小限のWALの量しか生成されません。 永続リレーションを作成あるいは書き換えるトランザクションの差分に関する情報は記録されません。 これにより、それらの操作が大幅に高速になります（14.4.7を参照してください）。 この最適化が適用される操作には以下のものがあげられます。

However, minimal WAL does not contain sufficient information for point-in-time recovery, so <literal>replica</literal> or higher must be used to enable continuous archiving (<xref linkend="guc-archive-mode"/>) and streaming binary replication. In fact, the server will not even start in this mode if <varname>max_wal_senders</varname> is non-zero. Note that changing <varname>wal_level</varname> to <literal>minimal</literal> makes previous base backups unusable for point-in-time recovery and standby servers. しかし、minimal WALにはポイントインタイムリカバリのための十分な情報が含まれていないので、replica以上を使って継続的アーカイブ(archive_mode)とストリーミングバイナリレプリケーションを可能にしなければなりません。 実際、max_wal_sendersが0以外の場合、サーバはこのモードで起動することさえありません。 wal_levelをminimalに変更すると、以前のベースバックアップがポイントインタイムリカバリとスタンバイサーバで使用できなくなることに注意してください。

In <literal>logical</literal> level, the same information is logged as with <literal>replica</literal>, plus information needed to extract logical change sets from the WAL. Using a level of <literal>logical</literal> will increase the WAL volume, particularly if many tables are configured for <literal>REPLICA IDENTITY FULL</literal> and many <command>UPDATE</command> and <command>DELETE</command> statements are executed. logicalレベルでは、replicaと同じ情報が記録されるのに加え、ロジカルチェンジセットをWALから取り出すのに必要な情報が追加されます。 logicalを使うとWALの量が増えます。 とりわけ、多数のテーブルがREPLICA IDENTITY FULLと設定されていて(訳注: ALTER TABLE参照)、多くのUPDATEとDELETE文が実行される場合はこのことが言えます。

In releases prior to 9.6, this parameter also allowed the values <literal>archive</literal> and <literal>hot_standby</literal>. These are still accepted but mapped to <literal>replica</literal>. 9.6よりも前のリリースでは、このパラメータはarchiveとhot_standbyという設定値も可能でした。 引き続きこれらも受け付けられますが、replicaへとマップされます。

If this parameter is on, the <productname>PostgreSQL</productname> server will try to make sure that updates are physically written to disk, by issuing <function>fsync()</function> system calls or various equivalent methods (see <xref linkend="guc-wal-sync-method"/>). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash. このパラメータがオンの場合、PostgreSQLサーバはfsync()システムコールを発行するか、もしくはこれに相当する方法（wal_sync_methodを参照）で、更新が物理的にディスクに確実に書き込まれるように試みます。 これは、オペレーティングシステムもしくはハードウェアがクラッシュした後、データベースクラスタを一貫した状態に復旧させることを確実にします。

While turning off <varname>fsync</varname> is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off <varname>fsync</varname> if you can easily recreate your entire database from external data. fsyncを停止することはしばしば性能上の利益になるとは言っても、停電やクラッシュの際に回復不可能なデータ破壊になることがあります。 従って外部データから全てのデータベースを簡単に再構築できる場合のみfsyncを停止してください。

Examples of safe circumstances for turning off <varname>fsync</varname> include the initial loading of a new database cluster from a backup file, using a database cluster for processing a batch of data after which the database will be thrown away and recreated, or for a read-only database clone which gets recreated frequently and is not used for failover. High quality hardware alone is not a sufficient justification for turning off <varname>fsync</varname>. fsyncを停止しても安全な状況の例としては、以下があげられます。 バックアップファイルから新しいデータベースクラスタにデータの初期読み込みを行う場合、バッチデータの処理のためにデータベースクラスタを使用し、その後データベースを削除して再構築する場合、読み込み専用のデータベースのクローンを頻繁に再作成するが、それをフェイルオーバーに使用しない場合、などです。 高性能なハードウェアであるからと言って、fsyncを停止することは正当性を主張する十分な理由とはなりません。

For reliable recovery when changing <varname>fsync</varname> off to on, it is necessary to force all modified buffers in the kernel to durable storage. This can be done while the cluster is shutdown or while <varname>fsync</varname> is on by running <command>initdb &#45;-sync-only</command>, running <command>sync</command>, unmounting the file system, or rebooting the server. fsyncを無効(off)から有効(on)に変更したときの信頼できるリカバリのためには、カーネル内の全ての変更されたバッファを恒久的ストレージに強制的に吐き出させることが必要です。 これは、クラスタがシャットダウンしている間、またはfsyncが有効のときに、initdb --sync-onlyを実行する、syncを実行する、ファイルシステムをアンマウントする、またはサーバを再起動することによって可能となります。

In many situations, turning off <xref linkend="guc-synchronous-commit"/> for noncritical transactions can provide much of the potential performance benefit of turning off <varname>fsync</varname>, without the attendant risks of data corruption. 多くの場合、重要でないトランザクションに対してsynchronous_commitを無効にすることにより、データ破壊という付随的危険性を伴うことなく、fsyncを無効にすることで得られるであろう性能上のメリットの多くを得ることができます。

<varname>fsync</varname> can only be set in the <filename>postgresql.conf</filename> file or on the server command line. If you turn this parameter off, also consider turning off <xref linkend="guc-full-page-writes"/>. fsync はpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。 このパラメータを無効にする場合、full_page_writesも同時に無効にすることを検討してください。

Specifies how much WAL processing must complete before the database server returns a <quote>success</quote> indication to the client. Valid values are <literal>remote_apply</literal>, <literal>on</literal> (the default), <literal>remote_write</literal>, <literal>local</literal>, and <literal>off</literal>. トランザクションのコミットがクライアントに「成功」の報告を返す前に、どれだけのWAL処理を完了しなければならないかを指定をします。 有効な値はremote_apply、on(デフォルト)、remote_write、local、offです。

If <varname>synchronous_standby_names</varname> is empty, the only meaningful settings are <literal>on</literal> and <literal>off</literal>; <literal>remote_apply</literal>, <literal>remote_write</literal> and <literal>local</literal> all provide the same local synchronization level as <literal>on</literal>. The local behavior of all non-<literal>off</literal> modes is to wait for local flush of WAL to disk. In <literal>off</literal> mode, there is no waiting, so there can be a delay between when success is reported to the client and when the transaction is later guaranteed to be safe against a server crash. (The maximum delay is three times <xref linkend="guc-wal-writer-delay"/>.) Unlike <xref linkend="guc-fsync"/>, setting this parameter to <literal>off</literal> does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning <varname>synchronous_commit</varname> off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see <xref linkend="wal-async-commit"/>. synchronous_standby_namesが空文字なら、意味のある設定はonとoffだけです。 remote_apply、remote_write、localはすべてonと同じ同期レベルを提供します。 offモード以外のローカルの振る舞いは、WALがディスクにローカルにフラッシュされるのを待ちます。 offモードでは待ちはありません。 ですから、クライアントに成功が報告されてから、トランザクションが後でサーバクラッシュに対して安全が保証されるまでの間に遅延が生じる可能性があります。 （遅延は最大でwal_writer_delayの3倍です。） fsyncと違って、このパラメータをoffにすることでデータベースの一貫性が損なわれるリスクはありません。 オペレーティングシステムやデータベースのクラッシュにより最近コミットされたということになっているトランザクションの一部が失われる可能性がありますが、これらのトランザクションが正常にアボートされた時とデータベースの状態は変わりません。 したがって、synchronous_commitのオフによる調整は、トランザクションの耐障害性を確実にするよりも性能が重要な場合の有用な代替案となるかも知れません。 詳細は30.4を参照してください。

If <xref linkend="guc-synchronous-standby-names"/> is non-empty, <varname>synchronous_commit</varname> also controls whether transaction commits will wait for their WAL records to be processed on the standby server(s). synchronous_standby_namesが空文字でない場合は、synchronous_commitは、WALレコードが、スタンバイサーバに複製されるまでトランザクションコミットを待機するか否かも制御します。

When set to <literal>remote_apply</literal>, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s), and also written to durable storage on the standbys. This will cause much larger commit delays than previous settings since it waits for WAL replay. When set to <literal>on</literal>, commits wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to durable storage. This ensures the transaction will not be lost unless both the primary and all synchronous standbys suffer corruption of their database storage. When set to <literal>remote_write</literal>, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and written it to their file systems. This setting ensures data preservation if a standby instance of <productname>PostgreSQL</productname> crashes, but not if the standby suffers an operating-system-level crash because the data has not necessarily reached durable storage on the standby. The setting <literal>local</literal> causes commits to wait for local flush to disk, but not for replication. This is usually not desirable when synchronous replication is in use, but is provided for completeness. remote_applyに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取って適用し、スタンバイ上で発行されたクエリから見えるようになり、スタンバイ上の永続的な記憶装置に書き込まれたことを報告するまでコミットは待機します。 WALのリプレイを待つので、今までの設定に比べるとこの設定によってずっと大きなコミットの遅延が発生します。 onに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、永続的な記憶装置にフラッシュしたことを報告するまでコミットは待機します。 このモードでは、プライマリおよびすべての同期スタンバイがデータベース記憶装置の故障を被った場合を除いて、トランザクションが失われないことが保証されます。 remote_writeに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、スタンバイのファイルシステムに書き出したことを報告するまでコミットは待機します。 この設定は仮にPostgreSQLのスタンバイインスタンスがクラッシュしたとしても、データ保護を保証するのに充分です。 しかし、スタンバイがオペレーティングシステムのレベルでクラッシュした場合はこの限りではありません。 データが必ずしもスタンバイの永続的な記憶装置に到達したとは言えないからです。 最後に、local設定は、コミットがローカルにディスクにフラッシュされるまで待機しますが、レプリケーションされるまでは待機しません。 これは通常同期レプリケーションが使用されている場合は望ましい設定ではありませんが、完全さのために提供されています。

This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue <command>SET LOCAL synchronous_commit TO OFF</command> within the transaction. このパラメータはいつでも変更可能です。 どのトランザクションの動作も、コミット時に有効であった設定によって決まります。 したがって、一部のトランザクションのコミットを同期的に、その他を非同期的にすることが可能で、かつ、有用です。 例えば、デフォルトが同期コミットの場合に複数文トランザクションを一つだけ非同期にコミットさせるためには、トランザクション内でSET LOCAL synchronous_commit TO OFFを発行します。

<xref linkend="synchronous-commit-matrix"/> summarizes the capabilities of the <varname>synchronous_commit</varname> settings. synchronous_commit設定の機能のまとめが表 20.1にあります。

Method used for forcing WAL updates out to disk. If <varname>fsync</varname> is off then this setting is irrelevant, since WAL file updates will not be forced out at all. Possible values are: WALの更新をディスクへ強制するのに使用される方法です。 fsyncがオフの場合この設定は役に立ちません。と言うのはWALファイルの更新が全く強制されないからです。取り得る値は以下のものです。

Not all of these choices are available on all platforms. The default is the first method in the above list that is supported by the platform, except that <literal>fdatasync</literal> is the default on Linux and FreeBSD. The default is not necessarily ideal; it might be necessary to change this setting or other aspects of your system configuration in order to create a crash-safe configuration or achieve optimal performance. These aspects are discussed in <xref linkend="wal-reliability"/>. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 全てのプラットフォームでこれら全ての選択肢が使えるわけではありません。 デフォルトは、上のリストのプラットフォームでサポートされるものの最初に列挙されているものです。 ただしLinuxとFreeBSDではfdatasyncがデフォルトです。 デフォルトは必ずしも理想的なものではありません。 クラッシュに適応した構成にする、あるいはアーカイブの最適性能を導くためには、この設定あるいはシステム構成の他の部分を変更することが必要かもしれません。 これらの側面は 30.1で解説されます。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

When this parameter is on, the <productname>PostgreSQL</productname> server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint. This is needed because a page write that is in process during an operating system crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WAL will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at the price of increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.) このパラメータが有効の場合、PostgreSQLサーバは、チェックポイントの後にそのページが最初に変更された過程で、ディスクページの全ての内容をWALに書き込みます。 オペレーティングシステムがクラッシュした時に進行中のページ書き込みは途中までしか終わっていない可能性があり、ディスク上のページが古いデータと新しいデータが混在する状態になるため、この機能が必要です。 通常WAL内に保存される行レベルの変更データは、クラッシュ後のリカバリ時にこうしたページを完全に復旧させるには不十分です。 完全なページイメージを保存することにより、ページを正しく復旧できることを保証しますが、その代わりに、WALに書き込まなければならないデータ量が増加することになります。 （WAL再生は常にチェックポイントから始まるため、チェックポイント後のそれぞれのページの最初の変更時にこれを行えば十分です。 従って、完全ページ書き出しのコストを低減する方法の1つは、チェックポイント間隔パラメータを大きくすることです。）

Turning this parameter off speeds normal operation, but might lead to either unrecoverable data corruption, or silent data corruption, after a system failure. The risks are similar to turning off <varname>fsync</varname>, though smaller, and it should be turned off only based on the same circumstances recommended for that parameter. このパラメータを無効にすると、通常の操作速度が上がりますが、システム障害後に、回復不能なデータ破損、あるいは警告なしのデータ損壊をもたらすかもしれません。 このリスクは小さいながらfsyncを無効にした場合と似ています。そしてそのfsyncに対して推奨されている同一の状況に基づく限りにおいて停止されなければなりません。

Turning off this parameter does not affect use of WAL archiving for point-in-time recovery (PITR) (see <xref linkend="continuous-archiving"/>). このパラメータを無効にしてもポイントインタイムリカバリ（PITR）用のWALアーカイブの使用に影響ありません（ 26.3を参照してください）。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. The default is <literal>on</literal>. このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。 デフォルトはonです。

When this parameter is <literal>on</literal>, the <productname>PostgreSQL</productname> server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint, even for non-critical modifications of so-called hint bits. このパラメータがonの場合、PostgreSQLサーバはチェックポイント後にはじめてページを変更する際に、ディスクページの全内容をWALに書き出します。 これは、あまり重要でない、ヒントビットと呼ばれるものに対する変更にさえ当てはまります。

If data checksums are enabled, hint bit updates are always WAL-logged and this setting is ignored. You can use this setting to test how much extra WAL-logging would occur if your database had data checksums enabled. データチェックサムが有効であると、ヒントビットの更新は常にWALにログされ、この設定パラメータは無視されます。この設定パラメータを使って、データチェックサムが有効なときにどれだけのWALログは余計に書きだされるかをテストすることができます。

This parameter can only be set at server start. The default value is <literal>off</literal>. このパラメータはサーバ起動時のみ設定可能です。 デフォルト値はoffです。

This parameter enables compression of WAL using the specified compression method. When enabled, the <productname>PostgreSQL</productname> server compresses full page images written to WAL when <xref linkend="guc-full-page-writes"/> is on or during a base backup. A compressed page image will be decompressed during WAL replay. The supported methods are <literal>pglz</literal>, <literal>lz4</literal> (if <productname>PostgreSQL</productname> was compiled with <option>&#45;-with-lz4</option>) and <literal>zstd</literal> (if <productname>PostgreSQL</productname> was compiled with <option>&#45;-with-zstd</option>). The default value is <literal>off</literal>. Only superusers and users with the appropriate <literal>SET</literal> privilege can change this setting. このパラメータは、指定された圧縮方法を使用したWALの圧縮を有効にします。 有効にすると、PostgreSQLサーバはfull_page_writesがオンの時またはベースバックアップ中にWALに書き込まれた全ページイメージを圧縮します。 圧縮されたページイメージはWAL再生中に伸長されます。 サポートされている方法はpglz、lz4(PostgreSQLが--with-lz4でコンパイルされた場合)およびzstd(PostgreSQLが--with-zstdでコンパイルされた場合)です。 デフォルト値はoffです。 スーパーユーザと適切なSET権限を持つユーザのみがこの設定を変更できます。

Enabling compression can reduce the WAL volume without increasing the risk of unrecoverable data corruption, but at the cost of some extra CPU spent on the compression during WAL logging and on the decompression during WAL replay. このパラメータを有効にすると、回復不可能なデータ破壊のリスクを増やすこと無しにWALの量を減らすことができます。 しかし、WALロギングの際の圧縮のため、またWALリプレイの際には伸張のために余分なCPUを使用するというコストが発生します。

If set to <literal>on</literal> (the default), this option causes new WAL files to be filled with zeroes. On some file systems, this ensures that space is allocated before we need to write WAL records. However, <firstterm>Copy-On-Write</firstterm> (COW) file systems may not benefit from this technique, so the option is given to skip the unnecessary work. If set to <literal>off</literal>, only the final byte is written when the file is created so that it has the expected size. このオプションがon（デフォルト）に設定されると、新しいWALファイルはゼロで初期化されます。 システムによっては、このことによってWALレコードを書く必要が出てくる前にスペースが割り当てられることを保証します。 しかし、Copy-On-Write (COW)ファイルシステムではこの技術は利点がないかもしれず、このオプションはスキップできるようになっています。 offに設定すると、ファイルを作る時に期待する大きさになるように最後のバイトだけが書かれます。

If set to <literal>on</literal> (the default), this option causes WAL files to be recycled by renaming them, avoiding the need to create new ones. On COW file systems, it may be faster to create new ones, so the option is given to disable this behavior. このオプションがon（デフォルト）に設定されると、新しくファイルを作るのを避けるために、名前を変えてWALファイルが再利用されます。 COWファイルシステムでは、新しいファイルを作るほうが速いかも知れないので、この挙動を無効にできるようにオプションとなっています。

The amount of shared memory used for WAL data that has not yet been written to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%) of <xref linkend="guc-shared-buffers"/>, but not less than <literal>64kB</literal> nor more than the size of one WAL segment, typically <literal>16MB</literal>. This value can be set manually if the automatic choice is too large or too small, but any positive value less than <literal>32kB</literal> will be treated as <literal>32kB</literal>. If this value is specified without units, it is taken as WAL blocks, that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB. This parameter can only be set at server start. 未だディスクに書き込まれていないWALデータに対して使用される共有メモリ容量です。 デフォルトの設定である-1は、shared_buffersの1/32（約3%）の容量に等しい大きさを選択します。 しかし、64kB未満ではなく、かつ典型的に16MBであるWALセグメントの大きさを超えることはありません。 もし、自動設定による選択が大きすぎたり、小さすぎる場合この値は手作業で設定可能です。 しかし、32kB未満のどんな正の値であっても、32kBとして取り扱われます。 この値が単位なしで指定された場合は、WALブロック単位であるとみなします。すなわち、XLOG_BLCKSZバイト、一般的には8kBです。 このパラメータはサーバ起動時のみ設定可能です。

The contents of the WAL buffers are written out to disk at every transaction commit, so extremely large values are unlikely to provide a significant benefit. However, setting this value to at least a few megabytes can improve write performance on a busy server where many clients are committing at once. The auto-tuning selected by the default setting of -1 should give reasonable results in most cases. WALバッファの内容はトランザクションのコミット毎にディスクに書き込まれます。 したがって、極端に大きな値は有意な効果を期待できません。 しかし、この値を数メガバイトに設定することにより、多くのクライアントが同時にコミットするトラフィック量の多いサーバでは書き込み性能が向上します。 デフォルト設定の-1で選択される自動チューニングによると、ほとんどの場合妥当な結果が得られます。

Specifies how often the WAL writer flushes WAL, in time terms. After flushing WAL the writer sleeps for the length of time given by <varname>wal_writer_delay</varname>, unless woken up sooner by an asynchronously committing transaction. If the last flush happened less than <varname>wal_writer_delay</varname> ago and less than <varname>wal_writer_flush_after</varname> worth of WAL has been produced since, then WAL is only written to the operating system, not flushed to disk. If this value is specified without units, it is taken as milliseconds. The default value is 200 milliseconds (<literal>200ms</literal>). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting <varname>wal_writer_delay</varname> to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 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ファイル内、またはサーバのコマンドラインのみで設定可能です。

Specifies how often the WAL writer flushes WAL, in volume terms. If the last flush happened less than <varname>wal_writer_delay</varname> ago and less than <varname>wal_writer_flush_after</varname> worth of WAL has been produced since, then WAL is only written to the operating system, not flushed to disk. If <varname>wal_writer_flush_after</varname> is set to <literal>0</literal> then WAL data is always flushed immediately. If this value is specified without units, it is taken as WAL blocks, that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB. The default is <literal>1MB</literal>. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 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ファイル内、またはサーバのコマンドラインのみで設定可能です。

When <varname>wal_level</varname> is <literal>minimal</literal> and a transaction commits after creating or rewriting a permanent relation, this setting determines how to persist the new data. If the data is smaller than this setting, write it to the WAL log; otherwise, use an fsync of affected files. Depending on the properties of your storage, raising or lowering this value might help if such commits are slowing concurrent transactions. If this value is specified without units, it is taken as kilobytes. The default is two megabytes (<literal>2MB</literal>). wal_levelがminimalで、トランザクションのコミットが永続リレーションを作るかあるいは書き換えた場合に、この設定は新しいデータをどのように永続させるかを決定します。 データがこの設定よりも少なければ、WALログに書きます。そうでなければ、影響のあるファイルに対してfsyncを使用します。 そのようなコミットが現在のトランザクションを低速化しているようであれば、使用する記憶装置の特性によってはこの値を増減することが役に立つかも知れません。 この値が単位なしに指定されるとキロバイトであると見なします。 デフォルトは2メガバイト(2MB)です。

Setting <varname>commit_delay</varname> adds a time delay before a WAL flush is initiated. This can improve group commit throughput by allowing a larger number of transactions to commit via a single WAL flush, if system load is high enough that additional transactions become ready to commit within the given interval. However, it also increases latency by up to the <varname>commit_delay</varname> for each WAL flush. Because the delay is just wasted if no other transactions become ready to commit, a delay is only performed if at least <varname>commit_siblings</varname> other transactions are active when a flush is about to be initiated. Also, no delays are performed if <varname>fsync</varname> is disabled. If this value is specified without units, it is taken as microseconds. The default <varname>commit_delay</varname> is zero (no delay). Only superusers and users with the appropriate <literal>SET</literal> privilege can change this setting. commit_delayを設定することにより、WALフラッシュを開始する前の時間遅延が追加されます。 このことにより、もし追加のトランザクションが与えられた時間間隔内でコミットが可能になるほどシステム負荷が充分に高い場合、一回のWALフラッシュでより多くの数のトランザクションをコミットできるようになり、コミット群のスループットを改善できます。 とは言っても、それぞれのWALフラッシュに対して最大commit_delayの待ち時間の増加をきたします。 コミットの準備が完了したトランザクションが他に存在しない場合、遅延は無駄になるため、遅延はフラッシュが開始されようとしている時点で少なくともcommit_siblingsだけのトランザクションが活動している場合にだけ機能します。 同様に、fsyncが無効の場合も遅延は機能しません。 この値が単位なしで指定された場合は、マイクロ秒単位であるとみなします。 デフォルトのcommit_delayはゼロ（遅延無し）です。 スーパーユーザと適切なSET権限を持つユーザのみがこの設定を変更できます。

In <productname>PostgreSQL</productname> releases prior to 9.3, <varname>commit_delay</varname> behaved differently and was much less effective: it affected only commits, rather than all WAL flushes, and waited for the entire configured delay even if the WAL flush was completed sooner. Beginning in <productname>PostgreSQL</productname> 9.3, the first process that becomes ready to flush waits for the configured interval, while subsequent processes wait only until the leader completes the flush operation. 9.3より前のPostgreSQLでは、commit_delayの振る舞いは異なっており、あまり効果がありませんでした。 全てのWALフラッシュではなく、コミットだけに影響していました。また、そしてWALフラッシュが早めに完了しても設定された遅延分待機していました。 PostgreSQL 9.3以降では、フラッシュの準備が整った最初のプロセスが設定値分待機し、後続のプロセスは最初のプロセスがフラッシュ操作を完了するまでの間だけ待機をします。

Minimum number of concurrent open transactions to require before performing the <varname>commit_delay</varname> delay. A larger value makes it more probable that at least one other transaction will become ready to commit during the delay interval. The default is five transactions. commit_delayの遅延を実行するときに必要とされる同時に開いているトランザクションの最小数です。 より大きい値にすると、遅延周期の間に、少なくとも1つの他のトランザクションのコミットの準備が整う確率が高くなります。 デフォルトは5トランザクションです。

Maximum time between automatic WAL checkpoints. If this value is specified without units, it is taken as seconds. The valid range is between 30 seconds and one day. The default is five minutes (<literal>5min</literal>). Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 自動的WALチェックポイント間の最大間隔を指定します。 この値が単位なしで指定された場合は、秒単位であるとみなします。 有効な範囲は、30秒から1日の間です。 デフォルトは5分（5min）です。 このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

Specifies the target of checkpoint completion, as a fraction of total time between checkpoints. The default is 0.9, which spreads the checkpoint across almost all of the available interval, providing fairly consistent I/O load while also leaving some time for checkpoint completion overhead. Reducing this parameter is not recommended because it causes the checkpoint to complete faster. This results in a higher rate of I/O during the checkpoint followed by a period of less I/O between the checkpoint completion and the next scheduled checkpoint. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. チェックポイントの間の時間のうち、どの程度の割合を使うかをチェックポイントの完了目標として指定します。 デフォルトは0.9で、可能な限りの間隔のほとんどにチェックポイントを拡散し、かなり一定のI/O負荷をもたらしますが、チェックポイントが完了するにあたってオーバーヘッドをもたらします。 チェックポイントの完了を早くするので、このパラメータを小さくするのはお勧めできません。 これにより、チェックポイント中はI/Oの割合が大きくなり、チェックポイントの完了から次のチェックポイントまでの間はより少ないI/Oとなります。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

Whenever more than this amount of data has been written while performing a checkpoint, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of stalls when an <function>fsync</function> is issued at the end of the checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The valid range is between <literal>0</literal>, which disables forced writeback, and <literal>2MB</literal>. The default is <literal>256kB</literal> on Linux, <literal>0</literal> elsewhere. (If <symbol>BLCKSZ</symbol> is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. チェックポイント実行中にこのデータ量よりも多く書く度に、OSが記憶装置に書き込むことを強制しようとします。 このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsyncが実行される際、あるいはOSがバックグラウンドでデータを大きな塊で書き出す際に性能の急激な低下を招く可能性を減らします。 多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。 この設定が無効なプラットフォームがあります。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 有効な設定値は、この強制書き込み機能が無効になる0から、2MBまでです。 デフォルト値は、Linuxでは256kBで、それ以外は0です。 (BLCKSZが8kbでなければ、この設定のデフォルト値と最大値がBLCKSZに比例して変更されます。) このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

Write a message to the server log if checkpoints caused by the filling of WAL segment files happen closer together than this amount of time (which suggests that <varname>max_wal_size</varname> ought to be raised). If this value is specified without units, it is taken as seconds. The default is 30 seconds (<literal>30s</literal>). Zero disables the warning. No warnings will be generated if <varname>checkpoint_timeout</varname> is less than <varname>checkpoint_warning</varname>. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. WALセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した時間よりも短い間隔で発生したとき、サーバログにメッセージを書き出します （これは、max_wal_sizeを増やす必要があることを示唆しています）。 この値が単位なしで指定された場合は、秒単位であるとみなします。 デフォルトは30秒（30s）です。 零の場合は警告を出しません。 checkpoint_timeoutがcheckpoint_warningより小さい場合は警告を出しません。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

Maximum size to let the WAL grow during automatic checkpoints. This is a soft limit; WAL size can exceed <varname>max_wal_size</varname> under special circumstances, such as heavy load, a failing <varname>archive_command</varname> or <varname>archive_library</varname>, or a high <varname>wal_keep_size</varname> setting. If this value is specified without units, it is taken as megabytes. The default is 1 GB. Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 自動WALチェックポイントの際にWALが増加する最大サイズです。 これはソフトリミットです。特別な状況下、たとえば高負荷、archive_commandの失敗、archive_libraryの失敗、wal_keep_sizeが大きな値に設定されている、などの時には、WALサイズはmax_wal_sizeを超えることがあります。 この値が単位なしで指定された場合は、メガバイト単位であるとみなします。 デフォルトは1GBです。 このパラメータを大きくすると、クラッシュリカバリに必要な時間が長くなります。 このパラメータは、postgresql.confファイルで設定するか、サーバのコマンドラインでのみ指定できます。

As long as WAL disk usage stays below this setting, old WAL files are always recycled for future use at a checkpoint, rather than removed. This can be used to ensure that enough WAL space is reserved to handle spikes in WAL usage, for example when running large batch jobs. If this value is specified without units, it is taken as megabytes. The default is 80 MB. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. この設定以下にWALのディスク使用量が保たれる限り、古いWALファイルは、消去されることなく今後のチェックポイントで使用するために常にリサイクルされます。 この設定は、たとえば大きなバッチジョブを走らせる際のWALの利用スパイクを取り扱うために、十分なWALのスペースが予約されていることを保証するために使用できます。 この値が単位なしで指定された場合は、メガバイト単位であるとみなします。 デフォルトは80MBです。 このパラメータは、postgresql.confファイルで設定するか、サーバのコマンドラインでのみ指定できます。

When <varname>archive_mode</varname> is enabled, completed WAL segments are sent to archive storage by setting <xref linkend="guc-archive-command"/> or <xref linkend="guc-archive-library"/>. In addition to <literal>off</literal>, to disable, there are two modes: <literal>on</literal>, and <literal>always</literal>. During normal operation, there is no difference between the two modes, but when set to <literal>always</literal> the WAL archiver is enabled also during archive recovery or standby mode. In <literal>always</literal> mode, all files restored from the archive or streamed with streaming replication will be archived (again). See <xref linkend="continuous-archiving-in-standby"/> for details. archive_modeが有効な場合、archive_commandあるいはarchive_libraryを設定することにより、完了したWALセグメントはアーカイブ格納領域に送信されます。 無効にするためのoffに加え、2つのモードがあります。onとalwaysです。 通常の運用ではこの2つのモードには違いはありませんが、alwaysに設定すると、アーカイブリカバリおよびスタンバイモードでWALアーカイバが有効になります。 alwaysモードでは、アーカイブからリストアされたファイルや、ストリーミングレプリケーションでストリームされたファイルもすべて(再び)アーカイブされます。 詳細は27.2.9を参照してください。

<varname>archive_mode</varname> is a separate setting from <varname>archive_command</varname> and <varname>archive_library</varname> so that <varname>archive_command</varname> and <varname>archive_library</varname> can be changed without leaving archiving mode. This parameter can only be set at server start. <varname>archive_mode</varname> cannot be enabled when <varname>wal_level</varname> is set to <literal>minimal</literal>. archive_commandとarchive_libraryがアーカイブモードを停止することなく変更できるように、archive_modeは、archive_commandとarchive_libraryとは別の設定項目になっています。 このパラメータはサーバ起動時のみ設定可能です。 wal_levelがminimalに設定されている場合、archive_modeを有効にすることはできません。

The local shell command to execute to archive a completed WAL file segment. Any <literal>%p</literal> in the string is replaced by the path name of the file to archive, and any <literal>%f</literal> is replaced by only the file name. (The path name is relative to the working directory of the server, i.e., the cluster's data directory.) Use <literal>%%</literal> to embed an actual <literal>%</literal> character in the command. It is important for the command to return a zero exit status only if it succeeds. For more information see <xref linkend="backup-archiving-wal"/>. 完了したWALファイルセグメントのアーカイブを実行するローカルのシェルコマンドです。 文字列内のすべての%pは、格納されるファイルのパスで置き換えられ、そして、%fはファイル名のみ置換します。 （このパス名はサーバの作業用ディレクトリ、つまり、クラスタのデータディレクトリからの相対パスです。） コマンド内に%文字そのものを埋め込むには%%を使用します。 コマンドが成功した場合にのみ終了ステータスゼロを返すことが重要です。 詳しくは26.3.1を参照ください。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. It is only used if <varname>archive_mode</varname> was enabled at server start and <varname>archive_library</varname> is set to an empty string. If both <varname>archive_command</varname> and <varname>archive_library</varname> are set, an error will be raised. If <varname>archive_command</varname> is an empty string (the default) while <varname>archive_mode</varname> is enabled (and <varname>archive_library</varname> is set to an empty string), WAL archiving is temporarily disabled, but the server continues to accumulate WAL segment files in the expectation that a command will soon be provided. Setting <varname>archive_command</varname> to a command that does nothing but return true, e.g., <literal>/bin/true</literal> (<literal>REM</literal> on Windows), effectively disables archiving, but also breaks the chain of WAL files needed for archive recovery, so it should only be used in unusual circumstances. このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。 サーバ起動時にarchive_modeが有効で、archive_libraryが空文字の時にのみ使用されます。 archive_commandとarchive_libraryの両方が有効ならばエラーが発生します。 archive_modeが有効であるにもかかわらず、archive_commandが空文字列（デフォルト）、（そしてarchive_libraryが空文字列）である場合、WALアーカイブ処理は一時的に無効になりますが、コマンドが後で提供されることを見越して、サーバはWALセグメントの蓄積を続けます。 例えば、/bin/true（WindowsではREM）のように、真を返すだけで何もしないコマンドをarchive_commandに設定すると、実質的にアーカイブ処理が無効になりますが、アーカイブからの復帰に必要なWALファイルの連鎖も同時に断ち切るため、特別な場合のみ使用するようにしなければなりません。

The library to use for archiving completed WAL file segments. If set to an empty string (the default), archiving via shell is enabled, and <xref linkend="guc-archive-command"/> is used. If both <varname>archive_command</varname> and <varname>archive_library</varname> are set, an error will be raised. Otherwise, the specified shared library is used for archiving. The WAL archiver process is restarted by the postmaster when this parameter changes. For more information, see <xref linkend="backup-archiving-wal"/> and <xref linkend="archive-modules"/>. アーカイビングが完了したWALファイルセグメントに使用するライブラリです。 空文字列（デフォルト）に設定された場合、シェル経由のアーカイビングが有効になり、archive_commandが使用されます。 archive_commandとarchive_libraryの両方が有効ならばエラーが発生します。 それ以外の場合は、指定された共有ライブラリがアーカイブに使用されます。 WALアーカイバプロセスは、このパラメータが変更されたときにpostmasterによって再起動されます。 詳細については、26.3.1および第51章を参照してください。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

The <xref linkend="guc-archive-command"/> or <xref linkend="guc-archive-library"/> is only invoked for completed WAL segments. Hence, if your server generates little WAL traffic (or has slack periods where it does so), there could be a long delay between the completion of a transaction and its safe recording in archive storage. To limit how old unarchived data can be, you can set <varname>archive_timeout</varname> to force the server to switch to a new WAL segment file periodically. When this parameter is greater than zero, the server will switch to a new segment file whenever this amount of time has elapsed since the last segment file switch, and there has been any database activity, including a single checkpoint (checkpoints are skipped if there is no database activity). Note that archived files that are closed early due to a forced switch are still the same length as completely full files. Therefore, it is unwise to use a very short <varname>archive_timeout</varname> &mdash; it will bloat your archive storage. <varname>archive_timeout</varname> settings of a minute or so are usually reasonable. You should consider using streaming replication, instead of archiving, if you want data to be copied off the primary server more quickly than that. If this value is specified without units, it is taken as seconds. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. archive_commandまたはarchive_library は、完了したWALセグメントに対してのみ呼び出されます。 したがって、サーバがWALトラフィックをほとんど生成しない場合（あるいはそのような余裕期間がある場合）、トランザクションの完了とアーカイブストレージへの安全な記録との間に長い遅延が発生する可能性があります。 アーカイブされていないデータの古さを制限するために、archive_timeoutを設定して、サーバに新しいWALセグメントファイルへの定期的な切り替えを強制することができます。 このパラメータが0より大きい場合、サーバは、最後のセグメントファイル切り替えからこの時間が経過し、単一のチェックポイント（データベースアクティビティがない場合はチェックポイントはスキップされます）を含むデータベースアクティビティが発生するたびに新しいセグメントファイルへの切り替えを行います。 強制的な切り替えにより早期に閉じられたアーカイブファイルは、完全に満杯のファイルと同じ長さのままであることに注意してください。 したがって、非常に短いarchive_timeoutを使用することは賢明ではなく、アーカイブストレージを膨張させます。 通常は1分程度のarchive_timeout設定が妥当です。 プライマリサーバからデータをより迅速にコピーしたい場合は、アーカイブではなくストリーミングレプリケーションを使用することを検討してください。この値が単位なしで指定された場合、秒として取得されます。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。

Whether to try to prefetch blocks that are referenced in the WAL that are not yet in the buffer pool, during recovery. Valid values are <literal>off</literal>, <literal>on</literal> and <literal>try</literal> (the default). The setting <literal>try</literal> enables prefetching only if the operating system provides the <function>posix_fadvise</function> function, which is currently used to implement prefetching. Note that some operating systems provide the function, but it doesn't do anything. リカバリ中に、まだバッファプールにない、WALで参照されているブロックをプリフェッチしようとするかどうか。 有効な値はoff、on、try(デフォルト)です。 try設定は、オペレーティングシステムがposix_fadvise関数を提供している場合にのみプリフェッチを有効にします。 この関数は現在、プリフェッチの実装に使用されています。 一部のオペレーティングシステムはこの関数を提供していますが、何も行わないことに注意してください。

Prefetching blocks that will soon be needed can reduce I/O wait times during recovery with some workloads. See also the <xref linkend="guc-wal-decode-buffer-size"/> and <xref linkend="guc-maintenance-io-concurrency"/> settings, which limit prefetching activity. すぐに必要になるブロックをプリフェッチすると、一部のワークロードでリカバリ中のI/O待機時間を短縮できます。 プリフェッチ・アクティビティを制限するwal_decode_buffer_sizeおよびmaintenance_io_concurrency設定も参照してください。

A limit on how far ahead the server can look in the WAL, to find blocks to prefetch. If this value is specified without units, it is taken as bytes. The default is 512kB. サーバがプリフェッチするブロックを見つけるためにWAL内をどれだけ先まで見ることができるかの制限です。 この値が単位なしで指定された場合、バイトとして扱われます。 デフォルトは512KBです。

The local shell command to execute to retrieve an archived segment of the WAL file series. This parameter is required for archive recovery, but optional for streaming replication. Any <literal>%f</literal> in the string is replaced by the name of the file to retrieve from the archive, and any <literal>%p</literal> is replaced by the copy destination path name on the server. (The path name is relative to the current working directory, i.e., the cluster's data directory.) Any <literal>%r</literal> is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be kept to allow a restore to be restartable, so this information can be used to truncate the archive to just the minimum required to support restarting from the current restore. <literal>%r</literal> is typically only used by warm-standby configurations (see <xref linkend="warm-standby"/>). Write <literal>%%</literal> to embed an actual <literal>%</literal> character. 一連のWALファイルからアーカイブセグメントを取り出すために実行するローカルのシェルコマンドです。 このパラメータはアーカイブリカバリでは必須ですが、ストリーミングレプリケーションではオプションです。 文字列中の%fはアーカイブから取り出すファイルの名前に置換され、%pはサーバ上のコピー先のパス名に置換されます。 （パス名は現在の作業ディレクトリの相対パス、つまりクラスタのデータディレクトリです。） %rは有効な最後のリスタートポイントを含むファイル名に置換されます。 これはリストアが再開可能であるために維持しなければならない最古のファイルで、現在のリストアからの再開をサポートするのに最小限必要なアーカイブを残して切り詰めるのに必要な情報として利用できます。 %rは通常ウォームスタンバイ構成でのみ使用されます。 （27.2参照。） %文字自体を埋め込むには%%と書いてください。

It is important for the command to return a zero exit status only if it succeeds. The command <emphasis>will</emphasis> be asked for file names that are not present in the archive; it must return nonzero when so asked. Examples: コマンドは、成功した時のみ終了コードのゼロを返却することが重要です。 コマンドはアーカイブにないファイル名を聞かれることになります。 その場合には、非ゼロの値を返却しなければなりません。以下に例を示します。

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

An exception is that if the command was terminated by a signal (other than <systemitem>SIGTERM</systemitem>, which is used as part of a database server shutdown) or an error by the shell (such as command not found), then recovery will abort and the server will not start up. 例外は、データベースサーバのシャットダウンの一部として、SIGTERM以外のシグナルでコマンドが終了させられたり、シェルによってエラーが発生した（コマンドが見つからない場合など）場合で、その場合はリカバリは中断され、サーバはスタートアップしなくなります。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータは postgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

This optional parameter specifies a shell command that will be executed at every restartpoint. The purpose of <varname>archive_cleanup_command</varname> is to provide a mechanism for cleaning up old archived WAL files that are no longer needed by the standby server. Any <literal>%r</literal> is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be <emphasis>kept</emphasis> to allow a restore to be restartable, and so all files earlier than <literal>%r</literal> may be safely removed. This information can be used to truncate the archive to just the minimum required to support restart from the current restore. The <xref linkend="pgarchivecleanup"/> module is often used in <varname>archive_cleanup_command</varname> for single-standby configurations, for example: オプションのパラメータは、すべてのリスタートポイントで実行されるシェルコマンドを指定します。 archive_cleanup_commandの目的は、スタンバイサーバにとって必要とされない古いアーカイブWALファイルをクリーンアップする仕組みを提供することです。 %rは最後の有効なリスタートポイントを含むファイル名に置換されます。 これはリストアが再開可能であるために保持しなければならない最古のファイルで、%rよりも前のすべてのファイルは安全に削除できます。 これは現在のリストアからの再開をサポートするのに最小限必要なアーカイブを残して切り詰めるのに必要な情報として利用できます。 単一のスタンバイ構成用のarchive_cleanup_commandで、たとえば以下のように、しばしばpg_archivecleanupモジュールが使われます。

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

Note however that if multiple standby servers are restoring from the same archive directory, you will need to ensure that you do not delete WAL files until they are no longer needed by any of the servers. <varname>archive_cleanup_command</varname> would typically be used in a warm-standby configuration (see <xref linkend="warm-standby"/>). Write <literal>%%</literal> to embed an actual <literal>%</literal> character in the command. だたし、複数のスタンバイサーバが同じアーカイブディレクトリからリストアしている場合は、どのサーバにおいてももはや必要がなくなるまでWALファイルが削除されることのないようにする必要があることに留意してください。 archive_cleanup_commandは通常ウォームスタンバイ構成で使用されます。 （27.2参照。） %文字自体を埋め込むには%%と書いてください。

If the command returns a nonzero exit status then a warning log message will be written. An exception is that if the command was terminated by a signal or an error by the shell (such as command not found), a fatal error will be raised. コマンドが非ゼロの終了ステータスを返した場合、警告ログメッセージが出力されます。 例外は、コマンドがシグナルで終了されたとき、あるいはシェルがエラーを起こしたとき（コマンドが見つからないなど）で、その場合致命的エラーが生じます。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

This parameter specifies a shell command that will be executed once only at the end of recovery. This parameter is optional. The purpose of the <varname>recovery_end_command</varname> is to provide a mechanism for cleanup following replication or recovery. Any <literal>%r</literal> is replaced by the name of the file containing the last valid restart point, like in <xref linkend="guc-archive-cleanup-command"/>. このパラメータは、リカバリの終了時に一度だけ起動されるシェルコマンドを指定します。 このパラメータはオプションです。 recovery_end_commandの目的はレプリケーションあるいはリカバリの後のクリーンアップのための機構を提供することにあります。 %rは、archive_cleanup_commandと同じように、有効な最後のリスタートポイントを含むWALファイル名に置換されます。

If the command returns a nonzero exit status then a warning log message will be written and the database will proceed to start up anyway. An exception is that if the command was terminated by a signal or an error by the shell (such as command not found), the database will not proceed with startup. コマンドが非ゼロの終了ステータスを返した場合、警告ログメッセージが出力されますが、データベースはスタートアップ処理を続けます。 例外は、コマンドがシグナルによって終了させられたか、シェルによってエラーが発生した（そのようなコマンドは見つからない）場合で、その場合はデータベースはスタートアップ処理を継続させません。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

This parameter specifies that recovery should end as soon as a consistent state is reached, i.e., as early as possible. When restoring from an online backup, this means the point where taking the backup ended. このパラメータは、リカバリが一貫した状態になり次第、すなわちできるだけ早く終了することを指定します。 オンラインバックアップからリストアした場合、これはバックアップが終了した時点を意味します。

Technically, this is a string parameter, but <literal>'immediate'</literal> is currently the only allowed value. 技術的にはこれは文字列型のパラメータですが、現時点では'immediate'だけが許容されている値です。

This parameter specifies the named restore point (created with <function>pg_create_restore_point()</function>) to which recovery will proceed. このパラメータは、指定した（pg_create_restore_point()により作成された）名前付きリストアポイントまでリカバリを進行させます。

This parameter specifies the time stamp up to which recovery will proceed. The precise stopping point is also influenced by <xref linkend="guc-recovery-target-inclusive"/>. このパラメータは、指定したタイムスタンプまでリカバリを進行させます。 正確な停止点はrecovery_target_inclusiveにも影響されます。

The value of this parameter is a time stamp in the same format accepted by the <type>timestamp with time zone</type> data type, except that you cannot use a time zone abbreviation (unless the <xref linkend="guc-timezone-abbreviations"/> variable has been set earlier in the configuration file). Preferred style is to use a numeric offset from UTC, or you can write a full time zone name, e.g., <literal>Europe/Helsinki</literal> not <literal>EEST</literal>. （timezone_abbreviations変数が設定ファイルで先に設定されていない限り）時間帯略語を使えないことを除けば、このパラメータの値はtimestamp with time zoneデータ型が受け付けるのと同じ形式のタイムスタンプです。 おすすめの形式はUTCからのオフセットか、EESTではなくEurope/Helsinkiのような完全な時間帯名です。

This parameter specifies the transaction ID up to which recovery will proceed. Keep in mind that while transaction IDs are assigned sequentially at transaction start, transactions can complete in a different numeric order. The transactions that will be recovered are those that committed before (and optionally including) the specified one. The precise stopping point is also influenced by <xref linkend="guc-recovery-target-inclusive"/>. このパラメータは、指定したトランザクションIDまでリカバリを進行させます。 トランザクションIDはトランザクション起動時に順番に割り当てられますが、トランザクションは数字順によらず完了することがあることに留意してください。 リカバリされるトランザクションは、指定されたものよりも前 (オプションによっては指定されたものも含まれる) にコミットされたものになります。 正確な停止点はrecovery_target_inclusiveにも影響されます。

This parameter specifies the LSN of the write-ahead log location up to which recovery will proceed. The precise stopping point is also influenced by <xref linkend="guc-recovery-target-inclusive"/>. This parameter is parsed using the system data type <link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. このパラメータは、指定した先行書き込みログ(WAL)の場所のLSNまでリカバリを進行させます。 正確な停止点は、recovery_target_inclusiveの影響も受けます。 このパラメータは、 システムデータ型pg_lsnを使用して解析されます。

Specifies whether to stop just after the specified recovery target (<literal>on</literal>), or just before the recovery target (<literal>off</literal>). Applies when <xref linkend="guc-recovery-target-lsn"/>, <xref linkend="guc-recovery-target-time"/>, or <xref linkend="guc-recovery-target-xid"/> is specified. This setting controls whether transactions having exactly the target WAL location (LSN), commit time, or transaction ID, respectively, will be included in the recovery. Default is <literal>on</literal>. 指定したリカバリ対象のちょうど後に停止するか(on)、ちょうどその前に停止するか(off)を指定します。 recovery_target_lsn、recovery_target_time、又はrecovery_target_xidが指定されている場合は適用されます。 この設定は、指定した対象のWALの場所(LSN)、コミット時刻、あるいはトランザクションIDが、それぞれ正確に一致するトランザクションをリカバリに含めるかどうかを制御します。 デフォルトはonです。

Specifies recovering into a particular timeline. The value can be a numeric timeline ID or a special value. The value <literal>current</literal> recovers along the same timeline that was current when the base backup was taken. The value <literal>latest</literal> recovers to the latest timeline found in the archive, which is useful in a standby server. <literal>latest</literal> is the default. リカバリが作成する個別のタイムラインを指定します。 値は数値のタイムラインIDか、特殊な値です。 currentでは、ベースバックアップが取得されたときにカレントだったタイムラインに沿ってリカバリします。 latestでは、アーカイブ時に見つけた最新のタイムラインにリカバリします。これはスタンバイサーバで有用です。 デフォルトはlatestです。

To specify a timeline ID in hexadecimal (for example, if extracted from a WAL file name or history file), prefix it with a <literal>0x</literal>. For instance, if the WAL file name is <filename>00000011000000A10000004F</filename>, then the timeline ID is <literal>0x11</literal> (or 17 decimal). タイムラインIDを16進数で指定するには(たとえば、WALファイル名前または歴史ファイルから抽出した場合)、0xを前に置きます。 例として、WALファイル名前が00000011000000A10000004Fであれば、タイムラインIDは0x11(または10進数で17)になります。

You usually only need to set this parameter in complex re-recovery situations, where you need to return to a state that itself was reached after a point-in-time recovery. See <xref linkend="backup-timelines"/> for discussion. 通常このパラメータの設定が必要となるのは、ポイントインタイムリカバリの実施後に到達した状態に戻す場合など、複雑なリカバリの状況のみです。 この論考については26.3.5を参照してください。

Specifies what action the server should take once the recovery target is reached. The default is <literal>pause</literal>, which means recovery will be paused. <literal>promote</literal> means the recovery process will finish and the server will start to accept connections. Finally <literal>shutdown</literal> will stop the server after reaching the recovery target. リカバリ対象に到達した場合に、サーバがする動作を指定します。 デフォルトはpauseで、リカバリを休止することを意味します。 promoteは、リカバリの過程が終われば、サーバは接続の受け付けを始めることを意味します。 最後に、shutdownは、リカバリ対象に到達した後にサーバを停止します。

The intended use of the <literal>pause</literal> setting is to allow queries to be executed against the database to check if this recovery target is the most desirable point for recovery. The paused state can be resumed by using <function>pg_wal_replay_resume()</function> (see <xref linkend="functions-recovery-control-table"/>), which then causes recovery to end. If this recovery target is not the desired stopping point, then shut down the server, change the recovery target settings to a later target and restart to continue recovery. pauseの設定の意図した使い方は、このリカバリ対象がリカバリのための最も望ましいポイントかどうかチェックするために、データベースに対して問い合わせを実行できるようにすることです。 休止された状態は、pg_wal_replay_resume()(表 9.93参照)の使用により再開することができます。 その後、それはリカバリを終了させます。 このリカバリ対象が希望の止まるポイントでない場合、サーバをシャットダウンし、リカバリ対象の設定をより後の対象に変更し、リカバリを継続するために再起動してください。

The <literal>shutdown</literal> setting is useful to have the instance ready at the exact replay point desired. The instance will still be able to replay more WAL records (and in fact will have to replay WAL records since the last checkpoint next time it is started). shutdownの設定はインスタンスを正確に望ましい再生ポイントで準備するのに有用です。 インスタンスはさらに多くのWALレコードを再生できます(実際、次に起動するときには最後のチェックポイントからWALレコードを再生しなければなりません)。

Note that because <filename>recovery.signal</filename> will not be removed when <varname>recovery_target_action</varname> is set to <literal>shutdown</literal>, any subsequent start will end with immediate shutdown unless the configuration is changed or the <filename>recovery.signal</filename> file is removed manually. recovery.signalはrecovery_target_actionがshutdownに設定されていると削除されないことに留意してください。 設定が変更されるか、recovery.signalが手動で削除されない限り、以降起動しても直ちに停止されてしまいます。

This setting has no effect if no recovery target is set. If <xref linkend="guc-hot-standby"/> is not enabled, a setting of <literal>pause</literal> will act the same as <literal>shutdown</literal>. If the recovery target is reached while a promotion is ongoing, a setting of <literal>pause</literal> will act the same as <literal>promote</literal>. この設定はリカバリ対象が設定されていない場合には効果がありません。 hot_standbyが有効になっていない場合、pauseの設定はshutdownと同じように動作します。 昇格中にリカバリ対象に到達した場合は、pauseはpromoteと同じように働きます。

In any case, if a recovery target is configured but the archive recovery ends before the target is reached, the server will shut down with a fatal error. どのような場合でも、リカバリ対象が設定されていて、アーカイブリカバリがそのリカバリ対象に到達する前に終了すると、サーバはフェイタルエラーで停止します。