Re: Proposal: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Proposal: Implement failover on libpq connect level.
Date
Msg-id 20150903154221.GJ3685@tamriel.snowman.net
Whole thread Raw
In response to Re: Proposal: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Proposal: Implement failover on libpq connect level.  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: [PROPOSAL] Effective storage of duplicates in B-tree index.
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: Can pg_dump make use of CURRENT/SESSION_USER