Re: dividing privileges for replication role.
От | Tomonari Katsumata |
---|---|
Тема | Re: dividing privileges for replication role. |
Дата | |
Msg-id | CAC55fYdOL8Gddivxc4uXRMqPfff2hxob4iWnek3AVr8tb9FggQ@mail.gmail.com обсуждение исходный текст |
Ответ на | dividing privileges for replication role. (Tomonari Katsumata <t.katsumata1122@gmail.com>) |
Ответы |
Re: dividing privileges for replication role.
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
<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 />
В списке pgsql-hackers по дате отправления: