Albe Laurenz <laurenz.a...@wien.gv.at> writes:
> Victor Wagner wrote:
>> It would just take a bit more time for client and a bit more load for
>> server - to make sure that this connection is read-write by
>> issuing
>> show transaction_read_only
>> statement before considering connection useful.
> That's not very comfortable, and a lot of middleware software won't easily
> learn the trick.
That sort-of ties into what seems to me the main objection to this
proposal, namely that there is already a way to do this sort of thing:
DNS-based load balancing. All the clients think they connect to
db.mycompany.com, but which server they actually get is determined by
what IP address the DNS server tells them to use.
This is a technology that is very well established, known to every
large-site admin, and usable for every Internet-based service. Even if
libpq had its own nonstandard way of doing something similar, the site
admins would probably still need to use DNS load balancing for other
services. In fact, they'd still need to use DNS balancing for Postgres,
because not everything connects with libpq (think JDBC for instance).
So I think we ought to reject this proposal, full stop. I see no
reason to re-invent this wheel, and there are good reasons not to.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
