pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
从 7.1 版开始 WAL 自动启用。管理员 无需任何操作， 只需确保满足 WAL 日志的额外 磁盘空间需求， 并完成必要的调优（见 第 9.3 节）。
WAL 日志存储在目录 $PGDATA/pg_xlogaccess/xlog.h 中描述；记录内容 取决于所记录事件的 类型。段文件以 顺序数字命名，从 0000000000000000 开始。目前 数字不会回绕，但 用尽可用数字也需要非常长的 时间。
WAL 缓冲区和控制结构位于 共享内存中，由后端处理；它们 由自旋锁保护。对共享内存的 需求取决于 缓冲区的数量；WAL 缓冲区的默认 大小是 64 kB。
如果日志与 主数据库文件位于不同的 磁盘上会更有利。这可以通过把目录 pg_xlog 移到另一个位置（当然要在 postmaster 关闭时）并从 $PGDATA 中的原位置创建指向 新位置的符号链接来 实现。
The aim of WAL, to ensure that the log is written before database records are altered, may be subverted by disk drives that falsely report a successful write to the kernel, when, in fact, they have only cached the data and not yet stored it on the disk. A power failure in such a situation may still lead to 不可恢复的数据损坏；管理员应尽量确保 存放 PostgreSQL 数据和 日志文件的磁盘不做 这样的虚假报告。
After a checkpoint has been made and the log flushed, the checkpoint's position is saved in the file pg_control. Therefore, when recovery is to be 时，后端先读取 pg_control 和 检查点记录；接着读取其位置保存在 检查点中的重做记录，并开始 REDO 操作。 因为检查点后第一次 修改页时页面的完整内容都保存在 日志中，页面将先被 恢复到一致的状态。
Using pg_control to get the checkpoint position speeds up the recovery process, but to handle possible corruption of pg_control, we should actually 实现以相反顺序——从最新到 最旧——读取现有日志段来找到 最后一个检查点。这一点在 7.1 版中尚未 完成。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。