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
- Install
prisma@2.23
and@prisma/client@2.23
- Create a new database on Render.com / ElephantSQL
- 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)
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 🤔
errors for
pnpx prisma db push --force-reset --accept-data-loss
(same for both instances):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
.env
file with this:pnpx prisma migrate deploy
(orpnpx prisma db push
with those flags mentioned above)In my opinion though, the more important thing is that
deploy
command doesn’t work… but seems like there’s a broader issue insteadInteresting, 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 😦