From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Subject: | md5 password deprecation might cause problems with PgBouncer setups |
Date: | 2025-06-06 21:48:18 |
Message-ID: | CAGECzQSY3JfPkQP2jXdYLSyxdAt5Vz8P3XT8mbKdoVJHHz131Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
First of all, I'm definitely in favor of sunsetting md5 password auth myself.
However, I would like to share a possible issue that users might run
into while we're doing this: Apparently the overhead of scram-256 is
much higher in some PgBouncer setups. I expect this to be mostly
setups where there are many short lived connections, but that's a
fairly normal scenario for PgBouncer. The bitnami docker image of
PgBouncer changed the default auth_type to scram-256 around two years
ago[1]. This still results in people reporting perf regressions when
upgrading PgBouncer[2][3].
I'm not sure how to improve this situation though. Maybe PgBouncer
will continue supporting md5 a while longer. Or we should start
recommending password auth. The single-threaded nature of PgBouncer
also makes these types of perf regressions extra problematic, because
once you hit 100% of the core that PgBouncer is running on, the only
way out is complicating your setup with multiple PgBouncer instances.
[1]: https://github.com/bitnami/containers/commit/190481f04144fe8ff1247da6fc7ed605951352b4
[2]: https://github.com/pgbouncer/pgbouncer/issues/912
[3]: https://github.com/pgbouncer/pgbouncer/issues/1332
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-06-06 22:12:02 | Re: md5 password deprecation might cause problems with PgBouncer setups |
Previous Message | Masahiko Sawada | 2025-06-06 21:34:12 | Re: Batch TIDs lookup in ambulkdelete |