At Tue, 23 Jun 2020 10:51:40 +0900, Michael Paquier <michael@paquier.xyz> wrote in
> On Sun, Jun 21, 2020 at 01:02:34PM -0700, Andres Freund wrote:
> > I still maintain that adding restrictions here is a bad idea. Even
> > disregarding the discussion of running normal queries interspersed, it's
> > useful to be able to both request WAL and receive logical changes over
> > the same connection. E.g. for creating a logical replica by first doing
> > a physical base backup (vastly faster), or fetching WAL for decoding
> > large transactions onto a standby.
> >
> > And I just don't see any reasons to disallow it. There's basically no
> > reduction in complexity by doing so.
>
> Yeah, I still stand by the same opinion here to do nothing. I suspect
> that we have good chances to annoy people and some cases we are
> overlooking here, that used to work.
In logical replication, a replication role is intended to be
accessible only to the GRANTed databases. On the other hand the same
role can create a dead copy of the whole cluster, including
non-granted databases. It seems like a sieve missing a mesh screen.
I agree that that doesn't harm as far as roles are strictly managed so
I don't insist so strongly on inhibiting the behavior. However, the
documentation at least needs amendment.
https://www.postgresql.org/docs/13/protocol-replication.html
====
To initiate streaming replication, the frontend sends the replication
parameter in the startup message. A Boolean value of true (or on, yes,
1) tells the backend to go into physical replication walsender mode,
wherein a small set of replication commands, shown below, can be
issued instead of SQL statements.
Passing database as the value for the replication parameter instructs
the backend to go into logical replication walsender mode, connecting
to the database specified in the dbname parameter. In logical
replication walsender mode, the replication commands shown below as
well as normal SQL commands can be issued.
====
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center