From: Michael Paquier Date: Wed, 24 Jul 2019 02:25:43 +0000 (+0900) Subject: Doc: Clarify interactions of pg_receivewal with remote_apply X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=fd7d387e0548fd371c06a91d75bc4632541ccfdd;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 0506120c00..177e9211c0 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.