Hi. We are using pgbouncer as part of our production database update
process, and are currently running a fork because pgbouncer didn't
quite give us the control we need. It seems to be working just fine,
the new commands work as intended and everything has been rock solid.
My coworker submitted a path on github, but this might not have been
the way to go about it::

https://github.com/markokr/pgbouncer-dev/pull/5

"""
We're using a bit of scripting on top of pgbouncer and streaming
replication to apply schema updates with no read outage and minimal
write downtime (a couple of seconds). To make this really quick we
need to be able to convince pgbouncer to immediately reject
connections to a particular database.

The KILL/PAUSE/RESUME commands give us per-database connection
control, but clients end up waiting for the backend connections to be
RESUMEd or time out. This is probably desirable for some users, but
not for us -- we want clients to fail immediately so they can fall
back to one of the replicas. To this end I've added a "disabled"
database flag set by the new DISABLE and ENABLE commands. When set,
the flag causes new client connections to be rejected (although
existing unused client connections can still pick up server
connections).

For now we're using a "DISABLE, wait for important connections to go
away, KILL, RESUME, replicate schema updates, ENABLE" sequence. Do you
have any opinions on safely introducing a variant of KILL that just
kills without pausing, to avoid the pointless RESUME step?
"""

I'd also love to see the per-database pool_mode patch go in
(https://github.com/ccutrer/pgbouncer-dev/commit/20c0586ec8be460b5bc472ef6a2ac481bf433df0).
I haven't tested this, but can do so if it will help it land.

-- 
Stuart Bishop 
http://www.stuartbishop.net/