On 15.01.2013 10:14, Simon Riggs wrote:
> On 15 January 2013 05:12, Tomonari Katsumata
> <katsumata.tomonari@po.ntts.co.jp> wrote:
>
>>> We added a REPLICATION privelge onto user accounts to control access.
>>>
>>> Perhaps we should add a CASCADE privilege as well, so that we can
>>> control whether we can connect to a master and/or a standby.
>>>
>>> Syntax would be
>>>
>>> ALTER USER foo
>>> [MASTER | CASCADE] REPLICATION
>>>
>>> REPLICATION allows both master and cascaded replication (same as now)
>>> MASTER REPLICATION allows master only
>>> CASCADE REPLICATION allows cascaded replication only
>>> NOREPLICATION allows neither option
>>>
>
>> Someone is working for it already ?
>> If not yet, may I try to implement it ?
>
> Please do. It looks fairly short.
To me, permissions doesn't feel like the right vehicle for controlling
this. Not sure what to suggest instead, a new GUC perhaps.
BTW, is there any reason to not allow streaming replication when
hot_standby=off? A streaming replication connection doesn't execute any
queries, so it doesn't need the system to be consistent.
Another thing to consider is that "pg_basebackup -X stream" also uses
streaming replication, so if you forbid cascade replication, you also
forbid using "pg_basebackup -X stream" on the standby. At the protocol
level, pg_basebackup streams the WAL just like a standby server does, so
we cannot distinguish those two cases in the server. The client could
tell the server which one it is, but using permissions to allow/forbid
based on that would make no sense as the client could lie which one it is.
- Heikki