si24 wrote
> Can some one please give me a bit more of a better explanation on how
> exactly the pgbouncer works as I am now lost.
Working from theory here but:
Pool (PGBouncer) Connections: 1
PostgreSQL Connections: 1
Container Threads: 2 [A, B]
Thread A: get connection -> OK
Thread B: get connection -> waiting for available connection
Thread A: do something with connection
Thread B: still waiting
Thread A: ***RELEASE CONNECTION*** <goes back into the pool>
Thread B: got a connection now
Thread A: get connection -> waiting for available connection
Thread B: do something with connection
Thread A: still waiting
Thread B: ***RELEASE CONNECTION*** <goes back into the pool>
Thread A: got a connection now
Each pool connection maintains a persistent connection in PostgreSQL
The number of pool connections can fluctuate between a minimum and maximum
If a pool connection is "checked out" it will never go away. Only after the
caller has "released/closed the connection" can it be potentially removed
from the pool. If there is not activity for a long while, and all pool
connections have been "closed", the number of open connections should
eventually go back down to the minimum. My guess is that a failure to close
these connections is causing the pooler to think they are still in use and
thus cannot release them from the pool and close the matching connection to
PostgreSQL.
I'd suggest you try some interactive use of your application by pretending
that you are two users and there is only a single connection available for
use. Only once that scenario works correctly should you go ahead and
increase the number of available connections. These connections, generally,
only aid in concurrency performance and should not be required to make you
application work properly.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Explanantion-on-pgbouncer-please-tp5776515p5776554.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
