Description
storage/sql is using github.com/lib/pq for its postgres backend. That will keep a connection pool, and open multiple connections if needed. When hammering the login endpoint, you'll eventually see pq: sorry, too many clients already errors.
TODO: Expose database/sql's SetMaxOpenConns via configuration.
ℹ️ What is this for?
This is something found when investigating #1292. When using Postgres for storage, it's not likely that you end up filling it up -- I couldn't fire enough requests to make the table size actually troublesome.
However, since github.com/lib/pq is opening more connections if it needs them, we'll eventually run out of available Postgres connections. The "typical default", according to the docs, is 100.
Especially when one Postgres service is shared with other clients besides Dex, this is an issue: unauthenticated requests can saturate the limited resource "connection to PG" for all services.
✔️ How does this help?
When setting MaxOpenConns in lib/pq, and all its connections are in use, it'll block until one becomes free. This would still be a condition that can be triggered from unauthenticated requests, so, it's not a solution to #1292 (when using PG). However, it'll not affect other services, as there will still be connections available in the (shared) Postgres service.