On Mon, 2008-08-04 at 22:56 -0400, Tom Lane wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: > > I think the proposal was for an extremely simple "works 75% of the time" > > failover solution. While I can see the attraction of that, the > > consequences of having failover *not* work are pretty severe. > > Exactly. The point of failover (or any other HA feature) is to get > several nines worth of reliability. "It usually works" is simply > not playing in the right league.
Why would you all presume that I haven't thought about the things you mention? Where did I say "...and this would be the only feature required for full and correct HA failover." The post is specifically about Client Failover, as the title clearly states. Your comments were illogical anyway, since if it was so bad a technique then it would not work for pgpool either, since it is also a client. If pgpool can do this, why can't another client? Why can't *all* clients? With correctly configured other components the primary will shut down if it is no longer the boss. The client will then be disconnected. If it switches to its secondary connection, we can have an option to read session_replication_role to ensure that this is set to origin. This covers the case where the client has lost connection with primary, though it is still up, yet can reach the standby which has not changed state. DB2, SQLServer and Oracle all provide this feature, BTW. We don't need to follow, but we should do that consciously. I'm comfortable with us deciding not to do it, if that is our considered judgement. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers