index 1765ea6c87e6eec4da90fdd462305a69fdb7ff0d..53f1466e429b91bf9de9d1899a7004ae3171e218 100644 (file)
<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>
</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>
@@ -1311,7 +1317,7 @@ stream_commit_cb(...); <-- commit of the streamed transaction
[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 <xref linkend="logicaldecoding-synchronous-caveats"/> for the details.)
+ See <xref linkend="logicaldecoding-synchronous-caveats"/> for the details.
</para>
</listitem>
</itemizedlist>