prisma: Timed out fetching a new connection, even with high connection_limit

Bug description

When I kick off many queries concurrently, I get this issue:

Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 1, connection limit: 100)

I expect to NOT get this issue

How to reproduce

async function example() {
  const prisma = getPrisma('some_url?connection_limit=100&pool_timeout=1');

  const range = [...Array(10).keys()];
  await Promise.all(range.map(async (val) => {
    await prisma.nft.findMany({take: 10});
  }));

  console.log("done!");
}

When I run this code, I get this error:

Timed out fetching a new connection from the connection pool. More info: http://pris.ly/d/connection-pool (Current connection pool timeout: 1, connection limit: 100)

However, based on the Prisma docs, it seems like I should not be running into this.

If there are no idle connections available in the connection pool, the query engine opens additional database connections and adds them to the connection pool until the number of database connections reaches the limit defined by connection_limit.

Since my connection_limit (100) is much higher than the number of queries I’m kicking off (10), I don’t get why I’m running into this issue.

Also, my DB supports a maximum of over 3000 connections

One more note: weirdly, if I use connection_limit=1, I get no errors

Expected behavior

I expect all my queries to execute successfully

Prisma information

Not needed

Environment & setup

  • OS: Mac OS
  • Database: PostgreSQL
  • Node.js version: 16.7.0

Prisma Version

prisma                  : 3.8.1
@prisma/client          : 3.8.1
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at ../../node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at ../../node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at ../../node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at ../../node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f
Studio                  : 0.452.0
Preview Features        : interactiveTransactions

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 5
  • Comments: 17 (11 by maintainers)

Most upvoted comments

Please open a new issue and describe the full problem @divmgl. If the change to the connecion string does not have any effect, something is wrong.

We were incorrect. Connection limit and pool timeouts are working as intended and we were looking at the wrong logs. Apologies for the terse message, we’re dealing with an outage and are trying to figure out what’s wrong.

The issue is that our entire server process is crashing when running a very long query with Prisma. I’ll open a separate issue if I can get some reproduction steps but it’ll be difficult because we’re dealing with production data and it only happens in a populated production environment. Anyhow, thanks again.

@janpio I’m having the same issue on https://kirka.io

My PostgreSQL database allows 1000 connections and with those Prisma options: connection_limit=800&pool_timeout=10, I’m randomly getting about once every 15 minutes, Timed out fetching a new connection from the connection pool. before Prisma reaches the 800 connections limit, if I understand correctly, Prisma would need to use all the connections available (800) before sending the Timeout error?

image

My database logs also show that everything is fine, and the api server isn’t lagging.

Version: 3.15.0 (I tried multiple versions of prisma 3)

I can provide any information needed, this issue has been annoying me for a couple days now, let me know if you need me to test anything particular.

Thank you