wal_level决定多少信息写入到 WAL 中。默认值是minimal，它只写入从崩溃或立即关机中进行恢复所需的信息。archive会增加 WAL 归档所需的日志；hot_standby会进一步增加在备库上运行只读查询所需的信息；最后，logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置。

在minimal级别，可以安全地跳过一些批量操作的 WAL 日志记录，使这些操作快得多（参见第 14.4.7 节）。 可以应用此优化的操作包括：

但 minimal 级别的 WAL 不包含足够的信息来从基础备份和 WAL 日志重建数据，因此必须使用archive或更高级别来启用 WAL 归档 （archive_mode）和流复制。

在hot_standby级别上，记录与archive相同的信息，以及从 WAL 重构正在运行事务的状态所需的信息。要在备库上启用只读查询，必须把主库上的wal_level设置为hot_standby或更高，并且在备库上启用hot_standby。据认为，使用hot_standby和archive级别在性能上几乎没有可测量的差别，因此如果注意到任何生产环境影响，欢迎反馈。

在logical级别上，记录与hot_standby相同的信息，以及从WAL中提取逻辑变更集所需的信息。 使用logical级别会增加 WAL 的数量，特别是如果许多表被配置为REPLICA IDENTITY FULL， 并且执行了许多UPDATE和DELETE语句。

如果打开这个参数，PostgreSQL服务器将尝试确保更新被物理地写入到磁盘，做法是发出fsync()系统调用或者使用多种等价的方法（见wal_sync_method）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。

虽然关闭fsync常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync。

可以安全关闭fsync的情形包括：从备份文件初始装载一个新数据库集簇；用数据库集簇处理一批数据，处理后就丢弃并重建该数据库；或者使用经常重建且不用于故障切换的只读数据库克隆。仅有高质量硬件不足以成为关闭fsync的理由。

为确保将fsync从关闭改为打开后能够可靠恢复，必须将内核中所有已修改的缓冲区强制写入持久存储。可以在集簇已关闭或 fsync 已开启时，通过运行initdb --sync-only、运行sync、卸载文件系统或重启服务器来完成。

在很多情况下，为非关键事务关闭synchronous_commit，可以获得关闭fsync所带来的大部分潜在性能收益，同时避免伴随的数据损坏风险。

fsync只能在postgresql.conf文件中或在服务器命令行上设置。如果你关闭这个参数，请也考虑关闭full_page_writes。

指定事务提交是否等待 WAL 记录写入磁盘后，命令才向客户端返回“成功”指示。有效值为on、remote_write、local和off。默认且安全的设置是on。当为off时，向客户端报告成功后，可能还要经过一段时间，事务才能真正保证不会因服务器崩溃而丢失。（最大延迟为wal_writer_delay的三倍。）与fsync不同，将此参数设为off不会带来数据库不一致的风险：操作系统或数据库崩溃可能会使一些最近报告已提交的事务丢失，但数据库状态会与这些事务已正常中止时完全相同。因此，当性能比完全确保事务持久性更重要时，关闭synchronous_commit可以是一种有用的替代方案。更多讨论见第 29.3 节。

如果设置了synchronous_standby_names，此参数还控制事务提交是否等待该事务的 WAL 记录复制到备库服务器。设为on时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其刷写到磁盘。这能保证事务不会丢失，除非主库和备库的数据库存储都损坏。设为remote_write时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其写入备库的操作系统，但数据未必已写入备库的持久存储。即使备库上的PostgreSQL实例崩溃，此设置也足以保证数据不丢失，但不能保证备库发生操作系统级别崩溃时数据不丢失。

使用同步复制时，通常要么等待本地刷盘和 WAL 记录复制两者都完成，要么允许事务异步提交，这样才是合理的。不过，对于希望等待本地刷盘但不等待同步复制的事务，可以使用local设置。如果未设置synchronous_standby_names，则设置on、remote_write和local提供的同步级别相同：事务提交只等待本地刷盘。

此参数可以随时更改；每个事务的行为由提交时生效的设置决定。因此，让一些事务同步提交、另一些事务异步提交是可行且有用的。例如，当默认设置要求同步提交时，可以在一个包含多条语句的事务中执行SET LOCAL synchronous_commit TO OFF，使该事务异步提交。

