Re: DRAFT 9.6 release

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

In response to

Responses

Browse pgsql-advocacy by date

  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