2 47.8. Synchronous Replication Support for Logical Decoding #
9 Logical decoding can be used to build synchronous replication solutions
10 with the same user interface as synchronous replication for streaming
11 replication. To do this, the streaming replication interface (see
12 Section 47.3) must be used to stream out data. Clients have to send
13 Standby status update (F) (see Section 54.4) messages, just like
14 streaming replication clients do.
18 A synchronous replica receiving changes via logical decoding will work
19 in the scope of a single database. Since, in contrast to that,
20 synchronous_standby_names currently is server wide, this means this
21 technique will not work properly if more than one database is actively
26 In synchronous replication setup, a deadlock can happen, if the
27 transaction has locked [user] catalog tables exclusively. See
28 Section 47.6.2 for information on user catalog tables. This is because
29 logical decoding of transactions can lock catalog tables to access
30 them. To avoid this users must refrain from taking an exclusive lock on
31 [user] catalog tables. This can happen in the following ways:
32 * Issuing an explicit LOCK on pg_class in a transaction.
33 * Perform CLUSTER on pg_class in a transaction.
34 * PREPARE TRANSACTION after LOCK command on pg_class and allow
35 logical decoding of two-phase transactions.
36 * PREPARE TRANSACTION after CLUSTER command on pg_trigger and allow
37 logical decoding of two-phase transactions. This will lead to
38 deadlock only when published table have a trigger.
39 * Executing TRUNCATE on [user] catalog table in a transaction.
41 Note that these commands can cause deadlocks not only for the system
42 catalog tables listed above but for other catalog tables.