DEPLOY.CONTEXT.GRANT.OWNERSHIP_MISSING — the migration role holds every grant and still cannot ALTER
- Category: safety
- Severity: critical
- Level: 0
- Downtime class: blocking
- Stability: stable
- Suites: deploy
- Applies to: PostgreSQL
The false green this exists to prevent
A grant check that asks only about privileges can answer yes for a role that will still fail on the
first ALTER TABLE. PostgreSQL has no grant for ALTER — it requires ownership, and
ownership is not a privilege anybody can hand out with GRANT.
So the worst outcome of a privilege check is not a missed finding. It is a green one: the deploy gate says the role is ready, and the migration stops halfway through.
Why it is a separate id from a missing privilege
The two send you to different actions:
| Finding | What fixes it |
|---|---|
| DEPLOY.PREFLIGHT.MISSING_PRIVILEGE | run the GRANT the message names |
| DEPLOY.CONTEXT.GRANT.OWNERSHIP_MISSING | transfer ownership, or run the migration as the owner |
Reported under one id, somebody reads "missing privilege", runs the GRANT, and watches the next
deploy fail identically.
Why critical
The migration does not refuse to start. It applies what it can and stops here — leaving the schema half-migrated while the application is already deployed against the other half. That is the failure this check exists to move out of the deploy window.
How ownership is decided
pg_has_role(role, relowner, 'USAGE'), which follows role inheritance on its own. Ownership held
through two levels of membership answers yes, and reimplementing that traversal would be a second
opinion about the server's own rules.
The cases this cannot see
- Ownership acquired between this check and the migration. The answer describes the moment it looked.
- An object the migration creates. It has no owner to compare against, and creating it needs
CREATEon the schema instead — which is the privilege check's question, not this one's.