From: Michael Paquier Date: Wed, 24 Jul 2019 02:26:29 +0000 (+0900) Subject: Doc: Clarify interactions of pg_receivewal with remote_apply X-Git-Tag: REL_11_5~31 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=059e22693b2312cd091e5afe5800cedc6abd14b8;p=postgresql Doc: Clarify interactions of pg_receivewal with remote_apply Using pg_receivewal with synchronous_commit = remote_apply set in the backend is incompatible if pg_receivewal is a synchronous standby as it never applies WAL, so document this problem and solutions to it. Backpatch to 9.6, where remote_apply has been added. Author: Robert Haas, Jesper Pedersen Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/1427a2d3-1e51-9335-1931-4f8853d90d5e@redhat.com Backpatch-through: 9.6 --- diff --git a/doc/src/sgml/ref/pg_receivewal.sgml b/doc/src/sgml/ref/pg_receivewal.sgml index a18ddd4bff..9c7b0f48c4 100644 --- a/doc/src/sgml/ref/pg_receivewal.sgml +++ b/doc/src/sgml/ref/pg_receivewal.sgml @@ -52,7 +52,17 @@ PostgreSQL documentation Unlike the WAL receiver of a PostgreSQL standby server, pg_receivewal by default flushes WAL data only when a WAL file is closed. The option must be specified to flush WAL data - in real time. + in real time. Since pg_receivewal does not + apply WAL, you should not allow it to become a synchronous standby when + equals + remote_apply. If it does, it will appear to be a + standby that never catches up, and will cause transaction commits to + block. To avoid this, you should either configure an appropriate value + for , or specify + application_name for + pg_receivewal that does not match it, or + change the value of synchronous_commit to + something other than remote_apply.