From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Joshua Tolley <eggyknap(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Synchronous replication |
Date: | 2010-08-02 09:02:34 |
Message-ID: | AANLkTimNM65jc7TPCag=hUGrD=CHH60jV1XZeXrnNSsW@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 1, 2010 at 9:51 PM, Robert Haas <robertmhaas(at)gmail(dot)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?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-08-02 10:53:58 | Re: Synchronous replication |
Previous Message | Fujii Masao | 2010-08-02 08:45:40 | Re: Synchronous replication |