At Tue, 23 Jun 2020 10:51:40 +0900, Michael Paquier <mich...@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