Обсуждение: pgsql: Document a few caveats in synchronous logical replication.
Document a few caveats in synchronous logical replication. In a synchronous logical setup, locking [user] catalog tables can cause deadlock. This is because logical decoding of transactions can lock catalog tables to access them so exclusively locking those in transactions can lead to deadlock. To avoid this users must refrain from having exclusive locks on catalog tables. Author: Takamichi Osumi Reviewed-by: Vignesh C, Amit Kapila Backpatch-through: 9.6 Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9f7bba2629cf3413638936d0376bb50403144332 Modified Files -------------- doc/src/sgml/logicaldecoding.sgml | 76 +++++++++++++++++++++++++++++---------- 1 file changed, 57 insertions(+), 19 deletions(-)
On Thu, Jun 17, 2021 at 7:25 AM Amit Kapila <akapila@postgresql.org> wrote: > In a synchronous logical setup, locking [user] catalog tables can cause > deadlock. This is because logical decoding of transactions can lock > catalog tables to access them so exclusively locking those in transactions > can lead to deadlock. To avoid this users must refrain from having > exclusive locks on catalog tables. If LOCK and TRUNCATE is advised against on all user catalog tables, why would CLUSTER only apply to pg_class? Surely its locking level is the same as LOCK? The use of "[user]" isn't fully explained, so it might not be clear that this applies to both Postgres catalog tables and any user tables that have been nominated as catalogs. Probably worth linking to the "Capabilities" section to explain. It would be worth coalescing the following sections into a single page, since they are just a few lines each: Streaming Replication Protocol Interface Logical Decoding SQL Interface System Catalogs Related to Logical Decoding > Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de Unfortunately this is a URL linking to the top of a huge discussion, so isn't useful in locating the actual discussion. -- Simon Riggs http://www.EnterpriseDB.com/
On Thu, Jun 17, 2021 at 5:15 PM Simon Riggs <simon.riggs@enterprisedb.com> wrote: > > On Thu, Jun 17, 2021 at 7:25 AM Amit Kapila <akapila@postgresql.org> wrote: > > > > Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de > > Unfortunately this is a URL linking to the top of a huge discussion, > so isn't useful in locating the actual discussion. > I have responded to your comments on the corresponding -hackers thread. -- With Regards, Amit Kapila.