登录20.5. 预写日志#
有关调整这些设置的其他信息，请参见第 30.5 节。
20.5.1. 设置#
wal_level(enum) #wal_level决定了写入 WAL 中的信息量。默认值为replica，它写入足够的数据来支持 WAL 归档和复制，包括在备用服务器上运行只读查询。minimal删除了除从崩溃或立即关机中恢复所需的信息之外的所有日志记录。最后，logical添加了支持逻辑解码所需的信息。每个级别都包括所有较低级别记录的信息。此参数只能在服务器启动时设置。minimal级别会生成最少的 WAL 卷。它不会记录在创建或重写它们的交易中永久关系的行信息。这可以使操作快得多（请参阅 第 14.4.7 节）。启动此优化的操作包括ALTER ... SET TABLESPACECLUSTERCREATE TABLEREFRESH MATERIALIZED VIEW（没有CONCURRENTLY）REINDEXTRUNCATE但是，最小 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。fsync(boolean) #如果此参数处于开启状态，PostgreSQL 服务器将尝试通过发出
fsync()系统调用或各种等效方法（请参阅 wal_sync_method）来确保更新已物理写入磁盘。这可确保数据库集群在操作系统或硬件崩溃后恢复到一致状态。虽然关闭
fsync通常会带来性能优势，但这可能会在断电或系统崩溃时导致无法恢复的数据损坏。因此，只有在您可以轻松地从外部数据重新创建整个数据库时，才建议关闭fsync。关闭
fsync的安全情况示例包括从备份文件加载新数据库集群的初始加载，使用数据库集群处理一批数据（之后数据库将被丢弃并重新创建），或用于只读数据库克隆（经常重新创建且不用于故障转移）。仅靠高质量硬件不足以关闭fsync。在将
fsync从关闭更改为开启时，为实现可靠恢复，必须强制内核中的所有已修改缓冲区进入持久存储。这可以在集群关闭时或通过运行initdb --sync-only、运行sync、卸载文件系统或重新启动服务器来实现fsync开启时。在许多情况下，为非关键事务关闭 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可能是一种有用的替代方案。有关更多讨论，请参见 第 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设置的功能。表 20.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 文件）
并非所有这些选项在所有平台上都可用。默认值是上述列表中平台支持的第一个方法，但
fdatasync是 Linux 和 FreeBSD 上的默认值。默认值不一定是理想的；可能需要更改此设置或系统配置的其他方面，以便创建防崩溃配置或实现最佳性能。这些方面在 第 30.1 节 中进行了讨论。此参数只能在postgresql.conf文件或服务器命令行中设置。full_page_writes(boolean) #当此参数开启时，PostgreSQL 服务器在检查点后对该页面进行首次修改期间，将每个磁盘页面的全部内容写入 WAL。这是必需的，因为在操作系统崩溃期间正在进行的页面写入可能仅部分完成，导致磁盘页面包含旧数据和新数据的混合。在崩溃后恢复期间，通常存储在 WAL 中的行级更改数据不足以完全恢复此类页面。存储完整页面映像可确保页面可以正确恢复，但代价是增加必须写入 WAL 的数据量。（由于 WAL 重放总是从检查点开始，因此在检查点后每次对每个页面进行首次更改时执行此操作就足够了。因此，降低全页写入成本的一种方法是增加检查点间隔参数。）
关闭此参数会加快正常操作，但可能在系统故障后导致无法恢复的数据损坏或静默数据损坏。风险类似于关闭
fsync，但较小，并且应该仅在为该参数推荐的相同情况下才将其关闭。关闭此参数不会影响将 WAL 归档用于时间点恢复 (PITR)（请参见 第 26.3 节）。
此参数只能在
postgresql.conf文件或服务器命令行中设置。默认值为on。wal_log_hints(boolean) #当此参数为
on时，PostgreSQL 服务器在检查点后对该页面进行首次修改期间，将每个磁盘页面的全部内容写入 WAL，即使是对所谓的提示位的非关键修改也是如此。如果启用了数据校验和，则提示位更新始终记录在 WAL 中，并且忽略此设置。您可以使用此设置来测试如果您的数据库启用了数据校验和，将产生多少额外的 WAL 日志记录。
此参数只能在服务器启动时设置。默认值为
off。wal_compression(enum) #此参数使用指定的压缩方法启用 WAL 压缩。启用后，PostgreSQL 服务器在 full_page_writes 开启时或在基本备份期间将写入 WAL 的完整页面映像进行压缩。在 WAL 重放期间将对压缩的页面映像进行解压缩。支持的方法有
pglz、lz4（如果 PostgreSQL 使用--with-lz4编译）和zstd（如果 PostgreSQL 使用--with-zstd编译）。默认值为off。只有超级用户和具有相应SET权限的用户才能更改此设置。启用压缩可以减少 WAL 卷，而不会增加数据损坏无法恢复的风险，但代价是在 WAL 记录期间的压缩和 WAL 重放期间的解压上花费一些额外的 CPU。
wal_init_zero(boolean) #如果设置为
on（默认值），此选项将导致用零填充新的 WAL 文件。在某些文件系统上，这可确保在需要写入 WAL 记录之前分配空间。但是，写时复制 (COW) 文件系统可能无法从该技术中受益，因此提供了跳过不必要工作的选项。如果设置为off，则仅在创建文件时写入最后一个字节，以便它具有预期的尺寸。wal_recycle(boolean) #如果设置为
on（默认值），此选项将导致通过重命名 WAL 文件来回收它们，从而避免了创建新 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文件或服务器命令行中设置。wal_skip_threshold(integer) #当
wal_level为minimal且一个事务在创建或重写一个永久关系后提交，此设置决定如何持久化新数据。如果数据小于此设置，则将其写入 WAL 日志；否则，使用受影响文件的 fsync。根据存储的属性，如果此类提交减慢并发事务，则提高或降低此值可能会有所帮助。如果未指定此值单位，则将其视为千字节。默认值为两兆字节 (2MB)。commit_delay(integer) #设置
commit_delay会在启动 WAL 刷新之前增加一个时间延迟。如果系统负载足够高，从而在给定时间间隔内有更多事务准备提交，则这可以通过允许更多事务通过单个 WAL 刷新提交来提高组提交吞吐量。但是，它也会使每个 WAL 刷新延迟最多commit_delay。由于如果没有其他事务准备提交，延迟就会浪费，因此只有当在即将启动刷新时至少有commit_siblings其他事务处于活动状态时才会执行延迟。此外，如果禁用了fsync，则不会执行延迟。如果未指定此值单位，则将其视为微秒。默认commit_delay为零（无延迟）。只有超级用户和具有适当SET权限的用户才能更改此设置。在 9.3 之前的 PostgreSQL 版本中，
commit_delay的行为不同，效果差得多：它只影响提交，而不是所有 WAL 刷新，并且即使 WAL 刷新提前完成，也会等待整个配置的延迟。从 PostgreSQL 9.3 开始，第一个准备好刷新的进程会等待配置的时间间隔，而后续进程只会等到领导者完成刷新操作。commit_siblings(integer) #在执行
commit_delay延迟之前所需的并发打开事务的最小数量。较大的值使在延迟间隔内至少有一个其他事务准备好提交的可能性更大。默认值为五个事务。
20.5.2. 检查点#
checkpoint_timeout(integer) #自动 WAL 检查点之间的最长时间。如果未指定此值单位，则将其视为秒。有效范围介于 30 秒到一天之间。默认值为五分钟 (
5min)。增加此参数可能会增加崩溃恢复所需的时间。此参数只能在postgresql.conf文件或服务器命令行中设置。checkpoint_completion_target(floating point) #指定检查点完成的目标，作为检查点之间总时间的几分之一。默认值为 0.9，这会将检查点分布在几乎所有可用间隔中，从而提供相当一致的 I/O 负载，同时还留出一些时间用于检查点完成开销。不建议降低此参数，因为它会导致检查点更快完成。这会导致在检查点期间 I/O 速率较高，然后在检查点完成和下一个计划检查点之间出现 I/O 较少的时段。此参数只能在
postgresql.conf文件或服务器命令行中设置。checkpoint_flush_after(integer) #每当在执行检查点时写入的数据量超过此值时，尝试强制操作系统将这些写入发送到底层存储。这样做将限制内核页面缓存中的脏数据量，从而降低在检查点结束时发出
fsync，或当操作系统在后台以较大批次回写数据时出现停滞的可能性。通常，这将极大地减少事务延迟，但也有一些情况，尤其是在工作负载大于 shared_buffers 但小于操作系统页面缓存的情况下，性能可能会下降。此设置在某些平台上可能无效。如果未指定此值单位，则将其视为块，即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或archive_library失败或wal_keep_size设置过高时，WAL 大小可能会超过max_wal_size。如果未指定单位，则此值将作为兆字节。默认值为 1 GB。增加此参数可能会增加崩溃恢复所需的时间。此参数只能在postgresql.conf文件或服务器命令行中设置。min_wal_size(integer) #只要 WAL 磁盘使用率保持低于此设置，旧的 WAL 文件就会在检查点处始终回收以供将来使用，而不是删除。这可用于确保保留足够的 WAL 空间来处理 WAL 使用率的峰值，例如在运行大型批处理作业时。如果未指定单位，则此值将作为兆字节。默认值为 80 MB。此参数只能在
postgresql.conf文件或服务器命令行中设置。
20.5.3. 归档#
archive_mode(enum) #当启用
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。archive_command(string) #用于归档已完成的 WAL 文件段的本地 shell 命令。字符串中的任何
%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 文件链，因此仅应在特殊情况下使用。archive_library(string) #用于归档已完成的 WAL 文件段的库。如果设置为一个空字符串（默认值），则启用通过 shell 进行归档，并使用 archive_command。如果同时设置
archive_command和archive_library，则会引发错误。否则，将使用指定的共享库进行归档。当此参数更改时，WAL 归档器进程由后端重新启动。有关更多信息，请参阅 第 26.3.1 节 和 第 51 章。此参数只能在
postgresql.conf文件或服务器命令行中设置。archive_timeout(integer) #仅对已完成 WAL 段调用 archive_command 或 archive_library。因此，如果服务器产生的 WAL 流量较小（或有空闲期），则事务完成与其在归档存储中安全记录之间可能会有很长的延迟。要限制未归档数据的旧程度，可以设置
archive_timeout以强制服务器定期切换到新的 WAL 段文件。当此参数大于零时，服务器将在自上次段文件切换以来经过此时间量并且有任何数据库活动（包括单个检查点）时切换到新的段文件（如果没有数据库活动，则跳过检查点）。请注意，由于强制切换而提前关闭的归档文件仍然与完全满的文件长度相同。因此，不建议使用非常短的archive_timeout— 它会使归档存储膨胀。通常，一分钟左右的archive_timeout设置是合理的。如果您希望数据比这更快地从主服务器复制，则应考虑使用流复制，而不是归档。如果未指定此值单位，则将其视为秒。此参数只能在postgresql.conf文件或服务器命令行中设置。
20.5.4. 恢复#
本节介绍适用于一般恢复的设置，影响崩溃恢复、流复制和基于归档的复制。
recovery_prefetch(enum) #在恢复期间，是否尝试预取 WAL 中引用的但尚未在缓冲池中的块。有效值是
off、on和try（默认值）。设置try仅在操作系统提供posix_fadvise函数时启用预取，该函数当前用于实现预取。请注意，某些操作系统提供了该函数，但它不起作用。预取即将需要的块可以减少某些工作负载在恢复期间的 I/O 等待时间。另请参阅 wal_decode_buffer_size 和 maintenance_io_concurrency 设置，它们限制预取活动。
wal_decode_buffer_size(integer) #限制服务器在 WAL 中向前查找以查找要预取的块的距离。如果未指定单位，则此值将以字节为单位。默认值为 512kB。
20.5.5. 归档恢复#
本节描述仅适用于恢复期间的设置。对于要执行的任何后续恢复，都必须重置这些设置。
“恢复”涵盖将服务器用作备用服务器或执行目标恢复。通常，备用模式用于提供高可用性和/或读取可扩展性，而目标恢复用于从数据丢失中恢复。
要在备用模式下启动服务器，请在数据目录中创建一个名为standby.signal的文件。服务器将进入恢复状态，并且在达到已归档 WAL 的末尾时不会停止恢复，而是会通过连接到primary_conninfo设置指定的发送服务器和/或使用restore_command获取新的 WAL 段来继续尝试恢复。对于此模式，本节和第 20.6.3 节中的参数很重要。来自第 20.5.6 节的参数也将应用，但通常在此模式下无用。
要在目标恢复模式下启动服务器，请在数据目录中创建一个名为recovery.signal的文件。如果创建了standby.signal和recovery.signal文件，则备用模式优先。当已归档的 WAL 完全重放或达到recovery_target时，目标恢复模式结束。在此模式下，将使用本节和第 20.5.6 节中的参数。
restore_command(string) #要执行的本地 shell 命令以检索 WAL 文件系列的已归档段。归档恢复需要此参数，但流复制不需要。字符串中的任何
%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文件或服务器命令行中设置。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通常用于热备用配置（请参阅第 27.2 节）。编写%%以在命令中嵌入实际%字符。如果命令返回非零退出状态，则将写入警告日志消息。一个例外是，如果命令被信号或 shell 错误（例如未找到命令）终止，则会引发致命错误。
此参数只能在
postgresql.conf文件或服务器命令行中设置。recovery_end_command(string) #此参数指定一个 shell 命令，该命令仅在恢复结束时执行一次。此参数是可选的。
recovery_end_command的目的是提供一种机制，以便在复制或恢复后进行清理。任何%r都将替换为包含最后一个有效重启点的文件的文件名，如 archive_cleanup_command 中所示。如果命令返回非零退出状态，则将编写一条警告日志消息，并且数据库将继续启动。但如果命令是由信号或 shell 错误（例如命令未找到）终止的，则数据库将不会继续启动。
此参数只能在
postgresql.conf文件或服务器命令行中设置。
20.5.6. 恢复目标#
默认情况下，恢复将恢复到 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是默认值。要以十六进制指定时间线 ID（例如，从 WAL 文件名或历史文件中提取），请在前面加上
0x。例如，如果 WAL 文件名为00000011000000A10000004F，则时间线 ID 为0x11（或十进制 17）。通常，你只需要在复杂重新恢复情况下设置此参数，在该情况下，你需要返回到在时间点恢复后达到的状态。请参阅 第 26.3.5 节 进行讨论。
recovery_target_action(enum) #指定服务器在达到恢复目标后应采取的操作。默认值为
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相同。在任何情况下，如果配置了恢复目标，但归档恢复在达到目标之前结束，服务器将以致命错误关闭。