The server closed your session because an administrator issued a fast or immediate shutdown command.
PostgreSQL Error 57P01 (admin_shutdown) signals that the server is shutting down after an administrator command. All active connections are force-closed. Wait for the server to restart or cancel the shutdown, then reconnect to fix the problem.
PostgreSQL Error 57P01 (admin_shutdown)
Error 57P01, condition name admin_shutdown, is a fatal PostgreSQL error that terminates client connections because the server is shutting down at an administrator’s request.
The message appears when a fast, smart, or immediate shutdown is issued through pg_ctl, systemd, or another service manager. Active sessions are disconnected to let PostgreSQL close cleanly.
A manual pg_ctl stop, systemctl stop postgresql, or AWS RDS reboot triggers admin_shutdown.
PostgreSQL signals backends to end immediately.
Operating-system shutdown or container redeploys also invoke orderly database shutdown, generating the same SQLSTATE for connected clients.
First, confirm whether the shutdown was intended. If you meant to restart PostgreSQL, simply wait until the service returns and reconnect.
If the shutdown was accidental, cancel it quickly with pg_ctl reload or by restarting the service, then reconnect clients.
Automated patching windows often stop PostgreSQL.
Schedule downtime and notify users to avoid surprise terminations.
In a Kubernetes deployment, liveness-probe failures may restart pods. Tune probes or resource limits to keep the server alive.
Use smart shutdowns during maintenance windows so active transactions finish gracefully. Monitor pg_stat_activity to ensure no critical work is lost.
Implement connection retry logic in applications and connection pools.
Galaxy’s editor automatically retries transient disconnects, keeping your workflow smooth.
57P02 (crash_shutdown) - Server crashed, not a planned shutdown. Investigate logs for segmentation faults.
53300 (too_many_connections) - Server still running but can’t accept new sessions. Increase max_connections or use a pool.
.
No. PostgreSQL finishes checkpoints before shutting down, so committed data is safe. Uncommitted transactions roll back.
Smart shutdown waits for all sessions to finish. Duration depends on active queries. Monitor pg_stat_activity to gauge progress.
The message level is FATAL and cannot be fully suppressed, but you can reduce client-side visibility by handling exceptions gracefully.
Galaxy’s SQL editor detects lost connections, auto-retries queries, and shows clear alerts, reducing workflow interruption during planned restarts.
.avif)
.avif){kind=logo}
