Rename min_recovery_apply_delay to recovery_min_apply_delay.
authorTom Lane
Sat, 10 May 2014 23:46:19 +0000 (19:46 -0400)
committerTom Lane
Sat, 10 May 2014 23:46:19 +0000 (19:46 -0400)
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
doc/src/sgml/release-9.4.sgml
src/backend/access/transam/recovery.conf.sample
src/backend/access/transam/xlog.c

index 0e78d909b5a6f953f491f3774bf82252e0b619f9..762207ebeae72797b1160066f5fe521ea3ad8d11 100644 (file)
@@ -403,15 +403,15 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
         
        
 
-     min-recovery-apply-delay" xreflabel="min_recovery_apply_delay">
-      min_recovery_apply_delay (integer)
+     recovery-min-apply-delay" xreflabel="recovery_min_apply_delay">
+      recovery_min_apply_delay (integer)
       
-        min_recovery_apply_delay recovery parameter
+        recovery_min_apply_delay recovery parameter
       
       
       
        
-        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.
        
        
         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.
        
        
index 21c6fc77f79405c0bbda19b872f7be9ac1f3bac1..f627113c991414e8bea989d862ed8790f54e0ff7 100644 (file)
 
       
        
-        Allow 
+        Add 
         linkend="recovery-config">recovery.conf
         parameter 
-        linkend="min-recovery-apply-delay">min_recovery_apply_delay
+        linkend="recovery-min-apply-delay">recovery_min_apply_delay
         to force delayed replication (Robert Haas, Fabrízio de
         Royes Mello, Simon Riggs)
        
index 2612a7df9fd5ac006dc7b07b3236020823bb0e43..745f27033abe207bfbf56ea869955ceeea5ad168 100644 (file)
 #
 # By default, a standby server keeps restoring XLOG records from the
 # primary indefinitely. If you want to stop the standby mode, finish recovery
-# and open the system in read/write mode, specify path to a trigger file.
+# and open the system in read/write mode, specify path to a trigger file.
 # The server will poll the trigger file path periodically and start as a
 # primary server when it's found.
 #
 #trigger_file = ''
 #
-# By default, a standby server keeps restoring XLOG records from the
-# primary as soon as possible. If you want to explicitly delay the replay of
-# committed transactions from the master, specify a recovery apply delay.
-# 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.
+# By default, a standby server restores XLOG records from the primary as
+# soon as possible. If you want to explicitly delay the replay of committed
+# transactions from the master, specify a minimum apply delay. 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.
 #
-#min_recovery_apply_delay = 0
+#recovery_min_apply_delay = 0
 #
 #---------------------------------------------------------------------------
 # HOT STANDBY PARAMETERS
index 3406fa5a29d7674d450b13d4b344202b3e5b052c..3d752c6418c83c74b6fd25a1345f282e9c565d36 100644 (file)
@@ -223,7 +223,7 @@ static bool recoveryPauseAtTarget = true;
 static TransactionId recoveryTargetXid;
 static TimestampTz recoveryTargetTime;
 static char *recoveryTargetName;
-static int min_recovery_apply_delay = 0;
+static int recovery_min_apply_delay = 0;
 static TimestampTz recoveryDelayUntilTime;
 
 /* options taken from recovery.conf for XLOG streaming */
@@ -5236,18 +5236,19 @@ readRecoveryCommandFile(void)
                    (errmsg_internal("trigger_file = '%s'",
                                     TriggerFile)));
        }
-       else if (strcmp(item->name, "min_recovery_apply_delay") == 0)
+       else if (strcmp(item->name, "recovery_min_apply_delay") == 0)
        {
            const char *hintmsg;
 
-           if (!parse_int(item->value, &min_recovery_apply_delay, GUC_UNIT_MS,
+           if (!parse_int(item->value, &recovery_min_apply_delay, GUC_UNIT_MS,
                           &hintmsg))
                ereport(ERROR,
                        (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
-                        errmsg("parameter \"%s\" requires a temporal value", "min_recovery_apply_delay"),
+                        errmsg("parameter \"%s\" requires a temporal value",
+                               "recovery_min_apply_delay"),
                         hintmsg ? errhint("%s", _(hintmsg)) : 0));
            ereport(DEBUG2,
-                   (errmsg("min_recovery_apply_delay = '%s'", item->value)));
+                   (errmsg("recovery_min_apply_delay = '%s'", item->value)));
        }
        else
            ereport(FATAL,
@@ -5669,7 +5670,7 @@ SetRecoveryPause(bool recoveryPause)
 }
 
 /*
- * When min_recovery_apply_delay is set, we wait long enough to make sure
+ * When recovery_min_apply_delay is set, we wait long enough to make sure
  * certain record types are applied at least that interval behind the master.
  *
  * Returns true if we waited.
@@ -5690,7 +5691,7 @@ recoveryApplyDelay(XLogRecord *record)
    int         microsecs;
 
    /* nothing to do if no delay configured */
-   if (min_recovery_apply_delay == 0)
+   if (recovery_min_apply_delay == 0)
        return false;
 
    /*
@@ -5711,7 +5712,7 @@ recoveryApplyDelay(XLogRecord *record)
        return false;
 
    recoveryDelayUntilTime =
-       TimestampTzPlusMilliseconds(xtime, min_recovery_apply_delay);
+       TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);
 
    /*
     * Exit without arming the latch if it's already past time to apply this