diff options
| -rw-r--r-- | doc/src/sgml/logicaldecoding.sgml | 76 |
1 files changed, 57 insertions, 19 deletions
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 05d59ce1c8a..4c2ca12445e 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -723,27 +723,65 @@ OutputPluginWrite(ctx, true); <sect1 id="logicaldecoding-synchronous"> <title>Synchronous Replication Support for Logical Decoding</title> + <sect2> + <title>Overview</title> - <para> - Logical decoding can be used to build - <link linkend="synchronous-replication">synchronous - replication</link> solutions with the same user interface as synchronous - replication for <link linkend="streaming-replication">streaming - replication</link>. To do this, the streaming replication interface - (see <xref linkend="logicaldecoding-walsender"/>) must be used to stream out - data. Clients have to send <literal>Standby status update (F)</literal> - (see <xref linkend="protocol-replication"/>) messages, just like streaming - replication clients do. - </para> - - <note> <para> - A synchronous replica receiving changes via logical decoding will work in - the scope of a single database. Since, in contrast to - that, <parameter>synchronous_standby_names</parameter> currently is - server wide, this means this technique will not work properly if more - than one database is actively used. + Logical decoding can be used to build + <link linkend="synchronous-replication">synchronous + replication</link> solutions with the same user interface as synchronous + replication for <link linkend="streaming-replication">streaming + replication</link>. To do this, the streaming replication interface + (see <xref linkend="logicaldecoding-walsender"/>) must be used to stream out + data. Clients have to send <literal>Standby status update (F)</literal> + (see <xref linkend="protocol-replication"/>) messages, just like streaming + replication clients do. + </para> + + <note> + <para> + A synchronous replica receiving changes via logical decoding will work in + the scope of a single database. Since, in contrast to + that, <parameter>synchronous_standby_names</parameter> currently is + server wide, this means this technique will not work properly if more + than one database is actively used. </para> - </note> + </note> + </sect2> + + <sect2 id="logicaldecoding-synchronous-caveats"> + <title>Caveats</title> + + <para> + In synchronous replication setup, a deadlock can happen, if the transaction + has locked [user] catalog tables exclusively. This is because logical decoding of + transactions can lock catalog tables to access them. To avoid this users + must refrain from taking an exclusive lock on [user] catalog tables. This can + happen in the following ways: + + <itemizedlist> + <listitem> + <para> + Issuing an explicit <command>LOCK</command> on <structname>pg_class</structname> + (or any other catalog table) in a transaction. + </para> + </listitem> + + <listitem> + <para> + Perform <command>CLUSTER</command> on <structname>pg_class</structname> in a + transaction. + </para> + </listitem> + + <listitem> + <para> + Executing <command>TRUNCATE</command> on [user] catalog table in a + transaction. + </para> + </listitem> + </itemizedlist> + </para> + </sect2> </sect1> </chapter> |