Incident brief
Too many connections
A non-superuser connection attempt arrived after every non-reserved connection slot was already in use. PostgreSQL rejected it so the reserved slots stay available for superuser roles.
In 10 seconds
- What
- Too many connections
- What triggers it
- With max_connections = 100 and superuser_reserved_connections = 3 (both defaults), open 97 connections with a non-superuser role and hold them open.
- The fix
- Raise max_connections (requires a restart) if the application genuinely needs more concurrent connections.
- Proof
- Reproduced on PostgreSQL 16.14 → With every non-reserved connection slot (97 of 100, since 3 are reserved for superusers) held open by a non-superuser role, one more connection attempt with that role was rejected with SQLSTATE 53300.
The fix
What to do right now
The immediate, application-level response to this error.
- Raise max_connections (requires a restart) if the application genuinely needs more concurrent connections.
- Put a connection pooler (e.g. PgBouncer) in front of PostgreSQL so application connections are reused instead of each request opening a new one.
- Don't 'fix' this by lowering superuser_reserved_connections to 0 — see the premium counterexample for exactly what that gives up.
-- Example direction: front the application with a pooler instead of connecting directly.
-- max_connections = 100 -- unchanged
-- superuser_reserved_connections = 3 -- unchanged, keeps an admin path open
SELECT 1 AS use_a_connection_pooler_in_production;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 — Connection Settings (19.3)
superuser_reserved_connections ... Determines the number of connection 'slots' that are reserved for connections by roles with the SUPERUSER attribute.Read the full section on postgresql.org →
Confirming 97 connections are held
max_connections is 100 and superuser_reserved_connections is 3, so 97 slots are available to ordinary roles — this confirms all 97 are in use before the next attempt.The 98th connection attempt (rejected)
With every non-reserved slot in use, PostgreSQL rejects any further non-superuser connection attempt with SQLSTATE 53300, keeping the 3 reserved slots free.Reproduce & verify
A real reproduction with every non-reserved slot exhausted
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab — the commands below are exactly what was executed.
- 1With max_connections = 100 and superuser_reserved_connections = 3 (both defaults), open 97 connections with a non-superuser role and hold them open.
- 2Attempt one more connection with that same non-superuser role.
- 3SQLSTATE 53300 is reported: the remaining slots are reserved for superuser roles.
97 real connections held open by a non-superuser role (100 max_connections minus 3 superuser_reserved_connections), then one more connection attempted with the same role.
CREATE ROLE batch8_conn_test_user LOGIN PASSWORD 'test123';
-- then 97 background connections, each holding: SELECT pg_sleep(30);SELECT count(*) FROM pg_stat_activity WHERE usename = 'batch8_conn_test_user';psql -U batch8_conn_test_user -d thesev1database -c "SELECT 1;"What PostgreSQL actually returned
CREATE ROLE count
-------
97
(1 row)psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: remaining connection slots are reserved for roles with the SUPERUSER attributeThe deeper lab audit for this error
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