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 a17082bb11c1af25b0c545d97f010fb2a22a9148..cd4f49177911c3b9083adf541ebf5eb63df1758c 100644 (file)
--- 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 --synchronous 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.