Reputation: 33
I'm working with a tech stack of Prisma ORM and Postgres on Supabase with PgBouncer enabled. We're also using Google Cloud Run to deploy our Node/Express API.
When looking through logs for production, you will see occurances of the same errors being raised again and again. One such example looks like:
Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 10, connection limit: 1)
I've read up on this page: https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/connection-pool.
The timeout of 10 seconds is the Prisma connection pool default and the connection limit of 1 is set via the query parameter of the connection string I use,
postgresql://[USER]:[PASSWORD]@localhost:[PORT]/[NAME]?pgbouncer=true&connection_limit=1
, given from the docs also: https://www.prisma.io/docs/guides/performance-and-optimization/connection-management/configure-pg-bouncer.
This was done because we thought multiple instances of our API containers would hog the connections to PgBouncer.
My question is:
connection_limit
query parameter pointless? Should I just get rid of that?What I've tried:
connection_limit
- this seemed to have little to no effect.pg_stat_activity
- I'm seeing 2 different client addresses across multiple processes, almost all idle (I assume because pgbouncer is managing them?)Upvotes: 1
Views: 3309
Reputation: 51
1 & 2: Looking at the Prisma docs, you should not be using connection_limit=1
since you're using an external connection pooler, i.e. PgBouncer. Have you tried increasing the connection_limit
beyond the Prisma default?
3: There are also some troubleshooting steps here related to the timeout error.
Upvotes: 2