On Mon, Aug 2, 2010 at 5:02 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Sun, Aug 1, 2010 at 9:51 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Perhaps someone will claim that nobody wants to do that anyway (which
>> I don't believe, BTW), but even in simpler cases it would be nicer to
>> have an explicit policy rather than - in effect - inferring a policy
>> from a soup of GUC settings. For example, if you want one synchronous
>> standby (A) and two asynchronous standbys (B and C). You can say
>> quorum=1 on the master and then configure vote=1 on A and vote=0 on B
>> and C, but now you have to look at four machines to figure out what
>> the policy is, and a change on any one of those machines can break it.
>> ISTM that if you can just write synchronous_standbys=A on the master,
>> that's a whole lot more clear and less error-prone.
>
> Some standbys may become master later by failover. So we would
> need to write something like synchronous_standbys=A on not only
> current one master but also those standbys. Changing
> synchronous_standbys would require change on all those servers.
> Or the master should replicate even that change to the standbys?
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
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company