Re: DRAFT 9.6 release

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: DRAFT 9.6 release
Дата
Msg-id 7fa0ad24-dbbc-93c6-e6c5-914542d4ac9b@agliodbs.com
обсуждение исходный текст
Ответ на DRAFT 9.6 release  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: DRAFT 9.6 release  ("Nicholson, Brad (Toronto, ON, CA)" <bnicholson@hpe.com>)
Re: DRAFT 9.6 release  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-advocacy
On 08/31/2016 07:13 PM, Michael Paquier wrote:

> 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.

So, I have to say, this doesn't *feel* like a major press-worthy feature
yet.  It will be in 10, but is it right now?


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


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

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