rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
1 changed files with 57 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -723,27 +723,65 @@ 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
<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.
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>
</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>