How to fix Crash shutdown in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 28, 2025· 169 views

PostgreSQL crash shutdown (57P02) occurs when the server crashes and terminates all client connections during recovery. The server automatically restarts and replays the write-ahead log (WAL) to restore data integrity.

Quick fix

Fixes 57P02

# On Linux, typically:
tail -f /var/log/postgresql/postgresql.log

# Or in the data directory:
tail -f /var/lib/postgresql/[VERSION]/main/log/postgresql.log
  1. Check PostgreSQL logs for root cause
  2. Check available disk space
  3. Allow PostgreSQL to automatically recover
  4. Verify database integrity after recovery
postgresql — error
# On Linux, typically:
tail -f /var/log/postgresql/postgresql.log
# Or in the data directory:
tail -f /var/lib/postgresql/[VERSION]/main/log/postgresql.log
Crash shutdown

What this error means

A crash shutdown error occurs when the PostgreSQL server has unexpectedly terminated due to a backend process crash, an out-of-memory condition, a segmentation fault, or a disk I/O failure. When this happens, the postmaster (PostgreSQL main process) detects the crash and immediately terminates all existing client connections to prevent data corruption. The error message "57P02: terminating connection because of crash of another server process" is displayed to each connected client. This is actually a protective mechanism—PostgreSQL automatically initiates crash recovery on the next startup by replaying the write-ahead log (WAL) to restore the database to a consistent state.

Typical symptoms

  • Client connections are suddenly terminated with error code 57P02
  • PostgreSQL server process is not responsive
  • Application gets disconnected from the database unexpectedly
  • Database logs show "database system was interrupted while in recovery"
  • Server automatically restarts with recovery messages
  • Connections fail with "cannot_connect_now" or connection timeout errors

Common causes

  1. Backend process crash due to a segmentation fault or memory corruption (most common)
  2. Out-of-memory (OOM) condition forcing the kernel to kill processes
  3. Disk I/O failure or corrupted data files
  4. Insufficient disk space during WAL replay
  5. Unclean shutdown (kill -9) instead of graceful pg_ctl stop
  6. Hardware failure or kernel panic
  7. Bug in PostgreSQL code or extensions

How to fix "Crash shutdown"

1Check PostgreSQL logs for root cause

Examine the PostgreSQL server logs to identify what caused the crash. Look for segmentation faults, out-of-memory messages, or disk errors.

bash
# On Linux, typically:
tail -f /var/log/postgresql/postgresql.log

# Or in the data directory:
tail -f /var/lib/postgresql/[VERSION]/main/log/postgresql.log

Look for messages like:
- "Segmentation fault"
- "Out of memory"
- "Connection lost unexpectedly"
- "Invalid page header"

2Check available disk space

Insufficient disk space is a common cause. Verify there is enough space for recovery and WAL replay.

bash
df -h
# Check the partition where PostgreSQL data directory is located

# Check the size of the WAL files:
du -sh /var/lib/postgresql/[VERSION]/main/pg_wal/

Ensure at least 20-30% of disk space is free before restarting.

3Allow PostgreSQL to automatically recover

By default, PostgreSQL is configured with restart_after_crash = on, which means it will automatically restart and perform crash recovery.

bash
# Start/restart PostgreSQL (it will auto-recover):
sudo systemctl restart postgresql

# Or using pg_ctl:
sudo -u postgres pg_ctl restart -D /var/lib/postgresql/[VERSION]/main

Watch the logs as it replays the WAL:

bash
tail -f /var/log/postgresql/postgresql.log | grep -i recovery

Wait for the message: "database system is ready to accept connections"

4Verify database integrity after recovery

Once recovery completes and the server is running, verify the integrity of critical tables.

bash
sudo -u postgres psql

-- Check for corruption:
REINDEX DATABASE postgres;

-- Run integrity checks on specific tables:
CHECK TABLE your_table_name;

-- Monitor recovery progress:
SELECT pg_is_in_recovery();

If any tables show corruption, restore from your backup.

5Investigate and fix underlying cause

Once the server is stable, identify the root cause to prevent future crashes.

For OOM crashes:

bash
# Check memory usage and set appropriate limits:
free -h

# Adjust PostgreSQL shared_buffers if necessary (in postgresql.conf):
shared_buffers = 256MB  # For 4GB RAM server

# Restart PostgreSQL for changes to take effect:
sudo systemctl restart postgresql

For segmentation faults:
- Check PostgreSQL version: SELECT version();
- Update to the latest stable version if you're on an old version
- Report the crash dump to PostgreSQL developers if it's reproducible

For disk I/O failures:
- Run disk diagnostics: sudo smartctl -a /dev/sda
- Check filesystem integrity: sudo fsck /mount/point (unmount first)
- Replace faulty hardware if needed

6Configure crash recovery settings (optional)

By default, PostgreSQL is configured well for crash recovery. However, you can verify these settings:

bash
sudo -u postgres psql

-- View recovery settings:
SHOW restart_after_crash;
SHOW wal_level;
SHOW max_wal_senders;  -- For replication

Recommended settings in postgresql.conf:

conf
# Ensure automatic recovery is enabled
restart_after_crash = on

# Use WAL archiving for faster recovery
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'

Reload the configuration:

bash
sudo -u postgres psql -c "SELECT pg_reload_conf();"

Advanced notes

Crash shutdown (57P02) is distinct from graceful shutdowns (57P01 - admin shutdown). The 57P02 error itself is not a problem—it's actually PostgreSQL's way of protecting data integrity. The real issue is what caused the crash in the first place.

Key recovery mechanisms:
- WAL Replay: PostgreSQL uses write-ahead logging to ensure durability. After a crash, it replays the WAL to recover committed transactions.
- Checkpoint: Periodic checkpoints create safe points in the database. Recovery only needs to replay changes after the last checkpoint.
- Data Page Verification: PostgreSQL can verify data page integrity during recovery using checksums (if enabled).

For production systems:
- Always maintain backups and test restore procedures regularly.
- Monitor disk space and system resources closely.
- Enable wal_level = replica and archive WAL files to another location for point-in-time recovery (PITR).
- Set up monitoring/alerting for OOM conditions, disk full errors, and log patterns indicating crashes.
- Use pg_basebackup for physical backups or logical backups with pg_dump for additional redundancy.
- Consider high availability solutions like Patroni or replication to a standby server.

Frequently asked questions

What does "57P02" mean?
A crash shutdown error occurs when the PostgreSQL server has unexpectedly terminated due to a backend process crash, an out-of-memory condition, a segmentation fault, or a disk I/O failure. When this happens, the postmaster (PostgreSQL main process) detects the crash and immediately terminates all existing client connections to prevent data corruption. The error message "57P02: terminating connection because of crash of another server process" is displayed to each connected client.
How do I fix "57P02"?
PostgreSQL crash shutdown (57P02) occurs when the server crashes and terminates all client connections during recovery. The server automatically restarts and replays the write-ahead log (WAL) to restore data integrity.
What causes "57P02"?
Backend process crash due to a segmentation fault or memory corruption (most common) Out-of-memory (OOM) condition forcing the kernel to kill processes Disk I/O failure or corrupted data files
Is the "57P02" 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