PostgreSQL 53400 Error: Causes and Solutions Complete Guide

PostgreSQL Error 53400: Configuration Limit Exceeded

PostgreSQL error code 53400 (configuration_limit_exceeded) occurs when the database server hits a hard limit defined by its configuration parameters. This is a server-level resource exhaustion error — not a query mistake — meaning it can impact all clients connected to the server simultaneously. Immediate action is required to restore normal operations.

---

Top 3 Causes

1. Exceeding max_connections

The most common trigger. When all connection slots are consumed, new clients are refused with this error.

-- Check current connection usage
SELECT 
    count(*) AS current_connections,
    (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max_allowed,
    round(count(*) * 100.0 /
        (SELECT setting::int FROM pg_settings WHERE name = 'max_connections'), 2) AS pct_used
FROM pg_stat_activity;

-- Identify and kill long-running idle connections
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
  AND state_change < now() - interval '10 minutes'
  AND pid <> pg_backend_pid();

2. Exceeding max_locks_per_transaction

Each transaction can hold a limited number of locks. Workloads involving hundreds of partitioned tables or large batch DDL operations frequently breach this limit.

-- View current lock activity
SELECT 
    locktype,
    relation::regclass AS table_name,
    mode,
    granted,
    pid
FROM pg_locks
WHERE relation IS NOT NULL
ORDER BY granted ASC;

-- Check and update the setting (requires restart)
SHOW max_locks_per_transaction;
ALTER SYSTEM SET max_locks_per_transaction = 256;

3. Stale Prepared Transactions Exceeding max_prepared_transactions

In two-phase commit (2PC) workflows, uncommitted prepared transactions accumulate and exhaust the limit. The default value is 0, which means 2PC is disabled unless explicitly configured.

-- List all prepared transactions and their age
SELECT 
    gid,
    owner,
    database,
    now() - prepared AS age
FROM pg_prepared_xacts
ORDER BY prepared;

-- Clean up stale prepared transactions
ROLLBACK PREPARED 'your_transaction_id_here';

-- Or commit them if appropriate
COMMIT PREPARED 'your_transaction_id_here';

---

Quick Fix Solutions

1. Kill idle connections using pg_terminate_backend() as shown above.
2. Increase limits temporarily with ALTER SYSTEM SET and reload:

-- Increase max_connections (requires full restart)
ALTER SYSTEM SET max_connections = 500;

-- Set timeouts to auto-clean stuck sessions
ALTER SYSTEM SET idle_in_transaction_session_timeout = '10min';
ALTER SYSTEM SET statement_timeout = '30min';

-- Reload configuration
SELECT pg_reload_conf();

1. Deploy PgBouncer between your app and PostgreSQL to multiplex thousands of application connections into a manageable number of real database connections.

---

Prevention Tips

• Monitor proactively. Set up alerts when connection usage exceeds 80% of max_connections. Use tools like Prometheus with postgres_exporter or AWS CloudWatch RDS metrics to catch problems before they become outages.

-- Use this as a health-check query in your monitoring pipeline
SELECT 
    CASE 
        WHEN (count(*) * 100.0 /
              (SELECT setting::int FROM pg_settings WHERE name = 'max_connections')) > 80
        THEN 'CRITICAL'
        ELSE 'OK'
    END AS health_status
FROM pg_stat_activity;

• Always use a connection pooler and enforce session hygiene. Configure idle_in_transaction_session_timeout and statement_timeout at the database level so runaway sessions are automatically terminated. Ensure application code always closes connections explicitly using try/finally or context manager patterns.

---

Related Errors

Code	Name	Relation
53000	insufficient_resources	Parent error class for all resource exhaustion
53100	disk_full	Disk-level resource exhaustion
53200	out_of_memory	Memory exhaustion, related to work_mem/shared_buffers
57P03	cannot_connect_now	Server refusing connections during startup/recovery

---

📖 Want a more detailed guide?
Check out the full in-depth version (Korean) on oraerror.com — includes detailed analysis, additional SQL examples, and prevention tips.