diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
index b69ce287c8..9335aca861 100644
--- a/doc/src/sgml/recovery-config.sgml
+++ b/doc/src/sgml/recovery-config.sgml
@@ -142,56 +142,6 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
-
- min_recovery_apply_delay (integer)
-
- min_recovery_apply_delay recovery parameter
-
-
-
- By default, a standby server keeps restoring 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 is not a major issue
- because the useful settings of the parameter are much larger than
- typical time deviation between the 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 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.
-
-
-
-
@@ -449,6 +399,56 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
+
+ min_recovery_apply_delay (integer)
+
+ min_recovery_apply_delay recovery parameter
+
+
+
+ By default, a standby server keeps restoring 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 is not a major issue
+ because the useful settings of the parameter are much larger than
+ typical time deviation between the 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 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.
+
+
+
+