On 22/03/17 03:38, Peter Eisentraut wrote:
> On 3/20/17 15:10, Petr Jelinek wrote:
>> Hmm but REPLICATION role can do basebackup/consume wal, so how does
>> giving it limited publication access help? Wouldn't we need some
>> SUBSCRIPTION role/grant used instead for logical replication connections
>> instead of REPLICATION for this to make sense?
>
> Since we're splitting up the pg_hba.conf setup for logical and physical
> connections, it would probably not matter.
Hmm yeah I know about that, I am not quite clear on how that change
affects this.
>
> But just to think it through, how could we split this up sensibly?
>
> Here is the complete list of things that rolreplication allows:
>
> - create/drop replication slot
> - pg_logical_slot_get_changes() and friends
> - connect to walsender
>
> For logical replication, we could slice it up this way:
>
> - new user attribute allowing the creating of logical replication slots
> - store owner of slot, allow drop and get based on ownership
> - allow anyone to connect as walsender
>
I am not quite sure we can do the owner part. Slots are not usual
catalog and there is this idea that it should be possible to create them
on standby (at least it was reason why our last year proposal to
propagate slot creation/updates via WAL was shot down). So we can't do
any of the dependency stuff for them.
> Another problem is that the walsender command to create a replication
> slot allows you to load an arbitrary plugin.
>
Yeah I am also not sure what to do with the SQL interface tbh as that
has same problem.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
