By default, after attempting to stop a child process with SIGQUIT, the postmaster will wait five seconds and then send SIGKILL to force immediate termination.
At a glance
| Property | Value |
|---|---|
| Parameter | send_abort_for_kill |
| Category | Developer Options |
| Default | (see documentation) |
| Value type | boolean (on/off) |
| Change scope | Reload (postgresql.conf, SIGHUP) |
| Available in | PostgreSQL 16, 17, 18, 19 (added in 16) |
What it does
By default, after attempting to stop a child process with SIGQUIT, the postmaster will wait five seconds and then send SIGKILL to force immediate termination. When this option is set to on, SIGABRT is sent instead of SIGKILL. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of “stuck” child processes. It can also consume lots of disk space in the event of repeated crashes, so do not enable this on systems you are not monitoring carefully. Beware that no support exists for cleaning up the core file(s) automatically. This parameter can only be set in the postgresql.conf file or on the server command line.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.
Inspect the current value and source with SHOW send_abort_for_kill; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'send_abort_for_kill';.
Tuning guidance
This is a developer and debugging aid, not a performance knob. Leave it at the default in production; enable it only temporarily, on a non-production or carefully controlled system, while diagnosing a specific problem. Several options in this group add overhead, generate large volumes of log output, or can damage data if misused — turn them off again as soon as the investigation is done.