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+11-0
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