有若干影响数据库性能的与 WAL 相关的 参数。本节说明它们的用法。 设置配置参数的详情请 查阅 第 3.4 节。

有两个常用的 WAL 函数： LogInsert 和 LogFlush。 LogInsert 用于把一条新记录放入 共享内存中的 WAL 缓冲区。如果 没有空间放新记录，LogInsert 就 不得不写出（移入内核缓存）几个已满的 WAL 缓冲区。这并 不理想，因为 LogInsert 在每次数据库低层修改（例如 元组插入）时都会被使用，而那时 受影响的数据页上正持有排他锁， 因此该操作需要尽可能 快。更糟的是，写出 WAL 缓冲区还 可能迫使创建新的日志段，这需要 更多 时间。正常情况下，WAL 缓冲区应当由 LogFlush 请求写出并 刷写，该请求大部分 在事务提交时发出，以确保 事务记录被刷写到永久存储。在日志 输出很高的系统上，LogFlush 请求 可能不够频繁，无法阻止 WAL 缓冲区被 LogInsert 写出。在这样的系统上， 应当通过修改 postgresql.conf 的 WAL_BUFFERS 参数来增加 WAL 缓冲区的数量。 WAL 缓冲区的默认 数量是 8。增大这个值将 相应地增加共享内存的使用。

检查点 是事务序列中 保证数据文件已用检查点之前记录的 所有信息更新过的点。在 检查点时刻，所有脏数据页被刷写到磁盘， 并向日志文件写入一条 特殊的检查点记录。结果是，一旦 发生崩溃，恢复者就知道应从日志中的 哪条记录（称为重做记录）开始 REDO 操作，因为在该记录之前 对数据文件所做的任何更改都已在 磁盘上。做完检查点之后，undo 记录之前写入的任何日志段都不再 需要并可被回收或 删除。（当实现了基于 WAL 的 BAR 时， 日志段在回收或删除之前会被 归档。）

检查点生成器还能为 将来的使用创建几个日志段，以避免 LogInsert 或 LogFlush 花时间创建它们。（如果发生那种情况，整个 数据库系统都会被创建操作拖延，所以 最好由不处于任何人关键路径上的 检查点生成器来创建 这些文件。）默认情况下，只有当前 段用了超过 75% 时才创建新的 16MB 段文件。如果系统在检查点之间 产生超过 4MB 的日志输出，这就 不够了。可以通过修改配置参数 WAL_FILES 让服务器 在检查点时预创建最多 64 个 日志段。

postmaster 每隔一段时间派生一个专门的 后端进程来创建下一个检查点。每 CHECKPOINT_SEGMENTS 个日志段 或每 CHECKPOINT_TIMEOUT 秒 （以先到者为准）创建一个 检查点。默认设置分别是 3 段和 300 秒。 也可以用 SQL 命令 CHECKPOINT 强制 检查点。

减小 CHECKPOINT_SEGMENTS 和/或 CHECKPOINT_TIMEOUT 会使检查点 更频繁。这可以让崩溃后恢复更快（因为 需要重做的工作更少）。但必须把这 与更频繁地刷写脏数据页的 增加的成本相权衡。此外， 为确保数据页一致性，每个 检查点后对数据页的第一次修改会导致 记录整个页面 内容。因此更小的检查点间隔会增加 日志输出量，部分抵消了使用更小 间隔的目的，而且无论如何都会 造成更多磁盘 I/O。

16MB 段文件的 数量总是至少 WAL_FILES + 1 个，通常 不会超过 WAL_FILES + MAX(WAL_FILES, CHECKPOINT_SEGMENTS) + 1 个。这可以用来 估算 WAL 的空间需求。通常，当旧的日志 段文件不再需要时，它们会被回收（改名为 将来的下一个顺序段）。如果由于日志输出 率的短期峰值，段文件超过了 WAL_FILES + MAX(WAL_FILES, CHECKPOINT_SEGMENTS) + 1 个， 不需要的段文件将被删除而不是 回收，直到系统回到该限制 之内。（如果这种情况经常发生， 应当增大 WAL_FILES 来 避免。删除以后 还得重新创建的日志段既昂贵又 无意义。）

COMMIT_DELAY 参数定义 后端在用 LogInsert 把提交 记录写入日志之后、 执行 LogFlush 之前 休眠多少微秒。这个延迟允许其他 后端把它们的提交记录加入日志， 从而让所有这些记录用一次 日志同步刷写。如果未启用 fsync，或者当前未处于活跃 事务中的其他后端少于 COMMIT_SIBLINGS 个，就不会 休眠；这避免了在 不太可能有其他后端很快提交时 休眠。注意在大多数平台上，休眠请求的 分辨率是十毫秒，因此 1 到 10000 微秒之间的任何非零 COMMIT_DELAY 设置效果都 相同。这些参数的理想值尚 不清楚；鼓励进行 实验。

WAL_SYNC_METHOD 参数决定 PostgreSQL 如何 要求内核把 WAL 更新强制 写到磁盘。就 可靠性而言所有选项都 相同，但哪一个 最快则非常依赖于平台。 注意如果关闭了 FSYNC，这个参数就 无关紧要。

把 WAL_DEBUG 参数设为任何非零 值将导致每次 LogInsert 和 LogFlush 的 WAL 调用都被 记录到标准错误。目前， 非零值具体是什么没有 区别。这个选项将来可能被 更通用的机制取代。