Error 55006 arises when you attempt to drop or alter a database object that another session is still using, preventing the required exclusive lock.
PostgreSQL Error 55006 object_in_use appears when you attempt to drop or alter an object that is still referenced by another session. Release the locks by terminating conflicting sessions or waiting until the transaction completes, then rerun the statement.
PostgreSQL Error 55006
PostgreSQL raises SQLSTATE 55006 when an ALTER, DROP, DETACH, or REINDEX command targets an object that another transaction currently locks. The system prevents data corruption by blocking the operation.
The error message usually expands to a descriptive line such as “database \"mydb\" is being accessed by other users” or “cannot detach partition because indexes are in use.”
The root cause is an unbreakable lock conflict.
The session running your statement needs an exclusive lock, but at least one other backend already holds a shared or exclusive lock on the same object.
Common triggers include active client connections, long-running queries, idle transactions left open, logical replication slots, autovacuum workers, and background maintenance tasks.
First locate blocking sessions with pg_locks or pg_stat_activity. Decide whether to wait, cancel, or terminate them.
Only after the conflicting lock disappears can you rerun your DDL safely.
Use database-superuser functions like pg_terminate_backend() sparingly on production, preferably during maintenance windows or after taking backups.
Dropping a database fails because other users stay connected – disconnect them or force a shutdown via pg_terminate_backend.
Detaching a partition fails during heavy reporting – pause report queries, detach, then resume workload.
Close idle transactions promptly, use shorter statement timeouts, and schedule DDL during low-traffic periods.
Monitoring tools or Galaxy’s session panel can surface lingering locks before they break deployments.
Automate kill scripts in CI pipelines to clear test databases, but never in production without review.
Error 55P03 (lock_not_available) signals lock timeouts rather than definitive conflicts; increase lock_timeout or free the lock. Error 57P03 (cannot_connect_now) appears when the database is in recovery; wait for promotion or finish recovery tasks.
.
Coordinate with application owners, set the database to single-user or maintenance mode, terminate backends, and monitor logs for unintended rollbacks.
Yes. Ask users to disconnect, set shorter statement timeouts, or wait until nightly downtime before running DDL.
No. 55006 is an immediate conflict, not a timeout. You must release the existing lock first.
Galaxy visualizes live locks, lets you terminate them with one click, and warns when your DDL would conflict, reducing surprises.
.avif)
.avif){kind=logo}
