= PgBouncer TODO list =

== Minor features ==

 * duplication: format_time vs. render_time
   - avoid localtime? (libc stat)
 * set server_reset_query = '';
 * check if SQL error codes are correct
 * login cleanup / more useful
 * 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
 * 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.
 * 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
 * auth_conn - access to pg_shadow, so auth_file is not needed

 * pid mapping for NOTIFY.

=== 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.

