WALは7.1以降では自動的に有効になります。WALログが必要とする追加ディスク容量を確保すること、そして必要ならばチューニングすることを除いては（Section 12.3を参照）、システム管理者は何もする必要はありません。
WALは $PGDATA/pg_xlogディレクトリに、16Mバイトのサイズをもつセグメントファイルの集合として格納されています。セグメントは8Kバイトのページに分割されます。ログレコード用のへッダはaccess/xlog.hに記述されています。 レコードの内容は、ログの対象となる事象のタイプによって異なります。セグメントファイルは名前として0000000000000000からはじまる、常に増加する数が与えられています。いまのところ、数字は巡回しませんが、利用可能な数字を使い尽くすには非常に長い時間がかかるはずです。
WALバッファとその制御用構造体は共有メモリ上にあり、バックエンドが使用します。 保護は軽量ロックで行います。必要な共有メモリの量はバッファの数によります。WALバッファの大きさはデフォルトで、8 kバイトのバッファが 8 個、つまり、全体で64Kバイトです。
主要なデータベースファイルが置いてあるディスクとは別のディスクにログを置くと利点があります。これはpg_xlogディレクトリを別の場所に（もちろんpostmasterを終了しておいてから）移動し、$PGDATAの元々の場所からシンボリックリンクを張ることによって可能となります。
WALの目的は、データベースレコードが変更される前、つまり、実際にはディスクドライブのキャッシュにデータがあり、まだディスクに書き込まれていないのに、書き込みが成功したと嘘の報告をカーネルにするようなディスクドライブによってデータが破壊される可能性がある前に、ログが書き込まれることを保証することにあります。そのような情況では、電源が落ちた際に、復旧不可能なデータの破壊が起ることがあります。システム管理者は、PostgreSQLのログを保持しているディスク装置がそのような嘘の報告をしないように保証するべきです。
チェックポイントが実行され、ログがフラッシュされた後、チェックポイントの位置はpg_controlに保存されます。したがって、データ回復を行う場合はバックエンドはまずpg_controlを読み、次にチェックポイントレコードを読みます。 そして、チェックポイントレコード内で示されたログの位置から前方をスキャンすることで REDO 処理を行います。データページの内容全体は、チェックポイント後の最初の変更されたページのログ内にありますので、そのチェックポイント以降に変更された全てのページは最初に一貫した状態に復旧されます。
pg_controlのチェックポイント位置を使うことによって回復処理の速度は早くなりますが、pg_controlが壊れた場合に備え、ログセグメントを逆順に読み（すなわち新しいものから古いものへと）、最終チェックポイントを見付ける方法を実際には実装した方がよいと思われます。まだこれはできていません。