Re: Proposal: Implement failover on libpq connect level.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: PostgreSQL - Hans-Jürgen Schönig <postgres@cybertec.at>
Cc: Albe Laurenz <laurenz.albe@wien.gv.at>,
"Victor Wagner *EXTERN*" <vitus@wagner.pp.ru>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-08-18T16:37:58Z
Lists: pgsql-hackers
On Tue, Aug 18, 2015 at 6:07 AM, PostgreSQL - Hans-Jürgen Schönig <postgres@cybertec.at> wrote: >> On 18 Aug 2015, at 11:19, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: >> >> Hans-Jürgen Schönig wrote: >>> in addition to that you have the “problem” of transactions. if you failover in the middle >>> of a transaction, strange things might happen from the application point of view. >>> >>> the good thing, however, is that stupid middleware is sometimes not able to handle >>> failed connections. however, overall i think it is more of a danger than a benefit. >> >> Maybe I misunderstood the original proposal, but my impression was that the alternative >> servers would be tried only at the time the connection is established, and there would be no >> such problems as you describe. > > it would still leave the problem of having a read only on the other side unless you are using BDR or so. That doesn't make this a bad idea. Some people are using replication solutions that can cope with this already (EDB has a proprietary product, and I'm sure there are people using BDR, too) and, as the solutions get better and more widely deployed, more people will want to do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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