Re: Automatic Client Failover

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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, with the portable poll()/
select()/... process, that is now know as pgbouncer.

Existing pgbouncer would have to be expanded to:
- provide a backward compatible mode
(session pooling, release server session at client closing time)
- allow to configure several backend servers and to try next on
certain conditions
- add hooks for clients to know when some events happen
(failure of current master, automatic switchover, etc)

Existing pgbouncer hooks and next ones could be managed with catalog
tables as we have special options table for autovacuum, e.g.,
pg_connection_pool, which could contain arbitrary SQL for new backend
fork, backend closing, failover, switchover, etc; and maybe the client
hooks would be NOTIFY messages sent from the backend at its initiative.

Would we then have the centrally managed behavior Tom is mentioning?
I'm understanding this in 2 ways:
- this extension would be able to distinguish between failure cases
where we are able
to do an automatic failover from "hard" crashes (impacting the
listener)
- when we have read-only slave(s) pgbouncer will be able to redirect
ro statements to it.

Maybe it would even be useful to see about Markus' work in Postgres-R
and its inter-backend communication system allowing the executor to
require more than one backend working on a single query. The pgbouncer
inherited system would then be a pre-forked backend pooling manager
too...

Once more, I hope that giving (not so) random ideas here as a (not
yet) pgsql hacker is helping the project more than it's disturbing
real work...

Regards,
- --
dim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkiXk5gACgkQlBXRlnbh1bkBhACfQdgHh27yGeyHgeCrC7aV1LET
U4IAn1N6FaanI2BEWMLyPWKmGtedaSQC
=ifVF
-----END PGP SIGNATURE-----