| From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Subject: | Re: Proposal: Conflict log history table for Logical Replication |
| Date: | 2026-06-04 10:35:06 |
| Message-ID: | CAJpy0uBaW7ziTsHOu_z37-epihxx3qGMjqdV+_-Z-RFjq5EOGg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I noticed that it is currently possible to acquire explicit locks on a CLT:
--Session locks table and does not commit txn:
postgres=# BEGIN;
LOCK TABLE pg_conflict.pg_conflict_log_16481 IN SHARE MODE;
BEGIN
LOCK TABLE
Doing so can cause the apply worker to block indefinitely when it
attempts to modify the CLT:
[247433] LOG: logical replication apply worker for subscription
"sub1" has started
[247433] LOG: process 247433 still waiting for RowExclusiveLock on
relation 16482 of database 5 after 1001.030 ms
[247433] DETAIL: Process holding the lock: 245584. Wait queue: 247433.
[247433] CONTEXT: waiting for RowExclusiveLock on relation 16482 of database 5
Toast Table behaviour:
postgres=*# LOCK TABLE pg_toast.pg_toast_16384 IN SHARE MODE;
ERROR: cannot lock relation "pg_toast_16384"
DETAIL: This operation is not supported for TOAST tables.
Should we consider disallowing explicit LOCK TABLE operations on CLTs,
similar to how PostgreSQL handles TOAST tables? Or does anyone see any
legitimate use-case (I don't) where we would need to allow explicit
LOCKs on CLT?
thanks
Shveta
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dagfinn Ilmari Mannsåker | 2026-06-04 10:39:02 | Re: future of PQfn() |
| Previous Message | Chao Li | 2026-06-04 10:30:09 | Re: Fix tuple deformation with virtual generated NOT NULL columns |