| 50.8. Synchronous Replication Support for Logical Decoding | ||||
|---|---|---|---|---|
| Prev | Up | Chapter 50. Logical Decoding | Home | Next |
50.8. Synchronous Replication Support for Logical Decoding#
50.8.1. Overview#
Logical decoding can be used to buildsynchronous replication solutions with the same user interface as synchronous replication forstreaming replication. To do this, the streaming replication interface (seeSection 50.3) must be used to stream out data. Clients have to sendStandby status update (F) (seeSection 56.4) messages, just like streaming replication clients do.
Note
A synchronous replica receiving changes via logical decoding will work in the scope of a single database. Since, in contrast to that,synchronous_standby_names currently is server wide, this means this technique will not work properly if more than one database is actively used.
50.8.2. Caveats#
In synchronous replication setup, a deadlock can happen, if the transaction has locked [user] catalog tables exclusively. SeeSection 50.6.2 for information on user catalog tables. 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:
Issuing an explicit
LOCKonpg_classin a transaction.Perform
CLUSTERonpg_classin a transaction.PREPARE TRANSACTIONafterLOCKcommand onpg_classand allow logical decoding of two-phase transactions.PREPARE TRANSACTIONafterCLUSTERcommand onpg_triggerand allow logical decoding of two-phase transactions. This will lead to deadlock only when published table have a trigger.Executing
TRUNCATEon [user] catalog table in a transaction.
Note that these commands can cause deadlocks not only for the system catalog tables listed above but for other catalog tables.