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