问题
I'm using pgbouncer on a web app and most threads begin with a BEGIN and end with a COMMIT or a ROLLBACK, so we're using transaction pooling and everything is fine.
However, we also have some processes which don't use transactions: instead, they just issue commands one after another.
I believe that, under transaction pooling, every command is a transaction by itself, just the way it is when you're connected directly to the server, and perhaps every command is getting a different connection from the pool. But I've been told that pgbouncer wouldn't do that and instead would never find the final COMMIT/ROLLBACK and thus the connection wouldn't return to the pool.
Anybody knows what happens? I couldn't find anything in the documentation.
回答1:
https://pgbouncer.github.io/usage.html
https://pgbouncer.github.io/config.html#description
Transaction pooling
A server connection is assigned to client only during a transaction. When PgBouncer notices that transaction is over, the server connection will be put back into the pool.
In your case if transaction is never ended (commited, rolled back) it will hit idle_transaction_timeout (default disabled) and idle in transaction connection will go back to pool, allowing others to connect. If you have the default value for it, at some point all connection pool will be filled, so new will be rejected. From this point you single statements won't work - they will wait for free connection that never appears.
Regarding single statements - they are not "transformed to transactions by pgbounce" neither "in transaction pooling, every command is a transaction by itself". This is controlled by AUTOCOMMIT for each session.
来源：https://stackoverflow.com/questions/23394272/how-does-pgbouncer-behave-when-transaction-pooling-is-enabled-and-a-single-state