database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-21 12:05:57 +03:00
Code

Doc: Clarify interactions of pg_receivewal with remote_apply

Browse Source 
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
This commit is contained in:
Michael Paquier 2019-07-24 11:26:33 +09:00
parent 46fb7ff65e
commit 1c423463e4
1 changed files with 11 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/sgml/ref/pg_receivewal.sgml
View File

@ -52,7 +52,17 @@ PostgreSQL documentation
Unlike the WAL receiver of a PostgreSQL standby server, <application>pg_receivewal</>
by default flushes WAL data only when a WAL file is closed.
The option <option>--synchronous</> 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>