Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

On Mon, Jan 5, 2026 at 4:49 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Sun, Jan 4, 2026 at 5:51 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Mon, Dec 29, 2025 at 11:32 AM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > On Thu, Dec 25, 2025 at 1:10 PM Dilip Kumar <dilipbalaut@gmail.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.

+1

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?

The dropdb() is not allowed if there is any subscription created under
that database[1], so logically the 'subdbid' in pg_subscription and
the dbid under which the conflict log table is created will be same
and if any of the subscription is created under that database the
database drop is restricted.  So I think we should be safe here.

[1]
/*
* Check if there are subscriptions defined in the target database.
*
* We can't drop them automatically because they might be holding
* resources in other databases/instances.
*/
if ((nsubscriptions = CountDBSubscriptions(db_id)) > 0)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
errmsg("database \"%s\" is being used by logical replication subscription",
dbname),
errdetail_plural("There is %d subscription.",
"There are %d subscriptions.",
nsubscriptions, nsubscriptions)));


--
Regards,
Dilip Kumar
Google