On Mon, Aug 2, 2010 at 8:57 AM, Yeb Havinga <yebhavinga@gmail.com> wrote:
> Fujii Masao wrote:
>>
>> On Mon, Aug 2, 2010 at 7:53 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>>>
>>> Let's not get *the manner of specifying the policy* confused with *the
>>> need to update the policy when the master changes*. It doesn't seem
>>> likely you would want the same value for synchronous_standbys on all
>>> your machines. In the most common configuration, you'd probably have:
>>>
>>> on A: synchronous_standbys=B
>>> on B: synchronous_standbys=A
>>>
>>
>> Oh, true. But, what if we have another synchronous standby called C?
>> We specify the policy as follows?:
>>
>> on A: synchronous_standbys=B,C
>> on B: synchronous_standbys=A,C
>> on C: synchronous_standbys=A,B
>>
>> We would need to change the setting on both A and B when we want to
>> change the name of the third standby from C to D, for example. No?
>>
>
> What if the master is named as well in the 'pool of servers that are in
> sync'? In the scenario above this pool would be A,B,C. Working with this
> concept has as benefit that the setting can be copied to all other servers
> as well, and is invariant under any number of failures or switchovers. The
> same could also hold for quorum expressions like A && (B || C), if A,B,C are
> either master or standby.
>
> I initially though that once the definitions could be the same on all
> servers, having them in a system catalog would be a good thing. However
> that'd propably hard to setup, and also in the case of failures during
> change of the parameters it could become very messy.
Yeah, I think this information has to be stored either in GUCs or in a
flat-file somewhere. Putting it in a system catalog will cause major
problems when trying to get a down system back up, I think.
I suspect that for complex setups, people will need to use some kind
of cluster-ware to update the settings as nodes go up and down. But I
think it will still be simpler if the nodes are named.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company