Re: Proposal: Implement failover on libpq connect level.

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Proposal: Implement failover on libpq connect level.
Дата
Msg-id 20150903154221.GJ3685@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Proposal: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Proposal: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Sep 3, 2015 at 4:00 AM, Shulgin, Oleksandr
> <oleksandr.shulgin@zalando.de> wrote:
> > I believe that having a floating IP for the master is much more practical
> > approach and it doesn't require any patch to libpq or modification of the
> > client connection settings.
>
> I think that's a great approach if all the machines are on the same
> subnet.  If they are in different datacenters, it doesn't work.

Anycast could technically be used to address that issue, but there's a
whole host of reasons why that would be quite painful for a PG
connection.

> I think it would be far better to progress to talking about what
> design we'd be comfortable with, rather than kidding ourselves that a
> feature that everyone else has and which somebody has taken the time
> to implement (thus, obviously it has value for them) and which has
> been discussed to general approval at PGCon developer meetings and
> which has been endorsed on this thread by three committers is somehow
> something that nobody really needs.  Seriously?

Agreed.  For my part, I like the JDBC configuration approach and
definitely would ask that we support 'host:port' options since not all
servers will be on the same port.  I don't agree with Tom's concern
regarding the simultaneous connection to all servers at once (yes, it's
a bit unfriendly, but I don't see that as a reason to not provide that
choice and there's a lot of reasons why you'd want it).

What would be nice is a better way to configure these more complicated
options than the single string or even the current very simple
pg_service.conf file.  For example, a service name which could define
*other* service names to try along with a plan for how to connect to
them (round robin, simultaneously, read/write only, etc) and perhaps
also support specifying multiple service names to the 'service'
parameter.  I'd prefer that we support all different configuration
options through the 'single string' method also, but I'm not convinced
that's a hard requirement.

Thanks!

Stephen

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

Предыдущее
От: Anastasia Lubennikova
Дата:
Сообщение: Re: [PROPOSAL] Effective storage of duplicates in B-tree index.
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Can pg_dump make use of CURRENT/SESSION_USER