Re: DRAFT 9.6 release

Список
Период
Сортировка
От Amit Langote
Тема Re: DRAFT 9.6 release
Дата
Msg-id 9a4b6300-2a48-2173-35ca-103554f44277@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: DRAFT 9.6 release  (Michael Paquier)
Список pgsql-advocacy
Дерево обсуждения
DRAFT 9.6 release  (Josh Berkus, )
 Re: DRAFT 9.6 release  (Amit Langote, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Bruce Momjian, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Bruce Momjian, )
   Re: DRAFT 9.6 release  (Michael Paquier, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Michael Paquier, )
  Re: DRAFT 9.6 release  (Amit Langote, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Amit Langote, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Michael Paquier, )
  Re: DRAFT 9.6 release  (Amit Langote, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Michael Paquier, )
  Re: DRAFT 9.6 release  (Josh Berkus, )
   Re: DRAFT 9.6 release -- is Final  (Josh Berkus, )
    Re: DRAFT 9.6 release -- is Final  (Simon Riggs, )
     Re: DRAFT 9.6 release -- is Final  (Simon Riggs, )
  Re: DRAFT 9.6 release -- is Final  (Josh Berkus, )
   Re: DRAFT 9.6 release -- is Final  (Stefan Kaltenbrunner, )
    Re: DRAFT 9.6 release -- is Final  (Simon Riggs, )
  Re: DRAFT 9.6 release -- is Final  (Josh Berkus, )
  Re: DRAFT 9.6 release -- is Final  (Josh Berkus, )
  Re: DRAFT 9.6 release -- new wording  (Josh Berkus, )
   Re: DRAFT 9.6 release -- new wording  (Justin Clift, )
    Re: DRAFT 9.6 release -- new wording  (Justin Clift, )
    Re: DRAFT 9.6 release -- new wording  (Robert Haas, )
   Re: DRAFT 9.6 release -- new wording  (Mike Toews, )
   Re: DRAFT 9.6 release -- new wording  (Masahiko Sawada, )
   Re: DRAFT 9.6 release -- new wording  (Josh Berkus, )
    Re: [MASSMAIL]Re: DRAFT 9.6 release -- new wording  ("Gilberto Castillo", )
   Re: DRAFT 9.6 release -- new wording  (Josh Berkus, )
    Re: DRAFT 9.6 release -- new wording  (Michael Banck, )
   Re: DRAFT 9.6 release -- new wording  (Josh Berkus, )
   Re: DRAFT 9.6 release -- new wording  (Josh Berkus, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Michael Paquier, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Michael Paquier, )
   Re: DRAFT 9.6 release  (Amit Langote, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  ("Nicholson, Brad (Toronto, ON, CA)", )
   Re: DRAFT 9.6 release  (Michael Paquier, )
  Re: DRAFT 9.6 release  (Robert Haas, )
   Re: DRAFT 9.6 release  (Bruce Momjian, )
    Re: DRAFT 9.6 release  (Robert Haas, )
 Re: DRAFT 9.6 release  (Josh Berkus, )
  Re: DRAFT 9.6 release  (Michael Paquier, )
On 2016/09/01 11:13, Michael Paquier wrote:
> On Thu, Sep 1, 2016 at 1:38 AM, Josh Berkus <> 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




В списке pgsql-advocacy по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: DRAFT 9.6 release
Следующее
От: "Nicholson, Brad (Toronto, ON, CA)"
Дата:
Сообщение: Re: DRAFT 9.6 release