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