diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index d2c6e15..333fec7 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -1066,28 +1066,73 @@ OutputPluginWrite(ctx, true);
Synchronous Replication Support for Logical Decoding
+
+ Overview
-
- Logical decoding can be used to build
- synchronous
- replication solutions with the same user interface as synchronous
- replication for streaming
- replication. To do this, the streaming replication interface
- (see ) must be used to stream out
- data. Clients have to send Standby status update (F)
- (see ) messages, just like streaming
- replication clients do.
-
+
+ Overview
+
-
-
- 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.
+
+ Logical decoding can be used to build
+ synchronous
+ replication solutions with the same user interface as synchronous
+ replication for streaming
+ replication. To do this, the streaming replication interface
+ (see ) must be used to stream out
+ data. Clients have to send Standby status update (F)
+ (see ) messages, just like streaming
+ replication clients do.
+
+
+
+
+ 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.
+
+
+
+
+
+ Caveats
+
+ Caveats
+
+
+
+ The use of any command to take an ACCESS EXCLUSIVE lock on [user] catalog tables
+ can cause the deadlock of logical decoding in synchronous mode. This means that
+ at the transaction commit or prepared transaction, the command hangs or the server
+ becomes to block any new connections. To avoid this, users must refrain from such
+ operations.
+
+
+
+ When COMMIT is conducted for a transaction that has
+ issued explicit LOCK on pg_class
+ with logical decoding, the deadlock occurs. Also, committing one that runs
+ CLUSTERpg_class is another
+ deadlock scenario.
+
+
+
+ Similarly, executing PREPARE TRANSACTION
+ after LOCK command on pg_class and
+ logical decoding of published table within the same transaction leads to the deadlock.
+ Clustering pg_trigger by CLUSTER command
+ brings about the deadlock as well, when published table has a trigger and any operations
+ that will be decoded are conducted on the same table.
+
+
+
+ The deadlock can happen when users execute TRUNCATE
+ on user_catalog_table under the condition that output plugin have reference to it.
-
+
+
@@ -1253,9 +1298,11 @@ stream_commit_cb(...); <-- commit of the streamed transaction
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 LOCK command) in
- such transactions.
+ [user] catalog tables exclusively. To avoid this users must refrain from
+ having locks on catalog tables (e.g. explicit LOCK command)
+ in such transactions.
+ (See Synchronous
+ Replication Support for Logical Decoding for the details.)