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 →
  1. Fix crash in WAL sender when starting physical replication

  2. Add a SHOW command to the replication command language.