用于将 WAL 更新强制写入磁盘的方法。如果fsync关闭，此设置就没有作用，因为 WAL 文件更新根本不会被强制写入磁盘。可选值为：

open_* 选项还会使用O_DIRECT（如果可用）。 不是在所有平台上都能使用所有这些选择。 默认值是列表中第一个被平台支持的那个， 不过fdatasync是 Linux 中的默认值。 默认值不一定最合适；可能需要更改此设置或系统配置的其他方面，以确保崩溃时的数据安全或达到最佳性能。 这些方面在第 29.1 节中讨论。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

启用此参数时，PostgreSQL服务器会在检查点之后首次修改每个磁盘页面时，将该页面的全部内容写入 WAL。这样做是因为，操作系统崩溃时正在进行的页面写入可能只完成了一部分，导致磁盘页面混有新旧数据。通常存储在 WAL 中的行级变更数据不足以在崩溃恢复时完整还原这样的页面。保存整页镜像能保证正确恢复页面，但会增加必须写入 WAL 的数据量。（由于 WAL 重放总是从检查点开始，只需在检查点之后首次修改每个页面时这样做。因此，减少整页写入开销的一种方法是增大检查点间隔参数。）

关闭此参数可以加快正常操作，但系统故障后可能出现不可恢复的数据损坏或静默数据损坏。风险与关闭fsync类似，虽然较小，但也只有在该参数建议的相同情形下才应关闭此参数。

关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见第 24.3 节）。

这个参数只能在postgresql.conf文件中或在服务器命令行上设置。默认值是on。

当这个参数为on时，PostgreSQL服务器在检查点之后首次修改页面时把该磁盘页面的整个内容都写入 WAL，即使对所谓的提示位做非关键修改也会这样做。

如果启用了数据校验和，提示位更新总是会被 WAL 记录并且这个设置会被忽略。你可以使用这个 设置测试如果你的数据库启用了数据校验和，会有多少额外的 WAL 记录发生。

这个参数只能在服务器启动时设置。默认值是off。

当这个参数为on时，PostgreSQL服务器在full_page_writes打开时或在基础备份期间，压缩写入WAL的整页镜像。在 WAL 重放期间将对压缩的整页镜像进行解压。默认值是off。只有超级用户能更改这个设置。

开启此参数可以减少 WAL 数据量，而且不会增加不可恢复的数据损坏风险；代价是在记录 WAL 时压缩、重放 WAL 时解压会额外消耗一些 CPU。

用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于shared_buffers的 1/32 的尺寸（大约3%），但是不小于64kB也不大于 WAL 段的尺寸（通常为16MB）。如果自动的选择太大或太小可以手工设置该值，但是任何小于32kB的正值都将被当作32kB。 这个参数只能在服务器启动时设置。

在每次事务提交时，WAL 缓冲区的内容被写出到磁盘，因此极大的值不太可能带来显著收益。不过，把这个值设置为至少几个兆字节可以在一个繁忙的服务器（其中很多客户端会在同一时间提交）上提高写性能。由默认设置 -1 选择的自动调节将在大部分情况下得到合理的结果。

指定 WAL 写入器两轮活动之间的延迟。在每一轮中，写入器会把 WAL 刷写到磁盘，然后休眠wal_writer_delay毫秒，再重复这一过程。 默认值为 200 毫秒（200ms）。请注意，许多系统的休眠延迟有效分辨率为 10 毫秒； 将wal_writer_delay设置为非 10 的倍数的值，可能与设置为下一个更大的 10 的倍数具有相同效果。 此参数只能在postgresql.conf文件中或在服务器命令行上设置。

设置commit_delay会在发起 WAL 刷盘之前添加以微秒为单位的时间延迟。 如果系统负载足够高，使得在给定时间间隔内有更多事务准备提交， 这可以通过允许更多事务通过一次 WAL 刷盘来提高组提交吞吐量。 不过，每次 WAL 刷盘的延迟也会因此增加，最多增加commit_delay微秒。 如果没有其他事务准备提交，等待就没有意义，因此仅当即将发起刷盘时至少还有 commit_siblings个其他活动事务，才会等待。 此外，如果禁用了fsync，也不会等待。 默认commit_delay为零（无延迟）。 只有超级用户能更改这个设置。

