How to fix Object in use in PostgreSQL

PostgreSQLINTERMEDIATEMEDIUMUpdated Dec 28, 2025· 170 views

The PostgreSQL error 55006 (object_in_use) occurs when you attempt to drop or modify a database object that is currently being accessed by another session. Terminate conflicting connections or wait for the object to become available.

Quick fix

Fixes 55006

SELECT pid, usename, application_name, state, query
FROM pg_stat_activity
WHERE datname = 'your_database_name'
AND state != 'idle';
  1. Check for active connections using the object
  2. Coordinate with users and close idle connections
  3. Terminate conflicting sessions if necessary
  4. Drop or alter the object
postgresql — error
SELECT pid, usename, application_name, state, query
FROM pg_stat_activity
WHERE datname = 'your_database_name'
AND state != 'idle';
Object in use

What this error means

PostgreSQL enforces object state prerequisites to maintain data integrity. The "Object in use" error (SQLSTATE 55006) is part of the "Object Not In Prerequisite State" error class, meaning you're attempting an operation on an object that is not in the required state. Specifically, the object is currently being accessed, locked, or held by another transaction or session, which prevents the operation (typically DROP or ALTER) from completing safely. This error protects against concurrent modifications that could corrupt data or cause transaction conflicts. PostgreSQL prevents you from dropping a table while someone is reading from it, or from altering a schema while connections are still active within it.

Typical symptoms

  • DROP DATABASE command fails when other users are connected to the database
  • DROP TABLE or DROP SCHEMA command fails with "Object in use" message
  • ALTER TABLE or other DDL operations fail when the object is being accessed by concurrent queries
  • Automated tools fail during maintenance windows because background processes hold object locks
  • Applications see transaction failures when attempting to restructure the database

Common causes

  1. Other database sessions actively using or querying the object you are trying to drop or modify
  2. Background processes like autovacuum holding locks on the target object
  3. Idle connections holding open transactions that locked the object
  4. Prepared statements or cursors keeping references to the object
  5. Replication lag (in streaming replication scenarios) causing objects to be in use on standby servers

How to fix "Object in use"

1Check for active connections using the object

Before dropping or modifying a database object, identify which sessions are accessing it:

sql
SELECT pid, usename, application_name, state, query
FROM pg_stat_activity
WHERE datname = 'your_database_name'
AND state != 'idle';

For dropping a specific table:

sql
SELECT l.locktype, l.relation::regclass, l.pid, a.usename, a.query
FROM pg_locks l
JOIN pg_stat_activity a ON l.pid = a.pid
WHERE l.relation = 'your_table'::regclass;
2Coordinate with users and close idle connections

Before terminating connections, notify users that database maintenance is happening. Close applications and idle connections gracefully:

sql
-- Find idle connections that have been idle for more than 10 minutes
SELECT pid, usename, state_change, query
FROM pg_stat_activity
WHERE state = 'idle'
AND state_change < NOW() - INTERVAL '10 minutes'
AND datname = 'your_database_name';

Ask users to close their connections or restart applications to release locks.

3Terminate conflicting sessions if necessary

If connections cannot be closed gracefully, terminate them. Use caution—aborted transactions may leave uncommitted work:

sql
-- Terminate a specific backend
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'your_database_name'
AND pid != pg_backend_pid();

The pid != pg_backend_pid() condition prevents you from terminating your own connection.

4Drop or alter the object

Once all conflicting sessions are closed, perform your operation:

sql
DROP DATABASE your_database_name;

Or for tables:

sql
DROP TABLE your_table;

If the object has dependencies, use CASCADE carefully:

sql
DROP TABLE your_table CASCADE;
5Schedule maintenance during low-activity windows

To minimize impact in production environments, perform database restructuring (dropping databases, tables, or schemas) during scheduled maintenance windows when activity is lowest. Monitor connection counts:

sql
SELECT datname, count(*) as connections
FROM pg_stat_activity
GROUP BY datname
ORDER BY connections DESC;

Plan schema changes when there are fewest connections to your database.

Advanced notes

PostgreSQL uses a sophisticated locking system to prevent concurrent modification conflicts. The "Object in use" error belongs to SQLSTATE class 55 (Object Not In Prerequisite State), which includes related errors like lock_not_available (55P03) and cant_change_runtime_param (55P02).

In high-concurrency environments, consider using ALTER DATABASE ... SET lock_timeout to automatically cancel long-running queries that hold locks:

sql
ALTER DATABASE your_database SET lock_timeout = '10s';

For rolling schema upgrades in production, use PostgreSQL's concurrent DDL capabilities:
- CREATE INDEX CONCURRENTLY (allows reads/writes during index creation)
- DROP INDEX CONCURRENTLY (creates placeholder index before dropping)

These avoid full table locks that trigger "Object in use" errors.

If you regularly encounter this error during automated testing (e.g., Rails test setup), ensure your test database connections are properly closed before attempting to drop the database. Many frameworks provide helpers like database.drop that handle this.

Frequently asked questions

What does "55006" mean?
PostgreSQL enforces object state prerequisites to maintain data integrity. The "Object in use" error (SQLSTATE 55006) is part of the "Object Not In Prerequisite State" error class, meaning you're attempting an operation on an object that is not in the required state. Specifically, the object is currently being accessed, locked, or held by another transaction or session, which prevents the operation (typically DROP or ALTER) from completing safely.
How do I fix "55006"?
The PostgreSQL error 55006 (object_in_use) occurs when you attempt to drop or modify a database object that is currently being accessed by another session. Terminate conflicting connections or wait for the object to become available.
What causes "55006"?
Other database sessions actively using or querying the object you are trying to drop or modify Background processes like autovacuum holding locks on the target object Idle connections holding open transactions that locked the object
Is the "55006" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading