Re: DRAFT 9.6 release

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: DRAFT 9.6 release
Date: 2016-08-31 00:35:59
Message-ID: CAB7nPqRVF2oDvSAvxM=fuxzW0eXqo6qSWG6L3gCssgNK77tG4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy

On Wed, Aug 31, 2016 at 7:32 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Tue, Aug 30, 2016 at 03:22:18PM -0700, Josh Berkus wrote:
>> What does that mean exactly? If I do:
>>
>> 3 ( s1, s2, s3, s4, s5 )
>>
>> And a commit is ack'd by s2, s3, and s5, what happens?
>
> As I understand it, it can continue with those three servers sending a
> confirmation back.

Assuming that all servers are connected at the moment decision is
made, you need to wait for s1, s2 *and* s3 to acknowledge depending on
synchronous_commit. By default that would be waiting for the LSN to
have been flushed on all of them. And the important point to get is
that what has been committed is dependent on the order of the items
listed. This is not quorum commit, in which case having only
confirmation from 3 servers in the set of 5 servers listed would be
fine.

If for example s2 and s4 are not connected at the moment of the
decision, you'd need to wait for acknowledgment from s1, s3 and s5
before moving on.
--
Michael

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Josh Berkus 2016-08-31 00:40:07 Re: DRAFT 9.6 release
Previous Message Bruce Momjian 2016-08-30 22:32:54 Re: DRAFT 9.6 release