在前面我们了解了PG数据库的故障恢复依赖于在启动时通过回放WAL段文件中的XLOG记录来完成，这篇我们学习一下PG数据库中WAL段文件是怎么管理的。
首先，我们需要知道WAL段文件是保存在pxg_xlog（PG V10版本以前，在PG V10版本以后变成 pg_wal）子目录下，如果一个WAL段文件写满后就会切换到一个新的段文件。总的WAL段文件个数由几个配置参数决定的。此外，对于WAL段文件的管理机制在PG 9.5版本得到了提升。
WAL段的切换
WAL段会在以下几种情况下发生切换：
- 一个WAL段文件被写满。
- 调用pg_switch_xlog函数。
- 开启archive_mode，且设置的archive_timeout达到超时时间。
被切换的文件经常会被回收（重命名并重新使用），不过如果不是必要的话也有可能被删除。
WAL段管理
当一个checkpoint开始时，数据库会评估并准备这一次checkpoint过程需要的WAL段文件个数。这个评估是根据之前checkpoint使用的文件数做出来的。他们从包含前一个REDO point的段开始算，值需要在min_wal_size（默认80MB，如5个文件）和max_wal_size（1GB，如64个文件）。当checkpoint开始，必要的文件会被保留或回收，不必要的文件会被删除。
以下是一个具体的例子。假如checkpoint开始前有6个WAL段文件，WAL_3包含上一个REDO point（在PG11及后面版本就是REDO point，因为已经没有prior REDO point），数据库在checkpoint开始时评估需要5个文件。此时，WAL_1会被重命名为WAL_7回收利用而WAL_2会被删除。
如果评估需要更多的文件，新的文件会被创建出来，总的WAL文件大小不能超过max_wal_size。比如下面例子，如果WAL_7被写满，WAL_8就会被创建出来。
根据服务的活跃情况WAL文件的个数会自适应地变化。如果WAL数据会持续的写并一直增长，那么评估出来的WAL段文件以及WAL文件的总尺寸也会相应的增长。相反，他们就会下降。
如果总的WAL文件大小超过了max_wal_size，就会开始一个checkpoint动作。通过checkpoint，一个新的REDO point被创建，然后上一个REDO point变成之前的，之后不必要的老的文件就会被回收。通过这种方式，PG总能够持有数据库恢复所需要的WAL段文件。
配置参数wal_keep_size（在PG 12或早期称为wal_keep_segments）也会影响WAL段文件的个数。
连续归档及归档日志
连续归档（Continuous Archiving）是一个新功能，在WAL段进行切换的时候将WAL段文件拷贝到归档路径，通过后台archiver进程来执行。被复制的文件也被称为archive log。这个功能经常会被用于物理备份以及PITR时间点恢复。
归档路径由参数archive_command控制，如：
archive_command = 'cp %p /home/postgres/archives/%f'
如上图所示，当WAL_7切换时，这个文件就会归档到归档目录下面，即Archive log 7。
在PG 14或早期版本，连接归档只能使用shell命令。在PG 15中，PG支持了一个可加载库功能来归档日志。
