Re: dividing privileges for replication role.

<p>Hi, Magnus, Josh, Michael, Craig<p>Thank you for comments and registring to CommitFest.<p>>> I made a patch to
divideprivileges for replication role.<br />>><br />>> Currently(9.2), the privilege for replication role
is<br/>>> true / false which means that standby server is able to<br />>> connect to another server or not
withthe replication role.<br /> ><br />>Why is it better to do this with a privilege, rather than just using<br
/>>pg_hba.conf?It doesn't represent an actual "permission level" after<br />>all - it's just an administrative
"flag"to say you can't connect.<br /> >Which AFAICS can just as easily be handled in pg_hba.conf? I guess I'm<br
/>>missingsomething?<br />><br />You are right.<br />Handling with pg_hba.conf is an easy way.<p>But I think many
usersthink about switch over, so<br />the pg_hba.conf is same on master and standby.<br />it's not convinient that we
haveto rewrite pg_hba.conf<br />whenever switch over occurs.<p>In the other hand, using a privilege, although we have
toprepare<br />each roles before, we don't need to rewrite pg_hba.conf.<br />So I think it's better with a privilege
thanusing only pg_hba.conf<p>----<p>>> In this patch, I made below.<br />>> a) adding new privileges for
replication:"MASTERREPLICATION" and "CASCADE<br />>> REPLICATION"<br />>>    "MASTER REPLICATION": 
Replication-connectionto master server is only<br /> >> allowed<br />>>    "CASCADE REPLICATION":
Replication-connectionto cascade server is only<br />>> allowed<br />>>    ("REPLICATION" already
implementedmeans replication-connection to both<br /> >> servers is allowed)<br />><br />>This seems to me
acase of making things more complicated for everyone<br />>in order to satisfy a very narrow use-case.  It certainly
doesn'tseem<br />>to me to do anything about the "accidental cycle" issue.  Am I missing<br /> >something?<br
/>><br/>I agreed that it is a very narrow use-case and accidental thing.<p>But I think we should provide a kind of
methodto avoid it,<br />because it has been different of before release.<p>And I don't think it's complicated, because
"REPLICATION"and<br />"NOREPLICATION" do same behavior with before release.<p>----<p>>> a) adding new privileges
forreplication:"MASTER REPLICATION" and "CASCADE<br />>> REPLICATION"<br />>><br />>>    "MASTER
REPLICATION": Replication-connection to master server is only<br /> >> allowed<br />>>    "CASCADE
REPLICATION":Replication-connection to cascade server is only<br />>> allowed<br />>>    ("REPLICATION"
alreadyimplemented means replication-connection to both<br /> >> servers is allowed)<br />>><br />>This
doesnot really solve the case you reported because, as reported in<br />>your bug, you could still have each slave
connectingto each other using<br />>the privilege CASCADE REPLICATION. It makes even the privilege level more<br />
>complicated.<br/>><br />Yes, the patch can not solve the case at all.<br />I just added a parameter for
users.<br/>It is responsibility of users to connect with a right role.<p>>What would be necessary to solve your
problemwould be to have each standby<br />>being aware that it is connected to a unique master. This is not really
an<br/>>issue with privileges but more of something like having a standby scanning<br /> >its upper cluster node
treeand check if there is a master connected. While<br />>checking the cluster node tree, you will also need to be
awareif a node<br />>has already been found when you scanned it to be sure that the same node<br /> >has not been
scanned,what would mean that you are in a cycle.<br />><br />I think this is very complicated.<br />At least, now I
can'tsolve it...<p>If someday we can detect it, this kind of switch will be needed.<br />Because some users may need
thecyclic situation.<p>----<p>I'm not insisting to use replication-role, but<br />I want something to control this
behavior.<p>regards,<br/>------------<br />NTT Software Corporation<br />  Tomonari Katsumata<br />