Hi,
(2013/01/16 4:03), Fujii Masao wrote:
> On Tue, Jan 15, 2013 at 5:25 PM, Heikki Linnakangas
> <hlinnakan...@vmware.com> wrote:
>> On 15.01.2013 10:14, Simon Riggs wrote:
>>>
>>> On 15 January 2013 05:12, Tomonari Katsumata
>>> <katsumata.tomon...@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.
>>
If this is before releasing 9.2.0, it is not problem to have a new GUC.
But 9.2 has released already.
I'm thinking about this change is for 9.3, right ?
And I'm thinking about compatibility when version up too.
If we control this with permissions, I think it is easy to
upgrade from 9.1 and 9.2 to 9.3 using pg_upgrade/pg_dumpall.
Type of pg_authid.rolreplication is boolean.
---------------------------------------------------------------------
9.1 false(f=0) true(t=1)
9.2 false(f=0) true(t=1)
---------------------------------------------------------------------
If I add permissions for cascading replication,
it will become integer and represent each permission like this:
---------------------------------------------------------------------
9.3 noreplication(0) replication(1) master-only(2) cascade-only(3)
---------------------------------------------------------------------
If pg_upgrade/pg_dumpall handle like bellow, user would never mind about
difference between versions.
from 9.1 to 9.3.
false(f=0) --> noreplication(0)
true(t=1) --> master-only(2)
from 9.2 to 9.3.
false(f=0) --> noreplication(0)
true(t=1) --> replication(1)
>> 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.
>
> I was thinking that the system must be consistent since streaming
replication
> connection reads the system catalog (e.g., ROLE information).
>
And I think it's because replication connection is established
by same way with another backend connection.
>> 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.
>
> Probably I'm missing something, but the standby server only has to
reject the
> replication connection if cascade replication is disabled, whether
it's from
> another standby or pg_basebackup. ISTM there is no need to distinguish
> those connections. No?
>
> When "pg_basebackup -X stream" fails to establish the replication
connection,
> it only has to just fail or automatically switch to "pg_basebackup -X
fetch".
>
I think so too.
If user who does not have right permission executes "pg_basebackup -X
stream",
it would make fail.
regards,
--------
NTT Software Corporation
Tomonari Katsumata
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
