Re: Support for N synchronous standby servers - take 2

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support for N synchronous standby servers - take 2
Дата
Msg-id CAB7nPqTVxTL3uTWML93BOEEh=2krG3hkT=R1_Y=7-Jee2WZ4KQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for N synchronous standby servers - take 2  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Support for N synchronous standby servers - take 2  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: WAL-related tools and .paritial WAL file
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Asynchronous execution on FDW