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

minimal 级别生成最少的 WAL 日志量。对于在当前事务中创建或重写的永久关系，不记录其行信息。这可以使操作速度更快（参见第 14.4.7 节）。触发此优化的操作包括：

然而，minimal 级别的 WAL 不包含足够的信息用于时间点恢复，因此必须使用 replica 或更高级别来启用持续归档（archive_mode）和流式二进制复制。实际上，如果 max_wal_senders 不为零，服务器甚至不会以此模式启动。请注意，将 wal_level 更改为 minimal 会使先前的基础备份无法用于时间点恢复和备库。

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

在 9.6 之前的版本中，这个参数也允许值 archive 和 hot_standby。现在仍然接受这些值，但是它们会被映射到 replica。

如果打开这个参数，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 处理。有效值为 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 可以是一种有用的替代方案。更多讨论见第 30.4 节。

如果 synchronous_standby_names 非空，synchronous_commit 还控制事务提交是否等待备库处理其 WAL 记录。

设为 remote_apply 时，提交会等待当前同步备库回复，确认已收到并应用该事务的提交记录，使其对备库上的查询可见，并且已将其写入备库的持久存储。由于需要等待 WAL 重放，这会比之前的设置产生大得多的提交延迟。设为 on 时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其刷写到持久存储。这能保证事务不会丢失，除非主库和所有同步备库的数据库存储都损坏。设为 remote_write 时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其写入各自的文件系统。此设置能保证备库上的 PostgreSQL 实例崩溃时数据不丢失，但不能保证备库发生操作系统级别崩溃时数据不丢失，因为数据未必已写入备库的持久存储。设为 local 时，提交会等待本地刷盘，但不等待复制。使用同步复制时通常不希望采用这种设置，提供它是为了使选项完整。

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

表 20.1 汇总了 synchronous_commit 各种设置具备的能力。

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

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

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

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

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

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

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

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

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

此参数启用使用指定的压缩方法对 WAL 进行压缩。启用后，PostgreSQL 服务器会压缩写入 WAL 的整页镜像，例如在启用 full_page_writes 时、基础备份期间等。在 WAL 重放期间，将对压缩的页镜像进行解压缩。支持的方法有 pglz、lz4（如果 PostgreSQL 使用 --with-lz4 编译）和 zstd（如果 PostgreSQL 使用 --with-zstd 编译）。值 on 是 pglz 的历史拼写。默认值为 off。只有超级用户和具有适当 SET 权限的用户才能更改此设置。

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

如果设置为 on（默认值），此选项会导致新的 WAL 文件被零填充。在某些文件系统上，这可确保在我们需要写入 WAL 记录之前分配空间。但是，写时复制（COW）文件系统可能不会从此技术中受益，因此可以选择跳过不必要的工作。如果设置为 off，则在创建文件时只写入最后一个字节，以便其具有预期大小。

如果设置为 on（默认值），此选项通过重命名来回收 WAL 文件，从而避免创建新文件。在 COW 文件系统上，创建新文件可能更快，因此提供了禁用此行为的选项。

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

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

指定 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 写入器刷写 WAL 的频繁程度，按数据量衡量。如果距上次刷盘的时间小于 wal_writer_delay，并且自那以后产生的 WAL 数据量小于 wal_writer_flush_after，则只将 WAL 写入操作系统，而不刷写到磁盘。如果 wal_writer_flush_after 被设置为 0，则 WAL 数据总是会被立即刷写。如果指定值时没有单位，则以 WAL 块作为单位，即为 XLOG_BLCKSZ 字节，通常为 8kB。默认是 1MB。这个参数只能在 postgresql.conf 文件中或者服务器命令行上设置。

当 wal_level 为 minimal，且事务在创建或重写永久关系后提交时，此设置决定如何持久保存新数据。如果数据量小于此设置，就将其写入 WAL；否则，对受影响的文件执行 fsync。如果这类提交拖慢了并发事务，根据存储的特性，增大或减小此值可能有所帮助。未指定单位时以千字节为单位。默认值为两兆字节（2MB）。

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

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

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

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

指定检查点完成所用时间的目标值，以检查点之间总时间的比例表示。默认值为 0.9，这会把检查点工作分散到几乎整个可用间隔内，使 I/O 负载较为平稳，同时为检查点完成时的额外工作留出一些时间。不建议减小此参数，因为这样会让检查点更快完成，导致检查点期间的 I/O 速率更高，而在检查点完成后到下一个计划检查点开始前的一段时间内 I/O 较少。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。

