logging_collector

logging_collector is the PostgreSQL setting that controls whether PostgreSQL starts a subprocess to capture stderr, csvlog and/or jsonlog into log files.

Note

Fact — official short description: “Start a subprocess to capture stderr, csvlog and/or jsonlog into log files.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
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

logging_collector starts a subprocess to capture stderr, csvlog and/or jsonlog into log files. The collector drains server stderr through a pipe and writes configured file formats; it is designed not to lose messages, so extreme backpressure can block emitters.

logging_collector is a POSTMASTER-context setting: PostgreSQL reads it during server startup, and a configuration reload or session SET cannot activate a new 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 logging_collector when csvlog/jsonlog or collector-managed stderr files are required, then load-test pipe throughput, rotation, disk-full behavior, shipping, and restart. It is a POSTMASTER setting and needs a controlled restart.
OLAP	Analytical workloads can emit large bursts at query completion; size collector and destination I/O for that burst and verify database processes do not stall behind collector backpressure.
Small nodes	Use one required format and bounded retention. A small node still needs disk alerts because the collector is designed not to lose messages and can propagate backpressure when its destination is slow or full.

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: The collector is required for the configured csvlog file pipeline and gives all profiles managed local log files.

Common pitfalls

Expecting a reload or SET to activate logging_collector, although it requires a controlled server restart.
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.
Enabling file-oriented destinations without the collector, or starting the collector without a disk and retention plan.

log_destination · log_directory · log_filename · log_rotation_age · log_rotation_size