Hi,
Le 12 mai 09 à 18:32, Robert Haas a écrit :
implement this same logic internally? IOW, when a client disconnects,
instead of having the backend exit immediately, have it perform the
equivalent of DISCARD ALL and then stick around for a minute or two
and, if a new connection request arrives within that time, have the
old backend handle the new connection...
A much better idea to solve this, in my opinion, would be to have
pgbouncer as a postmaster child, integrated into PostgreSQL. It allows
for choosing whether you want session pooling, transaction pooling or
statement pooling, which is a more deterministic way to choose when
your client connection will benefit from a fresh backend or an
existing one. And it's respecting some backend timeouts etc.
It's Open-Source proven technology, and I think I've heard about some
PostgreSQL distribution where it's already a postmaster's child.
<handwaving>
And when associated with Hot Standby (and Sync Wal Shipping), having a
connection pooler in -core could allow for transparent Read-Write
access to the slave: at the moment you need an XID (and when connected
on the slave), the backend could tell the pgbouncer process to
redirect the connection to the master. With such a feature, you don't
have to build client side high availability, just connect to either
the master or the slave and be done with it, whatever the SQL you're
gonna run.
</>
Regards,
--
dim
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
