Document a few caveats in synchronous logical replication.

In a synchronous logical setup, locking [user] catalog tables can cause
deadlock. This is because logical decoding of transactions can lock
catalog tables to access them so exclusively locking those in transactions
can lead to deadlock. To avoid this users must refrain from having
exclusive locks on catalog tables.

Author: Takamichi Osumi
Reviewed-by: Vignesh C, Amit Kapila
Backpatch-through: 9.6
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de
This commit is contained in:
Amit Kapila 2021-06-17 10:59:11 +05:30
parent 8f32299424
commit 5a456034b8

View File

@ -723,6 +723,8 @@ 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
@ -745,5 +747,41 @@ OutputPluginWrite(ctx, true);
than one database is actively used.
</para>
</note>
</sect2>
<sect2 id="logicaldecoding-synchronous-caveats">
<title>Caveats</title>
<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:
<itemizedlist>
<listitem>
<para>
Issuing an explicit <command>LOCK</command> on <structname>pg_class</structname>
(or any other catalog table) in a transaction.
</para>
</listitem>
<listitem>
<para>
Perform <command>CLUSTER</command> on <structname>pg_class</structname> in a
transaction.
</para>
</listitem>
<listitem>
<para>
Executing <command>TRUNCATE</command> on [user] catalog table in a
transaction.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
</chapter>