diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index b876758..acb9ece 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -1129,6 +1129,22 @@ OutputPluginWrite(ctx, true);
 
       <listitem>
        <para>
+        User has performed <command>PREPARE TRANSACTION</command> after <command>LOCK</command>
+        command on <structname>pg_class</structname> and logical decoding of published table
+        in a same transaction.
+       </para>
+      </listitem>
+
+      <listitem>
+       <para>
+        <command>CLUSTER</command> <structname>pg_trigger</structname> and <command>
+        PREPARE TRANSACTION</command> can cause a deadlock, if any published table have
+        a trigger and any operations that are decoded are conducted.
+       </para>
+      </listitem>
+
+      <listitem>
+       <para>
         Executing <command>TRUNCATE</command> on user_catalog_table can prevent output plugin
         from taking a lock to the table, which leads to a deadlock.
        </para>
@@ -1301,9 +1317,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>