## 20.5. Write Ahead Log

[20.5.1. Settings](runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS)

[20.5.2. Checkpoints](runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS)

[20.5.3. Archiving](runtime-config-wal.html#RUNTIME-CONFIG-WAL-ARCHIVING)

[20.5.4. Archive Recovery](runtime-config-wal.html#RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY)

[20.5.5. Recovery Target](runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET)

For additional information on tuning these settings, see[Section 30.5](wal-configuration.html).

### 20.5.1. Settings

`wal_level`(`enum`)[](<>)

`wal_level`determines how much information is written to the WAL. The default value is`replica`, which writes enough data to support WAL archiving and replication, including running read-only queries on a standby server.`minimal`removes all logging except the information required to recover from a crash or immediate shutdown. Finally,`logical`adds information necessary to support logical decoding. Each level includes the information logged at all lower levels. This parameter can only be set at server start.

In`minimal`level, no information is logged for permanent relations for the remainder of a transaction that creates or rewrites them. This can make operations much faster (see[Section 14.4.7](populate.html#POPULATE-PITR)). Operations that initiate this optimization include:

| `ALTER ... SET TABLESPACE` |
| -------------------------- |
| `CLUSTER` |
| `CREATE TABLE` |
| `刷新物化视图`（没有`同时`) |
| `重新索引` |
| `截短` |

但是最小 WAL 不包含足够的信息来从基本备份和 WAL 日志中重建数据，所以`复制品`必须使用或更高版本才能启用 WAL 归档（[档案\_模式](runtime-config-wal.html#GUC-ARCHIVE-MODE)) 和流复制。注意改变`wal_level`到`最小的`使之前进行的任何基础备份无法用于存档恢复和备用服务器，这可能会导致数据丢失。

在`合乎逻辑的`级别，记录相同的信息`复制品`，加上允许从 WAL 中提取逻辑更改集所需的信息。使用水平`合乎逻辑的`将增加 WAL 卷，特别是如果配置了许多表`副本身份已满`和许多`更新`和`删除`语句被执行。

In releases prior to 9.6, this parameter also allowed the values`archive`and`hot_standby`. These are still accepted but mapped to`replica`.

`fsync`(`boolean`)[](<>)

If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing`fsync()`system calls or various equivalent methods (see[wal_sync_method](runtime-config-wal.html#GUC-WAL-SYNC-METHOD)). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.

While turning off`fsync`is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off`fsync`if you can easily recreate your entire database from external data.

Examples of safe circumstances for turning off`fsync`include the initial loading of a new database cluster from a backup file, using a database cluster for processing a batch of data after which the database will be thrown away and recreated, or for a read-only database clone which gets recreated frequently and is not used for failover. High quality hardware alone is not a sufficient justification for turning off`fsync`.

更换时可靠恢复`同步`从关闭到打开，必须强制内核中所有修改的缓冲区到持久存储。这可以在集群关闭或`同步`通过运行开启`initdb --sync-only`， 跑步`同步`、卸载文件系统或重新启动服务器。

在许多情况下，关闭[同步\_犯罪](runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT)对于非关键事务可以提供关闭的许多潜在性能优势`同步`，没有数据损坏的伴随风险。

`同步`只能设置在`postgresql.conf`文件或在服务器命令行上。如果关闭这个参数，也要考虑关闭[满的\_页\_写](runtime-config-wal.html#GUC-FULL-PAGE-WRITES).

`同步提交`(`枚举`)[](<>)

指定在数据库服务器向客户端返回“成功”指示之前必须完成多少 WAL 处理。有效值为`远程应用`,`在`（默认），`远程写入`,`当地的`， 和`离开`.

如果`同步待机名称`为空，唯一有意义的设置是`在`和`离开`;`远程应用`,`远程写入`和`当地的`都提供相同的本地同步级别`在`.所有非本地行为`离开`模式是等待 WAL 本地刷新到磁盘。在`离开`模式下，没有等待，因此在向客户端报告成功与稍后保证事务可以安全防止服务器崩溃之间可能会有延迟。（最大延迟三倍[wal_writer_delay](runtime-config-wal.html#GUC-WAL-WRITER-DELAY).) Unlike[fsync](runtime-config-wal.html#GUC-FSYNC), setting this parameter to`off`does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning`synchronous_commit`off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see[Section 30.4](wal-async-commit.html).

If[synchronous_standby_names](runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES)is non-empty,`synchronous_commit`also controls whether transaction commits will wait for their WAL records to be processed on the standby server(s).

When set to`remote_apply`, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s), and also written to durable storage on the standbys. This will cause much larger commit delays than previous settings since it waits for WAL replay. When set to`on`, commits wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to durable storage. This ensures the transaction will not be lost unless both the primary and all synchronous standbys suffer corruption of their database storage. When set to`remote_write`, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and written it to their file systems. This setting ensures data preservation if a standby instance of PostgreSQL crashes, but not if the standby suffers an operating-system-level crash because the data has not necessarily reached durable storage on the standby. The setting`local`causes commits to wait for local flush to disk, but not for replication. This is usually not desirable when synchronous replication is in use, but is provided for completeness.

This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue`SET LOCAL synchronous_commit TO OFF`within the transaction.

[Table 20.1](runtime-config-wal.html#SYNCHRONOUS-COMMIT-MATRIX)summarizes the capabilities of the`synchronous_commit`settings.

**Table 20.1. synchronous_commit Modes**

| synchronous_commit setting | local durable commit | standby durable commit after PG crash | standby durable commit after OS crash | standby query consistency |
| -------------------------- | -------------------- | ------------------------------------- | ------------------------------------- | ------------------------- |
| remote_apply | • | • | • | • |
| on | • | • | • |  |
| 偏僻的\_写 | • | • |  |  |
| 当地的 | • |  |  |  |
| 离开 |  |  |  |  |

`wal_sync_method`(`枚举`)[](<>)

用于强制 WAL 更新到磁盘的方法。如果`同步`关闭则此设置无关紧要，因为 WAL 文件更新根本不会被强制退出。可能的值为：

-   `open_datasync`（写 WAL 文件`打开（）`选项`O_DSYNC`)

-   `数据同步`（称呼`数据同步（）`在每次提交时）

-   `同步`（称呼`同步（）`在每次提交时）

-   `fsync_writethrough`(call`fsync()`at each commit, forcing write-through of any disk write cache)

-   `open_sync`(write WAL files with`open()`option`O_SYNC`)

    The`open_`\*options also use`O_DIRECT`if available. Not all of these choices are available on all platforms. The default is the first method in the above list that is supported by the platform, except that`fdatasync`is the default on Linux and FreeBSD. The default is not necessarily ideal; it might be necessary to change this setting or other aspects of your system configuration in order to create a crash-safe configuration or achieve optimal performance. These aspects are discussed in[Section 30.1](wal-reliability.html). This parameter can only be set in the`postgresql.conf`file or on the server command line.

`full_page_writes`(`boolean`)[](<>)

When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint. This is needed because a page write that is in process during an operating system crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WAL will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at the price of increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.)

Turning this parameter off speeds normal operation, but might lead to either unrecoverable data corruption, or silent data corruption, after a system failure. The risks are similar to turning off`fsync`, though smaller, and it should be turned off only based on the same circumstances recommended for that parameter.

Turning off this parameter does not affect use of WAL archiving for point-in-time recovery (PITR) (see[第 26.3 节](continuous-archiving.html)）。

该参数只能在`postgresql.conf`文件或在服务器命令行上。默认是`在`.

`wal_log_hints`(`布尔值`)[](<>)

当这个参数是`在`，PostgreSQL 服务器在检查点之后对该页面的第一次修改期间将每个磁盘页面的全部内容写入 WAL，即使对于所谓的提示位的非关键修改也是如此。

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

此参数只能在服务器启动时设置。默认值为`离开`.

`wal_compression`(`布尔值`)[](<>)

当这个参数是`在`, PostgreSQL 服务器压缩整页图像写入 WAL 时[满的\_页\_写](runtime-config-wal.html#GUC-FULL-PAGE-WRITES)正在或正在进行基本备份。在 WAL 重放期间将解压缩压缩的页面图像。默认值为`离开`.只有超级用户可以更改此设置。

打开这个参数可以减少 WAL 的体积，而不会增加不可恢复的数据损坏的风险，但代价是在 WAL 日志记录期间的压缩和 WAL 重放期间的解压缩上花费了一些额外的 CPU。

`wal_init_zero`(`布尔值`)[](<>)

如果设置为`在`（默认），此选项导致新的 WAL 文件用零填充。在某些文件系统上，这可以确保在我们需要写入 WAL 记录之前分配空间。然而，*写时复制*(COW) 文件系统可能无法从这种技术中受益，因此可以选择跳过不必要的工作。如果设置为`离开`, 创建文件时只写入最后一个字节，使其具有预期的大小。

`wal_recycle`(`布尔值`)[](<>)

如果设置为`在`（默认值），此选项会通过重命名 WAL 文件来回收它们，从而避免创建新文件的需要。在 COW 文件系统上，创建新文件系统可能更快，因此可以选择禁用此行为。

`wal_buffers`(`整数`)[](<>)

用于尚未写入磁盘的 WAL 数据的共享内存量。默认设置 -1 选择等于 1/32（约 3%）的大小[共享\_缓冲区](runtime-config-resource.html#GUC-SHARED-BUFFERS), but not less than`64kB`nor more than the size of one WAL segment, typically`16MB`. This value can be set manually if the automatic choice is too large or too small, but any positive value less than`32kB`will be treated as`32kB`. If this value is specified without units, it is taken as WAL blocks, that is`XLOG_BLCKSZ`bytes, typically 8kB. This parameter can only be set at server start.

The contents of the WAL buffers are written out to disk at every transaction commit, so extremely large values are unlikely to provide a significant benefit. However, setting this value to at least a few megabytes can improve write performance on a busy server where many clients are committing at once. The auto-tuning selected by the default setting of -1 should give reasonable results in most cases.

`wal_writer_delay`(`integer`)[](<>)

Specifies how often the WAL writer flushes WAL, in time terms. After flushing WAL the writer sleeps for the length of time given by`wal_writer_delay`, unless woken up sooner by an asynchronously committing transaction. If the last flush happened less than`wal_writer_delay`ago and less than`wal_writer_flush_after`worth of WAL has been produced since, then WAL is only written to the operating system, not flushed to disk. If this value is specified without units, it is taken as milliseconds. The default value is 200 milliseconds (`200ms`). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting`wal_writer_delay`to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the`postgresql.conf`file or on the server command line.

`wal_writer_flush_after`(`整数`)[](<>)

指定 WAL writer 刷新 WAL 的频率，以数量为单位。如果最后一次刷新发生少于`wal_writer_delay`以前且小于`wal_writer_flush_after`价值 WAL 已经产生，然后 WAL 只写入操作系统，而不是刷新到磁盘。如果`wal_writer_flush_after`设定为`0`然后 WAL 数据总是立即刷新。如果这个值没有指定单位，则将其视为 WAL 块，即`XLOG_BLCKSZ`字节，通常为 8kB。默认是`1MB`.该参数只能在`postgresql.conf`文件或在服务器命令行上。

`wal_skip_threshold`(`整数`)[](<>)

什么时候`wal_level`是`最小的`并且在创建或重写永久关系后提交事务，此设置决定如何持久化新数据。如果数据小于此设置，则将其写入 WAL 日志；否则，请使用受影响文件的 fsync。根据存储的属性，如果此类提交会减慢并发事务，则提高或降低此值可能会有所帮助。如果此值指定为不带单位，则以千字节为单位。默认值为 2 MB (`2MB`）。

`提交延迟`(`integer`)[](<>)

Setting`commit_delay`adds a time delay before a WAL flush is initiated. This can improve group commit throughput by allowing a larger number of transactions to commit via a single WAL flush, if system load is high enough that additional transactions become ready to commit within the given interval. However, it also increases latency by up to the`commit_delay`for each WAL flush. Because the delay is just wasted if no other transactions become ready to commit, a delay is only performed if at least`commit_siblings`other transactions are active when a flush is about to be initiated. Also, no delays are performed if`fsync`is disabled. If this value is specified without units, it is taken as microseconds. The default`commit_delay`is zero (no delay). Only superusers can change this setting.

In PostgreSQL releases prior to 9.3,`commit_delay`behaved differently and was much less effective: it affected only commits, rather than all WAL flushes, and waited for the entire configured delay even if the WAL flush was completed sooner. Beginning in PostgreSQL 9.3, the first process that becomes ready to flush waits for the configured interval, while subsequent processes wait only until the leader completes the flush operation.

`commit_siblings`(`integer`)[](<>)

Minimum number of concurrent open transactions to require before performing the`commit_delay`delay. A larger value makes it more probable that at least one other transaction will become ready to commit during the delay interval. The default is five transactions.

### 20.5.2. Checkpoints

`checkpoint_timeout`(`integer`)[](<>)

Maximum time between automatic WAL checkpoints. If this value is specified without units, it is taken as seconds. The valid range is between 30 seconds and one day. The default is five minutes (`5分钟`）。增加此参数可以增加崩溃恢复所需的时间。该参数只能在`postgresql.conf`文件或在服务器命令行上。

`checkpoint_completion_target`(`浮点`)[](<>)

指定检查点完成的目标，作为检查点之间总时间的一部分。默认值为 0.9，它将检查点分布在几乎所有可用的时间间隔中，提供相当一致的 I/O 负载，同时也为检查点完成开销留出一些时间。不建议减小此参数，因为它会导致检查点更快地完成。这导致检查点期间的 I/O 速率更高，然后在检查点完成和下一个计划检查点之间的 I/O 时间段较少。该参数只能在`postgresql.conf`文件或在服务器命令行上。

`checkpoint_flush_after`(`整数`)[](<>)

每当在执行检查点时写入超过此数量的数据时，尝试强制操作系统将这些写入发出到底层存储。这样做将限制内核页面缓存中的脏数据量，从而减少在`同步`在检查点结束时发出，或者当操作系统在后台大批量写回数据时发出。通常这会大大减少事务延迟，但也有一些情况，尤其是工作负载大于[共享\_缓冲区](runtime-config-resource.html#GUC-SHARED-BUFFERS)，但小于操作系统的页面缓存，性能可能会降低。此设置在某些平台上可能无效。如果指定这个值没有单位，它被视为块，即`BLCKSZ`字节，通常为 8kB。有效范围介于`0`，它禁用强制写回，并且`2MB`.默认是`256kB`在 Linux 上，`0`别处。（如果`BLCKSZ`不是 8kB，默认值和最大值与之成比例。）此参数只能在`postgresql.conf`文件或在服务器命令行上。

`checkpoint_warning`(`整数`)[](<>)

如果由填充 WAL 段文件引起的检查点发生的时间比这个时间更近，则向服务器日志写入一条消息（这表明`max_wal_size`应该提高）。如果指定此值没有单位，则以秒为单位。默认值为 30 秒（`30 多岁`）。零禁用警告。如果出现以下情况，则不会生成警告`checkpoint_timeout`小于`checkpoint_warning`.该参数只能在`postgresql.conf`文件或在服务器命令行上。

`max_wal_size`(`整数`)[](<>)

在自动检查点期间让 WAL 增长的最大大小。这是一个软限制；WAL 大小可以超过`max_wal_size`在特殊情况下，如重载、故障`归档命令`，或高`wal_keep_尺码`背景如果指定此值时没有单位，则将其视为兆字节。默认值为1GB。增加此参数可以增加崩溃恢复所需的时间。此参数只能在`postgresql。形态`文件或在服务器命令行上。

`最小尺寸`(`整数`)[](<>)

只要WAL磁盘使用率低于此设置，旧的WAL文件就会被回收，以便将来在检查点使用，而不是删除。这可以用来确保保留足够的WAL空间，以处理WAL使用的峰值，例如在运行大批量作业时。如果指定此值时没有单位，则将其视为兆字节。默认值为80MB。此参数只能在`postgresql。形态`文件或在服务器命令行上。

### 20.5.3.存档

`存档模式`(`枚举`)[](<>)

什么时候`存档模式`如果启用，则通过设置将已完成的WA段发送到存档存储[档案文件\_命令](runtime-config-wal.html#GUC-ARCHIVE-COMMAND).除了`关`，要禁用，有两种模式：`在…上`和`总是`.在正常运行期间，两种模式之间没有差异，但当设置为`总是`WAL 归档程序也在归档恢复或待机模式期间启用。在`总是`模式下，所有从存档中恢复的文件或通过流复制流式传输的所有文件都将被存档（再次）。看[第 27.2.9 节](warm-standby.html#CONTINUOUS-ARCHIVING-IN-STANDBY)详情。

`归档模式`和`归档命令`是单独的变量，因此`归档命令`可以在不离开存档模式的情况下进行更改。此参数只能在服务器启动时设置。`归档模式`无法启用时`wal_level`被设定为`最小的`.

`归档命令`(`细绳`)[](<>)

要执行以归档已完成的 WAL 文件段的本地 shell 命令。任何`%p`字符串中的替换为要归档的文件的路径名，以及任何`％F`仅由文件名替换。（路径名是相对于服务器的工作目录，即集群的数据目录。）使用`%%`嵌入一​​个实际的`%`命令中的字符。该命令只有在成功时才返回零退出状态，这一点很重要。有关更多信息，请参阅[Section 26.3.1](continuous-archiving.html#BACKUP-ARCHIVING-WAL).

This parameter can only be set in the`postgresql.conf`file or on the server command line. It is ignored unless`archive_mode`was enabled at server start. If`archive_command`is an empty string (the default) while`archive_mode`is enabled, WAL archiving is temporarily disabled, but the server continues to accumulate WAL segment files in the expectation that a command will soon be provided. Setting`archive_command`to a command that does nothing but return true, e.g.,`/bin/true`(`REM`on Windows), effectively disables archiving, but also breaks the chain of WAL files needed for archive recovery, so it should only be used in unusual circumstances.

`archive_timeout`(`integer`)[](<>)

The[archive_command](runtime-config-wal.html#GUC-ARCHIVE-COMMAND)is only invoked for completed WAL segments. Hence, if your server generates little WAL traffic (or has slack periods where it does so), there could be a long delay between the completion of a transaction and its safe recording in archive storage. To limit how old unarchived data can be, you can set`archive_timeout`to force the server to switch to a new WAL segment file periodically. When this parameter is greater than zero, the server will switch to a new segment file whenever this amount of time has elapsed since the last segment file switch, and there has been any database activity, including a single checkpoint (checkpoints are skipped if there is no database activity). Note that archived files that are closed early due to a forced switch are still the same length as completely full files. Therefore, it is unwise to use a very short`archive_timeout`— it will bloat your archive storage.`archive_timeout`settings of a minute or so are usually reasonable. You should consider using streaming replication, instead of archiving, if you want data to be copied off the primary server more quickly than that. If this value is specified without units, it is taken as seconds. This parameter can only be set in the`postgresql.conf`file or on the server command line.

### 20.5.4. Archive Recovery

[](<>)

This section describes the settings that apply only for the duration of the recovery. They must be reset for any subsequent recovery you wish to perform.

“Recovery” covers using the server as a standby or for executing a targeted recovery. Typically, standby mode would be used to provide high availability and/or read scalability, whereas a targeted recovery is used to recover from data loss.

To start the server in standby mode, create a file called`standby.signal`[](<>)in the data directory. The server will enter recovery and will not stop recovery when the end of archived WAL is reached, but will keep trying to continue recovery by connecting to the sending server as specified by the`primary_conninfo`setting and/or by fetching new WAL segments using`restore_command`. For this mode, the parameters from this section and[Section 20.6.3](runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-STANDBY)are of interest. Parameters from[Section 20.5.5](runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET)will also be applied but are typically not useful in this mode.

To start the server in targeted recovery mode, create a file called`recovery.signal`[](<>)in the data directory. If both`standby.signal`and`recovery.signal`files are created, standby mode takes precedence. Targeted recovery mode ends when the archived WAL is fully replayed, or when`recovery_target`is reached. In this mode, the parameters from both this section and[Section 20.5.5](runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET)will be used.

`restore_command`(`string`)[](<>)

The local shell command to execute to retrieve an archived segment of the WAL file series. This parameter is required for archive recovery, but optional for streaming replication. Any`%f`in the string is replaced by the name of the file to retrieve from the archive, and any`%p`is replaced by the copy destination path name on the server. (The path name is relative to the current working directory, i.e., the cluster's data directory.) Any`%r`is replaced by the name of the file containing the last valid restart point. That is the earliest file that must be kept to allow a restore to be restartable, so this information can be used to truncate the archive to just the minimum required to support restarting from the current restore.`%r`is typically only used by warm-standby configurations (see[Section 27.2](warm-standby.html)). Write`%%`to embed an actual`%`character.

It is important for the command to return a zero exit status only if it succeeds. The command*will*be asked for file names that are not present in the archive; it must return nonzero when so asked. Examples:

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

An exception is that if the command was terminated by a signal (other than SIGTERM, which is used as part of a database server shutdown) or an error by the shell (such as command not found), then recovery will abort and the server will not start up.

This parameter can only be set in the`postgresql.conf`file or on the server command line.

`archive_cleanup_command`(`string`)[](<>)

This optional parameter specifies a shell command that will be executed at every restartpoint. The purpose of`归档清理命令`是提供一种机制来清理备用服务器不再需要的旧存档 WAL 文件。任何`%r`替换为包含最后一个有效重新启动点的文件的名称。那是必须是最早的文件*保留*允许还原可重新启动，因此所有文件早于`%r`可以安全移除。此信息可用于将存档截断为仅支持从当前还原重新启动所需的最小值。这[皮克\_归档清理](pgarchivecleanup.html)模块常用于`归档清理命令`对于单机配置，例如：

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

但是请注意，如果多个备用服务器从同一个存档目录恢复，则需要确保在任何服务器不再需要 WAL 文件之前不要删除它们。`归档清理命令`通常会在热备用配置中使用（请参阅[第 27.2 节](warm-standby.html)）。写`%%`嵌入一​​个实际的`%`命令中的字符。

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

该参数只能在`postgresql.conf`文件或在服务器命令行上。

`recovery_end_command`(`细绳`)[](<>)

This parameter specifies a shell command that will be executed once only at the end of recovery. This parameter is optional. The purpose of the`recovery_end_command`is to provide a mechanism for cleanup following replication or recovery. Any`%r`is replaced by the name of the file containing the last valid restart point, like in[archive_cleanup_command](runtime-config-wal.html#GUC-ARCHIVE-CLEANUP-COMMAND).

If the command returns a nonzero exit status then a warning log message will be written and the database will proceed to start up anyway. An exception is that if the command was terminated by a signal or an error by the shell (such as command not found), the database will not proceed with startup.

This parameter can only be set in the`postgresql.conf`file or on the server command line.

### 20.5.5. Recovery Target

By default, recovery will recover to the end of the WAL log. The following parameters can be used to specify an earlier stopping point. At most one of`recovery_target`,`recovery_target_lsn`,`recovery_target_name`,`recovery_target_time`, or`recovery_target_xid`can be used; if more than one of these is specified in the configuration file, an error will be raised. These parameters can only be set at server start.

```recovery_target`` = 'immediate'``` [](<>)

This parameter specifies that recovery should end as soon as a consistent state is reached, i.e., as early as possible. When restoring from an online backup, this means the point where taking the backup ended.

从技术上讲，这是一个字符串参数，但是`'即时'`是当前唯一允许的值。

`recovery_target_name`(`细绳`)[](<>)

此参数指定命名的还原点（创建与`pg_create_restore_point()`) 恢复将继续。

`recovery_target_time`(`时间戳`)[](<>)

此参数指定恢复将进行到的时间戳。精确停止点也受以下因素影响[恢复\_目标\_包括的](runtime-config-wal.html#GUC-RECOVERY-TARGET-INCLUSIVE).

该参数的值是一个时间戳，格式与服务器接受的相同。`带时区的时间戳`数据类型，但不能使用时区缩写（除非[时区\_缩写](runtime-config-client.html#GUC-TIMEZONE-ABBREVIATIONS)变量已在配置文件中设置）。首选样式是使用与 UTC 的数字偏移量，或者您可以编写完整的时区名称，例如，`欧洲/赫尔辛基`不是`东部标准时间`.

`recovery_target_xid`(`细绳`)[](<>)

此参数指定恢复将继续到的事务 ID。请记住，虽然事务 ID 在事务开始时按顺序分配，但事务可以以不同的数字顺序完成。将恢复的事务是那些在指定事务之前（并且可选地包括）提交的事务。精确停止点也受以下因素影响[恢复\_目标\_包括的](runtime-config-wal.html#GUC-RECOVERY-TARGET-INCLUSIVE).

`recovery_target_lsn`(`pg_lsn`)[](<>)

此参数指定将进行恢复的预写日志位置的 LSN。精确停止点也受以下因素影响[恢复\_目标\_包括的](runtime-config-wal.html#GUC-RECOVERY-TARGET-INCLUSIVE).该参数使用系统数据类型解析[`pg_lsn`](datatype-pg-lsn.html).

以下选项进一步指定恢复目标，并影响达到目标时发生的情况：

`recovery_target_inclusive`(`布尔值`)[](<>)

指定是否在指定的恢复目标（`在`)，或者就在恢复目标之前 (`离开`）。适用于[恢复\_目标\_lsn](runtime-config-wal.html#GUC-RECOVERY-TARGET-LSN),[恢复\_目标\_时间](runtime-config-wal.html#GUC-RECOVERY-TARGET-TIME)， 要么[恢复\_目标\_xid](runtime-config-wal.html#GUC-RECOVERY-TARGET-XID)被指定。此设置控制是否将具有确切目标 WAL 位置 (LSN)、提交时间或事务 ID 的事务分别包含在恢复中。默认为`在`.

`recovery_target_timeline`(`细绳`)[](<>)

指定恢复到特定时间线。该值可以是数字时间线 ID 或特殊值。价值`当前的`沿进行基本备份时的当前时间线进行恢复。价值`最新的`恢复到存档中找到的最新时间线，这在备用服务器中很有用。`最新的`是默认值。

您通常只需要在复杂的重新恢复情况下设置此参数，您需要在时间点恢复后返回到自身达到的状态。看[第 26.3.5 节](continuous-archiving.html#BACKUP-TIMELINES)供讨论。

`recovery_target_action`(`枚举`)[](<>)

指定达到恢复目标后服务器应采取的操作。默认是`暂停`，这意味着恢复将被暂停。`推动`意味着恢复过程将完成，服务器将开始接受连接。最后`关闭`达到恢复目标后将停止服务器。

预期用途`暂停`设置是允许对数据库执行查询以检查此恢复目标是否是最理想的恢复点。暂停状态可以通过使用来恢复`pg_wal_replay_resume()`（看[表 9.89](functions-admin.html#FUNCTIONS-RECOVERY-CONTROL-TABLE))，然后导致恢复结束。如果此恢复目标不是所需的停止点，则关闭服务器，将恢复目标设置更改为稍后的目标，然后重新启动以继续恢复。

这`关闭`设置对于使实例在所需的确切重放点准备好很有用。该实例仍然能够重放更多 WAL 记录（实际上，它必须在下次启动时重放自上次检查点以来的 WAL 记录）。

请注意，因为`恢复信号`时不会被删除`recovery_target_action`被设定为`关掉`, 任何后续启动都将以立即关闭结束，除非更改配置或`恢复信号`文件被手动删除。

如果未设置恢复目标，则此设置无效。如果[热的\_支持](runtime-config-replication.html#GUC-HOT-STANDBY)未启用，设置`暂停`将与`关掉`.如果在促销期间达到恢复目标，则设置`暂停`将与`推动`.

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