Parameter · Error Handling
restart_after_crash
Reinitialize server after backend crash.
- Default:
on - Type: bool
- Applies: Reload
In plain words
If any PostgreSQL process crashes (killed by the OOM killer, a segfault in an extension …), shared memory may be corrupt, so the postmaster stops all sessions. With restart_after_crash = on (default) it then reinitializes shared memory, replays WAL and accepts connections again, usually within seconds. With off it shuts the whole server down instead.
Turn it off only when cluster software (for example Patroni or Pacemaker) should decide what happens next, such as failing over.
For DBAs and operators
The crash sequence in the log:
LOG: client backend (PID 31337) was terminated by signal 9: Killed
DETAIL: Failed process was running: SELECT …
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was not properly shut down; automatic recovery in progress
With off: LOG: shutting down because "restart_after_crash" is off. Every connected client loses its session either way; uncommitted work is rolled back, committed work is safe (WAL).
Support notes
signal 9: Killedmeans the process receivedSIGKILL. On Linux an OOM killer is a common cause, but administrators, service managers and container runtimes can also send it; check kernel and service logs before concluding why it happened.- A process that exits with an unexpected exit code (not just a signal) also triggers this.
- Recovery time depends on WAL since the last checkpoint (
checkpoint_timeout,max_wal_size) and on recovery_init_sync_method. - Killing a backend with
kill -9causes this restart for everyone; usepg_terminate_backend()instead.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Postmaster Crash recovery Process model Server startup sequence
Related parameters
recovery_init_sync_method data_sync_retry exit_on_error checkpoint_timeout