On 2016/09/01 11:13, Michael Paquier wrote:
> On Thu, Sep 1, 2016 at 1:38 AM, Josh Berkus <josh@agliodbs.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.
If my reading of the documentation of the synchronous_standby_names
parameter is correct, the behavior in this case is said to be indeterminate:
"""
The name of a standby server for this purpose is the application_name
setting of the standby, as set in the primary_conninfo of the standby's
WAL receiver. There is no mechanism to enforce uniqueness. In case of
duplicates one of the matching standbys will be considered as higher
priority, though exactly which one is indeterminate.
"""
Although after looking at what goes on in the related code, it seems 2 of
3 replicas named g1 (Josh's example) could exhaust num_sync = 2 and ack
the commit (also as you show). Whereas I thought, as the document
suggests, that one of g1's and then one of g2's would need to ack.
Need document fix or am I still missing something?
Thanks,
Amit