wal_level决定多少信息写入到WAL中。默认值是minimal， 只写入数据库崩溃或突然关机时的恢复需要的信息。archive添加WAL归档需要的记录。 hot_standby添加备库只读查询时需要的信息。服务器启动时才可以设置这个参数。

minimal级别下，一些如表上的CREATE INDEX， CLUSTER和COPY的批量操作的WAL日志写，在同一事务中的这种日志写的创建或删除， 可以安全地跳过，这样可以是这些操作变得更快（参阅Section 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可以提供很多潜在的性能优势，而不会需要担心数据损坏。

这个选项只能在服务器启动的时候或者在postgresql.conf 文件里设置。 如果这个选项被关闭，那么请考虑把 full_page_writes也关闭了。

声明一个事务是否需要等待，在命令向客户端返回"success"提示之前， WAL记录写入磁盘。缺省的，安全的设置是on。当设置为off 时，在向客户端返回成功提示和保证事务安全（相比一个服务器崩溃）之间会有 时延。（最大时延是三倍wal_writer_delay）。 不同于 fsync，将这个参数设置为off不会产生 数据库不一致性的风险：一个系统或数据库故障可能会造成一些最近的提示已提交事务 的丢失，但数据库状态是一致的，如同这些事务已经强制清除一样。因此，当性能比 估算一个事务的有效期更重要是，关闭synchronous_commit可以作为一个 有效的代替手段。参阅Section 29.3。

这个参数可以随时进行修改；任何一个事务的行为是由提交时生效的设置决定的。 因此，可以有效的同步提交一些事务，同时异步提交其他事务。 例如，当缺省是相反时，实现一个单一事务的异步提交，在事务中使用SET LOCAL synchronous_commit TO OFF。

用来向磁盘强制更新 WAL 数据的方法。如果fsync是 关闭的，那么这个设置就没有意义，因为所有更新都不会强制输出。 可能的值是：

• (用带O_DSYNC选项的open()打开 WAL 文件)

• (每次提交的时候都调用fdatasync())

