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 →
  1. Allow logical replication conflicts to be logged to a table.

  2. Avoid orphaned objects dependencies