Query Raw with pg-bouncer loses schema

Bug description

I am running several select queries with $queryRaw against my postgres database. The following error ocures regularly (but not every time):

{"code": String("42P01"), "message": String("relation \"Book\" does not exist")}), error_code: "P2010" }

• I am using a specific schema name, that is different per environment (set via connection string)
• I am using pg_bouncer where the error occures. the error doesnt occur without pg_bouncer

Things I have tried without success:

• Running the queries in a transaction
• Running a simple primsa query first in the same transaction e.g. client.user.findMany({ take:1 })

Things I have tried that worked:

• Running the queries in a transaction and setting the searchpath first!

        const [_, a, b, c] = await client.$transaction([
          client.$queryRaw(`SET search_path TO "${config.DATABASE_SCHEMA}";`),
          client.$queryRaw`SELECT * FROM "Book";`,
          client.$queryRaw`SELECT * FROM "Author";`,
          client.$queryRaw`SELECT * FROM "Shelf";`,
        ]);

My impression is, that prisma doesnt set the search path in time for new connections.

How to reproduce

1. Run postgres with pg_bouncer set to transactional mode
2. Have a schema parameter added to your DATABASE_URL env variable
3. Add a table to your prisma schema and migrate
4. Run a raw query: $queryRawSELECT * FROM “MyTable”;``
5. Run this query repeatedly over 10 min

Expected behavior

No response

Prisma information

• prisma version: 2.25.0
• I am using a schema, added to the connection string
• I am using pg_bouncer set to transactional mode (this is important, because on staging and local I dont have pg_bouncer and there no error occures)

Environment & setup

• OS: Ubuntu
• Database: Postgres 12
• Node.js version: 14

Prisma Version

Can’t run this on prod unfortunately so this is from my local environment (macOS), with the same code:

Environment variables loaded from .env
prisma               : 2.25.0
@prisma/client       : 2.25.0
Current platform     : darwin
Query Engine         : query-engine c838e79f39885bc8e1611849b1eb28b5bb5bc922 (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli c838e79f39885bc8e1611849b1eb28b5bb5bc922 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core c838e79f39885bc8e1611849b1eb28b5bb5bc922 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt c838e79f39885bc8e1611849b1eb28b5bb5bc922 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : c838e79f39885bc8e1611849b1eb28b5bb5bc922
Studio               : 0.402.0

[0xsven]

Global schema being public?

Yes. The public schema. I mixed that up. (editing it for future readers)

Your theory is also the only thing that could lead to this behavior - but somehow it still sounds weird as we are not setting the schema patch async.

Can you maybe enable all logging for the queries etc and try to reproduce it? We do not log the connection something is executed with (yet), but maybe still something interesting pops out from that: https://www.prisma.io/docs/concepts/components/prisma-client/debugging + https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/logging#log-to-stdout

I am gonna do that and report back.

[janpio]

Global schema being public?

Your theory is also the only thing that could lead to this behavior - but somehow it still sounds weird as we are not setting the schema patch async.

Can you maybe enable all logging for the queries etc and try to reproduce it? We do not log the connection something is executed with (yet), but maybe still something interesting pops out from that: https://www.prisma.io/docs/concepts/components/prisma-client/debugging + https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/logging#log-to-stdout