Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
