From: | Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: dividing privileges for replication role. |
Date: | 2013-01-23 08:46:00 |
Message-ID: | CAC55fYe90U0-uqUfOhKRDiug-4A1YscjCaUqXb4VQSC-nXfkOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Tom
Thank you for comments.
> Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)com> writes:
> >> Why is it better to do this with a privilege, rather than just using
> >> pg_hba.conf?
>
>
> > 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.
>
>
> That sounds good, but if the behavior is controlled by a privilege
> (ie, it's stored in system catalogs) then it's impossible to have
> different settings on different slave servers --- or indeed to change
> the settings locally on a slave at all. You can only change settings
> on the master and let the change replicate to all the slaves.
>
Yes, I'm thinking changing settings on the master and the settings are
propagating to all slaves.
> Quite aside from whether you want to manage things like that, what
happens if
> your master has crashed and you find you need to change the settings on
> the way to getting a slave to take over?
>
> The crash-recovery worry is one of the main reasons that things like
> pg_hba.conf aren't stored in system catalogs already. It's not always
> convenient to need a running server before you can change the settings.
>
I understand that the approach in my patch(using pribileges for controlling
its behavior) does not match the policy.
But I'm still thinking I should put a something to controle
the behavior.
Then, how about to add a new option "standby_mode" to Database Connection
Control Functions like application_name.
ex:
primary_conninfo = 'port=5432 standby_mode=master-cascade'
primary_conninfo = 'port=5432 standby_mode=master-only'
primary_conninfo = 'port=5432 standby_mode=cascade-only'
I think it will be able to do same control with privilege controlling.
And it won't be contrary to the policy(no data is stored in system
catalogs).
Because it is corner-case, I should not do anything about this?
(Am I concerning too much?)
regards,
--------
NTT Software Corporation
Tomonari Katsumata
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-01-23 08:47:47 | Re: .gitignore additions |
Previous Message | Andrew Dunstan | 2013-01-23 08:15:39 | Re: .gitignore additions |