Re: dividing privileges for replication role.
От | Tomonari Katsumata |
---|---|
Тема | Re: dividing privileges for replication role. |
Дата | |
Msg-id | CAC55fYe90U0-uqUfOhKRDiug-4A1YscjCaUqXb4VQSC-nXfkOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: dividing privileges for replication role. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: dividing privileges for replication role.
(Michael Paquier <michael.paquier@gmail.com>)
|
Список | pgsql-hackers |
<p>Hi, Tom<p>Thank you for comments.<p>> Tomonari Katsumata <<a href="mailto:t.katsumata1122@gmail.com">t.katsumata1122@gmail.com</a>>writes:<br />> >> Why is it better to dothis with a privilege, rather than just using<br />> >> pg_hba.conf?<br /> > <br />> <br />> > Youare right.<br />> > Handling with pg_hba.conf is an easy way.<br />> <br />> > But I think many users thinkabout switch over, so<br />> > the pg_hba.conf is same on master and standby.<br /> > > it's not convinientthat we have to rewrite pg_hba.conf<br />> > whenever switch over occurs.<br />> <br />> > In theother hand, using a privilege, although we have to prepare<br />> > each roles before, we don't need to rewritepg_hba.conf.<br /> > <br />> <br />> That sounds good, but if the behavior is controlled by a privilege<br/>> (ie, it's stored in system catalogs) then it's impossible to have<br />> different settings on differentslave servers --- or indeed to change<br /> > the settings locally on a slave at all. You can only change settings<br/>> on the master and let the change replicate to all the slaves. <br />> <br />Yes, I'm thinking changingsettings on the master and the settings are<br /> propagating to all slaves.<p>> Quite aside from whether youwant to manage things like that, what happens if<br />> your master has crashed and you find you need to change thesettings on<br />> the way to getting a slave to take over?<br />> <br /> > The crash-recovery worry is one ofthe main reasons that things like<br />> pg_hba.conf aren't stored in system catalogs already. It's not always<br />>convenient to need a running server before you can change the settings.<br /> > <br />I understand that the approachin my patch(using pribileges for controlling<br />its behavior) does not match the policy.<p>But I'm still thinkingI should put a something to controle<br />the behavior.<p>Then, how about to add a new option "standby_mode" to DatabaseConnection <br />Control Functions like application_name.<p>ex:<br /> primary_conninfo = 'port=5432 standby_mode=master-cascade'<br/> primary_conninfo = 'port=5432 standby_mode=master-only'<br /> primary_conninfo = 'port=5432standby_mode=cascade-only'<p>I think it will be able to do same control with privilege controlling.<br />And itwon't be contrary to the policy(no data is stored in system catalogs).<p>Because it is corner-case, I should not do anythingabout this?<br />(Am I concerning too much?)<p><br />regards,<br />--------<br />NTT Software Corporation<br /> Tomonari Katsumata<br />
В списке pgsql-hackers по дате отправления: