Re: Proposal: Implement failover on libpq connect level.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Kevin Grittner <kgrittn@ymail.com>
Cc: Bruce Momjian <bruce@momjian.us>, "Shulgin,
Oleksandr" <oleksandr.shulgin@zalando.de>,
Andres Freund <andres@anarazel.de>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Albe Laurenz <laurenz.albe@wien.gv.at>,
Victor Wagner <vitus@wagner.pp.ru>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-09-11T12:38:58Z
Lists: pgsql-hackers
On Wed, Sep 9, 2015 at 4:30 PM, Kevin Grittner <kgrittn@ymail.com> wrote: > Robert Haas <robertmhaas@gmail.com> wrote: > >> I think the problem we should be trying to solve is: Given a set >> of server IPs, connect to one that is up. >> >> I believe this comes up in several different scenarios. >> >> Example #1: [single server; changing IP address gracefully] >> >> Example #2: [xDB/BDR client uses local master if up; else a remote] >> >> Example #3: [SR/HS with changing primary] > > For all of those it is clear that we do not need (or want!) > heartbeat, STONITH, fencing, etc. to be handled by the connector. > If the above are the sorts of problems we are trying to solve, a > very simple solution is the best. I know you outlined several; I'm > not sure it would matter all that much which one we used -- any > would work and someone should Just Do It. > >> I'm sure there are more. > > Ay, there's the rub. Some people seemed to be suggesting that this > should be far more than what you describe above. That would, IMO, > be a mistake. It sounds like we are pretty much on the same page. :-) -- 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