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
|
Список | 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 по дате отправления: