<sect2>

<title>Overview</title>

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.

</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>