select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / DEVELOPER OPTIONS

send_abort_for_kill

Read PG 18 manual ↗

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.

Type
bool
Context
sighup
Measured default
off
Unit
Metadata snapshot
18

Definition PG 18 manual

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.

Measured default history
Version intervalDefault
16 – 19off
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

When a child does not exit after SIGQUIT, the postmaster normally escalates to SIGKILL after five seconds. send_abort_for_kill uses SIGABRT instead so the stuck child normally writes a core dump.

SIGABRT provides forensic state but can take time and disk space, potentially delaying crash recovery. It is not guaranteed to terminate as promptly as SIGKILL in every failure mode.

PostgreSQL does not clean generated cores. OS policy and monitoring must prevent repeated stuck processes from filling storage. Its SIGHUP context allows configuration reload without a server restart.

Operational considerations

Leaving send_abort_for_kill enabled after the bounded diagnostic or recovery task.

Running the experiment on the only copy of production data.

Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.

Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Workload guidance

OLAP: Long analytical runs can amplify send_abort_for_kill's debug overhead and artifacts. Prefer standard EXPLAIN and statistics first, and isolate any developer experiment from normal users.

OLTP: Do not tune production OLTP with send_abort_for_kill. Enable it only for a bounded reproduction with an owner, log/disk budget, rollback condition, and evidence-capture plan; restore the default immediately afterward.

SMALL: Keep send_abort_for_kill at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.

Version history 1
  1. PG 15 → 16added

Related entries

Further reading

Definition snapshot: english-manuals:92987dc32109315fa9eb9c30d2e… · English manual source