postgres.git / summary / log / commit / refs
commit 059e22693b2312cd091e5afe5800cedc6abd14b8
Author: Michael Paquier <michael@paquier.xyz>
Date: Wed Jul 24 02:26:29 2019 +0000
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
doc/src/sgml/ref/pg_receivewal.sgml | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/ref/pg_receivewal.sgml b/doc/src/sgml/ref/pg_receivewal.sgml
index a18ddd4bff1..9c7b0f48c42 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, <application>pg_receivewal</application>
by default flushes WAL data only when a WAL file is closed.
The option <option>--synchronous</option> must be specified to flush WAL data
- in real time.
+ in real time. Since <application>pg_receivewal</application> does not
+ apply WAL, you should not allow it to become a synchronous standby when
+ <xref linkend="guc-synchronous-commit"/> equals
+ <literal>remote_apply</literal>. 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 <xref linkend="guc-synchronous-standby-names"/>, or specify
+ <varname>application_name</varname> for
+ <application>pg_receivewal</application> that does not match it, or
+ change the value of <varname>synchronous_commit</varname> to
+ something other than <literal>remote_apply</literal>.
</para>
<para>
[parent: ca553394b2ef]