Re: Proposal: Implement failover on libpq connect level.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Albe Laurenz <laurenz.albe@wien.gv.at>
Cc: "'''Victor Wagner *EXTERN*' *EXTERN*' *EXTERN*'" <vitus@wagner.pp.ru>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-08-19T13:41:32Z
Lists: pgsql-hackers
Albe Laurenz <laurenz.albe@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
Commits
-
libpq: Add target_session_attrs parameter.
- 721f7bd3cbcc 10.0 landed
-
Remove superuser checks in pgstattuple
- fd321a1dfd64 10.0 cited
-
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
- c405918858c0 9.6.0 cited