@@ -691,27 +691,65 @@ OutputPluginWrite(ctx, true);
691
691
692
692
<sect1 id="logicaldecoding-synchronous">
693
693
<title>Synchronous Replication Support for Logical Decoding</title>
694
+ <sect2>
695
+ <title>Overview</title>
694
696
695
- <para>
696
- Logical decoding can be used to build
697
- <link linkend="synchronous-replication">synchronous
698
- replication</link> solutions with the same user interface as synchronous
699
- replication for <link linkend="streaming-replication">streaming
700
- replication</link>. To do this, the streaming replication interface
701
- (see <xref linkend="logicaldecoding-walsender">) must be used to stream out
702
- data. Clients have to send <literal>Standby status update (F)</literal>
703
- (see <xref linkend="protocol-replication">) messages, just like streaming
704
- replication clients do.
705
- </para>
706
-
707
- <note>
708 697
<para>
709
- A synchronous replica receiving changes via logical decoding will work in
710
- the scope of a single database. Since, in contrast to
711
- that, <parameter>synchronous_standby_names</parameter> currently is
712
- server wide, this means this technique will not work properly if more
713
- than one database is actively used.
698
+ Logical decoding can be used to build
699
+ <link linkend="synchronous-replication">synchronous
700
+ replication</link> solutions with the same user interface as synchronous
701
+ replication for <link linkend="streaming-replication">streaming
702
+ replication</link>. To do this, the streaming replication interface
703
+ (see <xref linkend="logicaldecoding-walsender">) must be used to stream out
704
+ data. Clients have to send <literal>Standby status update (F)</literal>
705
+ (see <xref linkend="protocol-replication">) messages, just like streaming
706
+ replication clients do.
707
+ </para>
708
+
709
+ <note>
710
+ <para>
711
+ A synchronous replica receiving changes via logical decoding will work in
712
+ the scope of a single database. Since, in contrast to
713
+ that, <parameter>synchronous_standby_names</parameter> currently is
714
+ server wide, this m
10000
eans this technique will not work properly if more
715
+ than one database is actively used.
714
716
</para>
715
- </note>
717
+ </note>
718
+ </sect2>
719
+
720
+ <sect2 id="logicaldecoding-synchronous-caveats">
721
+ <title>Caveats</title>
722
+
723
+ <para>
724
+ In synchronous replication setup, a deadlock can happen, if the transaction
725
+ has locked [user] catalog tables exclusively. This is because logical decoding of
726
+ transactions can lock catalog tables to access them. To avoid this users
727
+ must refrain from taking an exclusive lock on [user] catalog tables. This can
728
+ happen in the following ways:
729
+
730
+ <itemizedlist>
731
+ <listitem>
732
+ <para>
733
+ Issuing an explicit <command>LOCK</command> on <structname>pg_class</structname>
734
+ (or any other catalog table) in a transaction.
735
+ </para>
736
+ </listitem>
737
+
738
+ <listitem>
739
+ <para>
740
+ Perform <command>CLUSTER</command> on <structname>pg_class</structname> in a
741
+ transaction.
742
+ </para>
743
+ </listitem>
744
+
745
+ <listitem>
746
+ <para>
747
+ Executing <command>TRUNCATE</command> on [user] catalog table in a
748
+ transaction.
749
+ </para>
750
+ </listitem>
751
+ </itemizedlist>
752
+ </para>
753
+ </sect2>
716
754
</sect1>
717
755
</chapter>
0 commit comments