On Wed, Jul 1, 2015 at 11:21:47AM -0700, Josh Berkus wrote:
> All:
>
> Replying to multiple people below.
>
> On 07/01/2015 07:15 AM, Fujii Masao wrote:
> > On Tue, Jun 30, 2015 at 2:40 AM, Josh Berkus <josh@agliodbs.com> wrote:
> >> You're confusing two separate things. The primary manageability problem
> >> has nothing to do with altering the parameter. The main problem is: if
> >> there is more than one synch candidate, how do we determine *after the
> >> master dies* which candidate replica was in synch at the time of
> >> failure? Currently there is no way to do that. This proposal plans to,
> >> effectively, add more synch candidate configurations without addressing
> >> that core design failure *at all*. That's why I say that this patch
> >> decreases overall reliability of the system instead of increasing it.
> >
> > I agree this is a problem even today, but it's basically independent from
> > the proposed feature *itself*. So I think that it's better to discuss and
> > work on the problem separately. If so, we might be able to provide
> > good way to find new master even if the proposed feature finally fails
> > to be adopted.
>
> I agree that they're separate features. My argument is that the quorum
> synch feature isn't materially useful if we don't create some feature to
> identify which server(s) were in synch at the time the master died.
I am coming in here late, but I thought the last time we talked about
this that the only reasonable way to communicate that we have changed to
synchronize with a secondary server (different application_name) is to
allow a GUC-configured command string to be run when a change like this
happens. The command string would write a status on another server or
send an email.
Based on the new s_s_name API, this would mean whenever we switch to a
different priority level, like 1 to 2, 2 to 3, or 2 to 1.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
