sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-01 00:01:20 -04:00
Code Issues Projects Releases Wiki Activity

Document a few caveats in synchronous logical replication.

Browse Source 
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 09:56:05 +05:30
parent 131ea3e908
commit 3cb828dbe2
1 changed files with 78 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
doc/src/sgml/logicaldecoding.sgml
View File

@ -1066,6 +1066,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
@ -1088,6 +1090,59 @@ 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>
<command>PREPARE TRANSACTION</command> after <command>LOCK</command> command
on <structname>pg_class</structname> and allow logical decoding of two-phase
transactions.
</para>
</listitem>
<listitem>
<para>
<command>PREPARE TRANSACTION</command> after <command>CLUSTER</command>
command on <structname>pg_trigger</structname> and allow logical decoding of
two-phase transactions. This will lead to deadlock only when published table
have a trigger.
</para>
</listitem>
<listitem>
<para>
Executing <command>TRUNCATE</command> on [user] catalog table in a
transaction.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<sect1 id="logicaldecoding-streaming">
@ -1253,9 +1308,10 @@ 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 <xref linkend="logicaldecoding-synchronous-caveats"/> for the details.)
</para>
</listitem>
</itemizedlist>