From 0d0b2bf175a53dfedcc0cb69eaba7576b0c286f2 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 10 May 2014 19:46:19 -0400
Subject: Rename min_recovery_apply_delay to recovery_min_apply_delay.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Per discussion, this seems like a more consistent choice of name.

Fabrízio de Royes Mello, after a suggestion by Peter Eisentraut;
some additional documentation wordsmithing by me
---
 doc/src/sgml/recovery-config.sgml | 16 ++++++++--------
 doc/src/sgml/release-9.4.sgml     |  4 ++--
 2 files changed, 10 insertions(+), 10 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
index 0e78d909b5a..762207ebeae 100644
--- a/doc/src/sgml/recovery-config.sgml
+++ b/doc/src/sgml/recovery-config.sgml
@@ -403,15 +403,15 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
         </listitem>
        </varlistentry>
 
-     <varlistentry id="min-recovery-apply-delay" xreflabel="min_recovery_apply_delay">
-      <term><varname>min_recovery_apply_delay</varname> (<type>integer</type>)
+     <varlistentry id="recovery-min-apply-delay" xreflabel="recovery_min_apply_delay">
+      <term><varname>recovery_min_apply_delay</varname> (<type>integer</type>)
       <indexterm>
-        <primary><varname>min_recovery_apply_delay</> recovery parameter</primary>
+        <primary><varname>recovery_min_apply_delay</> recovery parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
-        By default, a standby server keeps restoring WAL records from the
+        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,
@@ -428,15 +428,15 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
         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
+        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.
        </para>
        <para>
         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
+        is not an issue for MVCC though it may potentially increase the number
         of recovery conflicts generated.
        </para>
        <para>
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 21c6fc77f79..f627113c991 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -775,10 +775,10 @@
 
       <listitem>
        <para>
-        Allow <link
+        Add <link
         linkend="recovery-config"><filename>recovery.conf</></link>
         parameter <link
-        linkend="min-recovery-apply-delay"><varname>min_recovery_apply_delay</></link>
+        linkend="recovery-min-apply-delay"><varname>recovery_min_apply_delay</></link>
         to force delayed replication (Robert Haas, Fabr&iacute;zio de
         Royes Mello, Simon Riggs)
        </para>
-- 
cgit v1.2.3