documentation for wal_retrieve_retry_interval
There is no documentation what use case the new (in 9.5) parameter
wal_retrieve_retry_interval is for. The commit message
(5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but
even that is not clear, and obviously in the wrong place. Could we come
up with something more to put into the documentation?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Nov 20, 2015 at 1:33 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
There is no documentation what use case the new (in 9.5) parameter
wal_retrieve_retry_interval is for. The commit message
(5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but
even that is not clear, and obviously in the wrong place. Could we come
up with something more to put into the documentation?
Yeah, we should highlight the facts that recovery can be made more
responsive when attempting to detect WAL. In archive recovery, this
can be translated by the fact that new WAL segments can be detected
more quickly and make recovery more responsive. The opposite is
actually what leaded to the patch: requirement was to limit the number
of times archive host was requested with a server that had low
activity, the archive host being on AWS.
An idea would be something like the patch attached. Thoughts?
--
Michael
Attachments:
20151120_wal_retry_interval_doc.patchbinary/octet-stream; name=20151120_wal_retry_interval_doc.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 6e14851..392eb70 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3054,6 +3054,17 @@ include_dir 'conf.d'
<filename>postgresql.conf</> file or on the server command line.
The default value is 5 seconds. Units are milliseconds if not specified.
</para>
+ <para>
+ This parameter is useful in configurations where a node in recovery
+ needs to control the amount of time to wait for new WAL data to be
+ available. For example, in archive recovery, it is possible to
+ make the recovery more responsive in the detection of a new WAL
+ log file by reducing the value of this parameter. On a system with
+ low WAL activity, increasing it reduces the amount of requests necessary
+ to access WAL archives, something useful for example in cloud
+ environments where the amount of times an infrastructure is accessed
+ is taken into account.
+ </para>
</listitem>
</varlistentry>
On 11/19/15 11:26 PM, Michael Paquier wrote:
On Fri, Nov 20, 2015 at 1:33 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
There is no documentation what use case the new (in 9.5) parameter
wal_retrieve_retry_interval is for. The commit message
(5d2b45e3f78a85639f30431181c06d4c3221c5a1) alludes to something, but
even that is not clear, and obviously in the wrong place. Could we come
up with something more to put into the documentation?Yeah, we should highlight the facts that recovery can be made more
responsive when attempting to detect WAL. In archive recovery, this
can be translated by the fact that new WAL segments can be detected
more quickly and make recovery more responsive. The opposite is
actually what leaded to the patch: requirement was to limit the number
of times archive host was requested with a server that had low
activity, the archive host being on AWS.An idea would be something like the patch attached. Thoughts?
Sounds good. Thanks!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 23, 2015 at 11:25 PM, Peter Eisentraut wrote:
Sounds good. Thanks!
Great. Thanks for considering it!
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers