Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, michael@paquier.xyz
Cc: andres@anarazel.de, jkatz@postgresql.org, alvherre@2ndquadrant.com,
davecramer@postgres.rocks, masahiko.sawada@2ndquadrant.com,
sitnikov.vladimir@gmail.com, pgsql-hackers@postgresql.org, pg@bowt.ie
Date: 2020-06-24T09:45:38Z
Lists: pgsql-hackers
On 2020/06/24 11:56, Kyotaro Horiguchi wrote: > 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. Personally I'd like to disallow physical replication commands when I explicitly reject physical replication connection (i.e., set "host replication user x.x.x.x/x reject") in pg_hba.conf, whether on physical or logical replication connection. > 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. +1 Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
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