Tue, 30 Dec 2014 21:39:33 +0900 от Michael Paquier <michael.paqu...@gmail.com>:
> On Tue, Dec 30, 2014 at 9:33 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
> > On Tue, Dec 30, 2014 at 9:10 PM, Alexey Vasiliev <leopard...@inbox.ru>
> > wrote:
> >> To not modify current pg_usleep calculation, I changed
> >> restore_command_retry_interval value to seconds (not milliseconds). In this
> >> case, min value - 1 second.
> > Er, what the problem with not changing 1000000L to 1000L? The unit of
> > your parameter is ms AFAIK.
> Of course I meant in the previous version of the patch not the current
> one. Wouldn't it be useful to use it with for example retry intervals
> of the order of 100ms~300ms for some cases?
> --
> Michael
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
Thanks, patch changed.
As I understand now = (pg_time_t) time(NULL); return time in seconds, what is
why I multiply value to 1000 to compare with restore_command_retry_interval in
milliseconds.
I am not sure about small retry interval of time, in my cases I need interval
bigger 5 seconds (20-40 seconds). Right now I limiting this value be bigger 100
milliseconds.
--
Alexey Vasiliev
diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
index ef78bc0..52cb47d 100644
--- a/doc/src/sgml/recovery-config.sgml
+++ b/doc/src/sgml/recovery-config.sgml
@@ -145,6 +145,29 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</listitem>
</varlistentry>
+ <varlistentry id="restore-command-retry-interval" xreflabel="restore_command_retry_interval">
+ <term><varname>restore_command_retry_interval</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>restore_command_retry_interval</> recovery parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ If <varname>restore_command</> returns nonzero exit status code, retry
+ command after the interval of time specified by this parameter.
+ Default value is <literal>5s</>.
+ </para>
+ <para>
+ This is useful, if I using for restore of wal logs some
+ external storage and request each 5 seconds for wal logs
+ can be useless and cost additional money.
+ Increasing this parameter allow to increase retry interval of time,
+ if not found new wal logs inside external storage and no matter
+ what the slave database will lag behind the master.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</sect1>
diff --git a/src/backend/access/transam/recovery.conf.sample b/src/backend/access/transam/recovery.conf.sample
index b777400..5b63f60 100644
--- a/src/backend/access/transam/recovery.conf.sample
+++ b/src/backend/access/transam/recovery.conf.sample
@@ -58,6 +58,11 @@
#
#recovery_end_command = ''
#
+# specifies an optional retry interval of restore_command command, if previous return nonzero exit status code.
+# This can be useful to increase/decrease number of a restore_command calls.
+#
+#restore_command_retry_interval = 5s
+#
#---------------------------------------------------------------------------
# RECOVERY TARGET PARAMETERS
#---------------------------------------------------------------------------
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index e5dddd4..67a873c 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -235,6 +235,7 @@ static TimestampTz recoveryTargetTime;
static char *recoveryTargetName;
static int recovery_min_apply_delay = 0;
static TimestampTz recoveryDelayUntilTime;
+static int restore_command_retry_interval = 5000;
/* options taken from recovery.conf for XLOG streaming */
static bool StandbyModeRequested = false;
@@ -4881,6 +4882,28 @@ readRecoveryCommandFile(void)
(errmsg_internal("trigger_file = '%s'",
TriggerFile)));
}
+ else if (strcmp(item->name, "restore_command_retry_interval") == 0)
+ {
+ const char *hintmsg;
+
+ if (!parse_int(item->value, &restore_command_retry_interval, GUC_UNIT_MS,
+ &hintmsg))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("parameter \"%s\" requires a temporal value",
+ "restore_command_retry_interval"),
+ hintmsg ? errhint("%s", _(hintmsg)) : 0));
+ ereport(DEBUG2,
+ (errmsg_internal("restore_command_retry_interval = '%s'", item->value)));
+
+ if (restore_command_retry_interval < 100)
+ {
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("\"%s\" must have a bigger 100 milliseconds value",
+ "restore_command_retry_interval")));
+ }
+ }
else if (strcmp(item->name, "recovery_min_apply_delay") == 0)
{
const char *hintmsg;
@@ -10495,13 +10518,13 @@ WaitForWALToBecomeAvailable(XLogRecPtr RecPtr, bool randAccess,
* machine, so we've exhausted all the options for
* obtaining the requested WAL. We're going to loop back
* and retry from the archive, but if it hasn't been long
- * since last attempt, sleep 5 seconds to avoid
- * busy-waiting.
+ * since last attempt, sleep restore_command_retry_interval
+ * (by default 5 seconds) to avoid busy-waiting.
*/
now = (pg_time_t) time(NULL);
- if ((now - last_fail_time) < 5)
+ if (((now - last_fail_time) * 1000) < restore_command_retry_interval)
{
- pg_usleep(1000000L * (5 - (now - last_fail_time)));
+ pg_usleep(1000L * (restore_command_retry_interval - ((now - last_fail_time) * 1000)));
now = (pg_time_t) time(NULL);
}
last_fail_time = now;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
