Re: DRAFT 9.6 release

On Wed, Aug 31, 2016 at 9:40 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 08/30/2016 05:35 PM, Michael Paquier wrote:
>> 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.
>
> OK, so this says to me that we need a bunch of additional documentation
> on this feature, because the existing docs read like it's "any 3 out of
> the list" instead of "the first 3 which are connected".

Really? Here are the doc quotes that I guess matter, and I read that
differently than you do:
If any of the current synchronous standbys disconnects for whatever
reason, it will be replaced immediately with the next-highest-priority
standby.
[...]
For example, a setting of 3 (s1, s2, s3, s4) makes transaction commits
wait until their WAL records are received by *three higher-priority
standbys* chosen from standby servers s1, s2, s3 and s4.

This clearly says that we wait for the servers that have a higher
priority, meaning that we do *not* wait for any k elements in a set of
n listed, but suggest that the order of the element matters.
--
Michael