log_truncate_on_rotation

log_truncate_on_rotation is the PostgreSQL setting that controls whether PostgreSQL truncates existing log files of same name during log rotation.

Note

Fact — official short description: “Truncate existing log files of same name during log rotation.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueReporting and Logging / Where to Log: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–19 Beta 3	`off`	—	off

How it works

log_truncate_on_rotation truncates existing log files of same name during log rotation. Truncation occurs when time-based rotation reuses an existing filename; size rotation and other causes do not apply the same overwrite rule.

log_truncate_on_rotation is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The active path is composed from log_destination, logging_collector or syslog/eventlog, file naming and permissions, rotation triggers, and external shipping or retention.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Enable log_truncate_on_rotation only when time-based rotation intentionally reuses a filename and the previous file has been durably shipped or is meant to be replaced. Leave it off for unique timestamped names.
OLAP	For analytical logs, confirm that long-running ingestion has finished before a repeating name is truncated; use unique names when completion cannot be guaranteed.
Small nodes	A short repeating cycle can bound disk use, but truncation is not retention management. Monitor shipping and backups so the next time rotation cannot erase the only copy.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`on`	different	`'on'`
OLAP	`on`	different	`'on'`
CRIT	`on`	different	`'on'`
TINY	`on`	different	`'on'`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = on (dcs); OLAP: PG9.0–19 Beta 3 = on (dcs); CRIT: PG9.0–19 Beta 3 = on (dcs); TINY: PG9.0–19 Beta 3 = on (dcs). Advice, pending human review — Editorial inference: Truncation closes the weekday filename cycle so a reused daily name replaces the prior week’s file instead of appending forever.

Common pitfalls

Editing log_truncate_on_rotation without reloading configuration and verifying the effective value and subsequent behavior.
Combining incompatible destination, collector, filename, and rotation assumptions and then losing or overwriting logs.
Failing to monitor a full or unwritable log target, which can block logging or database activity depending on the path.
Expecting truncation on every rotation path; it is tied to time-based reuse of an existing filename.

logging_collector · log_destination · log_directory · log_filename · log_rotation_age · log_rotation_size