mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Document that logical replication supports synchronous replication

Browse Source 
Update the documentation a bit to include that logical replication as
well as other and third-party replication clients can participate in
synchronous replication.
This commit is contained in:
Peter Eisentraut 2017-07-02 00:10:57 -04:00
parent d8b3c81335
commit 2dca03439f
3 changed files with 39 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
doc/src/sgml/config.sgml
View File

@ -3074,7 +3074,19 @@ include_dir 'conf.d'
(as shown by a state of <literal>streaming</literal> in the
<link linkend="monitoring-stats-views-table">
<literal>pg_stat_replication</></link> view).
Specifying more than one standby names can allow very high availability.
Specifying more than one synchronous standby can allow for very high
availability and protection against data loss.
</para>
<para>
The name of a standby server for this purpose is the
<varname>application_name</> setting of the standby, as set in the
standby's connection information. In case of a physical replication
standby, this should be set in the <varname>primary_conninfo</>
setting in <filename>recovery.conf</filename>; the default
is <literal>walreceiver</literal>. For logical replication, this can
be set in the connection information of the subscription, and it
defaults to the subscription name. For other replication stream
consumers, consult their documentation.
</para>
<para>
This parameter specifies a list of standby servers using
@ -3136,15 +3148,12 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
as a synchronous standby.
</para>
<para>
The name of a standby server for this purpose is the
<varname>application_name</> setting of the standby, as set in the
<varname>primary_conninfo</> of the standby's WAL receiver. There is
no mechanism to enforce uniqueness. In case of duplicates one of the
matching standbys will be considered as higher priority, though
exactly which one is indeterminate.
The special entry <literal>*</> matches any
<varname>application_name</>, including the default application name
of <literal>walreceiver</>.
The special entry <literal>*</> matches any standby name.
</para>
<para>
There is no mechanism to enforce uniqueness of standby names. In case
of duplicates one of the matching standbys will be considered as
higher priority, though exactly which one is indeterminate.
</para>
<note>
<para>

12
doc/src/sgml/high-availability.sgml
View File

@ -1056,6 +1056,18 @@ primary_slot_name = 'node_a_slot'
require commit waits, including both prepare and commit.
</para>
<para>
A synchronous standby can be a physical replication standby or a logical
replication subscriber. It can also be any other physical or logical WAL
replication stream consumer that knows how to send the appropriate
feedback messages. Besides the built-in physical and logical replication
systems, this includes special programs such
as <command>pg_receivewal</command> and <command>pg_recvlogical</command>
as well as some third-party replication systems and custom programs.
Check the respective documentation for details on synchronous replication
support.
</para>
<sect3 id="synchronous-replication-config">
<title>Basic Configuration</title>

8
doc/src/sgml/logical-replication.sgml
View File

@ -184,6 +184,14 @@
of pre-existing table data.
</para>
<para>
A logical replication subscription can be a standby for synchronous
replication (see <xref linkend="synchronous-replication">). The standby
name is by default the subscription name. An alternative name can be
specified as <literal>application_name</literal> in the connection
information of the subscription.
</para>
<para>
Subscriptions are dumped by <command>pg_dump</command> if the current user
is a superuser. Otherwise a warning is written and subscriptions are