On Fri, Mar 6, 2026 at 9:49 PM Ashutosh Bapat <[email protected]> wrote: > > On Thu, Mar 5, 2026 at 2:23 PM Jeff Davis <[email protected]> wrote: > > > > On Thu, 2026-03-05 at 09:21 +0530, Amit Kapila wrote: > > > > Additionally, I ran into a problem that's worth highlighting: > > > > DROP SERVER ... CASCADE was broken, because the subscription is > > dependent on it but that's in a global catalog, which is not handled by > > doDeletion(). The subscription is conceptually a per-database object, > > but it's in a shared catalog with a subdbid field. I solved that > > problem by adding a guard to findDependentObjects() to check for the > > referenced object belonging to a shared catalog, and if so it just > > throws an error (so CASCADE is not supported for servers used in > > subscriptions). That's a simple but not a very satisfying solution, so > > let me know if you see a problem with that. > > I shared the awkwardness, but don't have any better ideas. However, it > does raise a question as to why do we need an FDW to be database > specific or for that matter a SERVER database specific. That might be > because it requires an extension which is database specific. Probably > we should support extensions which are database agnostic. However > that's way beyond the scope of this patch. Other way around why do we > need subscriptions to be shared objects? >
It is because the launcher process needs to traverse all subscriptions to start workers. -- With Regards, Amit Kapila.
