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.
What lands in your log
ERROR: database "reporting_snapshot" is being accessed by other users
In 10 seconds
- What triggers it
- Session A connects to the target database and stays connected.
- 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.
Fix
What to do right now
Application-level steps for 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);For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
55006 names an object that still has live users. Find sessions/locks for that object and coordinate shutdown rather than forcing a blind drop.
Database sessions that prevent DROP DATABASE
For database-level 55006, list every other backend connected to the current database.
SELECT pid, usename, application_name, client_addr, state,
now() - backend_start AS connected_for
FROM pg_stat_activity
WHERE datname = current_database()
AND pid <> pg_backend_pid()
ORDER BY backend_start;Locks on the named relation
Replace the relation literal for table/index 55006 variants.
SELECT l.pid, l.mode, l.granted, a.application_name,
now() - a.xact_start AS transaction_age, left(a.query, 120) AS query
FROM pg_locks l
JOIN pg_stat_activity a ON a.pid = l.pid
WHERE l.relation = to_regclass('<schema.relation>')
ORDER BY l.granted, a.xact_start;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.
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.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that doesn't disconnect anyone already connected: 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.
- Detect and resolve lock contentionQueries hang with no error and no progress, and you need the wait graph now.Free
- Measure and fence a Patroni failoverYou have never timed failover, proved the old primary is fenced, or verified client routing.Free
- hot_standby_feedback and the bloat it buysReplica queries stopped dying and the primary quietly stopped reclaiming space.Pro
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
Detect and resolve lock contentionRebuild a bloated index with REINDEX CONCURRENTLYRecover from a failed CREATE INDEX CONCURRENTLYWatch CREATE INDEX CONCURRENTLY progresshot_standby_feedback and the bloat it buysKeep ALTER TABLE from blocking your appMeasure and fence a Patroni failoverMonitor a CLUSTER or VACUUM FULL rewriteReclaim table bloat: plain VACUUM vs VACUUM FULLReclaim WAL held by an inactive replication slotStop a logical slot on a quiet database pinning WALStop an abandoned slot from filling the diskMonitor VACUUM progress on a large tableRead logical decoding lag from the spill countersShrink TOAST bloat from wide rowsRelated 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.