Incident brief
Dependent objects still exist
A DROP ROLE was attempted while that role still owned a table. PostgreSQL refused to drop the role rather than leave an object without a valid owner.
What lands in your log
ERROR: role "batch7_owner" cannot be dropped because some objects depend on it
In 10 seconds
- What triggers it
- Create a role, then make it the owner of a table.
- Fix
- Reassign ownership first: ALTER TABLE ... OWNER TO another_role, or use REASSIGN OWNED BY old_role TO new_role for everything at once.
- Proof
- Reproduced on PostgreSQL 16.14 → Dropping a role that still owned a table was rejected with SQLSTATE 2BP01, naming the exact dependent table in DETAIL.
Fix
What to do right now
Application-level steps for this error.
- Reassign ownership first: ALTER TABLE ... OWNER TO another_role, or use REASSIGN OWNED BY old_role TO new_role for everything at once.
- Then DROP ROLE succeeds because nothing depends on it anymore.
REASSIGN OWNED BY batch7_owner TO postgres;
DROP ROLE batch7_owner;For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
List the dependency chain before deciding between an ordered drop and CASCADE. CASCADE is not a diagnostic shortcut.
Objects depending on the target
Replace the target regclass. pg_describe_object renders the dependent catalog objects.
SELECT pg_describe_object(d.classid, d.objid, d.objsubid) AS dependent_object,
d.deptype
FROM pg_depend d
WHERE d.refobjid = to_regclass('<schema.target_relation>')
ORDER BY d.deptype, dependent_object;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, DROP ROLE
A role cannot be removed if it is still referenced in any database of the cluster; an error will be raised if so. Before dropping the role, you must drop all the objects it owns (or reassign their ownership).Read the full section on postgresql.org →
The rejected DROP ROLE
Per the manual, a role can't be removed while it's still referenced anywhere in the cluster, here, as the owner of a table.Confirming the role still works
The rejected DROP ROLE didn't remove the role, it's still there, still owning the table, exactly as before.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Create a role, then make it the owner of a table.
- 2Try to DROP ROLE that role.
- 3SQLSTATE 2BP01 is reported, naming the dependent table in DETAIL.
One client: create a role, make it own a table, then try to drop the role.
CREATE ROLE batch7_owner;
CREATE TABLE batch7_owned_table (id int);
ALTER TABLE batch7_owned_table OWNER TO batch7_owner;DROP ROLE batch7_owner;SELECT rolname FROM pg_roles WHERE rolname = 'batch7_owner';What PostgreSQL actually returned
CREATE ROLE
CREATE TABLE
ALTER TABLEERROR: role "batch7_owner" cannot be dropped because some objects depend on it
DETAIL: owner of table batch7_owned_table rolname
--------------
batch7_owner
(1 row)The deeper lab audit for this error
- Fix that revokes privileges but not ownership: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Runbook to fix this
Runbooks for this incident
Full step-by-step fixes for the condition behind this error: the diagnosis, the exact SQL, and output captured in the lab.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Fix it — runbooks
Related errors
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.