prisma: `Error: UserFacingError` or `Error querying the database: db error: ERROR: must be owner of view pg_stat_statements` for specific database

Bug description

Whenever I try to deploy migrations to any remote database that isn’t localhost, I get this error:

➜ pnpx prisma migrate deploy
Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "***", schema "public" at "***:5432"
Response: Can't reach database server at `***`:`5432`

Please make sure your database server is running at `***`:`5432`.
Error: UserFacingError

I also tried running this:

➜ pnpx prisma db push --force-reset  --accept-data-loss
Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "***", schema "public" at "***:5432"

Error: P3016

The fallback method for database resets failed, meaning Migrate could not clean up the database entirely. Original error: 
Database error
Error querying the database: db error: ERROR: must be owner of view pg_stat_statements
   0: sql_migration_connector::best_effort_reset
           with connection=Connection(Postgres(PostgresUrl { url: Url { scheme: "postgres", username: "***", password: Some("***"), host: Some(Domain("***")), port: None, path: "/doxjeowf", query: Some("statement_cache_size=0"), fragment: None }, query_params: PostgresUrlQueryParams { ssl_params: SslParams { certificate_file: None, identity_file: None, identity_password: <HIDDEN>, ssl_accept_mode: AcceptInvalidCerts }, connection_limit: None, schema: "public", ssl_mode: Prefer, pg_bouncer: false, host: None, socket_timeout: None, connect_timeout: Some(5s), pool_timeout: Some(10s), statement_cache_size: 0, max_connection_lifetime: None, max_idle_connection_lifetime: Some(300s) } }))
             at migration-engine/connectors/sql-migration-connector/src/lib.rs:99
   1: migration_core::api::Reset
             at migration-engine/core/src/api.rs:157

…so it connected somehow? but refuses to connect on deploy command… weird

How to reproduce

  1. Install prisma@2.23 and @prisma/client@2.23
  2. Create a new database on Render.com / ElephantSQL
  3. Run prisma migrate deploy

Expected behavior

It should deploy migrations with no issues. It works fine on localhost though, which is weird…

Prisma information

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DB_URL")
}

model Account {
  id                 Int       @id @default(autoincrement())
  compoundId         String    @unique @map("compound_id")
  userId             Int       @map("user_id")
  providerType       String    @map("provider_type")
  providerId         String    @map("provider_id")
  providerAccountId  String    @map("provider_account_id")
  refreshToken       String?   @map("refresh_token")
  accessToken        String?   @map("access_token")
  accessTokenExpires DateTime? @map("access_token_expires")
  createdAt          DateTime  @default(now()) @map("created_at")
  updatedAt          DateTime  @default(now()) @map("updated_at")

  @@index([providerAccountId], name: "providerAccountId")
  @@index([providerId], name: "providerId")
  @@index([userId], name: "userId")
  @@map("accounts")
}

model Session {
  id           Int      @id @default(autoincrement())
  userId       Int      @map("user_id")
  expires      DateTime
  sessionToken String   @unique @map("session_token")
  accessToken  String   @unique @map("access_token")
  createdAt    DateTime @default(now()) @map("created_at")
  updatedAt    DateTime @default(now()) @map("updated_at")

  @@map("sessions")
}

model User {
  id                     Int       @id @default(autoincrement())
  name                   String    @unique
  email                  String?   @unique
  emailVerified          DateTime? @map("email_verified")
  image                  String?
  createdAt              DateTime  @default(now()) @map("created_at")
  updatedAt              DateTime  @default(now()) @map("updated_at")
  Post                   Post[]
  twitterApiKey          String?   @unique
  twitterApiSecret       String?   @unique
  twitterApiAccessToken  String?   @unique
  twitterApiAccessSecret String?   @unique
  slug                   String    @unique @default(uuid())

  @@map("users")
}

model VerificationRequest {
  id         Int      @id @default(autoincrement())
  identifier String
  token      String   @unique
  expires    DateTime
  createdAt  DateTime @default(now()) @map("created_at")
  updatedAt  DateTime @default(now()) @map("updated_at")

  @@map("verification_requests")
}

model Source {
  id       Int    @id @default(autoincrement())
  httpLink String
  assetId  String

  Post Post[]
}

model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now()) @map("created_at")
  title     String
  published Boolean  @default(false)
  authorId  Int      @map("author_id")
  author    User     @relation(fields: [authorId], references: [id])
  content   Source   @relation(fields: [sourceId], references: [id])

  sourceId Int
  @@map("post")
}

Environment & setup

  • OS: 5.10.42-1-MANJARO
  • Database: PostgreSQL
  • Node.js version: 14.17.2

Prisma Version

