Re: Proposal: Conflict log history table for Logical Replication

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(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>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-06-04 09:24:26
Message-ID: CAFiTN-sbAXS6deUarPDunj2U+A6Dvhw_TASy4oMv4Tc63-_T9g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 4, 2026 at 2:47 PM shveta malik <shveta(dot)malik(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2026-06-04 09:26:59 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Previous Message jian he 2026-06-04 09:20:07 Re: Row pattern recognition