log_destination

Definition PG 18 manual

PostgreSQL supports several methods for logging server messages, including stderr, csvlog, jsonlog, and syslog. On Windows, eventlog is also supported. Set this parameter to a list of desired log destinations separated by commas. The default is to log to stderr only. This parameter can only be set in the postgresql.conf file or on the server command line.

If csvlog is included in log_destination, log entries are output in “comma-separated value” (CSV) format, which is convenient for loading logs into programs. See Section 19.8.4 for details. logging_collector must be enabled to generate CSV-format log output.

If jsonlog is included in log_destination, log entries are output in JSON format, which is convenient for loading logs into programs. See Section 19.8.5 for details. logging_collector must be enabled to generate JSON-format log output.

When either stderr, csvlog or jsonlog are included, the file current_logfiles is created to record the location of the log file(s) currently in use by the logging collector and the associated logging destination. This provides a convenient way to find the logs currently in use by the instance. Here is an example of this file's content:

stderr log/postgresql.log
csvlog log/postgresql.csv
jsonlog log/postgresql.json

current_logfiles is recreated when a new log file is created as an effect of rotation, and when log_destination is reloaded. It is removed when none of stderr, csvlog or jsonlog are included in log_destination, and when the logging collector is disabled.

local0.*    /var/log/postgresql

How it works

log_destination sets the destination for server log output. Valid values are combinations of "stderr", "syslog", "csvlog", "jsonlog", and "eventlog", depending on the platform. Several destinations can be active at once; csvlog and jsonlog require logging_collector, while stderr, syslog, and Windows eventlog follow different transport paths.

log_destination 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_destination 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.

Changing log_destination globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Size the log_destination path for bursty analytical output and verify that rotation or downstream ingestion cannot stall database processes.

OLTP: Set log_destination as part of one end-to-end logging design. Validate collector behavior, rotation, ownership, shipping, retention, and recovery from a full destination.

SMALL: Use a bounded, easily rotated log_destination configuration and monitor free space; a small node should not retain redundant formats or unlimited files.