> Shay>I don't know much about the Java world, but both pgbouncer and pgpool > (the major pools?) > > In Java world, https://github.com/brettwooldridge/HikariCP is a very good > connection pool. > Neither pgbouncer nor pgpool is required. > The architecture is: application <=> HikariCP <=> pgjdbc <=> PostgreSQL > > The idea is HikariCP pools pgjdbc connections, and server-prepared > statements are per-pgjdbc connection, so there is no reason to "discard > all" or "deallocate all" or whatever.
Interesting. What would happen if a user changes some of GUC parameters? Subsequent session accidentally inherits the changed GUC parameter? > Shay>send DISCARD ALL by default. That is a fact, and it has nothing to do > with any bugs or issues pgbouncer may have. That is correct for pgpool as well. > That is configurable. If pgbouncer/pgpool defaults to "wrong > configuration", why should we (driver developers, backend developers) try > to accommodate that? There's nothing wrong with DICARD ALL. It's just not suitable for your program (and HikariCP?). I don't know about pgbouncer but pgpool has been created for a general purpose connection pooler, which means it must behave as much as similarly to PostgreSQL backend from frontend's point of view. "DISCARD ALL" is needed to simulate the behavior of backend: it discards all properties set by a frontend including prepared statements when a session terminates. "DISCARD ALL" is perfect for this goal. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers