<firstterm>Write-Ahead Logging</firstterm> (<acronym>WAL</acronym>) is a standard method for ensuring data integrity. A detailed description can be found in most (if not all) books about transaction processing. Briefly, <acronym>WAL</acronym>'s central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after WAL records describing the changes have been flushed to permanent storage. If we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages can be redone from the WAL records. (This is roll-forward recovery, also known as REDO.) ログ先行書き込み（WAL）はデータの一貫性を確実にするための標準的な手法です。 詳細については、トランザクション処理について書かれた(すべてとは言いませんが)たいていの書籍に記載されています。 簡単に言うと、WALの基本的な考え方は、(テーブルやインデックスがある)データファイルへの変更は、ログへの記録、つまり、変更内容を記述したWALレコードが永続格納領域にフラッシュされた後にのみ書き出されなければならないということです。 このような手順に従って処理を行えば、たとえクラッシュが起きてもログを使ってデータベースをリカバリすることができるため、トランザクションのコミットの度にデータページをディスクにフラッシュする必要がなくなります。 リカバリの時点でデータページに対してまだ行われていない変更分は、WALレコードを使って再実行されます（これがREDOとして知られているロールフォワードリカバリです）。

Using <acronym>WAL</acronym> results in a significantly reduced number of disk writes, because only the WAL file needs to be flushed to disk to guarantee that a transaction is committed, rather than every data file changed by the transaction. The WAL file is written sequentially, and so the cost of syncing the WAL is much less than the cost of flushing the data pages. This is especially true for servers handling many small transactions touching different parts of the data store. Furthermore, when the server is processing many small concurrent transactions, one <function>fsync</function> of the WAL file may suffice to commit many transactions. WALを使用することでディスクへの書き込み回数が大幅に減少します。 と言うのも、トランザクションがコミットされたことを保証するために、そのトランザクションで変更された全てのデータファイルではなく、WALファイルだけをディスクにフラッシュする必要があるからです。 WALファイルへの書き込みはシーケンシャルに行われるため、データページをフラッシュするコストに比べWALの同期はずっと低コストになります。 これは特に、データ格納領域の様々な部分を変更する小さなトランザクションを多く扱うサーバで顕著に現れます。 さらに、サーバが小規模なトランザクションを同時に多く処理する時、WALファイルを一度fsyncすることで、多くのトランザクションをコミットすることができる場合もあります。

<acronym>WAL</acronym> also makes it possible to support on-line backup and point-in-time recovery, as described in <xref linkend="continuous-archiving"/>. By archiving the WAL data we can support reverting to any time instant covered by the available WAL data: we simply install a prior physical backup of the database, and replay the WAL just as far as the desired time. What's more, the physical backup doesn't have to be an instantaneous snapshot of the database state &mdash; if it is made over some period of time, then replaying the WAL for that period will fix any internal inconsistencies. また、WALにより、26.3で説明するオンラインバックアップとポイントインタイムリカバリをサポートできます。 WALのデータを保持することにより、そのWALデータが範囲内とする任意の時点に戻すことができます。 単純にデータベースの主となる物理バックアップをインストールし、WALを目的の時点まで単に再生することで実現できます。 さらに、物理バックアップはインスタンス化可能なデータベース状態のスナップショットである必要もありません。 ある程度の時間を経過して作成されたバックアップであっても、その期間用のWALを再生することにより、内部の不整合を修復します。