Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
关注 1
点赞 0
百科 捐赠
gooderp18绿色标准版
您最多选择25个主题 主题必须以字母或数字开头，可以包含连字符 (-)，并且长度不得超过35个字符
分支: master
分支列表 标签列表
${ item.name }
创建分支 ${ searchTerm }
从 'master'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/runtime-config-wal.html

728 行
56KB
原始文件 永久链接 Blame 文件历史 

  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>

  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>19.5. Write Ahead Log</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="runtime-config-resource.html" title="19.4. Resource Consumption" /><link rel="next" href="runtime-config-replication.html" title="19.6. Replication" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">19.5. Write Ahead Log</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-resource.html" title="19.4. Resource Consumption">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 19. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 19. Server Configuration</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="runtime-config-replication.html" title="19.6. Replication">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="RUNTIME-CONFIG-WAL"><div class="titlepage"><div><div><h2 class="title" style="clear: both">19.5. Write Ahead Log</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS">19.5.1. Settings</a></span></dt><dt><span class="sect2"><a href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS">19.5.2. Checkpoints</a></span></dt><dt><span class="sect2"><a href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-ARCHIVING">19.5.3. Archiving</a></span></dt><dt><span class="sect2"><a href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY">19.5.4. Archive Recovery</a></span></dt><dt><span class="sect2"><a href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET">19.5.5. Recovery Target</a></span></dt></dl></div><p>

  3.     For additional information on tuning these settings,

  4.     see <a class="xref" href="wal-configuration.html" title="29.4. WAL Configuration">Section 29.4</a>.

  5.    </p><div class="sect2" id="RUNTIME-CONFIG-WAL-SETTINGS"><div class="titlepage"><div><div><h3 class="title">19.5.1. Settings</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-WAL-LEVEL"><span class="term"><code class="varname">wal_level</code> (<code class="type">enum</code>)

  6.       <a id="id-1.6.6.8.3.2.1.1.3" class="indexterm"></a>

  7.       </span></dt><dd><p>

  8.         <code class="varname">wal_level</code> determines how much information is written to

  9.         the WAL. The default value is <code class="literal">replica</code>, which writes enough

  10.         data to support WAL archiving and replication, including running

  11.         read-only queries on a standby server. <code class="literal">minimal</code> removes all

  12.         logging except the information required to recover from a crash or

  13.         immediate shutdown.  Finally,

  14.         <code class="literal">logical</code> adds information necessary to support logical

  15.         decoding.  Each level includes the information logged at all lower

  16.         levels.  This parameter can only be set at server start.

  17.        </p><p>

  18.         In <code class="literal">minimal</code> level, WAL-logging of some bulk

  19.         operations can be safely skipped, which can make those

  20.         operations much faster (see <a class="xref" href="populate.html#POPULATE-PITR" title="14.4.7. Disable WAL Archival and Streaming Replication">Section 14.4.7</a>).

  21.         Operations in which this optimization can be applied include:

  22.         </p><table border="0" summary="Simple list" class="simplelist"><tr><td><code class="command">CREATE TABLE AS</code></td></tr><tr><td><code class="command">CREATE INDEX</code></td></tr><tr><td><code class="command">CLUSTER</code></td></tr><tr><td><code class="command">COPY</code> into tables that were created or truncated in the same

  23.          transaction</td></tr></table><p>

  24.         But minimal WAL does not contain enough information to reconstruct the

  25.         data from a base backup and the WAL logs, so <code class="literal">replica</code> or

  26.         higher must be used to enable WAL archiving

  27.         (<a class="xref" href="runtime-config-wal.html#GUC-ARCHIVE-MODE">archive_mode</a>) and streaming replication.

  28.        </p><p>

  29.         In <code class="literal">logical</code> level, the same information is logged as

  30.         with <code class="literal">replica</code>, plus information needed to allow

  31.         extracting logical change sets from the WAL. Using a level of

  32.         <code class="literal">logical</code> will increase the WAL volume, particularly if many

  33.         tables are configured for <code class="literal">REPLICA IDENTITY FULL</code> and

  34.         many <code class="command">UPDATE</code> and <code class="command">DELETE</code> statements are

  35.         executed.

  36.        </p><p>

  37.         In releases prior to 9.6, this parameter also allowed the

  38.         values <code class="literal">archive</code> and <code class="literal">hot_standby</code>.

  39.         These are still accepted but mapped to <code class="literal">replica</code>.

  40.        </p></dd><dt id="GUC-FSYNC"><span class="term"><code class="varname">fsync</code> (<code class="type">boolean</code>)

  41.       <a id="id-1.6.6.8.3.2.2.1.3" class="indexterm"></a>

  42.       </span></dt><dd><p>

  43.         If this parameter is on, the <span class="productname">PostgreSQL</span> server

  44.         will try to make sure that updates are physically written to

  45.         disk, by issuing <code class="function">fsync()</code> system calls or various

  46.         equivalent methods (see <a class="xref" href="runtime-config-wal.html#GUC-WAL-SYNC-METHOD">wal_sync_method</a>).

  47.         This ensures that the database cluster can recover to a

  48.         consistent state after an operating system or hardware crash.

  49.        </p><p>

  50.         While turning off <code class="varname">fsync</code> is often a performance

  51.         benefit, this can result in unrecoverable data corruption in

  52.         the event of a power failure or system crash.  Thus it

  53.         is only advisable to turn off <code class="varname">fsync</code> if

  54.         you can easily recreate your entire database from external

  55.         data.

  56.        </p><p>

  57.         Examples of safe circumstances for turning off

  58.         <code class="varname">fsync</code> include the initial loading of a new

  59.         database cluster from a backup file, using a database cluster

  60.         for processing a batch of data after which the database

  61.         will be thrown away and recreated,

  62.         or for a read-only database clone which

  63.         gets recreated frequently and is not used for failover.  High

  64.         quality hardware alone is not a sufficient justification for

  65.         turning off <code class="varname">fsync</code>.

  66.        </p><p>

  67.         For reliable recovery when changing <code class="varname">fsync</code>

  68.         off to on, it is necessary to force all modified buffers in the

  69.         kernel to durable storage.  This can be done while the cluster

  70.         is shutdown or while <code class="varname">fsync</code> is on by running <code class="command">initdb

  71.         --sync-only</code>, running <code class="command">sync</code>, unmounting the

  72.         file system, or rebooting the server.

  73.        </p><p>

  74.         In many situations, turning off <a class="xref" href="runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT">synchronous_commit</a>

  75.         for noncritical transactions can provide much of the potential

  76.         performance benefit of turning off <code class="varname">fsync</code>, without

  77.         the attendant risks of data corruption.

  78.        </p><p>

  79.         <code class="varname">fsync</code> can only be set in the <code class="filename">postgresql.conf</code>

  80.         file or on the server command line.

  81.         If you turn this parameter off, also consider turning off

  82.         <a class="xref" href="runtime-config-wal.html#GUC-FULL-PAGE-WRITES">full_page_writes</a>.

  83.        </p></dd><dt id="GUC-SYNCHRONOUS-COMMIT"><span class="term"><code class="varname">synchronous_commit</code> (<code class="type">enum</code>)

  84.       <a id="id-1.6.6.8.3.2.3.1.3" class="indexterm"></a>

  85.       </span></dt><dd><p>

  86.         Specifies whether transaction commit will wait for WAL records

  87.         to be written to disk before the command returns a <span class="quote">“<span class="quote">success</span>”</span>

  88.         indication to the client.  Valid values are <code class="literal">on</code>,

  89.         <code class="literal">remote_apply</code>, <code class="literal">remote_write</code>, <code class="literal">local</code>,

  90.         and <code class="literal">off</code>.  The default, and safe, setting

  91.         is <code class="literal">on</code>.  When <code class="literal">off</code>, there can be a delay between

  92.         when success is reported to the client and when the transaction is

  93.         really guaranteed to be safe against a server crash.  (The maximum

  94.         delay is three times <a class="xref" href="runtime-config-wal.html#GUC-WAL-WRITER-DELAY">wal_writer_delay</a>.)  Unlike

  95.         <a class="xref" href="runtime-config-wal.html#GUC-FSYNC">fsync</a>, setting this parameter to <code class="literal">off</code>

  96.         does not create any risk of database inconsistency: an operating

  97.         system or database crash might

  98.         result in some recent allegedly-committed transactions being lost, but

  99.         the database state will be just the same as if those transactions had

  100.         been aborted cleanly.  So, turning <code class="varname">synchronous_commit</code> off

  101.         can be a useful alternative when performance is more important than

  102.         exact certainty about the durability of a transaction.  For more

  103.         discussion see <a class="xref" href="wal-async-commit.html" title="29.3. Asynchronous Commit">Section 29.3</a>.

  104.        </p><p>

  105.         If <a class="xref" href="runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES">synchronous_standby_names</a> is non-empty, this

  106.         parameter also controls whether or not transaction commits will wait

  107.         for their WAL records to be replicated to the standby server(s).

  108.         When set to <code class="literal">on</code>, commits will wait until replies

  109.         from the current synchronous standby(s) indicate they have received

  110.         the commit record of the transaction and flushed it to disk.  This

  111.         ensures the transaction will not be lost unless both the primary and

  112.         all synchronous standbys suffer corruption of their database storage.

  113.         When set to <code class="literal">remote_apply</code>, commits will wait until replies

  114.         from the current synchronous standby(s) indicate they have received the

  115.         commit record of the transaction and applied it, so that it has become

  116.         visible to queries on the standby(s).

  117.         When set to <code class="literal">remote_write</code>, commits will wait until replies

  118.         from the current synchronous standby(s) indicate they have

  119.         received the commit record of the transaction and written it out to

  120.         their operating system. This setting is sufficient to

  121.         ensure data preservation even if a standby instance of

  122.         <span class="productname">PostgreSQL</span> were to crash, but not if the standby

  123.         suffers an operating-system-level crash, since the data has not

  124.         necessarily reached stable storage on the standby.

  125.         Finally, the setting <code class="literal">local</code> causes commits to wait for

  126.         local flush to disk, but not for replication.  This is not usually

  127.         desirable when synchronous replication is in use, but is provided for

  128.         completeness.

  129.        </p><p>

  130.         If <code class="varname">synchronous_standby_names</code> is empty, the settings

  131.         <code class="literal">on</code>, <code class="literal">remote_apply</code>, <code class="literal">remote_write</code>

  132.         and <code class="literal">local</code> all provide the same synchronization level:

  133.         transaction commits only wait for local flush to disk.

  134.        </p><p>

  135.         This parameter can be changed at any time; the behavior for any

  136.         one transaction is determined by the setting in effect when it

  137.         commits.  It is therefore possible, and useful, to have some

  138.         transactions commit synchronously and others asynchronously.

  139.         For example, to make a single multistatement transaction commit

  140.         asynchronously when the default is the opposite, issue <code class="command">SET

  141.         LOCAL synchronous_commit TO OFF</code> within the transaction.

  142.        </p></dd><dt id="GUC-WAL-SYNC-METHOD"><span class="term"><code class="varname">wal_sync_method</code> (<code class="type">enum</code>)

  143.       <a id="id-1.6.6.8.3.2.4.1.3" class="indexterm"></a>

  144.       </span></dt><dd><p>

  145.         Method used for forcing WAL updates out to disk.

  146.         If <code class="varname">fsync</code> is off then this setting is irrelevant,

  147.         since WAL file updates will not be forced out at all.

  148.         Possible values are:

  149.        </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>

  150.          <code class="literal">open_datasync</code> (write WAL files with <code class="function">open()</code> option <code class="symbol">O_DSYNC</code>)

  151.         </p></li><li class="listitem"><p>

  152.          <code class="literal">fdatasync</code> (call <code class="function">fdatasync()</code> at each commit)

  153.         </p></li><li class="listitem"><p>

  154.          <code class="literal">fsync</code> (call <code class="function">fsync()</code> at each commit)

  155.         </p></li><li class="listitem"><p>

  156.          <code class="literal">fsync_writethrough</code> (call <code class="function">fsync()</code> at each commit, forcing write-through of any disk write cache)

  157.         </p></li><li class="listitem"><p>

  158.          <code class="literal">open_sync</code> (write WAL files with <code class="function">open()</code> option <code class="symbol">O_SYNC</code>)

  159.         </p></li></ul></div><p>

  160.         The <code class="literal">open_</code>* options also use <code class="literal">O_DIRECT</code> if available.

  161.         Not all of these choices are available on all platforms.

  162.         The default is the first method in the above list that is supported

  163.         by the platform, except that <code class="literal">fdatasync</code> is the default on

  164.         Linux.  The default is not necessarily ideal; it might be

  165.         necessary to change this setting or other aspects of your system

  166.         configuration in order to create a crash-safe configuration or

  167.         achieve optimal performance.

  168.         These aspects are discussed in <a class="xref" href="wal-reliability.html" title="29.1. Reliability">Section 29.1</a>.

  169.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  170.         file or on the server command line.

  171.        </p></dd><dt id="GUC-FULL-PAGE-WRITES"><span class="term"><code class="varname">full_page_writes</code> (<code class="type">boolean</code>)

  172.       <a id="id-1.6.6.8.3.2.5.1.3" class="indexterm"></a>

  173.       </span></dt><dd><p>

  174.         When this parameter is on, the <span class="productname">PostgreSQL</span> server

  175.         writes the entire content of each disk page to WAL during the

  176.         first modification of that page after a checkpoint.

  177.         This is needed because

  178.         a page write that is in process during an operating system crash might

  179.         be only partially completed, leading to an on-disk page

  180.         that contains a mix of old and new data.  The row-level change data

  181.         normally stored in WAL will not be enough to completely restore

  182.         such a page during post-crash recovery.  Storing the full page image

  183.         guarantees that the page can be correctly restored, but at the price

  184.         of increasing the amount of data that must be written to WAL.

  185.         (Because WAL replay always starts from a checkpoint, it is sufficient

  186.         to do this during the first change of each page after a checkpoint.

  187.         Therefore, one way to reduce the cost of full-page writes is to

  188.         increase the checkpoint interval parameters.)

  189.        </p><p>

  190.         Turning this parameter off speeds normal operation, but

  191.         might lead to either unrecoverable data corruption, or silent

  192.         data corruption, after a system failure. The risks are similar to turning off

  193.         <code class="varname">fsync</code>, though smaller, and it should be turned off

  194.         only based on the same circumstances recommended for that parameter.

  195.        </p><p>

  196.         Turning off this parameter does not affect use of

  197.         WAL archiving for point-in-time recovery (PITR)

  198.         (see <a class="xref" href="continuous-archiving.html" title="25.3. Continuous Archiving and Point-in-Time Recovery (PITR)">Section 25.3</a>).

  199.        </p><p>

  200.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  201.         file or on the server command line.

  202.         The default is <code class="literal">on</code>.

  203.        </p></dd><dt id="GUC-WAL-LOG-HINTS"><span class="term"><code class="varname">wal_log_hints</code> (<code class="type">boolean</code>)

  204.       <a id="id-1.6.6.8.3.2.6.1.3" class="indexterm"></a>

  205.       </span></dt><dd><p>

  206.         When this parameter is <code class="literal">on</code>, the <span class="productname">PostgreSQL</span>

  207.         server writes the entire content of each disk page to WAL during the

  208.         first modification of that page after a checkpoint, even for

  209.         non-critical modifications of so-called hint bits.

  210.        </p><p>

  211.         If data checksums are enabled, hint bit updates are always WAL-logged

  212.         and this setting is ignored. You can use this setting to test how much

  213.         extra WAL-logging would occur if your database had data checksums

  214.         enabled.

  215.        </p><p>

  216.         This parameter can only be set at server start. The default value is <code class="literal">off</code>.

  217.        </p></dd><dt id="GUC-WAL-COMPRESSION"><span class="term"><code class="varname">wal_compression</code> (<code class="type">boolean</code>)

  218.       <a id="id-1.6.6.8.3.2.7.1.3" class="indexterm"></a>

  219.       </span></dt><dd><p>

  220.         When this parameter is <code class="literal">on</code>, the <span class="productname">PostgreSQL</span>

  221.         server compresses a full page image written to WAL when

  222.         <a class="xref" href="runtime-config-wal.html#GUC-FULL-PAGE-WRITES">full_page_writes</a> is on or during a base backup.

  223.         A compressed page image will be decompressed during WAL replay.

  224.         The default value is <code class="literal">off</code>.

  225.         Only superusers can change this setting.

  226.        </p><p>

  227.         Turning this parameter on can reduce the WAL volume without

  228.         increasing the risk of unrecoverable data corruption,

  229.         but at the cost of some extra CPU spent on the compression during

  230.         WAL logging and on the decompression during WAL replay.

  231.        </p></dd><dt id="GUC-WAL-INIT-ZERO"><span class="term"><code class="varname">wal_init_zero</code> (<code class="type">boolean</code>)

  232.       <a id="id-1.6.6.8.3.2.8.1.3" class="indexterm"></a>

  233.       </span></dt><dd><p>

  234.         If set to <code class="literal">on</code> (the default), this option causes new

  235.         WAL files to be filled with zeroes.  On some file systems, this ensures

  236.         that space is allocated before we need to write WAL records.  However,

  237.         <em class="firstterm">Copy-On-Write</em> (COW) file systems may not benefit

  238.         from this technique, so the option is given to skip the unnecessary

  239.         work.  If set to <code class="literal">off</code>, only the final byte is written

  240.         when the file is created so that it has the expected size.

  241.        </p></dd><dt id="GUC-WAL-RECYCLE"><span class="term"><code class="varname">wal_recycle</code> (<code class="type">boolean</code>)

  242.       <a id="id-1.6.6.8.3.2.9.1.3" class="indexterm"></a>

  243.       </span></dt><dd><p>

  244.         If set to <code class="literal">on</code> (the default), this option causes WAL

  245.         files to be recycled by renaming them, avoiding the need to create new

  246.         ones.  On COW file systems, it may be faster to create new ones, so the

  247.         option is given to disable this behavior.

  248.        </p></dd><dt id="GUC-WAL-BUFFERS"><span class="term"><code class="varname">wal_buffers</code> (<code class="type">integer</code>)

  249.       <a id="id-1.6.6.8.3.2.10.1.3" class="indexterm"></a>

  250.       </span></dt><dd><p>

  251.         The amount of shared memory used for WAL data that has not yet been

  252.         written to disk.  The default setting of -1 selects a size equal to

  253.         1/32nd (about 3%) of <a class="xref" href="runtime-config-resource.html#GUC-SHARED-BUFFERS">shared_buffers</a>, but not less

  254.         than <code class="literal">64kB</code> nor more than the size of one WAL

  255.         segment, typically <code class="literal">16MB</code>.  This value can be set

  256.         manually if the automatic choice is too large or too small,

  257.         but any positive value less than <code class="literal">32kB</code> will be

  258.         treated as <code class="literal">32kB</code>.

  259.         If this value is specified without units, it is taken as WAL blocks,

  260.         that is <code class="symbol">XLOG_BLCKSZ</code> bytes, typically 8kB.

  261.         This parameter can only be set at server start.

  262.        </p><p>

  263.         The contents of the WAL buffers are written out to disk at every

  264.         transaction commit, so extremely large values are unlikely to

  265.         provide a significant benefit.  However, setting this value to at

  266.         least a few megabytes can improve write performance on a busy

  267.         server where many clients are committing at once.  The auto-tuning

  268.         selected by the default setting of -1 should give reasonable

  269.         results in most cases.

  270.        </p></dd><dt id="GUC-WAL-WRITER-DELAY"><span class="term"><code class="varname">wal_writer_delay</code> (<code class="type">integer</code>)

  271.       <a id="id-1.6.6.8.3.2.11.1.3" class="indexterm"></a>

  272.       </span></dt><dd><p>

  273.         Specifies how often the WAL writer flushes WAL, in time terms.

  274.         After flushing WAL the writer sleeps for the length of time given

  275.         by <code class="varname">wal_writer_delay</code>, unless woken up sooner

  276.         by an asynchronously committing transaction. If the last flush

  277.         happened less than <code class="varname">wal_writer_delay</code> ago and less

  278.         than <code class="varname">wal_writer_flush_after</code> worth of WAL has been

  279.         produced since, then WAL is only written to the operating system, not

  280.         flushed to disk.

  281.         If this value is specified without units, it is taken as milliseconds.

  282.         The default value is 200 milliseconds (<code class="literal">200ms</code>).  Note that

  283.         on many systems, the effective resolution of sleep delays is 10

  284.         milliseconds; setting <code class="varname">wal_writer_delay</code> to a value that is

  285.         not a multiple of 10 might have the same results as setting it to the

  286.         next higher multiple of 10. This parameter can only be set in the

  287.         <code class="filename">postgresql.conf</code> file or on the server command line.

  288.        </p></dd><dt id="GUC-WAL-WRITER-FLUSH-AFTER"><span class="term"><code class="varname">wal_writer_flush_after</code> (<code class="type">integer</code>)

  289.       <a id="id-1.6.6.8.3.2.12.1.3" class="indexterm"></a>

  290.       </span></dt><dd><p>

  291.         Specifies how often the WAL writer flushes WAL, in volume terms.

  292.         If the last flush happened less

  293.         than <code class="varname">wal_writer_delay</code> ago and less

  294.         than <code class="varname">wal_writer_flush_after</code> worth of WAL has been

  295.         produced since, then WAL is only written to the operating system, not

  296.         flushed to disk.  If <code class="varname">wal_writer_flush_after</code> is set

  297.         to <code class="literal">0</code> then WAL data is always flushed immediately.

  298.         If this value is specified without units, it is taken as WAL blocks,

  299.         that is <code class="symbol">XLOG_BLCKSZ</code> bytes, typically 8kB.

  300.         The default is <code class="literal">1MB</code>.

  301.         This parameter can only be set in the

  302.         <code class="filename">postgresql.conf</code> file or on the server command line.

  303.        </p></dd><dt id="GUC-COMMIT-DELAY"><span class="term"><code class="varname">commit_delay</code> (<code class="type">integer</code>)

  304.       <a id="id-1.6.6.8.3.2.13.1.3" class="indexterm"></a>

  305.       </span></dt><dd><p>

  306.         Setting <code class="varname">commit_delay</code> adds a time delay

  307.         before a WAL flush is initiated.  This can improve

  308.         group commit throughput by allowing a larger number of transactions

  309.         to commit via a single WAL flush, if system load is high enough

  310.         that additional transactions become ready to commit within the

  311.         given interval.  However, it also increases latency by up to the

  312.         <code class="varname">commit_delay</code> for each WAL

  313.         flush.  Because the delay is just wasted if no other transactions

  314.         become ready to commit, a delay is only performed if at least

  315.         <code class="varname">commit_siblings</code> other transactions are active

  316.         when a flush is about to be initiated.  Also, no delays are

  317.         performed if <code class="varname">fsync</code> is disabled.

  318.         If this value is specified without units, it is taken as microseconds.

  319.         The default <code class="varname">commit_delay</code> is zero (no delay).

  320.         Only superusers can change this setting.

  321.        </p><p>

  322.         In <span class="productname">PostgreSQL</span> releases prior to 9.3,

  323.         <code class="varname">commit_delay</code> behaved differently and was much

  324.         less effective: it affected only commits, rather than all WAL flushes,

  325.         and waited for the entire configured delay even if the WAL flush

  326.         was completed sooner.  Beginning in <span class="productname">PostgreSQL</span> 9.3,

  327.         the first process that becomes ready to flush waits for the configured

  328.         interval, while subsequent processes wait only until the leader

  329.         completes the flush operation.

  330.        </p></dd><dt id="GUC-COMMIT-SIBLINGS"><span class="term"><code class="varname">commit_siblings</code> (<code class="type">integer</code>)

  331.       <a id="id-1.6.6.8.3.2.14.1.3" class="indexterm"></a>

  332.       </span></dt><dd><p>

  333.         Minimum number of concurrent open transactions to require

  334.         before performing the <code class="varname">commit_delay</code> delay. A larger

  335.         value makes it more probable that at least one other

  336.         transaction will become ready to commit during the delay

  337.         interval. The default is five transactions.

  338.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-WAL-CHECKPOINTS"><div class="titlepage"><div><div><h3 class="title">19.5.2. Checkpoints</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-CHECKPOINT-TIMEOUT"><span class="term"><code class="varname">checkpoint_timeout</code> (<code class="type">integer</code>)

  339.       <a id="id-1.6.6.8.4.2.1.1.3" class="indexterm"></a>

  340.       </span></dt><dd><p>

  341.         Maximum time between automatic WAL checkpoints.

  342.         If this value is specified without units, it is taken as seconds.

  343.         The valid range is between 30 seconds and one day.

  344.         The default is five minutes (<code class="literal">5min</code>).

  345.         Increasing this parameter can increase the amount of time needed

  346.         for crash recovery.

  347.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  348.         file or on the server command line.

  349.        </p></dd><dt id="GUC-CHECKPOINT-COMPLETION-TARGET"><span class="term"><code class="varname">checkpoint_completion_target</code> (<code class="type">floating point</code>)

  350.       <a id="id-1.6.6.8.4.2.2.1.3" class="indexterm"></a>

  351.       </span></dt><dd><p>

  352.         Specifies the target of checkpoint completion, as a fraction of

  353.         total time between checkpoints. The default is 0.5.

  354.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  355.         file or on the server command line.

  356.        </p></dd><dt id="GUC-CHECKPOINT-FLUSH-AFTER"><span class="term"><code class="varname">checkpoint_flush_after</code> (<code class="type">integer</code>)

  357.       <a id="id-1.6.6.8.4.2.3.1.3" class="indexterm"></a>

  358.       </span></dt><dd><p>

  359.         Whenever more than this amount of data has been

  360.         written while performing a checkpoint, attempt to force the

  361.         OS to issue these writes to the underlying storage.  Doing so will

  362.         limit the amount of dirty data in the kernel's page cache, reducing

  363.         the likelihood of stalls when an <code class="function">fsync</code> is issued at the end of the

  364.         checkpoint, or when the OS writes data back in larger batches in the

  365.         background.  Often that will result in greatly reduced transaction

  366.         latency, but there also are some cases, especially with workloads

  367.         that are bigger than <a class="xref" href="runtime-config-resource.html#GUC-SHARED-BUFFERS">shared_buffers</a>, but smaller

  368.         than the OS's page cache, where performance might degrade.  This

  369.         setting may have no effect on some platforms.

  370.         If this value is specified without units, it is taken as blocks,

  371.         that is <code class="symbol">BLCKSZ</code> bytes, typically 8kB.

  372.         The valid range is

  373.         between <code class="literal">0</code>, which disables forced writeback,

  374.         and <code class="literal">2MB</code>.  The default is <code class="literal">256kB</code> on

  375.         Linux, <code class="literal">0</code> elsewhere.  (If <code class="symbol">BLCKSZ</code> is not

  376.         8kB, the default and maximum values scale proportionally to it.)

  377.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  378.         file or on the server command line.

  379.        </p></dd><dt id="GUC-CHECKPOINT-WARNING"><span class="term"><code class="varname">checkpoint_warning</code> (<code class="type">integer</code>)

  380.       <a id="id-1.6.6.8.4.2.4.1.3" class="indexterm"></a>

  381.       </span></dt><dd><p>

  382.         Write a message to the server log if checkpoints caused by

  383.         the filling of WAL segment files happen closer together

  384.         than this amount of time (which suggests that

  385.         <code class="varname">max_wal_size</code> ought to be raised).

  386.         If this value is specified without units, it is taken as seconds.

  387.         The default is 30 seconds (<code class="literal">30s</code>).

  388.         Zero disables the warning.

  389.         No warnings will be generated if <code class="varname">checkpoint_timeout</code>

  390.         is less than <code class="varname">checkpoint_warning</code>.

  391.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  392.         file or on the server command line.

  393.        </p></dd><dt id="GUC-MAX-WAL-SIZE"><span class="term"><code class="varname">max_wal_size</code> (<code class="type">integer</code>)

  394.       <a id="id-1.6.6.8.4.2.5.1.3" class="indexterm"></a>

  395.       </span></dt><dd><p>

  396.         Maximum size to let the WAL grow to between automatic WAL

  397.         checkpoints. This is a soft limit; WAL size can exceed

  398.         <code class="varname">max_wal_size</code> under special circumstances, such as

  399.         heavy load, a failing <code class="varname">archive_command</code>, or a high

  400.         <code class="varname">wal_keep_segments</code> setting.

  401.         If this value is specified without units, it is taken as megabytes.

  402.         The default is 1 GB.

  403.         Increasing this parameter can increase the amount of time needed for

  404.         crash recovery.

  405.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  406.         file or on the server command line.

  407.        </p></dd><dt id="GUC-MIN-WAL-SIZE"><span class="term"><code class="varname">min_wal_size</code> (<code class="type">integer</code>)

  408.       <a id="id-1.6.6.8.4.2.6.1.3" class="indexterm"></a>

  409.       </span></dt><dd><p>

  410.         As long as WAL disk usage stays below this setting, old WAL files are

  411.         always recycled for future use at a checkpoint, rather than removed.

  412.         This can be used to ensure that enough WAL space is reserved to

  413.         handle spikes in WAL usage, for example when running large batch

  414.         jobs.

  415.         If this value is specified without units, it is taken as megabytes.

  416.         The default is 80 MB.

  417.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  418.         file or on the server command line.

  419.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-WAL-ARCHIVING"><div class="titlepage"><div><div><h3 class="title">19.5.3. Archiving</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-ARCHIVE-MODE"><span class="term"><code class="varname">archive_mode</code> (<code class="type">enum</code>)

  420.       <a id="id-1.6.6.8.5.2.1.1.3" class="indexterm"></a>

  421.       </span></dt><dd><p>

  422.         When <code class="varname">archive_mode</code> is enabled, completed WAL segments

  423.         are sent to archive storage by setting

  424.         <a class="xref" href="runtime-config-wal.html#GUC-ARCHIVE-COMMAND">archive_command</a>. In addition to <code class="literal">off</code>,

  425.         to disable, there are two modes: <code class="literal">on</code>, and

  426.         <code class="literal">always</code>. During normal operation, there is no

  427.         difference between the two modes, but when set to <code class="literal">always</code>

  428.         the WAL archiver is enabled also during archive recovery or standby

  429.         mode. In <code class="literal">always</code> mode, all files restored from the archive

  430.         or streamed with streaming replication will be archived (again). See

  431.         <a class="xref" href="warm-standby.html#CONTINUOUS-ARCHIVING-IN-STANDBY" title="26.2.9. Continuous Archiving in Standby">Section 26.2.9</a> for details.

  432.        </p><p>

  433.         <code class="varname">archive_mode</code> and <code class="varname">archive_command</code> are

  434.         separate variables so that <code class="varname">archive_command</code> can be

  435.         changed without leaving archiving mode.

  436.         This parameter can only be set at server start.

  437.         <code class="varname">archive_mode</code> cannot be enabled when

  438.         <code class="varname">wal_level</code> is set to <code class="literal">minimal</code>.

  439.        </p></dd><dt id="GUC-ARCHIVE-COMMAND"><span class="term"><code class="varname">archive_command</code> (<code class="type">string</code>)

  440.       <a id="id-1.6.6.8.5.2.2.1.3" class="indexterm"></a>

  441.       </span></dt><dd><p>

  442.         The local shell command to execute to archive a completed WAL file

  443.         segment.  Any <code class="literal">%p</code> in the string is

  444.         replaced by the path name of the file to archive, and any

  445.         <code class="literal">%f</code> is replaced by only the file name.

  446.         (The path name is relative to the working directory of the server,

  447.         i.e., the cluster's data directory.)

  448.         Use <code class="literal">%%</code> to embed an actual <code class="literal">%</code> character in the

  449.         command.  It is important for the command to return a zero

  450.         exit status only if it succeeds. For more information see

  451.         <a class="xref" href="continuous-archiving.html#BACKUP-ARCHIVING-WAL" title="25.3.1. Setting Up WAL Archiving">Section 25.3.1</a>.

  452.        </p><p>

  453.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  454.         file or on the server command line.  It is ignored unless

  455.         <code class="varname">archive_mode</code> was enabled at server start.

  456.         If <code class="varname">archive_command</code> is an empty string (the default) while

  457.         <code class="varname">archive_mode</code> is enabled, WAL archiving is temporarily

  458.         disabled, but the server continues to accumulate WAL segment files in

  459.         the expectation that a command will soon be provided.  Setting

  460.         <code class="varname">archive_command</code> to a command that does nothing but

  461.         return true, e.g. <code class="literal">/bin/true</code> (<code class="literal">REM</code> on

  462.         Windows), effectively disables

  463.         archiving, but also breaks the chain of WAL files needed for

  464.         archive recovery, so it should only be used in unusual circumstances.

  465.        </p></dd><dt id="GUC-ARCHIVE-TIMEOUT"><span class="term"><code class="varname">archive_timeout</code> (<code class="type">integer</code>)

  466.       <a id="id-1.6.6.8.5.2.3.1.3" class="indexterm"></a>

  467.       </span></dt><dd><p>

  468.         The <a class="xref" href="runtime-config-wal.html#GUC-ARCHIVE-COMMAND">archive_command</a> is only invoked for

  469.         completed WAL segments. Hence, if your server generates little WAL

  470.         traffic (or has slack periods where it does so), there could be a

  471.         long delay between the completion of a transaction and its safe

  472.         recording in archive storage.  To limit how old unarchived

  473.         data can be, you can set <code class="varname">archive_timeout</code> to force the

  474.         server to switch to a new WAL segment file periodically.  When this

  475.         parameter is greater than zero, the server will switch to a new

  476.         segment file whenever this amount of time has elapsed since the last

  477.         segment file switch, and there has been any database activity,

  478.         including a single checkpoint (checkpoints are skipped if there is

  479.         no database activity).  Note that archived files that are closed

  480.         early due to a forced switch are still the same length as completely

  481.         full files.  Therefore, it is unwise to use a very short

  482.         <code class="varname">archive_timeout</code> — it will bloat your archive

  483.         storage.  <code class="varname">archive_timeout</code> settings of a minute or so are

  484.         usually reasonable.  You should consider using streaming replication,

  485.         instead of archiving, if you want data to be copied off the master

  486.         server more quickly than that.

  487.         If this value is specified without units, it is taken as seconds.

  488.         This parameter can only be set in the

  489.         <code class="filename">postgresql.conf</code> file or on the server command line.

  490.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY"><div class="titlepage"><div><div><h3 class="title">19.5.4. Archive Recovery</h3></div></div></div><a id="id-1.6.6.8.6.2" class="indexterm"></a><p>

  491.      This section describes the settings that apply only for the duration of

  492.      the recovery.  They must be reset for any subsequent recovery you wish to

  493.      perform.

  494.     </p><p>

  495.      <span class="quote">“<span class="quote">Recovery</span>”</span> covers using the server as a standby or for

  496.      executing a targeted recovery.  Typically, standby mode would be used to

  497.      provide high availability and/or read scalability, whereas a targeted

  498.      recovery is used to recover from data loss.

  499.     </p><p>

  500.      To start the server in standby mode, create a file called

  501.      <code class="filename">standby.signal</code><a id="id-1.6.6.8.6.5.2" class="indexterm"></a>

  502.      in the data directory.  The server will enter recovery and will not stop

  503.      recovery when the end of archived WAL is reached, but will keep trying to

  504.      continue recovery by connecting to the sending server as specified by the

  505.      <code class="varname">primary_conninfo</code> setting and/or by fetching new WAL

  506.      segments using <code class="varname">restore_command</code>.  For this mode, the

  507.      parameters from this section and <a class="xref" href="runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-STANDBY" title="19.6.3. Standby Servers">Section 19.6.3</a> are of interest.

  508.      Parameters from <a class="xref" href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET" title="19.5.5. Recovery Target">Section 19.5.5</a> will

  509.      also be applied but are typically not useful in this mode.

  510.     </p><p>

  511.      To start the server in targeted recovery mode, create a file called

  512.      <code class="filename">recovery.signal</code><a id="id-1.6.6.8.6.6.2" class="indexterm"></a>

  513.      in the data directory.  If both <code class="filename">standby.signal</code> and

  514.      <code class="filename">recovery.signal</code> files are created, standby mode

  515.      takes precedence.  Targeted recovery mode ends when the archived WAL is

  516.      fully replayed, or when <code class="varname">recovery_target</code> is reached.

  517.      In this mode, the parameters from both this section and <a class="xref" href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET" title="19.5.5. Recovery Target">Section 19.5.5</a> will be used.

  518.     </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-RESTORE-COMMAND"><span class="term"><code class="varname">restore_command</code> (<code class="type">string</code>)

  519.       <a id="id-1.6.6.8.6.7.1.1.3" class="indexterm"></a>

  520.       </span></dt><dd><p>

  521.         The local shell command to execute to retrieve an archived segment of

  522.         the WAL file series. This parameter is required for archive recovery,

  523.         but optional for streaming replication.

  524.         Any <code class="literal">%f</code> in the string is

  525.         replaced by the name of the file to retrieve from the archive,

  526.         and any <code class="literal">%p</code> is replaced by the copy destination path name

  527.         on the server.

  528.         (The path name is relative to the current working directory,

  529.         i.e., the cluster's data directory.)

  530.         Any <code class="literal">%r</code> is replaced by the name of the file containing the

  531.         last valid restart point. That is the earliest file that must be kept

  532.         to allow a restore to be restartable, so this information can be used

  533.         to truncate the archive to just the minimum required to support

  534.         restarting from the current restore. <code class="literal">%r</code> is typically only

  535.         used by warm-standby configurations

  536.         (see <a class="xref" href="warm-standby.html" title="26.2. Log-Shipping Standby Servers">Section 26.2</a>).

  537.         Write <code class="literal">%%</code> to embed an actual <code class="literal">%</code> character.

  538.        </p><p>

  539.         It is important for the command to return a zero exit status

  540.         only if it succeeds.  The command <span class="emphasis"><em>will</em></span> be asked for file

  541.         names that are not present in the archive; it must return nonzero

  542.         when so asked.  Examples:

  543. </p><pre class="programlisting">

  544. restore_command = 'cp /mnt/server/archivedir/%f "%p"'

  545. restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

  546. </pre><p>

  547.         An exception is that if the command was terminated by a signal (other

  548.         than <span class="systemitem">SIGTERM</span>, which is used as part of a

  549.         database server shutdown) or an error by the shell (such as command

  550.         not found), then recovery will abort and the server will not start up.

  551.        </p><p>

  552.         This parameter can only be set at server start.

  553.        </p></dd><dt id="GUC-ARCHIVE-CLEANUP-COMMAND"><span class="term"><code class="varname">archive_cleanup_command</code> (<code class="type">string</code>)

  554.       <a id="id-1.6.6.8.6.7.2.1.3" class="indexterm"></a>

  555.       </span></dt><dd><p>

  556.         This optional parameter specifies a shell command that will be executed

  557.         at every restartpoint.  The purpose of

  558.         <code class="varname">archive_cleanup_command</code> is to provide a mechanism for

  559.         cleaning up old archived WAL files that are no longer needed by the

  560.         standby server.

  561.         Any <code class="literal">%r</code> is replaced by the name of the file containing the

  562.         last valid restart point.

  563.         That is the earliest file that must be <span class="emphasis"><em>kept</em></span> to allow a

  564.         restore to be restartable, and so all files earlier than <code class="literal">%r</code>

  565.         may be safely removed.

  566.         This information can be used to truncate the archive to just the

  567.         minimum required to support restart from the current restore.

  568.         The <a class="xref" href="pgarchivecleanup.html" title="pg_archivecleanup"><span class="refentrytitle"><span class="application">pg_archivecleanup</span></span></a> module

  569.         is often used in <code class="varname">archive_cleanup_command</code> for

  570.         single-standby configurations, for example:

  571. </p><pre class="programlisting">archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'</pre><p>

  572.         Note however that if multiple standby servers are restoring from the

  573.         same archive directory, you will need to ensure that you do not delete

  574.         WAL files until they are no longer needed by any of the servers.

  575.         <code class="varname">archive_cleanup_command</code> would typically be used in a

  576.         warm-standby configuration (see <a class="xref" href="warm-standby.html" title="26.2. Log-Shipping Standby Servers">Section 26.2</a>).

  577.         Write <code class="literal">%%</code> to embed an actual <code class="literal">%</code> character in the

  578.         command.

  579.        </p><p>

  580.         If the command returns a nonzero exit status then a warning log

  581.         message will be written.  An exception is that if the command was

  582.         terminated by a signal or an error by the shell (such as command not

  583.         found), a fatal error will be raised.

  584.        </p><p>

  585.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  586.         file or on the server command line.

  587.        </p></dd><dt id="GUC-RECOVERY-END-COMMAND"><span class="term"><code class="varname">recovery_end_command</code> (<code class="type">string</code>)

  588.       <a id="id-1.6.6.8.6.7.3.1.3" class="indexterm"></a>

  589.       </span></dt><dd><p>

  590.         This parameter specifies a shell command that will be executed once only

  591.         at the end of recovery. This parameter is optional. The purpose of the

  592.         <code class="varname">recovery_end_command</code> is to provide a mechanism for cleanup

  593.         following replication or recovery.

  594.         Any <code class="literal">%r</code> is replaced by the name of the file containing the

  595.         last valid restart point, like in <a class="xref" href="runtime-config-wal.html#GUC-ARCHIVE-CLEANUP-COMMAND">archive_cleanup_command</a>.

  596.        </p><p>

  597.         If the command returns a nonzero exit status then a warning log

  598.         message will be written and the database will proceed to start up

  599.         anyway.  An exception is that if the command was terminated by a

  600.         signal or an error by the shell (such as command not found), the

  601.         database will not proceed with startup.

  602.        </p><p>

  603.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  604.         file or on the server command line.

  605.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-WAL-RECOVERY-TARGET"><div class="titlepage"><div><div><h3 class="title">19.5.5. Recovery Target</h3></div></div></div><p>

  606.       By default, recovery will recover to the end of the WAL log. The

  607.       following parameters can be used to specify an earlier stopping point.

  608.       At most one of <code class="varname">recovery_target</code>,

  609.       <code class="varname">recovery_target_lsn</code>, <code class="varname">recovery_target_name</code>,

  610.       <code class="varname">recovery_target_time</code>, or <code class="varname">recovery_target_xid</code>

  611.       can be used; if more than one of these is specified in the configuration

  612.       file, an error will be raised.

  613.       These parameters can only be set at server start.

  614.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-RECOVERY-TARGET"><span class="term"><code class="varname">recovery_target</code><code class="literal"> = 'immediate'</code>

  615.       <a id="id-1.6.6.8.7.3.1.1.3" class="indexterm"></a>

  616.       </span></dt><dd><p>

  617.         This parameter specifies that recovery should end as soon as a

  618.         consistent state is reached, i.e. as early as possible. When restoring

  619.         from an online backup, this means the point where taking the backup

  620.         ended.

  621.        </p><p>

  622.         Technically, this is a string parameter, but <code class="literal">'immediate'</code>

  623.         is currently the only allowed value.

  624.        </p></dd><dt id="GUC-RECOVERY-TARGET-NAME"><span class="term"><code class="varname">recovery_target_name</code> (<code class="type">string</code>)

  625.       <a id="id-1.6.6.8.7.3.2.1.3" class="indexterm"></a>

  626.       </span></dt><dd><p>

  627.         This parameter specifies the named restore point (created with

  628.         <code class="function">pg_create_restore_point()</code>) to which recovery will proceed.

  629.        </p></dd><dt id="GUC-RECOVERY-TARGET-TIME"><span class="term"><code class="varname">recovery_target_time</code> (<code class="type">timestamp</code>)

  630.       <a id="id-1.6.6.8.7.3.3.1.3" class="indexterm"></a>

  631.       </span></dt><dd><p>

  632.         This parameter specifies the time stamp up to which recovery

  633.         will proceed.

  634.         The precise stopping point is also influenced by

  635.         <a class="xref" href="runtime-config-wal.html#GUC-RECOVERY-TARGET-INCLUSIVE">recovery_target_inclusive</a>.

  636.        </p><p>

  637.         The value of this parameter is a time stamp in the same format

  638.         accepted by the <code class="type">timestamp with time zone</code> data type,

  639.         except that you cannot use a time zone abbreviation (unless the

  640.         <a class="xref" href="runtime-config-client.html#GUC-TIMEZONE-ABBREVIATIONS">timezone_abbreviations</a> variable has been set

  641.         earlier in the configuration file).  Preferred style is to use a

  642.         numeric offset from UTC, or you can write a full time zone name,

  643.         e.g. <code class="literal">Europe/Helsinki</code> not <code class="literal">EEST</code>.

  644.        </p></dd><dt id="GUC-RECOVERY-TARGET-XID"><span class="term"><code class="varname">recovery_target_xid</code> (<code class="type">string</code>)

  645.       <a id="id-1.6.6.8.7.3.4.1.3" class="indexterm"></a>

  646.       </span></dt><dd><p>

  647.         This parameter specifies the transaction ID up to which recovery

  648.         will proceed. Keep in mind

  649.         that while transaction IDs are assigned sequentially at transaction

  650.         start, transactions can complete in a different numeric order.

  651.         The transactions that will be recovered are those that committed

  652.         before (and optionally including) the specified one.

  653.         The precise stopping point is also influenced by

  654.         <a class="xref" href="runtime-config-wal.html#GUC-RECOVERY-TARGET-INCLUSIVE">recovery_target_inclusive</a>.

  655.        </p></dd><dt id="GUC-RECOVERY-TARGET-LSN"><span class="term"><code class="varname">recovery_target_lsn</code> (<code class="type">pg_lsn</code>)

  656.       <a id="id-1.6.6.8.7.3.5.1.3" class="indexterm"></a>

  657.       </span></dt><dd><p>

  658.         This parameter specifies the LSN of the write-ahead log location up

  659.         to which recovery will proceed. The precise stopping point is also

  660.         influenced by <a class="xref" href="runtime-config-wal.html#GUC-RECOVERY-TARGET-INCLUSIVE">recovery_target_inclusive</a>. This

  661.         parameter is parsed using the system data type

  662.         <a class="link" href="datatype-pg-lsn.html" title="8.20. pg_lsn Type"><code class="type">pg_lsn</code></a>.

  663.        </p></dd></dl></div><p>

  664.        The following options further specify the recovery target, and affect

  665.        what happens when the target is reached:

  666.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-RECOVERY-TARGET-INCLUSIVE"><span class="term"><code class="varname">recovery_target_inclusive</code> (<code class="type">boolean</code>)

  667.       <a id="id-1.6.6.8.7.5.1.1.3" class="indexterm"></a>

  668.       </span></dt><dd><p>

  669.         Specifies whether to stop just after the specified recovery target

  670.         (<code class="literal">on</code>), or just before the recovery target

  671.         (<code class="literal">off</code>).

  672.         Applies when <a class="xref" href="runtime-config-wal.html#GUC-RECOVERY-TARGET-LSN">recovery_target_lsn</a>,

  673.         <a class="xref" href="runtime-config-wal.html#GUC-RECOVERY-TARGET-TIME">recovery_target_time</a>, or

  674.         <a class="xref" href="runtime-config-wal.html#GUC-RECOVERY-TARGET-XID">recovery_target_xid</a> is specified.

  675.         This setting controls whether transactions

  676.         having exactly the target WAL location (LSN), commit time, or transaction ID, respectively, will

  677.         be included in the recovery.  Default is <code class="literal">on</code>.

  678.        </p></dd><dt id="GUC-RECOVERY-TARGET-TIMELINE"><span class="term"><code class="varname">recovery_target_timeline</code> (<code class="type">string</code>)

  679.       <a id="id-1.6.6.8.7.5.2.1.3" class="indexterm"></a>

  680.       </span></dt><dd><p>

  681.         Specifies recovering into a particular timeline.  The value can be a

  682.         numeric timeline ID or a special value.  The value

  683.         <code class="literal">current</code> recovers along the same timeline that was

  684.         current when the base backup was taken.  The

  685.         value <code class="literal">latest</code> recovers

  686.         to the latest timeline found in the archive, which is useful in

  687.         a standby server.  <code class="literal">latest</code> is the default.

  688.        </p><p>

  689.         You usually only need to set this parameter

  690.         in complex re-recovery situations, where you need to return to

  691.         a state that itself was reached after a point-in-time recovery.

  692.         See <a class="xref" href="continuous-archiving.html#BACKUP-TIMELINES" title="25.3.5. Timelines">Section 25.3.5</a> for discussion.

  693.        </p></dd><dt id="GUC-RECOVERY-TARGET-ACTION"><span class="term"><code class="varname">recovery_target_action</code> (<code class="type">enum</code>)

  694.       <a id="id-1.6.6.8.7.5.3.1.3" class="indexterm"></a>

  695.       </span></dt><dd><p>

  696.         Specifies what action the server should take once the recovery target is

  697.         reached. The default is <code class="literal">pause</code>, which means recovery will

  698.         be paused. <code class="literal">promote</code> means the recovery process will finish

  699.         and the server will start to accept connections.

  700.         Finally <code class="literal">shutdown</code> will stop the server after reaching the

  701.         recovery target.

  702.        </p><p>

  703.         The intended use of the <code class="literal">pause</code> setting is to allow queries

  704.         to be executed against the database to check if this recovery target

  705.         is the most desirable point for recovery.

  706.         The paused state can be resumed by

  707.         using <code class="function">pg_wal_replay_resume()</code> (see

  708.         <a class="xref" href="functions-admin.html#FUNCTIONS-RECOVERY-CONTROL-TABLE" title="Table 9.86. Recovery Control Functions">Table 9.86</a>), which then

  709.         causes recovery to end. If this recovery target is not the

  710.         desired stopping point, then shut down the server, change the

  711.         recovery target settings to a later target and restart to

  712.         continue recovery.

  713.        </p><p>

  714.         The <code class="literal">shutdown</code> setting is useful to have the instance ready

  715.         at the exact replay point desired.  The instance will still be able to

  716.         replay more WAL records (and in fact will have to replay WAL records

  717.         since the last checkpoint next time it is started).

  718.        </p><p>

  719.         Note that because <code class="filename">recovery.signal</code> will not be

  720.         removed when <code class="varname">recovery_target_action</code> is set to <code class="literal">shutdown</code>,

  721.         any subsequent start will end with immediate shutdown unless the

  722.         configuration is changed or the <code class="filename">recovery.signal</code>

  723.         file is removed manually.

  724.        </p><p>

  725.         This setting has no effect if no recovery target is set.

  726.         If <a class="xref" href="runtime-config-replication.html#GUC-HOT-STANDBY">hot_standby</a> is not enabled, a setting of

  727.         <code class="literal">pause</code> will act the same as <code class="literal">shutdown</code>.

  728.        </p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="runtime-config-resource.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-replication.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">19.4. Resource Consumption </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 19.6. Replication</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1