Re: dividing privileges for replication role.

Hi, Magnus, Josh, Michael, Craig

Thank you for comments and registring to CommitFest.

>> I made a patch to divide privileges for replication role.
>>
>> Currently(9.2), the privilege for replication role is
>> true / false which means that standby server is able to
>> connect to another server or not with the replication role.
>
>Why is it better to do this with a privilege, rather than just using
>pg_hba.conf? It doesn't represent an actual "permission level" after
>all - it's just an administrative "flag" to say you can't connect.
>Which AFAICS can just as easily be handled in pg_hba.conf? I guess I'm
>missing something?
>
You are right.
Handling with pg_hba.conf is an easy way.

But I think many users think about switch over, so
the pg_hba.conf is same on master and standby.
it's not convinient that we have to rewrite pg_hba.conf
whenever switch over occurs.

In the other hand, using a privilege, although we have to prepare
each roles before, we don't need to rewrite pg_hba.conf.
So I think it's better with a privilege than using only pg_hba.conf

----

>> In this patch, I made below.
>> a) adding new privileges for replication:"MASTER REPLICATION" and
"CASCADE
>> REPLICATION"
>> "MASTER REPLICATION": Replication-connection to master server is only
>> allowed
>> "CASCADE REPLICATION": Replication-connection to cascade server is
only
>> allowed
>> ("REPLICATION" already implemented means replication-connection to
both
>> servers is allowed)
>
>This seems to me a case of making things more complicated for everyone
>in order to satisfy a very narrow use-case. It certainly doesn't seem
>to me to do anything about the "accidental cycle" issue. Am I missing
>something?
>
I agreed that it is a very narrow use-case and accidental thing.

But I think we should provide a kind of method to avoid it,
because it has been different of before release.

And I don't think it's complicated, because "REPLICATION" and
"NOREPLICATION" do same behavior with before release.

----

>> a) adding new privileges for replication:"MASTER REPLICATION" and
"CASCADE
>> REPLICATION"
>>
>> "MASTER REPLICATION": Replication-connection to master server is only
>> allowed
>> "CASCADE REPLICATION": Replication-connection to cascade server is
only
>> allowed
>> ("REPLICATION" already implemented means replication-connection to
both
>> servers is allowed)
>>
>This does not really solve the case you reported because, as reported in
>your bug, you could still have each slave connecting to each other using
>the privilege CASCADE REPLICATION. It makes even the privilege level more
>complicated.
>
Yes, the patch can not solve the case at all.
I just added a parameter for users.
It is responsibility of users to connect with a right role.

>What would be necessary to solve your problem would be to have each standby
>being aware that it is connected to a unique master. This is not really an
>issue with privileges but more of something like having a standby scanning
>its upper cluster node tree and check if there is a master connected. While
>checking the cluster node tree, you will also need to be aware if a node
>has already been found when you scanned it to be sure that the same node
>has not been scanned, what would mean that you are in a cycle.
>
I think this is very complicated.
At least, now I can't solve it...

If someday we can detect it, this kind of switch will be needed.
Because some users may need the cyclic situation.

----

I'm not insisting to use replication-role, but
I want something to control this behavior.

regards,
------------
NTT Software Corporation
Tomonari Katsumata