logging_collector

Definition PG 18 manual

This parameter enables the logging collector, which is a background process that captures log messages sent to stderr and redirects them into log files. This approach is often more useful than logging to syslog, since some types of messages might not appear in syslog output. (One common example is dynamic-linker failure messages; another is error messages produced by scripts such as archive_command.) This parameter can only be set at server start.

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.

Operational considerations

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.

Workload guidance

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.

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.

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