Re: Support for N synchronous standby servers - take 2

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(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-07-02 07:12:36
Message-ID: 5594E464.1000908@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-07-02 PM 03:52, Michael Paquier wrote:
> On Thu, Jul 2, 2015 at 3:29 PM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> On 2015-07-02 PM 03:12, Fujii Masao wrote:
>>>
>>> So I'm thinking that we basically need to check the progress on each
>>> standby to choose new master.
>>>
>>
>> Does HA software determine a standby to promote based on replication progress
>> or would things be reliable enough for it to infer one from the quorum setting
>> specified in GUC (or wherever)? Is part of the job of this patch to make the
>> latter possible? Just wondering or perhaps I am completely missing the point.
>
> Replication progress is a factor of choice, but not the only one. The
> sole role of this patch is just to allow us to have more advanced
> policy in defining how synchronous replication works, aka how we want
> to let the master acknowledge a commit synchronously from a set of N
> standbys. In any case, this is something unrelated to the discussion
> happening here.
>

Got it, thanks!

Regards,
Amit

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-07-02 07:15:30 Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE
Previous Message Michael Paquier 2015-07-02 07:02:27 Re: Asynchronous execution on FDW