send_abort_for_crash — PostgreSQL configuration parameter

By default, after a backend crash the postmaster will stop remaining child processes by sending them SIGQUIT signals, which permits them to exit more-or-less gracefully.

At a glance

What it does

By default, after a backend crash the postmaster will stop remaining child processes by sending them SIGQUIT signals, which permits them to exit more-or-less gracefully. When this option is set to on, SIGABRT is sent instead. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of other processes after a crash. 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_crash; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'send_abort_for_crash';.

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.

Reference

PostgreSQL documentation — send_abort_for_crash.