• (每次提交的时候调用fsync()）

• (每次提交的时候调用fsync()强制写出任何磁盘写缓冲区)

• (用带O_SYNC选项的open()写 WAL 文件)

open_*选项也可以使用O_DIRECT（如果可用的话） 不是在所有系统上都能使用上面四种选项。缺省是被支持的最前面一个选项， 除了fdatasync是Linux中的缺省值之外。默认的却不一定是最理想的； 有可能需要修改这个设置或系统配置的其他方面，为了创建一个崩溃-安全配置，或 达到最大性能。这些方面在Section 29.1中有讨论。 这个选项只能在服务器启动的时候或者在postgresql.conf 文件里设置。

打开这个选项的时候，PostgreSQL服务器在检查点之后 对页面的第一次写入时将整个页面写到 WAL 里面。这么做是因为在操作 系统崩溃过程中可能只有部分页面写入磁盘，从而导致在同一个页面中包含 新旧数据的混合。在崩溃后的恢复期间，由于在 WAL 里面存储的行变化信息 不够完整，因此无法完全恢复该页。把完整的页面影像保存下来就可以保证 正确存储页面，代价是增加了写入 WAL 的数据量。因为 WAL 重放总是从 一个检查点开始的，所以在检查点后每个页面第一次改变的时候做 WAL 备份就足够了。因此，一个减小全页面写开销的方法是增加检查点的间隔 参数值。

把这个选项关闭会加快正常操作的速度，但是可能导致不可恢复的数据损坏 或者无提示的数据损坏在系统出现故障后，它的危害类似于fsync， 只是比较小而已。应根据建议，在参数相同的情况下，最好关闭它。

关闭这个选项并不影响即时恢复(PITR)的 WAL 使用 (参阅节Section 24.3)。

这个选项只能在服务器启动的时候或者在postgresql.conf 文件里进行设置。缺省是on。

放在共享内存里用于 WAL 数据的磁盘页面缓冲区的数目。 缺省值为 8(64kB) 。这个设置只需要大到能保存下一次事务 生成的 WAL 数据即可，因为这些数据在每次事务提交时都会写入磁盘。 这个值只能在服务器启动的时候设置。

增大这个参数可能导致PostgreSQL要求更多的 System V共享内存，可能超过操作系统 的缺省配置。必要时，参阅节Section 17.4.1获取如何调节 这些参数的信息。

声明WAL写进程的周期。在每个周期中会将WAL刷到磁盘，之后，wal_writer_delay时间内休眠，然后重复。 默认只是200毫秒，需要注意的是，在许多操作系统上，设置为10毫秒会很有效；这个参数只有在postgresql.conf 中或通过服务器命令设置。

向 WAL 缓冲区写入记录和将缓冲区刷新到磁盘上之间的时间延迟，以微秒计。 非零的延迟允许多个事务共用一个fsync()系统 调用提交，如果系统负载足够高，那么在给出的间隔里，其它的事务可能 已经准备好提交了。但是如果没有其它事务准备提交，那么这个间隔就是 在浪费时间。因此，这个延迟只是在一个服务器进程写其提交日志时， 至少commit_siblings个其它事务在活跃的情况 下执行。缺省是零(无延迟)。

在执行commit_delay延迟的时候，要求最少同时打开的 并发事务数目。大一些的数值会导致在延迟期间另外一个事务准备好 提交的可能性增大。缺省是 5 。

日志文件段自动WAL检查点之间的最大数量（每个段正常是16兆字节）。 默认是3个段。增加这个参数的值会增加崩溃恢复的时间。 这个选项只能在服务器启动的时候或者在postgresql.conf 文件里设置。

在自动 WAL 检查点之间的最长时间，以秒计。缺省是 300 秒(5min)。 增加这个参数的值会增加崩溃恢复的时间。 这个选项只能在服务器启动的时候或者在postgresql.conf 文件里设置。

声明检查点的目标，作为一个检查点之间的总时间的一小部分。默认是0.5。 这个选项只能在服务器启动的时候或者在postgresql.conf文件里设置。

如果由于填充检查点段文件导致的检查点发生时间间隔接近这个参数表示的 秒数，那么就向服务器日志发送一个建议增加checkpoint_segments 值的消息。缺省是 30 秒(30s)。零则关闭警告。这个选项 只能在服务器启动的时候或者在postgresql.conf文件里设置。

当启用archive_mode时，通过设置archive_command命令将所有的 WAL段传递到归档目录。archive_mode和archive_command是两个不同的变量， 因此可以在脱离归档模式的前提下修改archive_command。 这个参数可以只在服务启动时设置，wal_level必须设置为archive或hot_standby 以支持archive_mode。

要执行归档所有WAL文件段的shell命令。字符串中的%p被替换成需要归档的文件的路径， 而%f只被文件名替换。(路径名是相对于服务器的工作目录， 即集群的数据目录)。如果你需要在命令里嵌入 %%字符 就必须双写%%。 这是很重要的命令，将返回一个零退出状态（只有当它成功时）。 参阅Section 24.3.1.

这个参数只能在postgresql.conf文件中或服务命令行中设置。 除非服务器启动时启用了archive_mode，否则忽略。 如果启用了archive_mode，但archive_command是一个空 字符串（缺省），WAL归档会临时禁用，但服务器仍会一直产生WAL段文件，直到 提供了archive_command命令。将 archive_command设置为一条命令不会起作用，除了返回一个真，如 /bin/true(或Windows下的REM)， 有效的禁用归档，但也会打破归档恢复所需的WAL文件间的链接，因此 只有在特殊情况下才能用。

archive_command仅在已完成的 WAL 段上调用。 因此，如果服务器只产生很少的 WAL 流量(或产生流量的周期很长)， 那么在完成事务以及安全归档存储之间将有一个很长的延时。为了限制 未归档数据的逗留时间，你可以强制服务器以archive_timeout 指定的秒数为周期切换到新的 WAL 段文件。该参数等于零表示关闭此特性， 并且存在活动的数据库，包括一个单独的检查点。 增加checkpoint_timeout会降低空闲系统上所需的检查点。 注意，由于强制切换而提早关闭的归档文件仍然与完整的归档文件长度相同。 因此，将archive_timeout设为很小的值是不明智的， 它将导致占用巨大的归档存储空间。将archive_timeout 设置为 60 秒左右是比较合理的。这个选项只能在服务器启动 的时候或者在postgresql.conf文件里设置。

声明从备服务器的并发连接的最大数（如，同时运行WAL发送进程的最大数）。 缺省是0。这个参数只能在服务启动时才能设置。 wal_level必须设置为archive或hot_standby 以允许从备服务器的连接。

声明WAL发送进程的活动循环间时延。在每一轮循环中，WAL会发送积累的WAL日志。 然后休眠等待wal_sender_delay毫秒，接着，重复。 缺省值是200毫秒(200ms)。需要注意的是，在许多系统上，将其设置为 10毫秒会更有效。这个参数只能在postgresql.conf文件中或 服务器命令中修改。

声明pg_xlog目录下所能保留的旧日志文件段的最小数目， 备服务器需要获取它们进行流复制。每个文件正常是16M。如果一个备服务器连接 主服务器时少于 wal_keep_segments段，主服务器会向备服务器传送一个 其仍需要的WAL，此时复制连接将被终止。（然而，备服务器可以从归档中获得段来恢复， 如果使用WAL归档的话）

只设置pg_xlog中保留的文件段的最小数目；系统可能需要更多的空间来 存放WAL归档或从一个检查点恢复。如果wal_keep_segments是零（缺省）， 系统不会为备用来保留额外的空间，并且备服务器可获得的就得WAL段的数目是一个 旧检查点位置和WAL归档状态的函数。这个参数对restartpoints无效，只能在 postgresql.conf文件中或服务器命令行中修改。

声明VACUUM和HOT更新所需要的事务数，以推迟清理死行版本。 缺省是0事务，表示以最快的速度清理死行版本。可能希望在一个支持热备服务的主库上设置为非0值， 如Section 25.5中描述的。这允许在备库上更多的查询时间，防止发生冲突（与之前的 行清理）。然而，这个值是根据在主库上写事务的数目确定的，因此很难预测备库查询需要多少额外的时间。 这个参数只能在postgresql.conf文件中或服务命令中设置。

声明在恢复期间，能不能进行连接进行查询，参阅Section 25.5。 缺省值是off。这个参数只能在服务器启动时设置。这个参数 只有在归档恢复或standby模式下才有用。

当启用热备时，这个参数决定在取消备库查询（与WAL应用条目冲突）之前， 备服务器会等待多长时间，参阅Section 25.5.2。 当WAL数据正在从WAL归档中（非当前）读取时，会应用 max_standby_archive_delay。缺省是30s。如果没声明，单位是毫秒。 当值时-1时，表示允许备服务器会一直等待，知道冲突结束。 这个参数只能在postgresql.conf文件中，或服务器命令行中设置。

注意，max_standby_archive_delay不同于在取消之前， 一个查询锁能运行的最长时间； 相反，它是最大的总时间允许，适用于任何一个WAL段数据。因此，在WAL段之前， 如果一个查询造成 明显的延迟，随后的冲突查询将有很少的允许时间。

当启用热备时，这个参数决定在取消备库查询（与WAL应用条目冲突）之前， 备服务器会等待多长时间，参阅Section 25.5.2。 当WAL数据正在从WAL归档中（非当前）读取时，会应用 max_standby_archive_delay。缺省是30s。如果没声明，单位是毫秒。 当值时-1时，表示允许备服务器会一直等待，知道冲突结束。 这个参数只能在postgresql.conf文件中，或服务器命令行中设置。

注意，max_standby_streaming_delay不同于在取消之前， 一个查询所能运行的最长时间； 相反，它是一旦它被从主服务器收到时，运行WAL段数据所允许的最大的总时间。 如果一个查询造成明显的延迟，随后的冲突查询将有很少的允许时间，直到备服务器 重新挂起。