Re: Patch: Implement failover on libpq connect level.
От | Craig Ringer |
---|---|
Тема | Re: Patch: Implement failover on libpq connect level. |
Дата | |
Msg-id | CAMsr+YGXTK3+i5zL3AkkR5BRP+Tw+f4+Ph=Z2_g7KD-nbb+cYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch: Implement failover on libpq connect level. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Patch: Implement failover on libpq connect level.
|
Список | pgsql-hackers |
On 6 November 2015 at 13:34, Robert Haas <robertmhaas@gmail.com> wrote: >> But some options control how >> next host should be choosen (i.e. use random order for load-balancing >> or sequential order for high availability), so they should be specified >> only once per connect string. > > But this seems like a point worthy of consideration. This makes me think that trying to wedge this into the current API using a funky connection string format might be a mistake. Lots of these issues would go away if you could provide more than just a connstring. >> Third category of options are specified per-cluster much more often >> than per node. But are quite often changed from compiled in default. > > This, too. Like this. If you have a global set of connection options, then per-connection options, it's a lot simpler. I guess that can be hacked in with a more dramatic change in the connstring format, otherwise, incorporating subsections or something. I'm not keen on doing anything like that, but there are all sorts of options... "global:[user=fred port=5432] host1:[host=somehost user=user1] host2:[host=localhost]" (puts head in brown paper bag) -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: