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
