Re: [19] CREATE SUBSCRIPTION ... SERVER

On Fri, Mar 6, 2026 at 9:49 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Thu, Mar 5, 2026 at 2:23 PM Jeff Davis <pgsql(at)j-davis(dot)com> 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.