From a73bd49c69e16197e8da43bc7cb17a38bd89aeee Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Thu, 24 Jun 2021 09:37:57 +0530 Subject: [PATCH] Doc: Update caveats in synchronous logical replication. Reported-by: Simon Riggs Author: Takamichi Osumi Reviewed-by: Amit Kapila Backpatch-through: 9.6 Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de --- doc/src/sgml/logicaldecoding.sgml | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 4c2ca12445e..35202a789cf 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -754,16 +754,18 @@ OutputPluginWrite(ctx, true); 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: + has locked [user] catalog tables exclusively. See + 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 LOCK on pg_class - (or any other catalog table) in a transaction. + in a transaction. @@ -781,6 +783,10 @@ OutputPluginWrite(ctx, true); + + Note that these commands that can cause deadlock apply to not only explicitly + indicated system catalog tables above but also to any other [user] catalog + table.