在PostgreSQL的 9.3 发布之前，commit_delay的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写，并且即使 WAL 刷盘更早完成，也会等待整个配置的延迟时间。从PostgreSQL 9.3 开始，第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作。

执行commit_delay延迟前要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。

自动 WAL 检查点之间的最长时间，以秒为单位。 合理的范围在 30 秒到 1 小时之间。默认是 5 分钟（5min）。增加这个参数的值可能会增加崩溃恢复所需的时间。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

指定检查点完成的目标，作为检查点之间总时间的一部分。默认是 0.5。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

如果由于填充检查点段文件导致的检查点之间的间隔低于这个参数表示的秒数，那么就向服务器日志写一个消息（它建议增加max_wal_size的值）。 默认值是 30 秒（30s）。零则关闭警告。如果checkpoint_timeout低于checkpoint_warning，则不会有警告产生。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。

在自动检查点期间允许WAL增长的最大大小。这是一个软限制；在特殊情况下，如重负载、失败的archive_command，或高wal_keep_segments设置下，WAL大小可能会超过max_wal_size。 默认值为1 GB。 增加此参数可能会增加崩溃恢复所需的时间。 此参数只能在postgresql.conf文件或服务器命令行中设置。

只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是 被回收以便未来使用，而不是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰，例如运行大型的批处理任务。 默认是 80 MB。这个参数只能在postgresql.conf 或者服务器命令行中设置。

当启用archive_mode时，完成的WAL段会通过设置 archive_command发送到归档存储。除了用于禁用归档的off外，还有两种模式：on和 always。在正常操作期间，这两种模式之间没有区别，但当设置为always时， WAL归档程序在归档恢复或备库模式下也会被启用。在always模式下，从归档中恢复的所有文件 或通过流复制传输的文件将被再次归档。详细信息请参见 第 25.2.9 节。

archive_mode和archive_command是 单独的变量，这样archive_command可以在不离开 归档模式的情况下进行更改。 此参数只能在服务器启动时设置。 当wal_level设置为minimal时， 无法启用archive_mode。

本地 shell 命令被执行来归档一个完成的 WAL 文件段。字符串中的任何%p被替换成要被归档的文件的路径名， 而%f只被文件名替换（路径名是相对于服务器的工作目录， 即集簇的数据目录）。如果要在命令里嵌入一个真正的%字符，可以使用%%。有一点很重要，该命令只在成功时返回一个零作为退出状态。更多信息请见第 24.3.1 节。

这个参数只能在postgresql.conf文件或服务器命令行中设置。 除非在服务器启动时启用了archive_mode，否则将被忽略。 如果archive_command是空字符串（默认值），而archive_mode已启用， WAL归档将暂时被禁用，但服务器将继续积累WAL段文件，期望很快会提供命令。 将archive_command设置为一个什么都不做但返回true的命令，例如/bin/true（Windows上为REM）， 实际上禁用了归档，但也破坏了用于归档恢复所需的WAL文件链，因此只应在不寻常的情况下使用。

archive_command只针对已完成的 WAL 段调用。 因此，如果您的服务器生成的WAL流量较少（或者在这样做时有间歇期），在事务完成和安全记录到归档存储之间可能会有很长的延迟。 为了限制未归档数据的年龄，您可以将archive_timeout设置为强制服务器定期切换到新的WAL段文件。 当此参数大于零时，只要自上次段文件切换以来经过了指定的秒数，并且存在任何数据库活动（包括单个检查点），服务器将切换到新的段文件。（增大 checkpoint_timeout 可以减少空闲系统上不必要的检查点。） 请注意，由于强制切换而提前关闭的归档文件仍然与完全填满的文件长度相同。因此，使用非常短的archive_timeout是不明智的，它会使您的归档存储膨胀。 通常，将archive_timeout设置为一分钟左右是合理的。如果您希望数据比这更快地从主库复制出来，您应该考虑使用流复制而不是归档。 此参数只能在postgresql.conf文件或服务器命令行中设置。