risma               : 2.23.0
@prisma/client       : 2.23.0
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/.pnpm/@prisma+engines@2.23.0-36.adf5e8cba3daf12d456d911d72b6e9418681b28b/node_modules/@prisma/engines/query-engine-debian-openssl-1.1.x)
Migration Engine     : migration-engine-cli adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/.pnpm/@prisma+engines@2.23.0-36.adf5e8cba3daf12d456d911d72b6e9418681b28b/node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/.pnpm/@prisma+engines@2.23.0-36.adf5e8cba3daf12d456d911d72b6e9418681b28b/node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary        : prisma-fmt adf5e8cba3daf12d456d911d72b6e9418681b28b (at node_modules/.pnpm/@prisma+engines@2.23.0-36.adf5e8cba3daf12d456d911d72b6e9418681b28b/node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash : adf5e8cba3daf12d456d911d72b6e9418681b28b
Studio               : 0.393.0

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 24 (12 by maintainers)

Most upvoted comments

For anyone in the future using elephantsql, this is simply the way they’ve gone about partitioning the hardware they have.

You don’t have full access to the database RDBMS, but rather, they use one system to create dozens of databases within the same Postgres management system.

I’m not sure at the moment if this is something that’s really possible or easy to work around. I’m sure there could be some adjustments within prisma’s own code to assist in this type of situation (whether that type of change is justified or not is a whole different game), but more often than not, you may need access to the full db management system.

@janpio checked on Prisma 2.26 on 2 different instances. Same stuff… so no it’s not fixed :\

errors are different though 🤔

on  master [⇡!] is 📦 v1.0.0 via ⬢ v16.4.2 
➜ pnpx prisma migrate deploy
Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "***", schema "public" at "***"
Error: P1001: Can't reach database server at `***`:`5432`

Please make sure your database server is running at `***`:`5432`.

on  master [⇡!] is 📦 v1.0.0 via ⬢ v16.4.2 
➜ pnpx prisma migrate deploy # using a new fresh db instance here
Environment variables loaded from .env
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "***", schema "public" at "***:5432"
Error: Error in migration engine: Starting migration engine RPC server
Can't reach database server at `***`:`5432`

Please make sure your database server is running at `***`:`5432`.

errors for pnpx prisma db push --force-reset --accept-data-loss (same for both instances):

Error: P3016

The fallback method for database resets failed, meaning Migrate could not clean up the database entirely. Original error: 
Database error
Error querying the database: db error: ERROR: cannot drop view pg_stat_statements because extension pg_stat_statements requires it
HINT: You can drop extension pg_stat_statements instead.
   0: sql_migration_connector::best_effort_reset
           with connection=Connection(Postgres((PostgreSql { client: PostgresClient, pg_bouncer: false, socket_timeout: None, statement_cache: Mutex { is_locked: false, has_waiters: false }, is_healthy: true }, PostgresUrl { url: Url { scheme: "postgres", username: "***", password: Some("***"), host: Some(Domain("***")), port: None, path: "/urdb_upbr", query: Some("statement_cache_size=0"), fragment: None }, query_params: PostgresUrlQueryParams { ssl_params: SslParams { certificate_file: None, identity_file: None, identity_password: <HIDDEN>, ssl_accept_mode: AcceptInvalidCerts }, connection_limit: None, schema: None, ssl_mode: Prefer, pg_bouncer: false, host: None, socket_timeout: None, connect_timeout: Some(5s), pool_timeout: Some(10s), statement_cache_size: 0, max_connection_lifetime: None, max_idle_connection_lifetime: Some(300s) } })))
             at migration-engine/connectors/sql-migration-connector/src/lib.rs:115
   1: migration_core::api::Reset
             at migration-engine/core/src/api.rs:155

Can you open a new issue about this with all the information you can provide? That is just broken and we need to find a way around that.

I switched to supabase, which has a pretty good PG offering, that seems to work fine.

@janpio

Ok I’ll show this step by step

  1. Sign Up on render.com
  2. Create a new database

image

  1. After creating the database, open it in the dashboard and scroll down.
  2. Copy Internal connection string

image

  1. Create a new Node.js project with prisma 2.23
  2. Create an .env file with this:
DB_URL=<connection string>
  1. Download my Prisma schema from the issue
  2. Run pnpx prisma migrate deploy (or pnpx prisma db push with those flags mentioned above)
  3. See error

In my opinion though, the more important thing is that deploy command doesn’t work… but seems like there’s a broader issue instead

Interesting, so during our reproduction we definitely have to look at both versions to get the full picture.

We’ll do that as soon as possible, until then seems that our Migrate tooling unfortunately does not like this database setup 😦