log_rotation_size

Definition PG 18 manual

When logging_collector is enabled, this parameter determines the maximum size of an individual log file. After this amount of data has been emitted into a log file, a new log file will be created. If this value is specified without units, it is taken as kilobytes. The default is 10 megabytes. Set to zero to disable size-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

log_rotation_size sets the maximum size a log file can reach before being rotated. 0 disables size-based creation of new log files. The collector rotates when the current file reaches approximately this size; zero disables the size trigger but not time-based rotation.

log_rotation_size 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_rotation_size 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.

Setting zero without a working time-based or external rotation policy and allowing unbounded growth.

Workload guidance

OLAP: Analytical bursts can cross a size threshold repeatedly; test the resulting filename suffixes, shipping throughput, and maximum single-file size rather than choosing a larger number by habit.

OLTP: Use a nonzero log_rotation_size when file size itself must be bounded, and coordinate it with a filename that cannot collide during multiple rotations in one time period. If set to zero, verify that time-based rotation and disk alerts provide the bound instead.

SMALL: A modest size cap limits damage from a logging spike, but too-small files increase metadata and shipping overhead. Zero is acceptable only with a proven time-based cycle and free-space guardrail.