log_truncate_on_rotation

Definition PG 18 manual

When logging_collector is enabled, this parameter will cause PostgreSQL to truncate (overwrite), rather than append to, any existing log file of the same name. However, truncation will occur only when a new file is being opened due to time-based rotation, not during server startup or size-based rotation. When off, pre-existing files will be appended to in all cases. For example, using this setting in combination with a log_filename like postgresql-%H.log would result in generating twenty-four hourly log files and then cyclically overwriting them. This parameter can only be set in the postgresql.conf file or on the server command line.

Example: To keep 7 days of logs, one log file per day named server_log.Mon, server_log.Tue, etc., and automatically overwrite last week's log with this week's log, set log_filename to server_log.%a, log_truncate_on_rotation to on, and log_rotation_age to 1440.

Example: To keep 24 hours of logs, one log file per hour, but also rotate sooner if the log file size exceeds 1GB, set log_filename to server_log.%H%M, log_truncate_on_rotation to on, log_rotation_age to 60, and log_rotation_size to 1000000. Including %M in log_filename allows any size-driven rotations that might occur to select a file name different from the hour's initial file name.

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.

Operational considerations

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.

Workload guidance

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.

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.

SMALL: 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.