Skip to main content
POST
/
api
/
v1
/
databases
/
{id}
/
repair-ownership
Repair ownership
curl --request POST \
  --url https://api.example.com/api/v1/databases/{id}/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: pg_dump / pg_restore runs as a superuser on the DBHost side. The restored tables end up owned by the superuser (or by whatever role name is baked into the dump — often postgres). Your application, however, connects as the owner role for your database, which doesn’t own the restored tables and therefore can’t read them. 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

ParameterTypeDescription
iduuidDatabase ID

​
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
{
  "name": "mydb",
  "status": "repaired",
  "message": "Ownership repair completed for 'mydb'"
}

​
Errors

StatusCodeDescription
401UNAUTHORIZEDMissing or invalid API key
404DATABASE_NOT_FOUNDDatabase doesn’t exist, isn’t owned by this user, or isn’t in scope for this key
500AGENT_ERRORThe VPS agent couldn’t connect to the database or reassign ownership

​
CLI

dbhost databases repair-ownership <database-id>
Running this when ownership is already correct is a no-op — every ALTER ... OWNER TO statement is idempotent.