Horton
Menu

Re: Proposal: Conflict log history table for Logical Replication

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shveta.malik@gmail.com>
Date: 2026-06-04T10:35:06Z
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow logical replication conflicts to be logged to a table.

  2. Avoid orphaned objects dependencies