Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: andres@anarazel.de, jkatz@postgresql.org, alvherre@2ndquadrant.com,
davecramer@postgres.rocks, masao.fujii@oss.nttdata.com,
masahiko.sawada@2ndquadrant.com, sitnikov.vladimir@gmail.com,
pgsql-hackers@postgresql.org, pg@bowt.ie
Date: 2020-06-24T02:56:38Z
Lists: pgsql-hackers
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix crash in WAL sender when starting physical replication
- 10ffe0fa72ed 13.0 landed
- 879ad9f90e83 14.0 landed
-
Add a SHOW command to the replication command language.
- d1ecd539477f 10.0 cited