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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: .gitignore additions
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: .gitignore additions