On Sun, Jan 4, 2026 at 5:51 PM Dilip Kumar <[email protected]> wrote: > > On Mon, Dec 29, 2025 at 11:32 AM shveta malik <[email protected]> wrote: > > > > On Thu, Dec 25, 2025 at 1:10 PM Dilip Kumar <[email protected]> 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.
