Re: DRAFT 9.6 release

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: DRAFT 9.6 release
Дата
Msg-id CAB7nPqRN3h3XNXkcXxPtkQOcpwvsiR0sNUdi8MexxgOZVfyYPA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: DRAFT 9.6 release  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: DRAFT 9.6 release  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-advocacy
On Thu, Sep 1, 2016 at 1:38 AM, Josh Berkus <josh@agliodbs.com> wrote:
> 2 ( g1, g2, g3 )
>
> where each of g1, g2 and g3 were three replicas with the same name
>
> then if two of the replicas from g1 ack'd the commit would proceed, even
> though no replica from g2 has?

[Checking]

Yes that's the case. If for example I have a set of slaves like that:
 application_name | replay_delta | sync_priority | sync_state
------------------+--------------+---------------+------------
 node1            |            0 |             1 | sync
 node1            |            0 |             1 | sync
 node1            |            0 |             1 | potential
 node2            |            0 |             2 | potential
 node2            |            0 |             2 | potential
 node2            |            0 |             2 | potential
 node3            |            0 |             0 | async
 node3            |            0 |             0 | async
 node3            |            0 |             0 | async
=# show synchronous_standby_names ;
 synchronous_standby_names
---------------------------
 2(node1, node2)

You'd need to have the confirmation to come from two nodes with node1
as application_name because those have the higher priority in the
list.
--
Michael


В списке pgsql-advocacy по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: DRAFT 9.6 release
Следующее
От: Amit Langote
Дата:
Сообщение: Re: DRAFT 9.6 release