9.9. WAL Segment Files Management
PostgreSQL writes XLOG records to WAL segment files stored in the pg_wal subdirectory (named pg_xlog in versions 9.6 or earlier). A new WAL segment file is switched in whenever the current file is filled. The number of WAL files varies based on configuration parameters and server activity.
Starting with version 9.4, Replication Slots can also control the number of WAL files based on replication status. Furthermore, version 9.5 introduced improvements to the management policy for WAL segment files.
The following subsections describe WAL segment file switching and basic management methods.
9.9.1. WAL Segment Switches
WAL segment switches occur when any of the following events happen:
- A WAL segment is filled.
- The function pg_switch_wal() (or pg_switch_xlog() in older versions) is called.
- The archive_mode parameter is enabled and the archive_timeout interval has expired.
When a WAL segment file is switched, PostgreSQL usually recycles it (renames and reuses it) for future use. However, the file may be removed later if it is no longer needed.
9.9.2. WAL Segment Management
Whenever a checkpoint starts, PostgreSQL estimates and prepares the number of WAL segment files needed for the next checkpoint cycle. This estimate is based on the WAL consumption in previous checkpoint cycles.
The count of WAL segment files starts from the segment containing the REDO point. This value must be between min_wal_size (defaulting to 80 MB, or 5 files) and max_wal_size (defaulting to 1 GB, or 64 files).
When a checkpoint starts, PostgreSQL keeps or recycles the necessary WAL segment files and removes any unnecessary ones.
Figure 9.23 shows a specific example.
Assume six WAL segment files exist before a checkpoint starts, and WAL_3 contains the REDO point. If PostgreSQL estimates that five files are needed, WAL_1 is renamed to WAL_7 for recycling, and WAL_2 is removed.
Files older than the one containing the REDO point can be removed because the recovery mechanism described in Section 9.8 never requires them.
Figure 9.23. Recycling and removing WAL segment files at a checkpoint.
If a spike in WAL activity requires more segments, PostgreSQL creates new WAL segment files as long as the total size remains below max_wal_size.
For example, in Figure 9.24, if WAL_7 is filled, WAL_8 is newly created.
Figure 9.24. Creating WAL segment file.
The number of WAL segment files adapts to server activity. If the WAL write rate increases constantly, the estimated number of files and the total size gradually increase. Conversely, if the write rate decreases, these values decrease.
If the total size of the WAL segment files exceeds max_wal_size, a checkpoint starts. Figure 9.25 illustrates this situation. During the checkpoint, a new REDO point is created and the old REDO point is discarded; then, unnecessary old WAL segment files are recycled. In this way, PostgreSQL maintains only the WAL segment files required for database recovery.
Figure 9.25. Checkpointing and recycling WAL segment files.
9.9.2.1. Other Factors
The wal_keep_size parameter (or wal_keep_segments in versions 12 or earlier) and the replication slot feature also affect the number of WAL segment files.