Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id CAB7nPqTVxTL3uTWML93BOEEh=2krG3hkT=R1_Y=7-Jee2WZ4KQ@mail.gmail.com
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Support for N synchronous standby servers - take 2
List pgsql-hackers
On Thu, Jul 2, 2015 at 3:29 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.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.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WAL-related tools and .paritial WAL file
Next
From: Michael Paquier
Date:
Subject: Re: Asynchronous execution on FDW