<firstterm>Asynchronous commit</firstterm> is an option that allows transactions to complete more quickly, at the cost that the most recent transactions may be lost if the database should crash. In many applications this is an acceptable trade-off. 非同期コミットとは、トランザクションをより高速に完了することができるオプションです。 もっとも最近のトランザクションがデータベースがクラッシュしてしまった場合に失われるという危険があります。 これは、多くのアプリケーションで受け入れられるトレードオフです。

As described in the previous section, transaction commit is normally <firstterm>synchronous</firstterm>: the server waits for the transaction's <acronym>WAL</acronym> records to be flushed to permanent storage before returning a success indication to the client. The client is therefore guaranteed that a transaction reported to be committed will be preserved, even in the event of a server crash immediately after. However, for short transactions this delay is a major component of the total transaction time. Selecting asynchronous commit mode means that the server returns success as soon as the transaction is logically completed, before the <acronym>WAL</acronym> records it generated have actually made their way to disk. This can provide a significant boost in throughput for small transactions. 前節で説明した通り、通常トランザクションのコミットは同期的です。 サーバはトランザクションのWALレコードが永続的格納領域にフラッシュされるまで、クライアントに成功したことを通知することを待機します。 従って、直後にサーバクラッシュといった障害があったとしても、コミットされたと報告されたトランザクションは保持されることをクライアントは保証されます。 しかし、短期のトランザクションでは、この遅延はトランザクションの処理時間の大半を占める要素となります。 非同期コミットモードを選択することは、サーバがWALレコードが実際に作成された通りにディスクに書き込まれるより前に、トランザクションの論理的な完了をもって成功したと通知することを意味します。 これにより、小規模なトランザクションでスループットがかなり向上します。

Asynchronous commit introduces the risk of data loss. There is a short time window between the report of transaction completion to the client and the time that the transaction is truly committed (that is, it is guaranteed not to be lost if the server crashes). Thus asynchronous commit should not be used if the client will take external actions relying on the assumption that the transaction will be remembered. As an example, a bank would certainly not use asynchronous commit for a transaction recording an ATM's dispensing of cash. But in many scenarios, such as event logging, there is no need for a strong guarantee of this kind. 非同期コミットにはデータ損失の危険があります。 トランザクションの完了をクライアントに通知してからトランザクションが本当に完了する（つまり、サーバクラッシュしても損失がないことが保証される）までの間にわずかな時間が存在します。 したがって、クライアントがトランザクションが記録されているという仮定を元に外部的な動作を行う場合は、非同期コミットを使用すべきではありません。 例えば、銀行では、ATMの現金支払を記録するトランザクションで非同期コミットを決して使用していないでしょう。 しかし、イベントロギングなど多くのシナリオでは、この種の強力な保証は必要ありません。

The risk that is taken by using asynchronous commit is of data loss, not data corruption. If the database should crash, it will recover by replaying <acronym>WAL</acronym> up to the last record that was flushed. The database will therefore be restored to a self-consistent state, but any transactions that were not yet flushed to disk will not be reflected in that state. The net effect is therefore loss of the last few transactions. Because the transactions are replayed in commit order, no inconsistency can be introduced &mdash; for example, if transaction B made changes relying on the effects of a previous transaction A, it is not possible for A's effects to be lost while B's effects are preserved. 非同期コミットによりもたらされる危険性は、データの破損ではなくデータの損失です。 データベースがクラッシュした場合、最後にフラッシュされた記録までWALを再生することで復旧が行われます。 このため、データベースは内部で一貫性を持った状態に復旧されますが、ディスクにフラッシュされていないトランザクションはすべてそこには反映されません。 したがって、影響を受けるのは、最後に行われたいくつかのトランザクションの損失です。 トランザクションはコミットされた順に再生されますので、一貫性が失われることはありません。 例えば、トランザクションBが以前に行われたトランザクションAの結果に依存した変更を行った場合、Bの影響が保存されている限り、Aの影響が失われることは起こり得ません。

The user can select the commit mode of each transaction, so that it is possible to have both synchronous and asynchronous commit transactions running concurrently. This allows flexible trade-offs between performance and certainty of transaction durability. The commit mode is controlled by the user-settable parameter <xref linkend="guc-synchronous-commit"/>, which can be changed in any of the ways that a configuration parameter can be set. The mode used for any one transaction depends on the value of <varname>synchronous_commit</varname> when transaction commit begins. ユーザは各トランザクションでコミットモードを選択することができます。 このため、同時実行されるトランザクションを同期的、および非同期の両方でコミットさせることができます。 これにより、性能とトランザクションの信頼性の確実性との間で柔軟な選択を行うことができます。 コミットモードはユーザによる設定が可能なパラメータsynchronous_commitで制御されます。 このパラメータは、設定パラメータを設定することができる全ての方法で変更することが可能です。 あるひとつのトランザクションで使用されるモードは、トランザクションのコミットが始まった時のsynchronous_commitの値に依存します。

