Skip to main content
POST
Repair ownership
Reassigns ownership of every table, sequence, view, and materialized view in the database to the database’s owner role. Idempotent — safe to run multiple times.

When to use this

Call this endpoint after you’ve restored a pg_dump into your database and then see permission denied for table X (Postgres SQLSTATE 42501) when your application connects. Why it happens: Legacy or out-of-band restores can preserve object owners that differ from the limited tenant owner. The staged DBHost restore path runs customer dump content as the limited owner and validates ownership before swap; it does not execute customer dump content as PostgreSQL superuser. New restores triggered through DBHost automatically run this repair step at the end. This endpoint exists for:
  • Databases that were restored before the automatic repair existed.
  • Clean-up after out-of-band psql / pg_restore activity.
  • Any situation where your app role hits permission denied on tables you expect to own.

Path parameters

What it does

For the target database only:
  1. ALTER SCHEMA public OWNER TO <owner> + grants USAGE, CREATE.
  2. Iterates every non-system schema and issues ALTER TABLE/SEQUENCE/VIEW/MATERIALIZED VIEW ... OWNER TO <owner>.
  3. Regrants the SQL-explorer role SELECT on the restored tables so the dashboard explorer keeps working.
The operation is scoped to a single database. It cannot affect any other tenant’s data.

Response

200 OK

Errors

CLI

Running this when ownership is already correct is a no-op — every ALTER ... OWNER TO statement is idempotent.