Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> Le 5 août 08 à 01:13, Tom Lane a écrit :
>> There is one really bad consequence of the oversimplified failover
>> design that Simon proposes, which is that clients might try to fail
>> over for reasons other than a primary server failure. (Think network
>> partition.) You really want any such behavior to be managed
>> centrally, IMHO.
> Then, what about having pgbouncer capability into -core. This would
> probably mean, AFAIUI, than the listen()ing process would no longer
> be postmaster but a specialized one,
Huh? The problem case is that the primary server goes down, which would
certainly mean that a pgbouncer instance on the same machine goes with
it. So it seems to me that integrating pgbouncer is 100% backwards.
Failover that actually works is not something we can provide with
trivial changes to Postgres. It's really a major project in its
own right: you need heartbeat detection, STONITH capability,
IP address redirection, etc. I think we should be recommending
external failover-management project(s) instead of offering a
half-baked home-grown solution. Searching freshmeat for "failover"
finds plenty of potential candidates, but not having used any of
them I'm not sure which are worth closer investigation.
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
