@@ -1097,16 +1097,18 @@ OutputPluginWrite(ctx, true);
10971097
10981098 <para>
10991099 In synchronous replication setup, a deadlock can happen, if the transaction
1100- has locked [user] catalog tables exclusively. This is because logical decoding of
1101- transactions can lock catalog tables to access them. To avoid this users
1102- must refrain from taking an exclusive lock on [user] catalog tables. This can
1103- happen in the following ways:
1100+ has locked [user] catalog tables exclusively. See
1101+ <xref linkend="logicaldecoding-capabilities"/> for information on user
1102+ catalog tables. This is because logical decoding of transactions can lock
1103+ catalog tables to access them. To avoid this users must refrain from taking
1104+ an exclusive lock on [user] catalog tables. This can happen in the following
1105+ ways:
11041106
11051107 <itemizedlist>
11061108 <listitem>
11071109 <para>
11081110 Issuing an explicit <command>LOCK</command> on <structname>pg_class</structname>
1109- (or any other catalog table) in a transaction.
1111+ in a transaction.
11101112 </para>
11111113 </listitem>
11121114
@@ -1141,6 +1143,10 @@ OutputPluginWrite(ctx, true);
11411143 </para>
11421144 </listitem>
11431145 </itemizedlist>
1146+
1147+ Note that these commands that can cause deadlock apply to not only explicitly
1148+ indicated system catalog tables above but also to any other [user] catalog
1149+ table.
11441150 </para>
11451151 </sect2>
11461152 </sect1>
@@ -1311,7 +1317,7 @@ stream_commit_cb(...); <-- commit of the streamed transaction
13111317 [user] catalog tables exclusively. To avoid this users must refrain from
13121318 having locks on catalog tables (e.g. explicit <command>LOCK</command> command)
13131319 in such transactions.
1314- ( See <xref linkend="logicaldecoding-synchronous-caveats"/> for the details.)
1320+ See <xref linkend="logicaldecoding-synchronous-caveats"/> for the details.
13151321 </para>
13161322 </listitem>
13171323 </itemizedlist>
