Re: Support for N synchronous standby servers - take 2

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Support for N synchronous standby servers - take 2
Дата
Msg-id CA+TgmoZjZ_MMo0E1eoZhbR+8ozV4CvwCfFvwtuvSbCj7aT_tiw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for N synchronous standby servers - take 2  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Thu, Feb 4, 2016 at 9:34 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> Now I'm thinking that mini-language is better choice. A json has some good
> points, but its big problem is that the setting value is likely to be very long.
> For example, when the master needs to wait for one local standby and
> at least one from three remote standbys in London data center, the setting
> value (synchronous_standby_names) would be
>
>   s_s_names = '{"priority":2, "nodes":["local1", {"quorum":1,
> "nodes":["london1", "london2", "london3"]}]}'
>
> OTOH, the value with mini-language is simple and not so long as follows.
>
>   s_s_names = '2[local1, 1(london1, london2, london3)]'

Yeah, that was my thought also.  Another idea which was suggested is
to create a completely new configuration file for this.  Most people
would only have simple stuff in there, of course, but then you could
have the information spread across multiple lines.

I don't in the end care very much about how we solve this problem.
But I'm glad you agree that whatever we do to solve the simple problem
should be a logical subset of what the full solution will eventually
look like, not a completely different design.  I think that's
important.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [WIP] Effective storage of duplicates in B-tree index.
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)