= PgBouncer TODO list =

== Slightly urgent features ==

 * move to libusual
 * auth_conn - access to pg_shadow, so auth_file is not needed.
   [ flat-text files are gone in 8.5+ ]
 * per_loop_maint/per_loop_activate take too much time in case
   of moderate load and lots of pools.  Perhaps active_pool_list
   would help, which contains only pools touched in current loop.
 * new states for clients: idle and in-query.  That allows to apply
   client_idle_timeout and query_timeout without walking all clients
   on maintenance time.

== Good-to-have features in transaction pooling ==

 * Protocol-level plan cache.
 * LISTEN/NOTIFY.  Requires strict SQL format.

== Minor features ==

 * duplication: format_time vs. render_time
   - avoid localtime? (libc stat)
 * set server_reset_query = '';
 * check if SQL error codes are correct
 * removing user should work - kill connections
 * keep stats about error counts
 * cleanup of logging levels, to make log more useful
 * to test:
   - signal flood
   - no mem / no fds handling
 * fix high-freq maintenance timer - it's only needed when
   PAUSE/RESUME/shutdown is issued.
 * Get rid of SBUF_SMALL_PKT logic - it makes processing code complex.
   Needs a new sbuf_prepare_*() to notify sbuf about short data.
   [Plain 'false' from handler postpones processing to next event loop.]

== Win32 features ==

 * Automatic registration of pgbevent.dll.  (Re-register also
   if old DLL does not exist.)
 * PAUSE/RESUME via service control panel.
 * Online reboot by DuplicateHandle().  Main question is:
   What should the UI look like?  Making it work for console
   app seems easy, but it does not make sense at all without
   working also for services.

== Dubious/complicated features ==

 * units for config parameters.
 * some preliminary notification that fd limit is full

 * Move all "look-at-full-packet" situtations to SBUF_EV_PKT_CALLBACK

 * pid mapping for NOTIFY.

 * `pool_mode = plproxy` - use postgres in full-duplex mode for autocommit
   queries, multiplexing several queries into one connection.  Should result
   in more effiicent CPU usage of server.

=== prepared plans ===

 * keeping track of protocol-level prepared plans
   - JDBC workaround in the meantime: protocolVersion=2

=== load-balancing ===

 * allow serveral server to serve one db
   - possibility to specify failover databases.
 * seems pointless - result would be less featureful HAProxy

=== SMP awareness ===

 * spread sockets over per-cpu threads.  needs confirmation that
   single-threadedness can be problem.  it can also be that only
   accept() + login handling of short connection is problem.
   that could be solved by just having threads for login handling,
   which would be lot simpler.  or just deciding that its not
   worth fixing.

