diff --git a/contrib/pg_archivecleanup/pg_archivecleanup.c b/contrib/pg_archivecleanup/pg_archivecleanup.c
index f12331a..339e805 100644
--- a/contrib/pg_archivecleanup/pg_archivecleanup.c
+++ b/contrib/pg_archivecleanup/pg_archivecleanup.c
@@ -255,7 +255,7 @@ usage(void)
printf(" -x EXT clean up files if they have this extension\n");
printf(" -?, --help show this help, then exit\n");
printf("\n"
- "For use as archive_cleanup_command in recovery.conf when standby_mode = on:\n"
+ "For use as archive_cleanup_command in postgresql.conf when standby_mode = on:\n"
" archive_cleanup_command = 'pg_archivecleanup [OPTION]... ARCHIVELOCATION %%r'\n"
"e.g.\n"
" archive_cleanup_command = 'pg_archivecleanup /mnt/server/archiverdir %%r'\n");
diff --git a/contrib/pg_standby/pg_standby.c b/contrib/pg_standby/pg_standby.c
index 059c820..907346e 100644
--- a/contrib/pg_standby/pg_standby.c
+++ b/contrib/pg_standby/pg_standby.c
@@ -531,7 +531,7 @@ usage(void)
printf(" -w MAXWAITTIME max seconds to wait for a file (0=no limit) (default=0)\n");
printf(" -?, --help show this help, then exit\n");
printf("\n"
- "Main intended use as restore_command in recovery.conf:\n"
+ "Main intended use as restore_command in postgresql.conf:\n"
" restore_command = 'pg_standby [OPTION]... ARCHIVELOCATION %%f %%p %%r'\n"
"e.g.\n"
" restore_command = 'pg_standby /mnt/server/archiverdir %%f %%p %%r'\n");
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 1712974..6bad86f 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1028,10 +1028,17 @@ SELECT pg_stop_backup();
- Create a recovery command file recovery.conf> in the cluster
- data directory (see ). You might
- also want to temporarily modify pg_hba.conf> to prevent
- ordinary users from connecting until you are sure the recovery was successful.
+ Set up recovery parameters in postgresql.conf> (see
+ and
+ ).
+
+
+
+
+ Create a file called recovery.trigger> in the cluster data
+ directory. You might also want to temporarily modify pg_hba.conf>
+ to prevent ordinary users from connecting until you are sure the recovery
+ was successful.
@@ -1040,10 +1047,9 @@ SELECT pg_stop_backup();
proceed to read through the archived WAL files it needs. Should the
recovery be terminated because of an external error, the server can
simply be restarted and it will continue recovery. Upon completion
- of the recovery process, the server will rename
- recovery.conf> to recovery.done> (to prevent
- accidentally re-entering recovery mode later) and then
- commence normal database operations.
+ of the recovery process, the server will delete
+ recovery.trigger> (to prevent accidentally re-entering
+ recovery mode later) and then commence normal database operations.
@@ -1057,12 +1063,11 @@ SELECT pg_stop_backup();
- The key part of all this is to set up a recovery configuration file that
- describes how you want to recover and how far the recovery should
- run. You can use recovery.conf.sample> (normally
- located in the installation's share/> directory) as a
- prototype. The one thing that you absolutely must specify in
- recovery.conf> is the restore_command>,
+ The key part of all this is to set up recovery parameters that
+ specify how you want to recover and how far the recovery should
+ run. The one thing that you absolutely must specify in
+ postgresql.conf> to recover from the backup is
+ the restore_command>,
which tells PostgreSQL> how to retrieve archived
WAL file segments. Like the archive_command>, this is
a shell command string. It can contain %f>, which is
@@ -1116,7 +1121,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
If you want to recover to some previous point in time (say, right before
the junior DBA dropped your main transaction table), just specify the
- required stopping point in recovery.conf>. You can specify
+ required stopping point in postgresql.conf>. You can specify
the stop point, known as the recovery target>, either by
date/time, named restore point or by completion of a specific transaction
ID. As of this writing only the date/time and named restore point options
@@ -1213,8 +1218,9 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
The default behavior of recovery is to recover along the same timeline
that was current when the base backup was taken. If you wish to recover
into some child timeline (that is, you want to return to some state that
- was itself generated after a recovery attempt), you need to specify the
- target timeline ID in recovery.conf>. You cannot recover into
+ was itself generated after a recovery attempt), you need to set
+ to the
+ target timeline ID in postgresql.conf>. You cannot recover into
timelines that branched off earlier than the base backup.
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 77a9303..07103e7 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2151,6 +2151,312 @@ include 'filename'
+
+
+
+ Recovery
+
+
+ Archive Recovery
+
+
+ These settings control the behavior of server when put in recovery by
+ creating a recovery trigger file recovery.trigger> in data
+ folder. Those parameters are not used if server is not in recovery.
+
+
+
+
+ restore_command (string)
+
+ restore_command> configuration parameter
+
+
+
+ The 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 ).
+ 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
+
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+ archive_cleanup_command (string)
+
+ archive_cleanup_command> configuration parameter
+
+
+
+ The shell command that will be executed at every restartpoint.
+ The purpose of archive_cleanup_command> is to
+ provide a mechanism for cleaning up old archived WAL files that
+ are no longer needed by the standby server.
+ 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, and so all files earlier than %r>
+ may be safely removed.
+ This information can be used to truncate the archive to just the
+ minimum required to support restart from the current restore.
+ The module
+ is often used in archive_cleanup_command> for
+ single-standby configurations, for example:
+archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
+ Note however that if multiple standby servers are restoring from the
+ same archive directory, you will need to ensure that you do not delete
+ WAL files until they are no longer needed by any of the servers.
+ archive_cleanup_command> would typically be used in a
+ warm-standby configuration (see ).
+ Write %%> to embed an actual %> character in the
+ command.
+
+
+ If the command returns a non-zero exit status then a WARNING log
+ message will be written.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+ recovery_end_command (string)
+
+ recovery_end_command> configuration parameter
+
+
+
+ The 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>.
+
+
+ If the command returns a non-zero 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, the database will not proceed with startup.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+
+
+ Recovery Target
+
+
+
+ recovery_target_name (string)
+
+ recovery_target_name> configuration parameter
+
+
+
+ Specifies the named restore point, created with
+ pg_create_restore_point()> to which recovery will proceed.
+ At most one of recovery_target_name>,
+ recovery_target_time> or
+ recovery_target_xid> can be specified. The default
+ value is an empty string, which will recover to the end of the WAL log.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+ recovery_target_time (string)
+
+ recovery_target_time> configuration parameter
+
+
+
+ Specifies the time stamp up to which recovery will proceed.
+ This parameter must be specified in the date/time format
+ (see for details).
+ At most one of recovery_target_time>,
+ recovery_target_name> or
+ recovery_target_xid> can be specified.
+ The default value is an empty string, which will recover to
+ the end of the WAL log. The precise stopping point is also
+ influenced by recovery_target_inclusive>.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+ recovery_target_xid (string)
+
+ recovery_target_xid> configuration parameter
+
+
+
+ Specifies the transaction ID up to which recovery will proceed.
+ Keep in mind that while transaction IDs are assigned sequentially
+ at transaction start, transactions can complete in a different
+ numeric order. The transactions that will be recovered are
+ those that committed before (and optionally including)
+ the specified one. At most one of recovery_target_xid>,
+ recovery_target_name> or
+ recovery_target_time> can be specified.
+ The default value is an empty string, which will recover to the end of
+ the WAL log. The precise stopping point is also influenced by
+ recovery_target_inclusive>.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+ recovery_target_inclusive (boolean)
+
+ recovery_target_inclusive> configuration parameter
+
+
+
+ Specifies whether we stop just after the specified recovery target
+ (on>), or just before the recovery target (off>).
+ Applies to both recovery_target_time>
+ and recovery_target_xid>, whichever one is
+ specified for this recovery. This indicates whether transactions
+ having exactly the target commit time or ID, respectively, will
+ be included in the recovery. Default is on>.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode.
+
+
+
+
+
+ recovery_target_timeline (string)
+
+ recovery_target_timeline> configuration parameter
+
+
+
+ Specifies recovering into a particular timeline. The default value is
+ an empty string, which will recover along the same timeline that was
+ current when the base backup was taken. Setting this to
+ latest> recovers to the latest timeline found in the archive,
+ which is useful in a standby server. Other than that you only need to
+ set this parameter in complex re-recovery situations, where you need
+ to return to a state that itself was reached after a point-in-time
+ recovery. See for discussion.
+
+
+ This parameter can only be set at server start. It only has effect
+ during archive recovery or in standby mode.
+
+
+
+
+
+ pause_at_recovery_target (boolean)
+
+ pause_at_recovery_target> configuration parameter
+
+
+
+ Specifies whether recovery should pause when the recovery target
+ is reached. The default is on>.
+ This is intended to allow queries to be executed against the
+ database to check if this recovery target is the most desirable
+ point for recovery. The paused state can be resumed by using
+ pg_xlog_replay_resume()> (See
+ ), which then
+ causes recovery to end. If this recovery target is not the
+ desired stopping point, then shutdown the server, change the
+ recovery target settings to a later target and restart to
+ continue recovery.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect during archive
+ recovery or in standby mode if recovery target is set.
+
+
+
+
+
+
+
+ Migration from recovery.conf
+
+
+ Prior PostgreSQL> 9.2, all the recovery parameters had
+ to be specified in a configuration file called recovery.conf>
+ located at the root of data folder of server. Servers running
+ PostgreSQL> 9.3 and above return an error if
+ recovery.conf> is found in data folder.
+
+
+
+ postgresql.conf> provides two parameters allowing the
+ inclusion of external configuration files by either setting
+ include_if_exists> to include a given file or include_dir>
+ to include a directory containing a set of files configuration files.
+ In order to migrate an existing recovery.conf> used with
+ a server whose version is lower than 9.2, set one of those parameters to
+ include it correctly. It is also necessary to rename recovery.conf>
+ to a new name if the file included is located at root of data folder.
+
+
+
@@ -2371,6 +2677,93 @@ include 'filename'
+
+ standby_mode (boolean)
+
+ standby_mode> configuration parameter
+
+
+
+ Specifies whether to start the PostgreSQL> server as
+ a standby when the file called recovery.trigger> exists.
+ The default value is off>.
+ If this parameter is on>, the server will not
+ stop recovery when the end of archived WAL is reached,
+ but will keep trying to continue recovery by fetching new WAL segments
+ using restore_command> and/or by connecting to
+ the primary server as specified by the primary_conninfo>
+ setting.
+
+
+ This parameter can only be set at server start. It only has effect
+ if file recovery.trigger> exists.
+
+
+
+
+
+ primary_conninfo (string)
+
+ primary_conninfo> configuration parameter
+
+
+
+ Specifies a connection string to be used for the standby server
+ to connect with the primary. This string is in the format
+ accepted by the libpq PQconnectdb function,
+ described in . If any option is
+ unspecified in this string, then the corresponding environment
+ variable (see ) is checked. If the
+ environment variable is not set either, then defaults are used.
+ If this parameter is an empty string (the default), no attempt is
+ made to connect to the master.
+
+
+ The connection string should specify the host name (or address)
+ of the primary server, as well as the port number if it is not
+ the same as the standby server's default.
+ Also specify a user name corresponding to a role that has the
+ REPLICATION> and LOGIN> privileges on the
+ primary (see
+ ).
+ A password needs to be provided too, if the primary demands password
+ authentication. It can be provided in the
+ primary_conninfo string, or in a separate
+ ~/.pgpass> file on the standby server (use
+ replication> as the database name).
+ Do not specify a database name in the
+ primary_conninfo string.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect in standby mode.
+
+
+ If this parameter is changed while replication is in progress,
+ the standby terminates replication, and then tries to restart
+ replication with new setting.
+
+
+
+
+
+ trigger_file (string)
+
+ trigger_file> configuration parameter
+
+
+
+ Specifies a trigger file whose presence ends recovery in the
+ standby. Even if this value is not set, you can still promote
+ the standby using pg_ctl promote>.
+
+
+ This parameter can only be set in the postgresql.conf>
+ file or on the server command line. It only has effect in standby mode.
+
+
+
+
hot_standby (boolean)
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index d1b7dc6..7a59c51 100644
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -43,7 +43,6 @@
-
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 89f08af..544c4a6 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -15438,7 +15438,7 @@ postgres=# select pg_start_backup('label_goes_here');
pg_create_restore_point> creates a named transaction log
record that can be used as recovery target, and returns the corresponding
transaction log location. The given name can then be used with
- to specify the point up to which
+ to specify the point up to which
recovery will proceed. Avoid creating multiple restore points with the
same name, since recovery will stop at the first one whose name matches
the recovery target.
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c8f6fa8..8b02016 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -591,7 +591,7 @@ protocol to make nodes agree on a serializable transactional order.
In standby mode, the server continuously applies WAL received from the
master server. The standby server can read WAL from a WAL archive
- (see ) or directly from the master
+ (see ) or directly from the master
over a TCP connection (streaming replication). The standby server will
also attempt to restore any WAL found in the standby cluster's
pg_xlog> directory. That typically happens after a server
@@ -658,8 +658,8 @@ protocol to make nodes agree on a serializable transactional order.
To set up the standby server, restore the base backup taken from primary
server (see ). Create a recovery
- command file recovery.conf> in the standby's cluster data
- directory, and turn on standby_mode>. Set
+ trigger file recovery.trigger> in the standby's cluster data
+ directory. Turn on standby_mode> and set
restore_command> to a simple command to copy files from
the WAL archive. If you plan to have multiple standby servers for high
availability purposes, set recovery_target_timeline> to
@@ -695,7 +695,7 @@ protocol to make nodes agree on a serializable transactional order.
If you're using a WAL archive, its size can be minimized using the parameter to remove files that are no
+ linkend="guc-archive-cleanup-command"> parameter to remove files that are no
longer required by the standby server.
The pg_archivecleanup> utility is designed specifically to
be used with archive_cleanup_command> in typical single-standby
@@ -706,7 +706,7 @@ protocol to make nodes agree on a serializable transactional order.
- A simple example of a recovery.conf> is:
+ A simple example of standby settings is:
standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
@@ -763,8 +763,8 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
To use streaming replication, set up a file-based log-shipping standby
server as described in . The step that
turns a file-based log-shipping standby into streaming replication
- standby is setting primary_conninfo> setting in the
- recovery.conf> file to point to the primary server. Set
+ standby is setting primary_conninfo> to
+ point to the primary server. Set
and authentication options
(see pg_hba.conf>) on the primary so that the standby server
can connect to the replication> pseudo-database on the primary
@@ -824,15 +824,14 @@ host replication foo 192.168.1.100/32 md5
The host name and port number of the primary, connection user name,
- and password are specified in the recovery.conf> file.
+ and password are specified in primary_conninfo>.
The password can also be set in the ~/.pgpass> file on the
standby (specify replication> in the database>
field).
For example, if the primary is running on host IP 192.168.1.50>,
port 5432, the account name for replication is
foo>, and the password is foopass>, the administrator
- can add the following line to the recovery.conf> file on the
- standby:
+ can set primary_conninfo> on the standby like this:
# The standby connects to the primary that is running on host 192.168.1.50
@@ -1212,8 +1211,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
To trigger failover of a log-shipping standby server,
run pg_ctl promote> or create a trigger
- file with the file name and path specified by the trigger_file>
- setting in recovery.conf>. If you're planning to use
+ file with the file name and path specified by the trigger_file>.
+ If you're planning to use
pg_ctl promote> to fail over, trigger_file> is
not required. If you're setting up the reporting servers that are
only used to offload read-only queries from the primary, not for high
@@ -1258,8 +1257,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
The magic that makes the two loosely coupled servers work together is
simply a restore_command> used on the standby that,
when asked for the next WAL file, waits for it to become available from
- the primary. The restore_command> is specified in the
- recovery.conf> file on the standby server. Normal recovery
+ the primary. Normal recovery
processing would request a file from the WAL archive, reporting failure
if the file was unavailable. For standby processing it is normal for
the next WAL file to be unavailable, so the standby must wait for
@@ -1346,8 +1344,14 @@ if (!triggered)
+ Create a file called recovery.trigger> in the standby's
+ cluster data directory to trigger the recovery.
+
+
+
+
Begin recovery on the standby server from the local WAL
- archive, using a recovery.conf> that specifies a
+ archive, specifying a
restore_command> that waits as described
previously (see ).
@@ -1838,9 +1842,8 @@ if (!triggered)
Administrator's Overview
- If hot_standby> is turned on> in
- postgresql.conf> and there is a recovery.conf>
- file present, the server will run in Hot Standby mode.
+ If hot_standby> is turned on> and there is a file
+ recovery.trigger> present, the server will run in Hot Standby mode.
However, it may take some time for Hot Standby connections to be allowed,
because the server will not accept connections until it has completed
sufficient recovery to provide a consistent state against which queries
diff --git a/doc/src/sgml/pgarchivecleanup.sgml b/doc/src/sgml/pgarchivecleanup.sgml
index 932914b..2984da4 100644
--- a/doc/src/sgml/pgarchivecleanup.sgml
+++ b/doc/src/sgml/pgarchivecleanup.sgml
@@ -38,8 +38,8 @@
To configure a standby
- server to use pg_archivecleanup>, put this into its
- recovery.conf configuration file:
+ server to use pg_archivecleanup>, specify
+ like this:
archive_cleanup_command = 'pg_archivecleanup archivelocation> %r'
@@ -47,7 +47,7 @@ archive_cleanup_command = 'pg_archivecleanup archivelocation> %r'
files should be removed.
- When used within , all WAL files
+ When used within archive_cleanup_command>, all WAL files
logically preceding the value of the %r> argument will be removed
from archivelocation>. This minimizes the number of files
that need to be retained, while preserving crash-restart capability. Use of
diff --git a/doc/src/sgml/pgstandby.sgml b/doc/src/sgml/pgstandby.sgml
index ca2b5c0..15097ca 100644
--- a/doc/src/sgml/pgstandby.sgml
+++ b/doc/src/sgml/pgstandby.sgml
@@ -46,8 +46,8 @@
To configure a standby
- server to use pg_standby>, put this into its
- recovery.conf configuration file:
+ server to use pg_standby>, specify
+ like this:
restore_command = 'pg_standby archiveDir> %f %p %r'
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 522316c..b2e089b 100644
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -155,7 +155,6 @@
&maintenance;
&backup;
&high-availability;
- &recovery-config;
&monitoring;
&diskusage;
&wal;
diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
deleted file mode 100644
index c0c543e..0000000
--- a/doc/src/sgml/recovery-config.sgml
+++ /dev/null
@@ -1,361 +0,0 @@
-
-
-
- Recovery Configuration
-
-
- configuration
- of recovery
- of a standby server
-
-
-
- This chapter describes the settings available in the
- recovery.conf>recovery.conf>>
- file. They apply only for the duration of the
- recovery. They must be reset for any subsequent recovery you wish to
- perform. They cannot be changed once recovery has begun.
-
-
-
- Settings in recovery.conf> are specified in the format
- name = 'value'>. One parameter is specified per line.
- Hash marks (#) designate the rest of the
- line as a comment. To embed a single quote in a parameter
- value, write two quotes (''>).
-
-
-
- A sample file, share/recovery.conf.sample>,
- is provided in the installation's share/> directory.
-
-
-
-
- Archive Recovery Settings
-
-
-
- restore_command (string)
-
- restore_command> recovery parameter
-
-
-
- The 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 ).
- 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
-
-
-
-
-
-
- archive_cleanup_command (string)
-
- archive_cleanup_command> recovery parameter
-
-
-
- This optional parameter specifies a shell command that will be executed
- at every restartpoint. The purpose of
- archive_cleanup_command> is to provide a mechanism for
- cleaning up old archived WAL files that are no longer needed by the
- standby server.
- 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, and so all files earlier than %r>
- may be safely removed.
- This information can be used to truncate the archive to just the
- minimum required to support restart from the current restore.
- The module
- is often used in archive_cleanup_command> for
- single-standby configurations, for example:
-archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
- Note however that if multiple standby servers are restoring from the
- same archive directory, you will need to ensure that you do not delete
- WAL files until they are no longer needed by any of the servers.
- archive_cleanup_command> would typically be used in a
- warm-standby configuration (see ).
- Write %%> to embed an actual %> character in the
- command.
-
-
- If the command returns a non-zero exit status then a WARNING log
- message will be written.
-
-
-
-
-
- recovery_end_command (string)
-
- recovery_end_command> recovery parameter
-
-
-
- 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 .
-
-
- If the command returns a non-zero 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, the database will not proceed with startup.
-
-
-
-
-
-
-
-
-
-
- Recovery Target Settings
-
-
-
- recovery_target_name
- (string)
-
-
- recovery_target_name> recovery parameter
-
-
-
- This parameter specifies the named restore point, created with
- pg_create_restore_point()> to which recovery will proceed.
- At most one of recovery_target_name>,
- or
- can be specified. The default is to
- recover to the end of the WAL log.
-
-
-
-
-
- recovery_target_time
- (timestamp)
-
-
- recovery_target_time> recovery parameter
-
-
-
- This parameter specifies the time stamp up to which recovery
- will proceed.
- At most one of recovery_target_time>,
- or
- can be specified.
- The default is to recover to the end of the WAL log.
- The precise stopping point is also influenced by
- .
-
-
-
-
-
- recovery_target_xid (string)
-
- recovery_target_xid> recovery parameter
-
-
-
- This parameter specifies the transaction ID up to which recovery
- will proceed. Keep in mind
- that while transaction IDs are assigned sequentially at transaction
- start, transactions can complete in a different numeric order.
- The transactions that will be recovered are those that committed
- before (and optionally including) the specified one.
- At most one of recovery_target_xid>,
- or
- can be specified.
- The default is to recover to the end of the WAL log.
- The precise stopping point is also influenced by
- .
-
-
-
-
-
- recovery_target_inclusive
- (boolean)
-
-
- recovery_target_inclusive> recovery parameter
-
-
-
- Specifies whether we stop just after the specified recovery target
- (true), or just before the recovery target
- (false).
- Applies to both
- and , whichever one is
- specified for this recovery. This indicates whether transactions
- having exactly the target commit time or ID, respectively, will
- be included in the recovery. Default is true>.
-
-
-
-
-
- recovery_target_timeline
- (string)
-
-
- recovery_target_timeline> recovery parameter
-
-
-
- Specifies recovering into a particular timeline. The default is
- to recover along the same timeline that was current when the
- base backup was taken. Setting this to latest> recovers
- to the latest timeline found in the archive, which is useful in
- a standby server. Other than that you only need to set this parameter
- in complex re-recovery situations, where you need to return to
- a state that itself was reached after a point-in-time recovery.
- See for discussion.
-
-
-
-
-
- pause_at_recovery_target
- (boolean)
-
-
- pause_at_recovery_target> recovery parameter
-
-
-
- Specifies whether recovery should pause when the recovery target
- is reached. The default is true.
- This is intended to allow queries to be executed against the
- database to check if this recovery target is the most desirable
- point for recovery. The paused state can be resumed by using
- pg_xlog_replay_resume()> (See
- ), which then
- causes recovery to end. If this recovery target is not the
- desired stopping point, then shutdown the server, change the
- recovery target settings to a later target and restart to
- continue recovery.
-
-
- This setting has no effect if is not
- enabled, or if no recovery target is set.
-
-
-
-
-
-
-
-
-
- Standby Server Settings
-
-
-
- standby_mode (boolean)
-
- standby_mode> recovery parameter
-
-
-
- Specifies whether to start the PostgreSQL> server as
- a standby. If this parameter is on>, the server will
- not stop recovery when the end of archived WAL is reached, but
- will keep trying to continue recovery by fetching new WAL segments
- using restore_command>
- and/or by connecting to the primary server as specified by the
- primary_conninfo> setting.
-
-
-
-
- primary_conninfo (string)
-
- primary_conninfo> recovery parameter
-
-
-
- Specifies a connection string to be used for the standby server
- to connect with the primary. This string is in the format
- described in . If any option is
- unspecified in this string, then the corresponding environment
- variable (see ) is checked. If the
- environment variable is not set either, then
- defaults are used.
-
-
- The connection string should specify the host name (or address)
- of the primary server, as well as the port number if it is not
- the same as the standby server's default.
- Also specify a user name corresponding to a suitably-privileged role
- on the primary (see
- ).
- A password needs to be provided too, if the primary demands password
- authentication. It can be provided in the
- primary_conninfo string, or in a separate
- ~/.pgpass> file on the standby server (use
- replication> as the database name).
- Do not specify a database name in the
- primary_conninfo string.
-
-
- This setting has no effect if standby_mode> is off>.
-
-
-
-
- trigger_file (string)
-
- trigger_file> recovery parameter
-
-
-
- Specifies a trigger file whose presence ends recovery in the
- standby. Even if this value is not set, you can still promote
- the standby using pg_ctl promote>.
- This setting has no effect if standby_mode> is off>.
-
-
-
-
-
-
-
-
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index eb0c1d6..31de46e 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -190,13 +190,13 @@ PostgreSQL documentation
-
+
- Write a minimal recovery.conf in the output directory (or into
- the base archive file when using tar format) to ease setting
- up a standby server.
+ Write a minimal recovery.trigger in the output
+ directory (or into the base archive file when using tar format)
+ to ease setting up a standby server.
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index 051ab69..8d137f0 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -4939,7 +4939,7 @@
Add recovery.conf> setting pause_at_recovery_target>
+ linkend="guc-pause-at-recovery-target">pause_at_recovery_target>
to pause recovery at target (Simon Riggs)
@@ -4959,7 +4959,7 @@
These named restore points can be specified as recovery
targets using the new recovery.conf> setting
- recovery_target_name>.
+ recovery_target_name>.
@@ -4991,8 +4991,7 @@
- Allow recovery.conf>
+ Allow recovery.conf>
to use the same quoting behavior as postgresql.conf>
(Dimitri Fontaine)
diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index 0980c6e..68f1ce9 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -5,8 +5,8 @@ Typical markup:
&<> use & escapes
PostgreSQL
-postgresql.conf, pg_hba.conf,
- recovery.conf
+postgresql.conf, pg_hba.conf
+ recovery.trigger
[A-Z][A-Z_ ]+[A-Z_] , , ,
[A-Za-z_][A-Za-z0-9_]+()
-[-A-Za-z_]+