Re: Questions about the new subscription parameter: password_required

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Questions about the new subscription parameter: password_required
Date: 2023-10-13 18:54:07
Message-ID: 65b82a680990a13299526ecc2ff7a8fdbf0923ea.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2023-10-13 at 11:18 +0200, Benoit Lobréau wrote:
> I tried adding a section in "Logical Replication > Subscription" with
> the text you suggested and links in the CREATE / ALTER SUBSRIPTION
> commands.
>
> Is it better ?

Minor comments:

* Use possessive "its" instead of the contraction, i.e. "before
transferring its ownership".
* I like that docs cover the case where a password is specified, but
the remote server doesn't require one. But the warning is the wrong
place to explain that, it should be in the main behavioral description
in 31.2.2.
* The warning feels like it has too many negatives and confused me at
first. I struggled myself a bit to come up with something less
confusing, but perhaps less is more: "Ensure that password_required is
properly set before transferring ownership of a subscription to a non-
superuser, otherwise the subscription may start to fail."
* Missing space in the warning after "password_required = true"
* Mention that a non-superuser-owned subscription with
password_required = false is partially locked down, e.g. the owner
can't change the connection string any more.
* 31.2.2 could probably be in the CREATE SUBSCRIPTION docs instead,
and linked from the ALTER docs. That's fairly normal for other commands
and I'm not sure there needs to be a separate section in logical
replication. I don't have a strong opinion here.

I like the changes; this is a big improvement. I'll leave it to Robert
to commit it, so that he can ensure it matches how he expected the
feature to be used and sufficiently covers the behavioral aspects.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Fredouille 2023-10-13 19:33:57 Re: unnest multirange, returned order
Previous Message Andres Freund 2023-10-13 18:30:35 Re: Performance degradation on concurrent COPY into a single relation in PG16.