参阅Section 30.4获取调节这些设置的额外信息。
wal_level (enum) #wal_level决定多少信息写入到 WAL 中。默认值是replica，它会写入足够的数据以支持WAL归档和复制，包括在备库上运行只读查询。minimal会去掉除从崩溃或者立即关机中进行恢复所需的信息之外的所有记录。最后，logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置。
在minimal级别，可以安全地跳过一些批量操作的 WAL 日志记录，使这些操作快得多（参见Section 14.4.7）。 可以应用此优化的操作包括：
CREATE TABLE AS |
CREATE INDEX |
CLUSTER |
向同一事务中创建或截断的表执行COPY |
但最少的 WAL 不包含足够的信息来从基础备份和 WAL 日志重建数据，因此必须使用replica或更高级别来启用 WAL 归档 （archive_mode）和流复制。
在logical级别上，记录与replica相同的信息，以及从WAL中提取逻辑变更集所需的信息。 使用logical级别会增加WAL的容量，特别是如果许多表被配置为REPLICA IDENTITY FULL， 并且执行了许多UPDATE和DELETE语句。
在 9.6 之前的版本中，这个参数也允许值archive和hot_standby。现在仍然接受这些值，但是它们会被映射到replica。
fsync (boolean) #如果打开这个参数，PostgreSQL服务器将尝试确保更新被物理地写入到磁盘，做法是发出fsync()系统调用或者使用多种等价的方法（见wal_sync_method）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。
虽然关闭fsync常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync。
能安全关闭fsync的环境的示例包括从一个备份文件中初始加载一个新数据库集簇、使用一个数据库集簇来在数据库被删掉并重建之后处理一批数据，或者一个被经常重建并却不用于失效备援的只读数据库克隆。单独的高质量硬件不足以成为关闭fsync的理由。
当把fsync从关闭改成打开时，为了可靠的恢复，需要强制在内核中的所有被修改的缓冲区进入持久化存储。这可以在多个时机来完成： 在集簇被关闭时或在fsync因为运行initdb --sync-only而打开时、运行sync时、卸载文件系统时或者重启服务器时。
在很多情况下，为不重要的事务关闭synchronous_commit可以提供很多关闭fsync的潜在性能收益，并不会有的同时， 关闭fsync可以提供很多潜在的性能优势，而不会有伴随着的数据损坏风险。
fsync只能在postgresql.conf文件中或在服务器命令行上设置。如果你关闭这个参数，请也考虑关闭full_page_writes。
synchronous_commit (enum) #指定数据库服务器返回“success”指示给客户端之前，必须要完成多少WAL处理。 合法的值为remote_apply, on(默认值), remote_write,local, 和 off。
如果synchronous_standby_names为空，则唯一有意义的设置为on 和 off ； remote_apply，remote_write 和 local都提供与on相同的本地同步级别。 所有非off模式的本地行为都是等待WAL的本地刷新到磁盘。 在 off模式，无需等待，因此在向客户端报告成功和以后保证事务安全防止服务器崩溃之间可能会出现延迟。 （最大的延迟是wal_writer_delay的三倍。） 不同于fsync，将这个参数设置为off不会产生数据库不一致性的风险：一个操作系统或数据库崩溃可能会造成一些最近据说已提交的事务丢失，但数据库状态是一致的，就像这些事务已经被干净地中止。 因此，当性能比完全确保事务的持久性更重要时，关闭synchronous_commit可以作为一个有效的代替手段。更多讨论见Section 30.3。
如果synchronous_standby_names为非空，synchronous_commit也控制是否事务提交将等待它们的 WAL 记录在备库上被处理。
当设置为 remote_apply 时，提交将等待，直到来自当前同步备库的答复显示他们已收到事务的提交记录并应用了它，以便它变得对备库上的查询可见，并写入备库上的持久存储。 这将导致比以前的设置更大的提交延迟，因为它等待 WAL 重放(replay)。 当设置为on时，提交将等待，直到来自于当前同步的备库的回复显示它们已经收到了事务的提交记录并将其刷入了磁盘。 这保证事务将不会被丢失，除非主库和所有同步备库都遭受到了数据库存储损坏的问题。 当这个参数被设置为remote_write时，提交将等待，直到来自当前的同步备库的回复指示它们已经收到了该事务的提交记录并且已经把该记录写到它们的文件系统，这种设置保证数据得以保存，在PostgreSQL的备库实例崩溃时，但是不能保证备库遭受操作系统级别崩溃时数据能被保持，因为数据不一定必须要在备库上达到持久存储。 设置local会导致提交等待本地刷写到磁盘，而不是复制。在使用同步复制时这通常是不可取的，但是为了完整性提供了这个选项。
这个参数可以随时被修改；任何一个事务的行为由其提交时生效的设置决定。因此，可以同步提交一些事务，同时异步提交其他事务。例如，当默认是相反时，实现一个单一多语句事务的异步提交，在事务中发出SET LOCAL synchronous_commit TO OFF。
Table 19.1概括了 synchronous_commit 各种设置具备的能力。
Table 19.1. synchronous_commit 模式
| synchronous_commit 设置 | 本地持久提交 | PG 崩溃备库持久提交 | OS 崩溃备库持久提交 | 备库查询一致性 |
|---|---|---|---|---|
| remote_apply | • | • | • | • |
| on | • | • | • | |
| remote_write | • | • | ||
| local | • | |||
| off |
wal_sync_method (enum) #用来向强制 WAL 更新到磁盘的方法。如果fsync是关闭的，那么这个设置就不相关，因为 WAL 文件更新将根本不会被强制。可能的值是：
open_datasync（用open()选项O_DSYNC写 WAL 文件）
fdatasync（在每次提交时调用fdatasync()）
fsync（在每次提交时调用fsync()）
fsync_writethrough（在每次提交时调用fsync()，强制任何磁盘写高速缓存的直通写）
open_sync（用open()选项O_SYNC写 WAL 文件）
open_* 选项也可以使用O_DIRECT（如果可用）。 不是在所有平台上都能使用所有这些选择。 默认值是列表中第一个被平台支持的那个， 不过fdatasync是 Linux和FreeBSD中的默认值。 默认值不一定是最理想的；有可能需要修改这个设置或系统配置的其他方面来创建一个崩溃-安全的配置，或达到最佳性能。 这些方面在Section 30.1中讨论。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
full_page_writes (boolean) #当这个参数为打开时，PostgreSQL服务器在一个检查点之后的页面的第一次修改期间将每个页面的全部内容写到 WAL 中。这么做是因为在操作系统崩溃期间正在处理的一次页写入可能只有部分完成，从而导致在一个磁盘页面中混合有新旧数据。在崩溃后的恢复期间，通常存储在 WAL 中的行级改变数据不足以完全恢复这样一个页面。存储整页镜像可以保证页面被正确存储，但代价是增加了必须被写入 WAL 的数据量（因为 WAL 重放总是从一个检查点开始，所以在检查点后每个页面的第一次改变时这样做就够了。因此，一种减小全页面写开销的方法是增加检查点间隔参数值）。
把这个参数关闭会加快正常操作，但是在系统失败后可能导致不可恢复的数据损坏，或者静默的数据损坏。其风险类似于关闭fsync， 但是风险较小。并且只有在对该参数建议的相同情况下才应该关闭它。
关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见Section 25.3）。
这个参数只能在postgresql.conf文件中或在服务器命令行上设置。默认值是on。
wal_log_hints (boolean) #当这个参数为on时，PostgreSQL服务器一个检查点之后页面被第一次修改期间把该磁盘页面的整个内容都写入 WAL，即使对所谓的提示位做非关键修改也会这样做。
如果启用了数据校验和，提示位更新总是会被 WAL 记录并且这个设置会被忽略。你可以使用这个 设置测试如果你的数据库启用了数据校验和，会有多少额外的 WAL 记录发生。
这个参数只能在服务器启动时设置。默认值是off。
wal_compression (boolean) #当这个参数为on时，PostgreSQL服务器在full_page_writes打开时或在基础备份期间，压缩写入WAL的整页镜像。在WAL回放期间将对压缩的页面镜像进行解压。默认值是off。只有超级用户能更改这个设置。
开启这个参数可以在不增加不可恢复的数据损坏风险的情况下减少WAL数据量，但代价是在WAL记录期间用于压缩以及在WAL回放期间用于解压的额外CPU开销。
wal_buffers (integer) #用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于shared_buffers的 1/32 的尺寸（大约3%），但是不小于64kB也不大于 WAL 段的尺寸（通常为16MB）。如果自动的选择太大或太小可以手工设置该值，但是任何小于32kB的正值都将被当作32kB。 这个参数只能在服务器启动时设置。
在每次事务提交时，WAL 缓冲区的内容被写出到磁盘，因此极大的值不可能提供显著的收益。不过，把这个值设置为几个兆字节可以在一个繁忙的服务器（其中很多客户端会在同一时间提交）上提高写性能。由默认设置 -1 选择的自动调节将在大部分情况下得到合理的结果。
wal_writer_delay (integer) #指定 WAL 写入器刷写 WAL 的频繁程度。刷写 WAL 之后，它会休眠wal_writer_delay毫秒，除非被异步提交的事务唤醒。 如果上一次刷写距今少于wal_writer_delay毫秒，并且此后产生的 WAL 少于wal_writer_flush_after字节， 则只将 WAL 写入操作系统，而不刷写到磁盘。 默认值为 200 毫秒（200ms）。请注意，许多系统的休眠延迟有效分辨率为 10 毫秒； 将wal_writer_delay设置为非 10 的倍数的值，可能与设置为下一个更大的 10 的倍数具有相同效果。 此参数只能在postgresql.conf文件中或在服务器命令行上设置。
wal_writer_flush_after (integer) #指定 WAL 写入器刷写 WAL 的频繁程度。如果上一次刷写距今少于wal_writer_delay毫秒， 并且此后产生的 WAL 少于wal_writer_flush_after字节，则只将 WAL 写入操作系统，而不刷写到磁盘。 如果wal_writer_flush_after设置为0，则立即刷写 WAL 数据。 默认值为1MB。此参数只能在postgresql.conf文件中或在服务器命令行上设置。
commit_delay (integer) #设置commit_delay会在执行WAL刷新之前添加以微秒为单位的时间延迟。 如果系统负载足够高，使得在给定时间间隔内有更多事务准备提交， 这可以通过允许更多事务通过单个WAL刷新来提高组提交吞吐量。 然而，这也会增加延迟，最多为每个WAL刷新的commit_delay微秒。 因为如果没有其他事务准备提交，延迟就是浪费的，所以只有在至少有 commit_siblings其他事务活动时才会执行延迟， 当要启动刷新时，如果fsync被禁用，则不会执行延迟。 默认commit_delay为零（无延迟）。 只有超级用户能更改这个设置。
在PostgreSQL的 9.3 发布之前，commit_delay的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写，并且即使在 WAL 刷写马上就要完成时也会等待一整个配置的延迟。从PostgreSQL 9.3 中开始，第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作。
commit_siblings (integer) #在执行commit_delay延迟时，要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。
checkpoint_timeout (integer) #自动 WAL 检查点之间的最长时间，以秒为单位。 合理的范围在 30 秒到 1 天之间。默认是 5 分钟（5min）。增加这个参数的值会增加崩溃恢复所需的时间。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
checkpoint_completion_target (floating point) #指定检查点完成的目标，作为检查点之间总时间的一部分。默认是 0.5。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
checkpoint_flush_after (integer) #当执行检查点时写入的数据量超过checkpoint_flush_after字节时，就尝试强制 OS 把这些写发送到底层存储。 这样做将会限制内核页面高速缓存中的脏数据数量，降低在检查点末尾发出fsync或者 OS 在后台大批量写回数据时被卡住的可能性。 那常常会导致大幅度压缩的事务延迟，但是也有一些情况（特别是负载超过shared_buffers但小于 OS 页面高速缓存）的性能会降低。 这种设置可能会在某些平台上没有效果。 合法的范围在0（禁用强制写回）和2MB之间。Linux 上的默认值是256kB，其他平台上是0（如果BLCKSZ不是8kB，则默认值和最大值会按比例缩放到它）。这个参数只能在postgresql.conf文件中或者服务器命令行上设置。
checkpoint_warning (integer) #如果由于填充检查点段文件导致的检查点之间的间隔低于这个参数表示的秒数，那么就向服务器日志写一个消息（它建议增加max_wal_size的值）。 默认值是 30 秒（30s）。零则关闭警告。如果checkpoint_timeout低于checkpoint_warning，则不会有警告产生。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
max_wal_size (integer) #在自动检查点期间允许WAL增长的最大大小。这是一个软限制；在特殊情况下，如重负载、失败的archive_command，或高wal_keep_segments设置下，WAL大小可能会超过max_wal_size。 默认值为1 GB。 增加此参数可能会增加崩溃恢复所需的时间。 此参数只能在postgresql.conf文件或服务器命令行中设置。
min_wal_size (integer) #只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是 被回收以便未来使用，而不是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰，例如运行大型的批处理任务。 默认是 80 MB。这个参数只能在postgresql.conf 或者服务器命令行中设置。
archive_mode (enum) #当启用archive_mode时，完成的WAL段会通过设置 archive_command发送到归档存储。除了off， 要禁用，有两种模式：on和 always。在正常操作期间，这两种模式之间没有区别，但当设置为always时， WAL归档程序在归档恢复或待机模式下也会被启用。在always模式下，从归档中恢复的所有文件 或通过流复制传输的文件将被再次归档。详细信息请参见 Section 26.2.9。
archive_mode和archive_command是 单独的变量，这样archive_command可以在不离开 归档模式的情况下进行更改。 此参数只能在服务器启动时设置。 当wal_level设置为minimal时， 无法启用archive_mode。
archive_command (string) #本地 shell 命令被执行来归档一个完成的 WAL 文件段。字符串中的任何%p被替换成要被归档的文件的路径名， 而%f只被文件名替换（路径名是相对于服务器的工作目录， 即集簇的数据目录）。如果要在命令里嵌入一个真正的%字符，可以使用%%。有一点很重要，该命令只在成功时返回一个零作为退出状态。更多信息请见Section 25.3.1。
这个参数只能在postgresql.conf文件或服务器命令行中设置。 除非在服务器启动时启用了archive_mode，否则将被忽略。 如果archive_command是空字符串（默认值），而archive_mode已启用， WAL归档将暂时被禁用，但服务器将继续积累WAL段文件，期望很快会提供命令。 将archive_command设置为一个什么都不做但返回true的命令，例如/bin/true（Windows上为REM）， 实际上禁用了归档，但也破坏了用于归档恢复所需的WAL文件链，因此只应在不寻常的情况下使用。
archive_timeout (integer) #archive_command仅在完成的WAL段上调用。 因此，如果您的服务器生成的WAL流量较少（或者在这样做时有间歇期），在事务完成和安全记录到归档存储之间可能会有很长的延迟。 为了限制未归档数据的年龄，您可以将archive_timeout设置为强制服务器定期切换到新的WAL段文件。 当此参数大于零时，只要自上次段文件切换以来经过了指定的秒数，并且存在任何数据库活动，包括单个检查点（如果没有数据库活动，则跳过检查点），服务器将切换到新的段文件。 请注意，由于强制切换而提前关闭的归档文件仍然与完全填满的文件长度相同。因此，使用非常短的archive_timeout是不明智的，它会使您的归档存储膨胀。 通常，将archive_timeout设置为一分钟左右是合理的。如果您希望数据比这更快地从主库复制出来，您应该考虑使用流复制而不是归档。 此参数只能在postgresql.conf文件或服务器命令行中设置。