Re: DRAFT 9.6 release

On 08/30/2016 06:20 PM, Josh Berkus wrote:
> On 08/30/2016 06:12 PM, Michael Paquier wrote:
> 
>> 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.
> 
> Yeah, the problem is that "higher priority" isn't defined, and could
> mean a lot of things.  It *is* defined in the actual section on
> synchronous standby, though (25.2.8.2.); maybe what we need is less docs
> under the GUC and more references to that?
> 
> Otherwise, you're going to have lots of people confused that it's
> actually quorum commit, as witnessed by the current discussion.  Right
> now what's in the GUC doc page appears to be complete but isn't.

Also, if I do this:


2 ( g1, g2, g3 )

... and g1, g2 and g3 are *groups* of three standbys each, what happens?
 Does it wait for one or more responses from g1 and from g2, or does
getting two responses from g1 trigger a commit?

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


-- 
Sent via pgsql-advocacy mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy