Re: Proposal: Implement failover on libpq connect level.

Bruce Momjian <bruce@momjian.us> wrote:

> It is annoying for less capable database to say they have high
> availability when that just involves having a client library that
> can connect to multiple hosts.

This sounds like the "But all the *other* kids are doing it!"
argument, which comes up often.  We generally resist doing
something solely on that basis, so the rest of the email is really
what matters, I think, much as this does gall.

> Yes, we can do this in DNS, but that is all happening at a
> different layer.

More than that, there are technical reasons that can be a bad
solution.  As just one example, the servers might well be in
different domains.

> Now, the counter-argument is that this is the wrong layer to do
> it, and we will end up adding tons of configurations variables to
> libpq to control this.

Yeah, we definitely *don't* want to implement some sort of failover
manager in every connector -- that way madness lies.

> We are clearly not adding this just because JDBC has it --- we
> are adding it because it allows for more complex server
> configurations.

I think what we need is a clear description of use cases where we
think this is the solution, and some clear boundaries to the scope
-- so it is also clear what kinds of problems this is *not*
intended to solve.

> Could this ability be more powerfully done with DNS or a
> connection pooler, yes, but not everyone wants that complexity.
> For me, this libpq change has a simple user API with a small
> amount of code change that give us a simple solution to a common
> problem.

I'm not saying we shouldn't have something like this; but we need a
clear definition of that common problem we are solving.  I don't
think I've seen that yet.  I've seen various spins on solutions 
described, from which I can infer various possible problems; but to 
pick the best version of this as *the* solution I think we need a 
clear statement of the problem itself.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company