8 ms·
It seems like this uses native Postgres security/roles which I think would prevent a connection pooler from working (unless you held open 1 connection per user)
by nijave 4y ago
It seems like this uses native Postgres security/roles which I think would prevent a connection pooler from working (unless you held open 1 connection per user)
Ultimately it'd be nice if Postgres could keep a hot worker pool for connections instead of forking processes but afaik there's been plenty of debate over the years and no consensus
I think high connection thrashing also eats up CPU and there's the issue of increasing load eats more RAM which reduces Postgres memory cache. We had a connection leak problem and clearing ~2600 PG connections saved something like 80-100GB of RAM
- mike_hearn 4y agoI think you can use https://github.com/pgaudit/set_user https://github.com/pgaudit/set_user combined with some pgbouncer configuration to solve that, but agreed that postgres doesn't have perfect support for this scenario. It'd be better to have a proxy that is designed specifically for this use case that knows how to drive something like the set_user extension (and better if it were to be merged upstream).