From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL mailing lists <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: DRAFT 9.6 release |
Date: | 2016-09-01 02:13:26 |
Message-ID: | CAB7nPqRN3h3XNXkcXxPtkQOcpwvsiR0sNUdi8MexxgOZVfyYPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
On Thu, Sep 1, 2016 at 1:38 AM, Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-09-01 02:40:53 | Re: DRAFT 9.6 release |
Previous Message | Josh Berkus | 2016-08-31 16:38:51 | Re: DRAFT 9.6 release |