remove_temp_files_after_crash

Definition PG 18 manual

When set to on, which is the default, PostgreSQL will automatically remove temporary files after a backend crash. If disabled, the files will be retained and may be used for debugging, for example. Repeated crashes may however result in accumulation of useless files. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

After a backend crash, remove_temp_files_after_crash controls whether PostgreSQL removes temporary files left by the failed process. on is the normal cleanup behavior.

Turning it off preserves artifacts for forensic debugging but repeated failures can accumulate useless files and exhaust the temporary-file file systems.

The setting does not prevent a crash, recover query state, or retain ordinary temporary tables for reuse. Any forensic retention needs explicit space monitoring and later cleanup. Its SIGHUP context allows configuration reload without a server restart.

Operational considerations

Leaving remove_temp_files_after_crash 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 remove_temp_files_after_crash'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 remove_temp_files_after_crash. 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 remove_temp_files_after_crash at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.