Specifies whether to start the PostgreSQL server as a standby. If
this parameter is
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
Specifies a connection string to be used for the standby server to connect with the primary. This string is in the format described in Section 34.1.1. If any option is unspecified in this string, then the corresponding environment variable (see Section 34.14) 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 Section 126.96.36.199).
A password needs to be provided too, if the primary demands
password authentication. It can be provided in the
primary_conninfo string, or in
~/.pgpass file on
the standby server (use
replication as the database name). Do not
specify a database name in the
This setting has no effect if
Optionally specifies an existing replication slot to be
used when connecting to the primary via streaming
replication to control resource removal on the upstream
node (see Section 26.2.6).
This setting has no effect if
primary_conninfo is not set.
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
promote. This setting has no effect if
By default, a standby server restores WAL records from
the primary as soon as possible. It may be useful to have a
time-delayed copy of the data, offering opportunities to
correct data loss errors. This parameter allows you to
delay recovery by a fixed period of time, measured in
milliseconds if no unit is specified. For example, if you
set this parameter to
the standby will replay each transaction commit only when
the system time on the standby is at least five minutes
past the commit time reported by the master.
It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on master and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on master and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers.
The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied.
The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting.
This parameter is intended for use with streaming
replication deployments; however, if the parameter is
specified it will be honored in all cases.
hot_standby_feedback will be delayed by
use of this feature which could lead to bloat on the
master; use both together with care.
Synchronous replication is affected by this setting
COMMIT will need to wait to
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.