Re: Proposal: Conflict log history table for Logical Replication
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: shveta malik <shveta.malik@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>
Date: 2026-06-04T09:24:26Z
Lists: pgsql-hackers
On Thu, Jun 4, 2026 at 2:47 PM shveta malik <shveta.malik@gmail.com> wrote: > > Currently we allow inheritance from CLT. I see 2 side-effects > > a) Queries on the CLT will always include rows from inherited tables. > Whether this is desirable or not is subjective, but it can lead to > unexpected results for DBAs querying the CLT directly. > > CREATE TABLE public.my_custom_extended_log() INHERITS > (pg_conflict.pg_conflict_log_16392); > INSERT INTO public.my_custom_extended_log (relid, schemaname, relname, > conflict_type) VALUES (99999, 'public', 'fake_table', > 'forged_conflict_type'); > > postgres=# SELECT count(*), conflict_type FROM > pg_conflict.pg_conflict_log_16392 GROUP BY conflict_type; > count | conflict_type > -------+---------------------- > 5 | insert_exists > 2 | forged_conflict_type > > b) > DROP SUBSCRIPTION may unintentionally drop inherited tables. > > When a subscription is dropped, the associated CLT is removed > internally using DROP-CASCADE. As a result, any user table inheriting > from the CLT would also be dropped, causing the user to lose any data > stored in those inherited tables. > > postgres=# DROP SUBSCRIPTION sub1; > NOTICE: drop cascades to table my_custom_extended_log > NOTICE: dropped conflict log table > "pg_conflict.pg_conflict_log_16392" for subscription "sub1" > NOTICE: dropped replication slot "sub1" on publisher > > OTOH, regular tables provide an opportunity for the user to review > dependencies and decide how to proceed: > > postgres=# create table tab1( i int); > CREATE TABLE > > postgres=# create table tab_i() inherits (tab1); > CREATE TABLE > > postgres=# drop table tab1; > ERROR: cannot drop table tab1 because other objects depend on it > DETAIL: table tab_i depends on table tab1 > HINT: Use DROP ... CASCADE to drop the dependent objects too. > > ~~ > > I previously thought inheriting from CLT should be acceptable as that > is purely the user's decision to create a child table for its own > purpose, but upon rethinking, I believe it should be blocked. > Thoughts? Yeah, I don't think there should be any use case for inheriting from CLT. IMHO restricting this might help us handle more such cases. -- Regards, Dilip Kumar Google
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow logical replication conflicts to be logged to a table.
- a5918fddf10d master landed
-
Avoid orphaned objects dependencies
- 2fbb21170e90 19 (unreleased) cited