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 <j...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
