Re: Proposal: Conflict log history table for Logical Replication

On Sun, Jan 4, 2026 at 5:51 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, Dec 29, 2025 at 11:32 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Thu, Dec 25, 2025 at 1:10 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > 5)
> > + /*
> > + * Establish an internal dependency between the conflict log table and the
> > + * subscription. By using DEPENDENCY_INTERNAL, we ensure the table is
> > + * automatically reaped when the subscription is dropped. This also
> > + * prevents the table from being dropped independently unless the
> > + * subscription itself is removed.
> > + */
> > + ObjectAddressSet(myself, RelationRelationId, relid);
> > + ObjectAddressSet(subaddr, SubscriptionRelationId, subid);
> > + recordDependencyOn(&myself, &subaddr, DEPENDENCY_INTERNAL);
> >
> > Now that we have pg_conflict, which is treated similarly to a system
> > catalog, I’m wondering whether we actually need to maintain this
> > dependency to prevent the CLT table or schema from being dropped.
> > Also, given that this currently goes against the convention that a
> > shared object cannot be present in pg_depend, could DropSubscription()
> > and AlterSubscription() instead handle dropping the table explicitly
> > in required scenarios?
>
> I thought about it while implementing the catalog schema, but then
> left as it is considering pg_toast tables also maintain internal
> dependency on the table, having said that, during drop
> subscription/alter subscription we anyway have to explicitly call the
> performDeletion of the table so seems like we are not achieving
> anything by maintaining dependency. Lets see what others have to say
> on this? I prefer removing this dependency because this is an
> exceptional case where we are maintaining dependency from a local
> object to a shared object. And now if we do not have any need for
> this we better get rid of it.
>

The main reason we wanted DEPENDENCY_INTERNAL was to prevent the user
from "breaking" the subscription by dropping the table or its schema.
But now with the introduction of the pg_conflict system schema, we can
avoid that. So, it makes sense to drop the table explicitly where
required. BTW, what happens if one drops the database which has a
pg_conflict schema and a conflict table and then tries to drop the
subscription? Do we need special handling for this if we remove the
dependency stuff?

--
With Regards,
Amit Kapila.