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
|
Список | 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 по дате отправления: