Doc: Update caveats in synchronous logical replication.

Reported-by: Simon Riggs
Author: Takamichi Osumi
Reviewed-by: Amit Kapila
Backpatch-through: 9.6
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de

1 files changed, 11 insertions, 5 deletions

diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 9b05636fa4e..43a75f8cdd0 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -722,16 +722,18 @@ OutputPluginWrite(ctx, true);
 
     <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:
+     has locked [user] catalog tables exclusively. See
+     <xref linkend="logicaldecoding-capabilities"> for information on user
+     catalog tables. 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.
+        in a transaction.
        </para>
       </listitem>
 
@@ -749,6 +751,10 @@ OutputPluginWrite(ctx, true);
        </para>
       </listitem>
      </itemizedlist>
+
+     Note that these commands that can cause deadlock apply to not only explicitly
+     indicated system catalog tables above but also to any other [user] catalog
+     table.
     </para>
    </sect2>
   </sect1>