MIME-Version: 1.0
References: <149ff9264db27cdf724b65709fbbaee4bf316835.camel@j-davis.com>
 <CAExHW5vv-78ixJs3arsuZ+12A4AyqehJnDPhejp0m4FAKG6JZA@mail.gmail.com>
 <830a2bc6cbbb2e6e01c6c0d9f31f320822e10603.camel@j-davis.com>
 <CAExHW5sAo4Gv3AwuxQNGSQ2Z45B8_MZEb-SG-B8D-hLMdrquAg@mail.gmail.com>
 <e531ec798298a21d671babd45849092850b8675e.camel@j-davis.com>
 <ac4042d6-204c-9661-9949-79ab8a1f8604@joeconway.com>
 <CAExHW5unvpDv6yMSmqurHP7Du1PqoJFWVxeK-4YNm5EnoNJiSQ@mail.gmail.com>
 <433d0845248e86c0317d9d396926182cfe157340.camel@j-davis.com>
 <CAExHW5sQVJeCgCGMkum_k4Z4VPaK5GkdAjHW-d+F3MngBZ9qBA@mail.gmail.com>
 <05ae37abb207cd6bf6b126780024692d91402b0b.camel@j-davis.com>
 <93392ffa941ab0d436e19e0ab5d04d0e42c02d3f.camel@j-davis.com>
 <26be917cb07b6aa3ef5dd15f6b59d1b375ece6e8.camel@j-davis.com>
 <CALj2ACXDua2Az15Kj3OZFaRm49G8-faemiEEv8t9GNCcsxv8Hw@mail.gmail.com>
 <55201bd916e748acfc754c8f95880dae8e4e5ed0.camel@j-davis.com>
 <CAExHW5v5poohyfNRVQp3yjVE56ej0dWvVMbysSSVtg21aHT3uQ@mail.gmail.com>
 <e71e029309171eb8b6ca393306f9bc5acfbfdf8f.camel@j-davis.com>
 <CAExHW5vF+cp9efQj=-W+Rhbr9f9ZZqt3XFnP0NB5jKsm=C=5tw@mail.gmail.com>
 <2a89b14a2b1622bffb8b137ca1f9ab7866f2d2b9.camel@j-davis.com>
 <61831790a0a937038f78ce09f8dd4cef7de7456a.camel@j-davis.com>
 <CAExHW5uCzS-VeSYQHTHxFSdQik-f_O892xmzrzm2fuO+ro+otA@mail.gmail.com>
 <0910b47040406c1d24ec0150dafb5bae6b910ed7.camel@j-davis.com>
 <CAExHW5vDPBB_PShBmSj=v=Jf1K=vSmWdPZTzCJsLpqDgqek+sA@mail.gmail.com>
 <7338f22c4534322a08ab6ce9f879e2e308eb5e5d.camel@j-davis.com>
 <CAExHW5uirmv8tj7LJ3zDo2tfaP_fffAeRbKT--3vBe7pa0in0g@mail.gmail.com>
 <d233117a82774de6e606cb383d1e0efea72c8879.camel@j-davis.com>
 <CAExHW5v5yn7HSD86OJ+Fj-FUcZK4mT40i7DBZoU2hQwfpeYLvw@mail.gmail.com>
 <e0914faf80f4f7f099f6f33597dd3b0f75779cec.camel@j-davis.com>
 <34fd5885b8245d1014f4426ea22af61229d42e3e.camel@j-davis.com>
 <e37776aa4d5679e2efc7d81e7dae4a8998658e37.camel@j-davis.com>
 <e0c6fd0fa6036df36779c8bd8ae763c6f4064135.camel@j-davis.com>
 <CANhcyEUoJeXw2W8TtUZRK48YLuV7R_cKsu=KfvgCAh0YqCC4gw@mail.gmail.com>
 <7a5df376fffb273430aec9e89f88c31d52dcf295.camel@j-davis.com>
 <5dfe845221db2e7d38fc7c2a18a4ba5ea29cdfc0.camel@j-davis.com>
 <CAD21AoA3dOqh4DeRtLJjzBxYaMfmzxw+s9tMo_wgnV7RdfUvtA@mail.gmail.com>
 <60ff024706fe1beab62a89ac07eb6a721856de2e.camel@j-davis.com>
 <b881ea575dab426422e483ab7edfcd98b532cbef.camel@j-davis.com>
 <CAA4eK1K79RCQ-WrN3gvdC=HzRcpeOhho+kWWKWatKzm4v_aypg@mail.gmail.com>
 <80303af653a3da2a94e32ff91d6538675e921bf0.camel@j-davis.com>
 <CAExHW5vV5znEvecX=ra2-v7UBj9-M6qvdDzuB78M-TxbYD1PEA@mail.gmail.com>
In-Reply-To: 
 <CAExHW5vV5znEvecX=ra2-v7UBj9-M6qvdDzuB78M-TxbYD1PEA@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sat, 7 Mar 2026 12:35:32 +0530
Message-ID: 
 <CAA4eK1JfU5eDz1GvWRZtP=bYwMoj2NDLtfdo-L4rbxmP1XpyJQ@mail.gmail.com>
Subject: Re: [19] CREATE SUBSCRIPTION ... SERVER
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Masahiko Sawada <sawada.mshk@gmail.com>,
	Shlok Kyal <shlok.kyal.oss@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
 Joe Conway <mail@joeconway.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1JfU5eDz1GvWRZtP%3DbYwMoj2NDLtfdo-L4rbxmP1XpyJQ%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 6, 2026 at 9:49=E2=80=AFPM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Thu, Mar 5, 2026 at 2:23=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wro=
te:
> >
> > 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.

--=20
With Regards,
Amit Kapila.