diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 42c004f..5a7a0c8 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -690,28 +690,61 @@ OutputPluginWrite(ctx, true);
   </sect1>
 
   <sect1 id="logicaldecoding-synchronous">
-   <title>Synchronous Replication Support for Logical Decoding</title>
+    <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>
+      <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>
 
-   <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>
+       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>
-   </note>
+
+     <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>
+       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>