This error appears when PostgreSQL is in the process of shutting down and rejects new connection attempts. It typically occurs during planned maintenance, restarts, or server failures. Fix by verifying the server status, waiting for the shutdown to complete, or investigating why an unexpected shutdown occurred.
When PostgreSQL receives a shutdown signal (SIGTERM, SIGQUIT, or administrator command), it enters a shutdown state where it stops accepting new connections and waits for existing connections to close. This FATAL error is returned to any client attempting to connect during this window. The error with code 57P03 indicates a specific server rejection reason. The shutdown state is temporary - once the database finishes shutting down and restarts, new connections will be accepted again. The error can also occur if recovery is in progress after a crash or improper shutdown.
First, verify whether the server is actually running and in what state:
sudo systemctl status postgresqlOr if using a custom installation:
pg_isready -h localhost -p 5432The output will indicate:
- accepting connections - server is running and ready
- rejecting connections - server is running but not ready (startup/shutdown)
- no response - server is down
If the shutdown was intentional, the database will complete within seconds or minutes depending on:
- Shutdown mode (smart, fast, or immediate)
- Number of active connections
- Any long-running transactions
Monitor the PostgreSQL log for completion:
sudo tail -f /var/log/postgresql/postgresql-*.logLook for the message LOG: database system is shut down which indicates completion. Then restart the service:
sudo systemctl start postgresqlIf the shutdown was unexpected, examine the logs for root causes:
sudo tail -100 /var/log/postgresql/postgresql-*.logLook for messages like:
- LOG: database system was not properly shut down - indicates a crash
- LOG: starting crash recovery - recovery is in progress
- ERROR: out of memory - resource exhaustion
- WARNING: terminating connection because of crash - another process crashed
Crash recovery may take several minutes on large databases. Do not interrupt this process.
Unexpected shutdowns can occur when the system runs out of disk space or memory:
# Check disk space
df -h /var/lib/postgresql
# Check available memory
free -h
# Check CPU load
uptimeIf disk space is critically low (95%+), delete old logs and backups:
sudo find /var/log/postgresql -name "*.log" -mtime +7 -deleteIf memory is exhausted, consider increasing available RAM or adjusting PostgreSQL memory settings in postgresql.conf:
shared_buffers = 256MB # Conservative for limited memoryIn replication setups (primary/standby), high network latency or slow standbys can trigger walsender timeouts, causing shutdown:
sudo -u postgres psql -c "SHOW wal_sender_timeout;"
sudo -u postgres psql -c "SHOW wal_receiver_timeout;"Default is 60 seconds. If your standby is slow or the network is unreliable, increase these values in postgresql.conf:
wal_sender_timeout = 300s # increased from 60s
wal_receiver_timeout = 300sThen reload the configuration:
sudo systemctl reload postgresqlTo avoid future slow shutdowns during maintenance:
1. Before shutting down, run a manual checkpoint to flush data to disk:
sudo -u postgres psql -c "CHECKPOINT;"2. Then perform a fast shutdown (which will be quick since checkpoint is done):
sudo systemctl stop postgresqlAlternatively, use pg_ctl with explicit mode:
sudo -u postgres pg_ctl -D /var/lib/postgresql/[version]/main stop -m fastAvoid immediate mode unless absolutely necessary, as it forces recovery on next startup.
Error code 57P03 is specifically for ERRCODE_CANNOT_CONNECT_NOW. In Docker environments, this error commonly appears during container shutdown sequences when the database is still running. Ensure Docker health checks have appropriate timeouts and that shutdown signals (SIGTERM) are handled gracefully. For applications using connection pooling (PgBouncer, pgpool-II), verify these are configured with idle_in_transaction_session_timeout to automatically close idle connections, preventing them from blocking shutdown. In AWS RDS, this error during failover is normal and expected - connections will be rejected for 1-5 minutes during failover. Applications should implement exponential backoff retry logic when seeing this error. For Kubernetes deployments, ensure preStop hooks give PostgreSQL adequate time to shut down (typically 30-60 seconds). Transaction ID wraparound can also trigger unwanted shutdowns if the database enters 'no_more_connections' mode - monitor autovacuum_naptime and run VACUUM ANALYZE regularly to prevent this.
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL
ERROR 42501: must be owner of table
How to fix "must be owner of table" in PostgreSQL
trigger cannot change partition destination
How to fix "Trigger cannot change partition destination" in PostgreSQL
SSL error: certificate does not match host name
SSL error: certificate does not match host name in PostgreSQL
No SSL connection
No SSL connection to PostgreSQL