Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, michael@paquier.xyz, andres@anarazel.de, jkatz@postgresql.org, 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-24T16:50:16Z
Lists: pgsql-hackers
Greetings, * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > On 2020-Jun-24, Kyotaro Horiguchi wrote: > > > 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. > > In other words -- essentially, if you grant replication access to a role > only to a specific database, they can steal the whole cluster. > > I don't see what's so great about that, but apparently people like it. Sure, people who aren't in charge of security I'm sure like the ease of use. Doesn't mean it makes sense or that we should be supporting that. What we should have is a way to allow administrators to configure a system for exactly what they want to allow, and it doesn't seem like we're doing that today and therefore we should fix it. This isn't the only area we have that issue in. Thanks, Stephen
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