diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 8af438c..60d7ef5 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -724,27 +724,61 @@ 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, 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>
-   </note>
+
+     <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>
+   </sect2>
   </sect1>
  </chapter>