@@ -142,56 +142,6 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
142142 </listitem>
143143 </varlistentry>
144144
145- <varlistentry id="min-recovery-apply-delay" xreflabel="min_recovery_apply_delay">
146- <term><varname>min_recovery_apply_delay</varname> (<type>integer</type>)</term>
147- <indexterm>
148- <primary><varname>min_recovery_apply_delay</> recovery parameter</primary>
149- </indexterm>
150- <listitem>
151- <para>
152- By default, a standby server keeps restoring WAL records from the
153- primary as soon as possible. It may be useful to have a time-delayed
154- copy of the data, offering various options to correct data loss errors.
155- This parameter allows you to delay recovery by a fixed period of time,
156- specified in milliseconds if no unit is specified. For example, if
157- you set this parameter to <literal>5min</literal>, the standby will
158- replay each transaction commit only when the system time on the standby
159- is at least five minutes past the commit time reported by the master.
160- </para>
161- <para>
162- It is possible that the replication delay between servers exceeds the
163- value of this parameter, in which case no delay is added.
164- Note that the delay is calculated between the WAL timestamp as written
165- on master and the time on the current standby. Delays
166- in transfer because of networks or cascading replication configurations
167- may reduce the actual wait time significantly. If the system
168- clocks on master and standby are not synchronised, this may lead to
169- recovery applying records earlier than expected but is not a major issue
170- because the useful settings of the parameter are much larger than
171- typical time deviation between the servers. Be careful to allow for
172- different timezone settings on master and standby.
173- </para>
174- <para>
175- The delay occurs only on WAL records for COMMIT and Restore Points.
176- Other records may be replayed earlier than the specified delay, which
177- is not an issue for MVCC though may potentially increase the number
178- of recovery conflicts generated.
179- </para>
180- <para>
181- The delay occurs until the standby is promoted or triggered. After that
182- the standby will end recovery without further waiting.
183- </para>
184- <para>
185- This parameter is intended for use with streaming replication deployments,
186- however, if the parameter is specified it will be honoured in all cases.
187- Synchronous replication is not affected by this setting because there is
188- not yet any setting to request synchronous apply of transaction commits.
189- <varname>hot_standby_feedback</> will be delayed by use of this feature
190- which could lead to bloat on the master; use both together with care.
191- </para>
192- </listitem>
193- </varlistentry>
194-
195145 </variablelist>
196146
197147 </sect1>
@@ -449,6 +399,56 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
449399 </listitem>
450400 </varlistentry>
451401
402+ <varlistentry id="min-recovery-apply-delay" xreflabel="min_recovery_apply_delay">
403+ <term><varname>min_recovery_apply_delay</varname> (<type>integer</type>)</term>
404+ <indexterm>
405+ <primary><varname>min_recovery_apply_delay</> recovery parameter</primary>
406+ </indexterm>
407+ <listitem>
408+ <para>
409+ By default, a standby server keeps restoring WAL records from the
410+ primary as soon as possible. It may be useful to have a time-delayed
411+ copy of the data, offering various options to correct data loss errors.
412+ This parameter allows you to delay recovery by a fixed period of time,
413+ specified in milliseconds if no unit is specified. For example, if
414+ you set this parameter to <literal>5min</literal>, the standby will
415+ replay each transaction commit only when the system time on the standby
416+ is at least five minutes past the commit time reported by the master.
417+ </para>
418+ <para>
419+ It is possible that the replication delay between servers exceeds the
420+ value of this parameter, in which case no delay is added.
421+ Note that the delay is calculated between the WAL timestamp as written
422+ on master and the time on the current standby. Delays
423+ in transfer because of networks or cascading replication configurations
424+ may reduce the actual wait time significantly. If the system
425+ clocks on master and standby are not synchronised, this may lead to
426+ recovery applying records earlier than expected but is not a major issue
427+ because the useful settings of the parameter are much larger than
428+ typical time deviation between the servers. Be careful to allow for
429+ different timezone settings on master and standby.
430+ </para>
431+ <para>
432+ The delay occurs only on WAL records for COMMIT and Restore Points.
433+ Other records may be replayed earlier than the specified delay, which
434+ is not an issue for MVCC though may potentially increase the number
435+ of recovery conflicts generated.
436+ </para>
437+ <para>
438+ The delay occurs until the standby is promoted or triggered. After that
439+ the standby will end recovery without further waiting.
440+ </para>
441+ <para>
442+ This parameter is intended for use with streaming replication deployments,
443+ however, if the parameter is specified it will be honoured in all cases.
444+ Synchronous replication is not affected by this setting because there is
445+ not yet any setting to request synchronous apply of transaction commits.
446+ <varname>hot_standby_feedback</> will be delayed by use of this feature
447+ which could lead to bloat on the master; use both together with care.
448+ </para>
449+ </listitem>
450+ </varlistentry>
451+
452452 </variablelist>
453453 </sect1>
454454