wal_level决定多少信息写入到 WAL 中。默认值是minimal，它只写入从崩溃或立即关机中进行恢复所需的信息。archive会增加 WAL 归档所需的日志；hot_standby会进一步增加在备库上运行只读查询所需的信息。这个参数只能在服务器启动时设置。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用于 WAL 数据的共享内存中的内存量。默认值是 64 千字节（64kB）。这个设置只需要大到足以容纳一个典型事务产生的 WAL 数据量，因为数据在每次事务提交时都会被写出到磁盘。这个参数只能在服务器启动时设置。

增加这个参数可能会导致PostgreSQL请求比你的操作系统默认配置所允许的更多的System V共享内存。如果有必要，关于如何调整那些参数的信息见第 17.4.1 节。

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

把一个提交记录写入 WAL 缓冲区和把缓冲区刷出到磁盘之间的时间延迟，以微秒计。如果系统负载足够高，使得额外的事务在给定间隔内变为准备好提交，一个非零的延迟可以允许多个事务只用一次fsync()系统调用提交。但如果没有其他事务变为准备好提交，这个延迟就纯属浪费。因此，只有当服务器进程写完它的提交记录的那一刻，至少有commit_siblings个其他事务处于活动状态时，才会执行该延迟。默认值为零（无延迟）。

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

自动 WAL 检查点之间日志文件段的最大数量（每个段通常为 16 兆字节）。默认值为三个段。增加这个参数会增加崩溃恢复所需的时间。此参数只能在postgresql.conf文件中或服务器命令行上设置。

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

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

如果由填充检查点段文件导致的检查点发生得比这个秒数更接近，就向服务器日志写一条消息（这建议应该增大checkpoint_segments）。默认值是 30 秒（30s）。零会禁用警告。此参数只能在postgresql.conf文件中或服务器命令行上设置。

当启用archive_mode时，已完成的 WAL 段会通过设置archive_command被发送到归档存储。archive_mode和archive_command是单独的变量，这样即使不离开归档模式也可以修改archive_command。这个参数只能在服务器启动时设置。要启用archive_mode，wal_level必须被设置为archive或hot_standby。

本地 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文件或服务器命令行中设置。

指定来自备库或流式基础备份客户端的并发连接的最大数量（即同时运行 WAL 发送进程的最大数）。默认值为 0，即禁用复制。WAL 发送进程计入总连接数，因此此参数的值不能高于max_connections。此参数只能在服务器启动时设置。wal_level必须设置为archive或 hot_standby，才允许来自备库的连接。

指定 WAL 发送进程各轮活动之间的延迟。每一轮中，WAL 发送进程把自上一轮以来积累的所有 WAL 发送到备库，然后休眠wal_sender_delay毫秒，再重复此过程。默认值为 200 毫秒（200ms）。注意，在许多系统上，休眠延迟的有效分辨率为 10 毫秒；将wal_sender_delay设为不是 10 的倍数的值，可能与将它设为下一个更大的 10 的倍数效果相同。此参数只能在postgresql.conf文件中或服务器命令行上设置。

指定在pg_xlog目录中保留的过去日志文件段的最小数量，以便备库可能需要获取它们来进行流复制。每个段通常为 16 兆字节。如果连接到发送服务器的备库落后超过wal_keep_segments个段，发送服务器可能会移除备库仍需要的 WAL 段，在这种情况下，复制连接将被终止。下游连接最终也会因此失败。（但是，如果使用了 WAL 归档，备库可以通过从归档中获取该段来恢复。）

此设置只指定在pg_xlog中保留的最小段数；系统可能需要为 WAL 归档或从检查点恢复而保留更多段。如果wal_keep_segments为零（默认值），系统不会为备库额外保留任何段，因此备库可用的旧 WAL 段数取决于前一个检查点的位置和 WAL 归档的状态。此参数对重启点没有影响。此参数只能在postgresql.conf文件中或服务器命令行上设置。

指定VACUUM和HOT更新延迟清理死行版本的事务数。默认值为零个事务，意味着可以尽快移除死行版本，也就是在它们不再对任何打开的事务可见时立即移除。如第 25.5 节所述，在为热备服务器提供支持的主库上，你可能希望将此参数设置为非零值。这让备库上的查询有更多时间完成，而不会因过早清理行而发生冲突。但是，由于此值以主库上发生的写事务数计量，很难预测会给备库查询带来多少额外的宽限时间。此参数只能在postgresql.conf文件中或在服务器命令行上设置。

指定在恢复期间，你是否能够连接并运行查询，如第 25.5 节中所述。默认值是off。这个参数只能在服务器启动时设置。它只在归档恢复期间或备库模式下才有效。

当热备处于活动状态时，此参数确定备库在取消与即将应用的WAL条目冲突的备库查询之前应等待多长时间，如第 25.5.2 节中所述。max_standby_archive_delay在从WAL归档中读取WAL数据时适用（因此不是当前的）。如果未指定单位，则将其视为毫秒。默认值为30秒。值为-1允许备库永远等待冲突查询完成。此参数只能在postgresql.conf文件或服务器命令行中设置。

注意，max_standby_archive_delay并不等同于查询在被取消前可以运行的最长时间；它表示应用任意一个 WAL 段的数据所允许的最长总时间。因此，如果某个查询先前在处理该 WAL 段时已造成显著延迟，后续冲突查询的宽限时间就会短得多。

当热备处于活动状态时，此参数确定备库在取消与即将应用的WAL条目冲突的备库查询之前应等待多长时间，如第 25.5.2 节中所述。max_standby_streaming_delay在通过流复制接收WAL数据时应用。如果未指定单位，则将其视为毫秒。默认值为30秒。值为-1允许备库永远等待冲突查询完成。此参数只能在postgresql.conf文件或服务器命令行中设置。

注意，max_standby_streaming_delay并不等同于查询在被取消前可以运行的最长时间；它表示从主库接收到 WAL 数据后，允许用于应用这些数据的最长总时间。因此，如果某个查询已造成显著延迟，后续冲突查询的宽限时间就会短得多，直到备库再次赶上进度。