19.5. 预写式日志 #
参阅第 29.4 节获取调节这些设置的额外信息。
19.5.1. 设置 #
wal_level(enum) #wal_level决定多少信息写入到 WAL 中。默认值是replica，它会写入足够的数据以支持 WAL 归档和复制，包括在备库上运行只读查询。minimal会去掉除从崩溃或者立即关机中进行恢复所需的信息之外的所有记录。最后，logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置。在
minimal级别，可以安全地跳过一些批量操作的 WAL 日志记录，使这些操作快得多（参见第 14.4.7 节）。可以应用此优化的操作包括：CREATE TABLE ASCREATE INDEXCLUSTER向同一事务中创建或截断的表执行 COPY但 minimal 级别的 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只能在postgresql.conf文件中或在服务器命令行上设置。如果你关闭这个参数，请也考虑关闭 full_page_writes。synchronous_commit(enum) #指定数据库服务器向客户端返回“成功”指示之前，必须完成多少 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可以是一种有用的替代方案。更多讨论见第 29.3 节。如果 synchronous_standby_names 非空，
synchronous_commit还控制事务提交是否等待备库处理其 WAL 记录。设为
remote_apply时，提交会等待当前同步备库回复，确认已收到并应用该事务的提交记录，使其对备库上的查询可见，并且已将其写入备库的持久存储。由于需要等待 WAL 重放，这会比之前的设置产生大得多的提交延迟。设为on时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其刷写到持久存储。这能保证事务不会丢失，除非主库和所有同步备库的数据库存储都损坏。设为remote_write时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其写入各自的文件系统。此设置能保证备库上的 PostgreSQL 实例崩溃时数据不丢失，但不能保证备库发生操作系统级别崩溃时数据不丢失，因为数据未必已写入备库的持久存储。设为local时，提交会等待本地刷盘，但不等待复制。使用同步复制时通常不希望采用这种设置，提供它是为了使选项完整。此参数可以随时更改；每个事务的行为由提交时生效的设置决定。因此，让一些事务同步提交、另一些事务异步提交是可行且有用的。例如，当默认设置要求同步提交时，可以在一个包含多条语句的事务中执行
SET LOCAL synchronous_commit TO OFF，使该事务异步提交。表 19.1 汇总了
synchronous_commit各种设置具备的能力。表 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 中的默认值。默认值不一定最合适；可能需要更改此设置或系统配置的其他方面，以确保崩溃时的数据安全或达到最佳性能。这些方面在第 29.1 节中讨论。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。full_page_writes(boolean) #启用此参数时，PostgreSQL 服务器会在检查点之后首次修改每个磁盘页面时，将该页面的全部内容写入 WAL。这样做是因为，操作系统崩溃时正在进行的页面写入可能只完成了一部分，导致磁盘页面混有新旧数据。通常存储在 WAL 中的行级变更数据不足以在崩溃恢复时完整还原这样的页面。保存整页镜像能保证正确恢复页面，但会增加必须写入 WAL 的数据量。（由于 WAL 重放总是从检查点开始，只需在检查点之后首次修改每个页面时这样做。因此，减少整页写入开销的一种方法是增大检查点间隔参数。）
关闭此参数可以加快正常操作，但系统故障后可能出现不可恢复的数据损坏或静默数据损坏。风险与关闭
fsync类似，虽然较小，但也只有在建议关闭fsync的相同情形下，才应关闭此参数。关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见第 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_init_zero(boolean) #如果设置为
on（默认值），此选项会导致新的 WAL 文件被零填充。在某些文件系统上，这可确保在我们需要写入 WAL 记录之前分配空间。但是，写时复制（COW）文件系统可能不会从此技术中受益，因此可以选择跳过不必要的工作。如果设置为off，则在创建文件时只写入最后一个字节，以便其具有预期大小。wal_recycle(boolean) #如果设置为
on（默认值），此选项通过重命名来回收 WAL 文件，从而避免创建新文件。在 COW 文件系统上，创建新文件可能更快，因此提供了禁用此行为的选项。wal_buffers(integer) #用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于 shared_buffers 的 1/32 的尺寸（大约 3%），但是不小于
64kB也不大于 WAL 段的尺寸（通常为16MB）。如果自动的选择太大或太小可以手工设置该值，但是任何小于32kB的正值都将被当作32kB。如果指定值时没有单位，则以 WAL 块作为单位，即为XLOG_BLCKSZ字节，通常为 8kB。这个参数只能在服务器启动时设置。在每次事务提交时，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 数据总是会被立即刷写。如果指定值时没有单位，则以 WAL 块作为单位，即为XLOG_BLCKSZ字节，通常为 8kB。默认是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延迟前要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。
19.5.2. 检查点 #
checkpoint_timeout(integer) #自动 WAL 检查点之间的最长时间。如果指定值时没有单位，则以秒为单位。合理的范围在 30 秒到 1 天之间。默认是 5 分钟（
5min）。增加这个参数的值可能会增加崩溃恢复所需的时间。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。checkpoint_completion_target(floating point) #指定检查点完成的目标，作为检查点之间总时间的一部分。默认是 0.5。这个参数只能在
postgresql.conf文件中或在服务器命令行上设置。checkpoint_flush_after(integer) #当执行检查点时写入的数据量超过此数量时，就尝试强制 OS 把这些写发送到底层存储。这样做将会限制内核页面高速缓存中的脏数据数量，降低在检查点末尾发出
fsync或者 OS 在后台大批量写回数据时被卡住的可能性。这通常能显著降低事务延迟，但是也有一些情况（特别是负载超过 shared_buffers 但小于 OS 页面高速缓存）的性能会降低。这种设置可能会在某些平台上没有效果。如果指定值时没有单位，则以块为单位，即为BLCKSZ字节，通常为 8kB。合法的范围在0（禁用强制写回）和2MB之间。Linux 上的默认值是256kB，其他平台上是0（如果BLCKSZ不是 8kB，则默认值和最大值会按比例缩放到它）。这个参数只能在postgresql.conf文件中或者服务器命令行上设置。checkpoint_warning(integer) #如果由于填充 WAL 段文件导致的检查点之间的间隔低于这个参数表示的时间量，那么就向服务器日志写一个消息（它建议增加
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或者服务器命令行中设置。
19.5.3. 归档 #
archive_mode(enum) #当启用
archive_mode时，完成的 WAL 段会通过设置 archive_command 发送到归档存储。除了用于禁用归档的off外，还有两种模式：on和always。在正常操作期间，这两种模式之间没有区别，但当设置为always时，WAL 归档程序在归档恢复或备库模式下也会被启用。在always模式下，从归档中恢复的所有文件或通过流复制传输的文件将被再次归档。详细信息请参见第 26.2.9 节。archive_mode和archive_command是单独的变量，这样archive_command可以在不离开归档模式的情况下进行更改。此参数只能在服务器启动时设置。当wal_level设置为minimal时，无法启用archive_mode。archive_command(string) #本地 shell 命令被执行来归档一个完成的 WAL 文件段。字符串中的任何
%p被替换成要被归档的文件的路径名，而%f只被文件名替换（路径名是相对于服务器的工作目录，即集簇的数据目录）。如果要在命令里嵌入一个真正的%字符，可以使用%%。有一点很重要，该命令只在成功时返回一个零作为退出状态。更多信息请见第 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文件或服务器命令行中设置。
19.5.4. 归档恢复 #
本节介绍仅在恢复期间生效的设置。如果之后还要进行恢复，必须重新设置这些参数。
“恢复”涵盖使用服务器作为备库或用于执行目标恢复。通常情况，备库模式用于提供高可用性和/或读可扩展性，而目标恢复用于从数据丢失中恢复。
若要在备库模式下启动服务器，在数据目录中建立名为 standby.signal 的文件。服务器将会进入恢复状态并且在到达归档 WAL 末尾时不会停止恢复，但将保持尝试继续恢复，通过连接到 primary_conninfo 设置指定的发送服务器和/或用 restore_command 获取新的 WAL 分段。对于这种模式，来自本节的参数和第 19.6.3 节是值得关注的。第 19.5.5 节中的参数也会被应用，但通常在这种模式下没用。
要启动服务器为目标恢复模式，需在数据目录中建立名为 recovery.signal 的文件。如果同时创建了 standby.signal 和 recovery.signal 文件，则优先使用备库模式。目标恢复模式在归档的 WAL 全部回放或到达 recovery_target 时结束。在这种模式下，将使用来自本节和第 19.5.5 节的参数。
restore_command(string) #用于获取 WAL 文件系列的一个已归档段的本地 shell 命令。这个参数是归档恢复所必需的，但是对于流复制是可选的。在该字符串中的任何
%f会被替换为从归档中获得的文件的名字，并且任何%p会被在服务器上的复制目标路径名替换（该路径名是相对于当前工作目录的，即集簇的数据目录）。任何%r会被包含上一个可用重启点的文件的名字所替换。在那些必须被保留用于使得一次恢复变成可重启的文件中，这个文件是其中最早的一个，因此这个信息可以被用来把归档截断为支持从当前恢复重启所需的最小值。%r通常只被温备配置（见第 26.2 节）所使用。要嵌入一个真正的%字符，需要写成%%。很重要的一点是，该命令只有在成功时才返回一个为零的退出状态。该命令将会被要求获取归档中不存在的文件；遇到这种情况时，它必须返回非零。示例：
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
一个例外是如果该命令被一个信号（不是 SIGTERM，它是数据库服务器关闭的一部分）或者一个 shell 错误（例如命令未找到）终止，则恢复将会中止并且服务器将不会启动。
这个参数只能在服务器启动时设置。
archive_cleanup_command(string) #这个可选参数指定了一个 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通常被用于一种温备配置（见第 26.2 节）中。要在该命令中嵌入一个真正的%字符，需要写成%%。如果该命令返回一个非零退出状态，则将会写出一个警告日志消息。一个例外是如果该命令被一个信号或者一个 shell 错误（例如命令未找到）终止，则会抛出一个致命错误。
这个参数只能在
postgresql.conf文件中或通过服务器命令行进行设置。recovery_end_command(string) #这个参数指定了一个将只在恢复末尾被执行一次的 shell 命令。这个参数是可选的。
recovery_end_command的目的是为复制或恢复之后的清除提供一种机制。与 archive_cleanup_command 中相似，任何%r会被替换为包含最后一个可用重启点的文件的名称。如果该命令返回一个非零退出状态，则一个警告日志消息将被写出并且不管怎样该数据库将继续启动。一个例外是如果该命令被一个信号或者 shell 错误（例如命令未找到）中止，该数据库将不会继续启动。
这个参数只能在
postgresql.conf文件中或通过服务器命令行进行设置。
19.5.5. 恢复目标 #
默认情况下，恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。在 recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time 和 recovery_target_xid 中，最多只能使用一个，如果在配置文件中使用了多个，将会产生一个错误。这些参数只能在服务器启动时设置。
recovery_target= 'immediate'#这个参数指定恢复应该在达到一个一致状态后尽快结束，即尽早结束。在从一个在线备份中恢复时，这意味着备份结束的那个点。
在技术上，这是一个字符串参数，但是
'immediate'是目前唯一允许的值。recovery_target_name(string) #这个参数指定（
pg_create_restore_point()所创建）的已命名的恢复点，恢复将进行到该恢复点。recovery_target_time(timestamp) #此参数指定恢复要进行到的时间戳。精确的停止点还受到 recovery_target_inclusive 的影响。
此参数的值是一个被
timestamp with time zone数据类型接受的相同格式的时间戳，只不过你不能使用时区缩写（除非 timezone_abbreviations 变量在配置文件中已提前设置）。首选样式是使用 UTC 的数字偏移量，或者你可以写一个完整时区名称，例如Europe/Helsinki而不是EEST。recovery_target_xid(string) #这个参数指定恢复要进行到的事务 ID。记住虽然事务 ID 是在事务开始时顺序分配的，但是事务可能以不同的数字顺序完成。那些在指定事务之前（也可以包括该事务）提交的事务将被恢复。精确的停止点也受到 recovery_target_inclusive 的影响。
recovery_target_lsn(pg_lsn) #此参数指定恢复要进行到的预写日志位置的 LSN。精确的停止点也受 recovery_target_inclusive 的影响。使用系统数据类型
pg_lsn解析此参数。
下列选项进一步指定恢复目标，并且影响到达目标时会发生什么：
recovery_target_inclusive(boolean) #指定我们是否仅在指定的恢复目标之后停止（
on），或者仅在恢复目标之前停止（off）。适用于 recovery_target_lsn、recovery_target_time 或者 recovery_target_xid 被指定的情况。这个设置控制恢复是否包含 WAL 位置（LSN）、提交时间或事务 ID 分别恰好等于目标值的事务。默认值为on。recovery_target_timeline(string) #指定恢复到一个特定的时间线中。该值可以是数字时间线 ID 或特殊值。值
current沿着与执行基础备份时相同的时间线恢复。值latest将恢复到归档中能找到的最新时间线，这在备库中很有用。latest是默认值。你通常只需要在复杂的再次恢复场景中设置此参数，也就是当你需要回到某个状态，而该状态本身又是在一次时间点恢复之后达到的。相关讨论见第 25.3.5 节。
recovery_target_action(enum) #指定在达到恢复目标时服务器应该立刻采取的动作。默认动作是
pause，这表示恢复将会被暂停。promote表示恢复处理将会结束并且服务器将开始接受连接。最后，shutdown将在达到恢复目标之后停止服务器。使用
pause设置的目的是允许对数据库执行查询，以检查这个恢复目标是否为最合适的恢复位置。暂停的状态可以使用pg_wal_replay_resume()（见表 9.86）继续，这会让恢复终结。如果这个恢复目标不是想要的停止点，那么关闭服务器，将恢复目标设置改为一个稍后的目标并且重启以继续恢复。要让实例在想要的重放点那里准备好，
shutdown设置可以派上用场。该实例将仍能重放更多 WAL 记录（并且事实上，下次启动时必须重新回放自上一个检查点以来的 WAL 记录）。注意由于在
recovery_target_action被设置为shutdown时，recovery.signal将不会被移除，任何后续的启动都将会以立刻关闭为终结，除非该配置被改变或者recovery.signal文件被手工移除。如果没有设置恢复目标，此设置无效。如果没有启用 hot_standby，
pause设置的行为将与shutdown相同。