On Tue, Mar 3, 2026 at 3:04 AM Jeff Davis <[email protected]> wrote:
>
> Attached v18:
>
I haven't checked the details but while glancing at the patch, I have
few observations:
1.
@@ -92,9 +92,11 @@
CATALOG(pg_subscription,6100,SubscriptionRelationId)
BKI_SHARED_RELATION BKI_ROW
* exceeded max_retention_duration, when
* defined */
+ Oid subserver; /* Set if connecting with server */
+
#ifdef CATALOG_VARLEN /* variable-length fields start here */
/* Connection string to the publisher */
- text subconninfo BKI_FORCE_NOT_NULL;
+ text subconninfo; /* Set if connecting with connection string */
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 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, subenabled,
subbinary, substream, subtwophasestate, subdisableonerr,
subpasswordrequired, subrunasowner, subfailover,
subretaindeadtuples, submaxretention, subretentionactive,
subslotname, subsynccommit, subpublications, suborigin)
ON pg_subscription TO public;
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 = 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
--
With Regards,
Amit Kapila.
