<acronym>WAL</acronym> is automatically enabled; no action is required from the administrator except ensuring that the disk-space requirements for the <acronym>WAL</acronym> files are met, and that any necessary tuning is done (see <xref linkend="wal-configuration"/>). WALは自動的に有効になります。 WALファイルが必要とするディスク容量を確保することと、必要なチューニングを実施すること（30.5を参照）以外は、管理者は何もする必要はありません。
<acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
files as each new record is written. The insert position is described by
a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
the WAL, increasing monotonically with each new record.
<acronym>LSN</acronym> values are returned as the datatype
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. Values can be
compared to calculate the volume of <acronym>WAL</acronym> data that
separates them, so they are used to measure the progress of replication
and recovery.
新しいレコードが作成されるごとに、WALレコードがWALファイルに追加されます。
挿入位置はログシーケンス番号(LSN)によって記録されます。LSNはWALのバイトオフセットで、新しいレコードごとに単調増加します。
LSN値は、pg_lsnデータ型として返されます。
2つのLSN値を比較することでWALデータの差分量を計算することができるので、レプリケーションやリカバリの進捗状況を測定できます。
<acronym>WAL</acronym> files are stored in the directory
<filename>pg_wal</filename> under the data directory, as a set of
segment files, normally each 16 MB in size (but the size can be changed
by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is
divided into pages, normally 8 kB each (this size can be changed via the
<option>--with-wal-blocksize</option> configure option). The WAL record headers
are described in <filename>access/xlogrecord.h</filename>; the record
content is dependent on the type of event that is being logged. Segment
files are given ever-increasing numbers as names, starting at
<filename>000000010000000000000001</filename>. The numbers do not wrap,
but it will take a very, very long time to exhaust the
available stock of numbers.
WALファイルは、データディレクトリ以下のpg_walディレクトリに、通常16メガバイトのサイズを持つセグメントファイルの集合として格納されています(ただし、このサイズはinitdbの--wal-segsizeオプションで変更できます)。
各セグメントは通常8キロバイトのページに分割されます(このサイズは--with-wal-blocksizeというconfigureオプションで変更できます)。
WALレコード用のヘッダはaccess/xlogrecord.hに記述されています。レコードの内容は、ログの対象となるイベントの種類によって異なります。
セグメントファイルは名前として000000010000000000000001から始まる、常に増加する数が与えられています。
数字は巡回しませんが、利用可能な数字を使い尽くすには非常に長い時間がかかるはずです。
It is advantageous if the WAL is located on a different disk from the
main database files. This can be achieved by moving the
<filename>pg_wal</filename> directory to another location (while the server
is shut down, of course) and creating a symbolic link from the
original location in the main data directory to the new location.
主要なデータベースファイルが置いてあるディスクとは別のディスクにWALを置くと利点があります。
これはpg_walディレクトリを別の場所に（もちろんサーバを終了しておいてから）移動し、主データディレクトリ以下の元々の場所から新しい場所へのシンボリックリンクを張ることによって可能となります。
The aim of <acronym>WAL</acronym> is to ensure that the log is written before database records are altered, but this can be subverted by disk drives<indexterm><primary>disk drive</primary></indexterm> that falsely report a successful write to the kernel, when in fact they have only cached the data and not yet stored it on the disk. A power failure in such a situation might lead to irrecoverable data corruption. Administrators should try to ensure that disks holding <productname>PostgreSQL</productname>'s <acronym>WAL</acronym> files do not make such false reports. (See <xref linkend="wal-reliability"/>.) WALの目的である、確実にデータベースレコードが変更される前にログが書き出されることは、実際にはキャッシュにしかデータがなく、ディスクには格納されていない時にディスクドライブが格納に成功したとカーネルに虚偽の報告を行うことによって失われる可能性があります。 そのような状況では、電源が落ちた際に、復旧不可能なデータ破損が起こることがあります。 管理者は、PostgreSQLのWALファイルを保持しているディスク装置がそのような嘘の報告をしないように保証するべきです。(30.1を参照して下さい。)
After a checkpoint has been made and the WAL flushed, the
checkpoint's position is saved in the file
<filename>pg_control</filename>. Therefore, at the start of recovery,
the server first reads <filename>pg_control</filename> and
then the checkpoint record; then it performs the REDO operation by
scanning forward from the WAL location indicated in the checkpoint
record. Because the entire content of data pages is saved in the
WAL on the first page modification after a checkpoint (assuming
<xref linkend="guc-full-page-writes"/> is not disabled), all pages
changed since the checkpoint will be restored to a consistent
state.
チェックポイントが実行され、WALがフラッシュされた後、チェックポイントの位置はpg_controlに保存されます。
したがって、リカバリの開始時は、サーバはまずpg_controlを読み、次にチェックポイントレコードを読みます。
そして、チェックポイントレコード内で示されたWALの位置から前方にスキャンしてREDO処理を行います。
データページの内容全体は、チェックポイント後の最初のページ変更時にWAL内に保存されますので(full_page_writesパラメータが無効にされていないという前提です)、そのチェックポイント以降に変更された全てのページは一貫した状態に復旧されます。
To deal with the case where <filename>pg_control</filename> is
corrupt, we should support the possibility of scanning existing WAL
segments in reverse order — newest to oldest — in order to find the
latest checkpoint. This has not been implemented yet.
<filename>pg_control</filename> is small enough (less than one disk page)
that it is not subject to partial-write problems, and as of this writing
there have been no reports of database failures due solely to the inability
to read <filename>pg_control</filename> itself. So while it is
theoretically a weak spot, <filename>pg_control</filename> does not
seem to be a problem in practice.
pg_controlが壊れた場合に備え、既存のWALセグメントを逆順に読み（すなわち新しいものから古いものへと）、最終チェックポイントを見つける方法を実際には実装した方が良いと思われます。
まだこれはできていません。
pg_controlはかなり小さなもの（1ディスクページ未満）ですので、一部のみ書き込みされるという問題は起こりません。
またこの書き込みの時点では、pg_control自体の読み込みができないことによるデータベースエラーという報告はありません。
このため、pg_controlは理屈では弱点ですが、実質問題になりません。