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

不过，使用 fsync 会带来性能损失：提交一个事务时， PostgreSQL 必须等待操作系统把预写日志刷写 到磁盘。当 fsync 被禁用时，操作系统可以尽其所能 地缓冲、排序和延迟写操作。这可以显著提高性能。然而，如果系统崩溃， 最近提交的若干事务的结果可能部分或全部丢失。在最坏的情况下，可能 发生不可恢复的数据损坏。（数据库软件自身的崩溃在这里不 是风险因素。只有操作系统层面的崩溃才会带来损坏的风险。）

由于存在这些风险，fsync 没有一个普遍正确的设置。 有些管理员总是禁用 fsync，另一些管理员只在初始 批量装载数据时才关闭它（此时一旦出错，有明确的重启点），还有一些 管理员始终启用 fsync。默认值是启用 fsync，以获得最大的可靠性。如果你信任你的操作 系统、你的硬件以及你的电力公司（或你的电池备份），可以考虑禁用 fsync。

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

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

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

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

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

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

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

关闭此参数可以加快正常操作，但操作系统崩溃或断电后可能导致数据库损坏。风险与关闭fsync类似，不过较小。如果你的硬件（如带电池的磁盘控制器）或文件系统软件能把部分页写入的风险降到可接受的低水平（例如 ReiserFS 4），关闭此参数可能是安全的。

关闭这个选项并不影响用于时间点恢复（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。这个参数只能在服务器启动时 设置。

用于归档 WAL 文件序列中一个已完成段的 shell 命令。字符串中的任何 %p 都会被替换为要归档文件的路径名，任何 %f 则只替换为文件名。（路径名相对于服务器的 工作目录，即集簇的数据目录。）使用 %% 可以在 命令中嵌入一个真正的 % 字符。更多信息见 第 24.3.1 节。

这个参数只能在 postgresql.conf 文件或服务器 命令行中设置。除非在服务器启动时启用了 archive_mode，否则它会被忽略。如果 archive_command 是空字符串（默认值），而 archive_mode 已启用，那么 WAL 归档会被暂时 禁用，但服务器会继续累积 WAL 段文件，期待很快会提供一个命令。 有一点很重要：该命令当且仅当成功时才返回零退出状态。示例：

archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows

archive_command只针对已完成的 WAL 段调用。 因此，如果您的服务器生成的WAL流量较少（或者在这样做时有间歇期），在事务完成和安全记录到归档存储之间可能会有很长的延迟。 为了限制未归档数据的年龄，您可以将archive_timeout设置为强制服务器定期切换到新的WAL段文件。 当此参数大于零时，只要自上次段文件切换以来经过了这么多秒，服务器就会 切换到新的段文件。请注意，由于强制切换而提前关闭的归档文件仍然 与完全填满的文件长度相同。因此，使用非常短的 archive_timeout 是不明智的，它会使您的归档存储 膨胀。通常，将 archive_timeout 设置为一分钟 左右是合理的。此参数只能在 postgresql.conf 文件或服务器命令行中设置。