Re: Support for N synchronous standby servers - take 2

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Support for N synchronous standby servers - take 2
Date: 2015-08-27 22:06:01
Message-ID: 20150827220601.GA27796@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)agliodbs(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-08-27 22:20:20 Re: 9.5 feature count
Previous Message Jeff Janes 2015-08-27 21:55:18 Spurious standby query cancellations