当执行检查点时写入的数据量超过此数量时，就尝试强制 OS 把这些写发送到底层存储。这样做将会限制内核页面高速缓存中的脏数据数量，降低在检查点末尾发出 fsync 或者 OS 在后台大批量写回数据时被卡住的可能性。这通常能显著降低事务延迟，但是也有一些情况（特别是负载超过 shared_buffers 但小于 OS 页面高速缓存）的性能会降低。这种设置可能会在某些平台上没有效果。如果指定值时没有单位，则以块为单位，即为 BLCKSZ 字节，通常为 8kB。合法的范围在 0（禁用强制写回）和 2MB 之间。Linux 上的默认值是 256kB，其他平台上是 0（如果 BLCKSZ 不是 8kB，则默认值和最大值会按比例缩放到它）。这个参数只能在 postgresql.conf 文件中或者服务器命令行上设置。

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

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

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

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

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

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

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

用于归档已完成的 WAL 段文件的库。如果设置为空字符串（默认值），则通过 shell 进行归档，并使用 archive_command。如果 archive_command 和 archive_library 都被设置，则会报错。否则，指定的共享库用于归档。当此参数更改时，postmaster 会重新启动 WAL 归档进程。有关更多信息，请参见第 26.3.1 节和第 51 章。

这个参数只能在 postgresql.conf 文件中或者服务器命令行中设置。

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

是否在恢复期间尝试预取在 WAL 中引用但尚未在缓冲池中的块。有效值为 off，on 和 try（默认值）。设置 try 仅在操作系统提供 posix_fadvise 函数时才启用预取，该函数目前用于实现预取。请注意，一些操作系统提供该函数，但它不起作用。

预取即将需要的块可以减少某些工作负载下恢复期间的 I/O 等待时间。另请参阅 wal_decode_buffer_size 和 maintenance_io_concurrency 设置，限制预取活动。

服务器可以在 WAL 中查找预取块的最大提前量限制。如果未指定单位，则将其视为字节。默认值为 512kB。该参数只能在服务器启动时设置。

用于获取 WAL 文件系列的一个已归档段的本地 shell 命令。这个参数是归档恢复所必需的，但是对于流复制是可选的。在该字符串中的任何 %f 会被替换为从归档中获得的文件的名字，并且任何 %p 会被替换为服务器上的复制目标路径名（该路径名是相对于当前工作目录的，即集簇的数据目录）。任何 %r 会被包含上一个可用重启点的文件的名字所替换。在那些必须被保留用于使得一次恢复变成可重启的文件中，这个文件是其中最早的一个，因此这个信息可以被用来把归档截断为支持从当前恢复重启所需的最小值。%r 通常只被温备配置（见第 27.2 节）所使用。要嵌入一个真正的% 字符，需要写成%%。

很重要的一点是，该命令只有在成功时才返回一个为零的退出状态。该命令将会被要求获取归档中不存在的文件；遇到这种情况时，它必须返回非零。示例：

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

一个例外是如果该命令被一个信号（不是 SIGTERM，它是数据库服务器关闭的一部分）或者一个 shell 错误（例如命令未找到）终止，则恢复将会中止并且服务器将不会启动。

这个参数只能在 postgresql.conf 文件中或通过服务器命令行进行设置。

这个可选参数指定了一个 shell 命令，它将在每一个重启点被执行。archive_cleanup_command 的目的是提供一种清除不再被备库需要的旧的已归档 WAL 文件的机制。任何 %r 会被替换为包含最后一个可用重启点的文件的名称。这是为使恢复可重新启动而必须保留的最早文件，并且因此比 %r 更早的所有文件可以被安全地移除。这个信息可以被用来把归档截断为支持从当前恢复重启所需的最小值。对于单一备库配置，pg_archivecleanup 模块常常被用在 archive_cleanup_command 中，例如：

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

但是注意，如果多个备库正在从同一个归档目录中恢复，你将需要保证只有当所有服务器都不再需要这些 WAL 文件时才会删除它们。archive_cleanup_command 通常被用于一种温备配置（见第 27.2 节）中。要在该命令中嵌入一个真正的% 字符，需要写成%%。

如果该命令返回一个非零退出状态，则将会写出一个警告日志消息。一个例外是如果该命令被一个信号或者一个 shell 错误（例如命令未找到）终止，则会抛出一个致命错误。