Certain utility commands, for instance <command>DROP TABLE</command>, are forced to commit synchronously regardless of the setting of <varname>synchronous_commit</varname>. This is to ensure consistency between the server's file system and the logical state of the database. The commands supporting two-phase commit, such as <command>PREPARE TRANSACTION</command>, are also always synchronous. 例えばDROP TABLEなどの特定のユーティリティコマンドでは、synchronous_commitの設定に関わらず、強制的に同期的コミットが行われます。 これにより、サーバのファイルシステムとデータベースの論理的な状態との間の一貫性が保証されます。 PREPARE TRANSACTIONなどの二相コミットをサポートするコマンドもまた、常に同期的です。

If the database crashes during the risk window between an asynchronous commit and the writing of the transaction's <acronym>WAL</acronym> records, then changes made during that transaction <emphasis>will</emphasis> be lost. The duration of the risk window is limited because a background process (the <quote>WAL writer</quote>) flushes unwritten <acronym>WAL</acronym> records to disk every <xref linkend="guc-wal-writer-delay"/> milliseconds. The actual maximum duration of the risk window is three times <varname>wal_writer_delay</varname> because the WAL writer is designed to favor writing whole pages at a time during busy periods. もし非同期コミットとそのトランザクションのWALレコードの書き込みの間の危険期間にデータベースがクラッシュしたとすると、そのトランザクションでなされた変更は失われるでしょう。 バックグラウンドプロセス（「WALライタ」）が未書き込みのWALレコードをwal_writer_delayミリ秒毎にディスクにフラッシュしますので、この危険期間は制限されます。 WALライタは稼働中に一回ページ全体を書き込むように設計されているため、危険期間の実際の最大の長さはwal_writer_delayの３倍です。

Asynchronous commit provides behavior different from setting <xref linkend="guc-fsync"/> = off. <varname>fsync</varname> is a server-wide setting that will alter the behavior of all transactions. It disables all logic within <productname>PostgreSQL</productname> that attempts to synchronize writes to different portions of the database, and therefore a system crash (that is, a hardware or operating system crash, not a failure of <productname>PostgreSQL</productname> itself) could result in arbitrarily bad corruption of the database state. In many scenarios, asynchronous commit provides most of the performance improvement that could be obtained by turning off <varname>fsync</varname>, but without the risk of data corruption. 非同期コミットではfsync = offという設定とは異なる動作になります。 fsyncはサーバ全体に関する設定であり、すべてのトランザクションの動作を変更します。 これは、PostgreSQLにおける、データベースの様々な場所への書き込みを同期しようとするすべてのロジックを無効にします。 このため、システムクラッシュ（PostgreSQL自体の障害ではなくハードウェアやオペレーティングシステムのクラッシュ）の結果、予測できないデータベース状態の破損が起こります。 非同期コミットはデータ破損の危険性はなく、多くの状況ではfsyncを無効にした場合に得られる性能向上とほぼ同等の性能を提供します。

<xref linkend="guc-commit-delay"/> also sounds very similar to asynchronous commit, but it is actually a synchronous commit method (in fact, <varname>commit_delay</varname> is ignored during an asynchronous commit). <varname>commit_delay</varname> causes a delay just before a transaction flushes <acronym>WAL</acronym> to disk, in the hope that a single flush executed by one such transaction can also serve other transactions committing at about the same time. The setting can be thought of as a way of increasing the time window in which transactions can join a group about to participate in a single flush, to amortize the cost of the flush among multiple transactions. またcommit_delayも非同期コミットと類似のように見えますが、これは実のところ同期コミットの一方法です。 （実際、非同期コミット時commit_delayは無視されます。） トランザクションがWALをディスクにフラッシュする直前に、こうしたトランザクションによって実行される一度のフラッシュにより、ほぼ同時期にコミットを行う他のトランザクションの分も処理できるようにすることを目的とした遅延がcommit_delayにより発生します。 この設定は、複数のトランザクションの中でフラッシュのコストを償却するために、トランザクションが一回のフラッシュに参加しようとするグループに参加できる時間的猶予を広げる方法として考えることができます。