Fwd: Two questions I would like insight on

    pulled from pg_shadow.  If we go with this procedure, I would have to update the auth file

    every time the user password is changed, which I would like to avoid. Several years ago

    I ran pgpool which had the option of authenticating directly from pg_hba.conf avoiding the necessity

    of maintaining an auth file with password.

      Can we execute a similar procedure in pg_bouncer or are we relegated with having to maintain

      an auth file with password?

 2.   FATAL:  remaining connection slots are reserved for non-replication super user connections error:

      In my testing I purposely reduced the max_connection parameter to test the limits and functionality

      of pg_bouncer  I expected that pgbouncer would limit the pool connections number to a formula

      similar to the following:

         total pool connections allowed = max_connections - (superuser reserved connections  + total slony connections)

                 (slony run outside of pg_bouncer control

       This is pretty much what I got:  Extra pool connections would be queued until one freed up (using session pooling)

       What surprised me was the FATAL error above cropping up in the logs. I've always interpreted FATAL as the connection

       being totally dead and lost.  But my testing worked as I hoped for with all queries eventually being executed.

          Is getting the FATAL: remaining connection ... error really ok?  Is pg_bouncer simply creating another server connection

           later to fulfill the query?  Or am I missing something that I should be on the lookout for?

     [databases]
slonytst = host=10.10.4.52 port=5433  dbname=slonytst pool_size = 8

[pgbouncer]
pool_mode = session
listen_port = 5432
listen_addr = *
auth_type = md5
auth_file = /home/postgres/pgbouncer/passwd.file
logfile = pgbouncer.log
pidfile = pgbouncer.pid
default_pool_size = 8
admin_users = postgres
stats_users = stat_collector
max_client_conn = 30