这个参数只能在 postgresql.conf 文件中或通过服务器命令行进行设置。

这个参数指定了一个将只在恢复末尾被执行一次的 shell 命令。这个参数是可选的。recovery_end_command 的目的是为复制或恢复之后的清除提供一种机制。与 archive_cleanup_command 中相似，任何 %r 会被替换为包含最后一个可用重启点的文件的名称。

如果该命令返回一个非零退出状态，则一个警告日志消息将被写出并且不管怎样该数据库将继续启动。一个例外是如果该命令被一个信号或者 shell 错误（例如命令未找到）中止，该数据库将不会继续启动。

这个参数只能在 postgresql.conf 文件中或通过服务器命令行进行设置。

这个参数指定恢复应该在达到一个一致状态后尽快结束，即尽早结束。在从一个在线备份中恢复时，这意味着备份结束的那个点。

在技术上，这是一个字符串参数，但是'immediate' 是目前唯一允许的值。

这个参数指定（pg_create_restore_point() 所创建）的已命名的恢复点，恢复将进行到该恢复点。

此参数指定恢复要进行到的时间戳。精确的停止点还受到 recovery_target_inclusive 的影响。

此参数的值是一个时间戳，格式与 timestamp with time zone 数据类型所接受的格式相同，只不过你不能使用时区缩写（除非 timezone_abbreviations 变量在配置文件中已提前设置）。首选样式是使用 UTC 的数字偏移量，或者你可以写一个完整时区名称，例如 Europe/Helsinki 而不是 EEST。

这个参数指定恢复要进行到的事务 ID。记住虽然事务 ID 是在事务开始时顺序分配的，但是事务可能以不同的数字顺序完成。那些在指定事务之前（也可以包括该事务）提交的事务将被恢复。精确的停止点也受到 recovery_target_inclusive 的影响。

此参数指定恢复要进行到的预写日志位置的 LSN。精确的停止点也受 recovery_target_inclusive 的影响。使用系统数据类型 pg_lsn 解析此参数。

指定我们是否仅在指定的恢复目标之后停止（on），或者仅在恢复目标之前停止（off）。适用于 recovery_target_lsn、recovery_target_time 或者 recovery_target_xid 被指定的情况。这个设置控制恢复是否包含 WAL 位置（LSN）、提交时间或事务 ID 分别恰好等于目标值的事务。默认值为 on。

指定恢复到一个特定的时间线中。该值可以是数字时间线 ID 或特殊值。值 current 沿着与执行基础备份时相同的时间线恢复。值 latest 将恢复到归档中能找到的最新时间线，这在备库中很有用。latest 是默认值。

如果要以十六进制指定时间线 ID（例如从 WAL 文件名或历史文件中提取），请在前面加上 0x。例如，如果 WAL 文件名为 00000011000000A10000004F，那么时间线 ID 就是 0x11（十进制为 17）。

你通常只需要在复杂的再次恢复场景中设置此参数，也就是当你需要回到某个状态，而该状态本身又是在一次时间点恢复之后达到的。相关讨论见第 26.3.5 节。

指定在达到恢复目标时服务器应该立刻采取的动作。默认动作是 pause，这表示恢复将会被暂停。promote 表示恢复处理将会结束并且服务器将开始接受连接。最后，shutdown 将在达到恢复目标之后停止服务器。

使用 pause 设置的目的是允许对数据库执行查询，以检查这个恢复目标是否为最合适的恢复位置。暂停的状态可以使用 pg_wal_replay_resume()（见表 9.93）继续，这会让恢复终结。如果这个恢复目标不是想要的停止点，那么关闭服务器，将恢复目标设置改为一个稍后的目标并且重启以继续恢复。

要让实例在想要的重放点那里准备好，shutdown 设置可以派上用场。该实例将仍能重放更多 WAL 记录（并且事实上，下次启动时必须重新回放自上一个检查点以来的 WAL 记录）。

注意由于在 recovery_target_action 被设置为 shutdown 时，recovery.signal 将不会被移除，任何后续的启动都将会以立刻关闭为终结，除非该配置被改变或者 recovery.signal 文件被手工移除。

如果没有设置恢复目标，这个设置没有效果。如果没有启用 hot_standby，pause 设置的动作将和 shutdown 一样。如果在备库提升期间达到恢复目标，pause 的设置将与 promote 的行为相同。

在任何情况下，如果已配置了恢复目标，但归档恢复在达到目标之前结束，则服务器将关闭，并出现致命错误。