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>
In-Reply-To: <80303af653a3da2a94e32ff91d6538675e921bf0.camel@j-davis.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Fri, 6 Mar 2026 21:49:00 +0530
Message-ID: 
 <CAExHW5vV5znEvecX=ra2-v7UBj9-M6qvdDzuB78M-TxbYD1PEA@mail.gmail.com>
Subject: Re: [19] CREATE SUBSCRIPTION ... SERVER
To: Jeff Davis <pgsql@j-davis.com>
Cc: Amit Kapila <amit.kapila16@gmail.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/CAExHW5vV5znEvecX%3Dra2-v7UBj9-M6qvdDzuB78M-TxbYD1PEA%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 5, 2026 at 2:23=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wrote=
:
>
> On Thu, 2026-03-05 at 09:21 +0530, Amit Kapila wrote:
> > We revoke view rights on subconninfo from the public. See below [A]
> > in
> > system_views.sql. Do we want to do the same for subserver or is it
> > okay for users to see it?
>
> I can't think of a reason that the server name should be secret, but
> let me know if you think so.
>
> >  I think the following comment and some place
> > in docs needs to be updated.
> > [A]
> > -- All columns of pg_subscription except subconninfo are publicly
> > readable.
> > REVOKE ALL ON pg_subscription FROM public;
> > GRANT SELECT (oid, subdbid, subskiplsn, subname, subowner,
>
> Good catch! Thank you.
>
> > 2. We may want to update the following text in pg_dump docs about the
> > new way of connecting to hosts. See [B] (When dumping logical
> > replication subscriptions, pg_dump will generate CREATE SUBSCRIPTION
> > commands that use the connect =3D false option, so that restoring the
> > subscription does not make remote connections for creating a
> > replication slot or for initial table copy. That way, the dump can be
> > restored without requiring network access to the remote servers. It
> > is
> > then up to the user to reactivate the subscriptions in a suitable
> > way.
> > If the involved hosts have changed, the connection information might
> > have to be changed.)
> >
> > [B] - https://www.postgresql.org/docs/devel/app-pgdump.html
> >
>
> I think the above comment is still correct -- it would be a bit easier
> to deal with servers rather than raw connection strings, but the
> comment already says "...might have to be changed" which is just a
> reminder to look.
>
>
> Attached a new patch that also addressed the review comments from here:
>
> https://www.postgresql.org/message-id/CAD21AoCpr8UfmOngKZ92hZ-78cr2H+3Tbs=
9QLveYoWnWBfxrxw@mail.gmail.com
>
> 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? Again probably beyond the
scope of this patch.

I also see some code duplicated across Create and Alter subscription
code paths. Even without this patch the code was duplicated, but with
this patch the amount of duplication has increased. Can we deduplicate
some of the code?

I don't think we need a separate ForeignServerName function. In
AlterSubscription() we already have ForeignSever object which has
server name in it. Other two callers invoke
ForeignServerConnectionString() which in turn fetches ForeignServer
object. Those callers instead may fetch ForeignServer object
themselves and pass it to ForeignServerConnectionString() and use it
in the error message.

The patch has changes to pg_dump.c but there is no corresponding test.
But I don't think we need a separate test. If the objects created in
regress/*.sql tests are not dropped, 002_pg_upgrade.pl would test
dump/restore of subscriptions with server.

I think we need tests for testing changes in connection when ALTER
SUBSCRIPTION ... SERVER is executed and also those for switching
between SERVER and CONNECTION.

--=20
Best Wishes,
Ashutosh Bapat