diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index d2c6e15..333fec7 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -1066,28 +1066,73 @@ 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>
+     <indexterm>
+       <primary>Overview</primary>
+     </indexterm>
 
-   <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>
+       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>
+   </sect2>
+
+   <sect2 id ="logicaldecoding-synchronous-caveats">
+     <title>Caveats</title>
+     <indexterm>
+       <primary>Caveats</primary>
+     </indexterm>
+
+     <para>
+       The use of any command to take an ACCESS EXCLUSIVE lock on [user] catalog tables
+       can cause the deadlock of logical decoding in synchronous mode. This means that
+       at the transaction commit or prepared transaction, the command hangs or the server
+       becomes to block any new connections. To avoid this, users must refrain from such
+       operations.
+     </para>
+
+     <para>
+       When <command>COMMIT</command> is conducted for a transaction that has
+       issued explicit <command>LOCK</command> on <structname>pg_class</structname>
+       with logical decoding, the deadlock occurs. Also, committing one that runs
+       <command>CLUSTER</command> <structname>pg_class</structname> is another
+       deadlock scenario.
+     </para>
+
+     <para>
+       Similarly, executing <command>PREPARE TRANSACTION</command>
+       after <command>LOCK</command> command on <structname>pg_class</structname> and
+       logical decoding of published table within the same transaction leads to the deadlock.
+       Clustering <structname>pg_trigger</structname> by <command>CLUSTER</command> command
+       brings about the deadlock as well, when published table has a trigger and any operations
+       that will be decoded are conducted on the same table.
+     </para>
+
+     <para>
+       The deadlock can happen when users execute <command>TRUNCATE</command>
+       on user_catalog_table under the condition that output plugin have reference to it.
      </para>
-   </note>
+   </sect2>
+
   </sect1>
 
   <sect1 id="logicaldecoding-streaming">
@@ -1253,9 +1298,11 @@ stream_commit_cb(...);  &lt;-- commit of the streamed transaction
       <para>
        The logical replication solution that builds distributed two phase commit
        using this feature can deadlock if the prepared transaction has locked
-       [user] catalog tables exclusively. They need to inform users to not have
-       locks on catalog tables (via explicit <command>LOCK</command> command) in
-       such transactions.
+       [user] catalog tables exclusively. To avoid this users must refrain from
+       having locks on catalog tables (e.g. explicit <command>LOCK</command> command)
+       in such transactions.
+       (See <link linkend="logicaldecoding-synchronous-caveats">Synchronous
+          Replication Support for Logical Decoding</link> for the details.)
       </para>
      </listitem>
     </itemizedlist>