How to fix FATAL: the database system is shutting down in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 26, 2025· 269 views

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.

Quick fix

Fixes FATAL: the database system is shutting down

sudo systemctl status postgresql
  1. Check PostgreSQL server status
  2. Wait for shutdown to complete if in progress
  3. Check PostgreSQL logs for crash indicators
  4. Verify disk space and system resources
postgresql — error
sudo systemctl status postgresql
FATAL: the database system is shutting down

What this error means

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.

Typical symptoms

  • All connection attempts fail with the 57P03 FATAL error
  • Error appears immediately after issuing shutdown commands
  • Server log shows no other errors before the FATAL message
  • Connections fail during known maintenance windows
  • Once the database restarts, connections work normally
  • In replication setups, standby nodes fail to connect to the master

Common causes

  1. Planned shutdown: administrator issued SIGTERM or pg_ctl stop command
  2. Maintenance restart: scheduled upgrades or configuration changes
  3. Unexpected server crash requiring recovery
  4. Out of memory or system resource exhaustion triggering shutdown
  5. Replication timeout (wal_sender_timeout or wal_receiver_timeout exceeded)
  6. Improper shutdown from previous crash forcing recovery on startup
  7. Long-running transaction or backup operation preventing shutdown completion

How to fix "FATAL: the database system is shutting down"

1Check PostgreSQL server status

First, verify whether the server is actually running and in what state:

bash
sudo systemctl status postgresql

Or if using a custom installation:

bash
pg_isready -h localhost -p 5432

The 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

2Wait for shutdown to complete if in progress

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:

bash
sudo tail -f /var/log/postgresql/postgresql-*.log

Look for the message LOG: database system is shut down which indicates completion. Then restart the service:

bash
sudo systemctl start postgresql
3Check PostgreSQL logs for crash indicators

If the shutdown was unexpected, examine the logs for root causes:

bash
sudo tail -100 /var/log/postgresql/postgresql-*.log

Look 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.

4Verify disk space and system resources

Unexpected shutdowns can occur when the system runs out of disk space or memory:

bash
# Check disk space
df -h /var/lib/postgresql

# Check available memory
free -h

# Check CPU load
uptime

If disk space is critically low (95%+), delete old logs and backups:

bash
sudo find /var/log/postgresql -name "*.log" -mtime +7 -delete

If memory is exhausted, consider increasing available RAM or adjusting PostgreSQL memory settings in postgresql.conf:

bash
shared_buffers = 256MB  # Conservative for limited memory
5Review configuration for replication timeout issues

In replication setups (primary/standby), high network latency or slow standbys can trigger walsender timeouts, causing shutdown:

bash
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:

bash
wal_sender_timeout = 300s      # increased from 60s
wal_receiver_timeout = 300s

Then reload the configuration:

bash
sudo systemctl reload postgresql
6Prevent slow shutdowns with manual checkpoints

To avoid future slow shutdowns during maintenance:

1. Before shutting down, run a manual checkpoint to flush data to disk:

bash
sudo -u postgres psql -c "CHECKPOINT;"

2. Then perform a fast shutdown (which will be quick since checkpoint is done):

bash
sudo systemctl stop postgresql

Alternatively, use pg_ctl with explicit mode:

bash
sudo -u postgres pg_ctl -D /var/lib/postgresql/[version]/main stop -m fast

Avoid immediate mode unless absolutely necessary, as it forces recovery on next startup.

Advanced notes

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.

Frequently asked questions

What does "FATAL: the database system is shutting down" mean?
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.
How do I fix "FATAL: the database system is shutting down"?
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.
What causes "FATAL: the database system is shutting down"?
Planned shutdown: administrator issued SIGTERM or pg_ctl stop command Maintenance restart: scheduled upgrades or configuration changes Unexpected server crash requiring recovery
Is the "FATAL: the database system is shutting down" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading