# 6.2.1 The Pocket Diary (WAL I/O)  While most read waits are caused by missing pages in memory, write waits are often tied to the engine's strict durability guarantees. ## The Durable Write (WAL) Before a process can confirm that a transaction has committed, it must ensure that the change is written to the **Write-Ahead Log (WAL)**. As detailed in **[[Chapter 4/4.1 - The Pocket Diary (WAL & fsync)|Chapter 4]]**, this append-only stream is the single source of truth for crash recovery. Writing to the WAL is sequential, but it must be made durable to the physical medium. - **`IO:WALWrite`**: The process has finished its work and is currently waiting for the drive controller to acknowledge the write of a WAL record. - **`IO:WALSync`**: The physical confirmation process where the engine forces the OS kernel to flush its caches to the hardware (via `fsync`). If your workload is dominated by `WAL` wait events, your transaction throughput is limited by the latency of your storage hardware. This is common in "High-Commit" workloads where thousands of small transactions are processed per second. To optimize this, you can move the `pg_wal` directory to a dedicated, high-performance NVMe disk, or use **Asynchronous Commits** (`synchronous_commit = off`) which allows the engine to acknowledge the transaction before the `fsync` completes—accepting a small window of data loss risk in exchange for massive throughput gains. > [!info] Diagnostics: WAL Write Latency > To see the full taxonomy of ledger stalls—including initialization and synchronization waits—browse the **[[Workloads/IO/WAL/_WAL|WAL I/O Event Library]]**. --- | ← Previous | ↑ Table of Contents | Next → | | :--- | :---: | ---: | | [[Chapter 6/6.2 - The Elevator Queue (Disk Wait)\|6.2 The Elevator Queue (Disk Wait)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 6/6.2.2 - The Infrastructure Ledgers (Metadata & SLRU)\|6.2.2 The Infrastructure Ledgers (Metadata & SLRU)]] |