PostgreSQL raises error 53400 when a server-defined resource limit such as connections, locks, or replication slots is exhausted.
PostgreSQL Error 53400 – configuration_limit_exceeded occurs when a server limit like max_connections, max_locks_per_transaction, or max_replication_slots is hit. Raise the relevant setting in postgresql.conf and restart, or free resources to resolve the error.
PostgreSQL Error 53400
Error 53400 signals that a server-wide limit configured in postgresql.conf has been reached. PostgreSQL refuses the operation rather than risking instability.
The message text varies by subsystem. Examples include "too many connections", "too many replication slots", or "too many background workers". All map to the SQLSTATE code 53400.
Reaching max_connections is the most frequent trigger.
New sessions are blocked once all usable connection slots are filled.
Exceeding limits for replication slots, background workers, WAL senders, prepared transactions, advisory locks, or locks per transaction also throws 53400.
Identify which limit was hit with the accompanying message or by checking pg_stat_activity and pg_settings. Free resources or increase the relevant setting, then reload or restart the server.
For max_connections, terminate idle sessions or raise max_connections and shared_buffers proportionally.
For replication slots, drop unused slots or bump max_replication_slots.
Web applications leaking connections produce "too many connections". Implement pooling or shorter connection lifetimes to resolve.
Logical replication setups often exceed max_replication_slots.
Remove orphaned slots with pg_drop_replication_slot() or raise the limit.
Use a connection pooler like PgBouncer to cap active backend count well below max_connections.
Monitor pg_settings limits and actual usage with queries in Galaxy or cron jobs, then alert before thresholds are reached.
FATAL: remaining connection slots are reserved for non-replication superuser connections – happens just before 53400 on connections.
ERROR: cannot allocate memory for replication slot – memory pressure variant that may accompany slot limits.
.
No. It covers any configuration limit, including replication slots, locks, or background workers. Read the full message to know which limit triggered.
Some settings like max_locks_per_transaction and max_worker_processes require a restart. Others, such as max_replication_slots in v13+, can reload.
Start with connections = expected workload + 20% headroom. Use PgBouncer so max_connections rarely exceeds a few hundred.
Galaxya0shows live pg_stat_activity and pg_settings outputs in its editor, letting you spot approaching limits and adjust queries or settings proactively.
.avif)
.avif){kind=logo}
