Incident brief
Object in use
A DROP DATABASE was attempted while another session was still connected to that database. PostgreSQL refused to drop it out from under an active connection.
In 10 seconds
- What
- Object in use
- What triggers it
- Session A connects to the target database and stays connected.
- The fix
- Disconnect (or wait for) every other session connected to the target database, then DROP DATABASE.
- Proof
- Reproduced on PostgreSQL 16.14 → DROP DATABASE on a database with one other active connection was rejected with SQLSTATE 55006, naming exactly one other session.
The fix
What to do right now
The immediate, application-level response to this error.
- Disconnect (or wait for) every other session connected to the target database, then DROP DATABASE.
- Or use DROP DATABASE ... WITH (FORCE) (PostgreSQL 13+) to have PostgreSQL terminate those connections itself.
- Setting CONNECTION LIMIT 0 does not disconnect anyone already connected — see the counterexample.
DROP DATABASE reporting_snapshot WITH (FORCE);Diagnose
See it live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Standard triage — not specific to this error
These are canonical PostgreSQL system-catalog queries, shown as SQL to run. No sample output is attached because this is general triage, not a captured lab transcript.This SQLSTATE does not have an error-specific live snapshot yet. These are the canonical system-catalog queries you run against the affected server to see the problem in real time — standard triage, not a reproduced transcript.
What is running right now
Active backends, how long each has been running, and what it is waiting on.
SELECT pid,
state,
wait_event_type,
wait_event,
now() - query_start AS running_for,
left(query, 80) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
AND pid <> pg_backend_pid()
ORDER BY running_for DESC NULLS LAST;Who is blocking whom
Turn raw blocking PIDs into the actual queries on both sides of the wait.
SELECT blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query
FROM pg_stat_activity AS blocked
JOIN LATERAL unnest(pg_blocking_pids(blocked.pid)) AS b(pid) ON true
JOIN pg_stat_activity AS blocking ON blocking.pid = b.pid
WHERE cardinality(pg_blocking_pids(blocked.pid)) > 0;Locks that are still waiting
Every lock a backend has requested but not yet been granted.
SELECT l.pid,
l.locktype,
l.mode,
l.granted,
COALESCE(c.relname, l.transactionid::text) AS object
FROM pg_locks l
LEFT JOIN pg_class c ON c.oid = l.relation
WHERE NOT l.granted
ORDER BY l.pid;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual — not paraphrased.
PostgreSQL 16 Documentation — DROP DATABASE
if anyone else is connected to the target database, this command will fail unless you use the FORCE optionRead the full section on postgresql.org →
Session A — stays connected to the target database
Session A is just an ordinary, idle connection to reporting_snapshot — nothing unusual about it.Session B — the blocked DROP DATABASE
PostgreSQL refused to drop a database that still has an active connection, and told session B exactly how many other sessions were the reason (1).Reproduce & verify
A real, two-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.
- 1Session A connects to the target database and stays connected.
- 2Session B tries to DROP DATABASE on that same target.
- 3SQLSTATE 55006 is reported, naming how many other sessions are connected.
Session A stays connected to the target database. Session B tries to drop that same database.
DROP DATABASE IF EXISTS reporting_snapshot;
CREATE DATABASE reporting_snapshot;-- connected to reporting_snapshot
SELECT pg_sleep(15);-- connected to a different database
DROP DATABASE reporting_snapshot;What PostgreSQL actually returned
DROP DATABASE
CREATE DATABASE pg_sleep
----------
(1 row)ERROR: database "reporting_snapshot" is being accessed by other users
DETAIL: There is 1 other session using the database.A common first instinct is to set CONNECTION LIMIT 0 to 'lock out' the database before dropping it. That was tested directly against the same still-connected session A. DROP DATABASE ... WITH (FORCE) was then tested against the same situation as the actual fix.
Use DROP DATABASE ... WITH (FORCE) while session A is still connected.
Without this
Above: DROP DATABASE fails while session A is connected.
With this, tested
Below: DROP DATABASE ... WITH (FORCE) succeeds and disconnects session A itself.
What Pro unlocks here
- The exact prevention SQL — copy-paste ready
- Raw psql output captured from the Docker lab
- A senior-DBA action list to take it further
- Live monitoring queries to catch it in production
- The deeper audit: fix-that-fails counterexample, GUC before/after, server-log evidence
Related & next steps
Follow the thread
Everything this error touches — jump straight to the sibling error, term, runbook, or parameter.
Related errors
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Reviewed by
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed