Why we built yet another Postgres connection pooler

> Since connection poolers reuse connections between clients, the connection state of one client “leaks” into the connection state of another.

Wow this is very bad. This actually happens in typical Postgres setups?

It's awesome to see AGPL instead of the horrible BSL variants that have been going around.

Any plans to add Query Caching for Selects?

as per:

https://www.pgpool.net/docs/latest/en/html/runtime-in-memory...

Is there a pooler handling schema switching in PostgreSQL? like something in front of django-tenant ?

Doesn't this NOTIFY performance fix mean that it isn't transactional any more?

Clickhouse also just put out a fun article on scaling pgbouncer too, talking about scaling out so_reuseport while not having to shard so harshly (a major limitation pgdog here is addressing via rewrite), https://clickhouse.com/blog/pgbouncer-clickhouse-managed-pos... https://news.ycombinator.com/item?id=48814152

[flagged]

we moved our django app behind pgbouncer transaction pooling a few days ago and the surprise wasn't SET so much as queryset.iterator(). it relies on server side cursors, which don't survive being pooled, so we had to disable it everywhere and let it fall back to client side. also had to move statement_timeout out of the app's connection options into the pooler's own connect query, since libpq startup params just get silently ignored behind it.

[flagged]