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.
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 31.1.1. If any option is unspecified in this string, then the corresponding environment variable (see Section 31.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 184.108.40.206). 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.
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 25.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 pg_ctl promote. This setting has no effect if standby_mode is off.
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 various options to correct data loss errors. This parameter allows you to delay recovery by a fixed period of time, specified in milliseconds if no unit is specified. For example, if you set this parameter to 5min, 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 timestamp as written on master and the time on the current standby. Delays in transfer because of networks or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on master and standby are not synchronised, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of the parameter are much larger than typical time deviations between servers. Be careful to allow for different timezone settings on master and standby.
The delay occurs only on WAL records for COMMIT and Restore Points. Other records may be replayed earlier than the specified delay, which is not an issue for MVCC though it may potentially increase the number of recovery conflicts generated.
The delay occurs 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 honoured in all cases. Synchronous replication is not affected by this setting because there is not yet any setting to request synchronous apply of transaction commits. hot_standby_feedback will be delayed by use of this feature which could lead to bloat on the master; use both together with care.