log_destination

log_destination is the PostgreSQL setting that defines the destination for server log output.

Note

Fact — official short description: “Sets the destination for server log output.”

Identity

Type , Valuestring: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
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 , Valuestderr: stderr

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	`stderr`	—	stderr

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
OLAP	Size the log_destination path for bursty analytical output and verify that rotation or downstream ingestion cannot stall database processes.
Small nodes	Use a bounded, easily rotated log_destination configuration and monitor free space; a small node should not retain redundant formats or unlimited files.

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	`csvlog`	different	`csvlog`
OLAP	`csvlog`	different	`csvlog`
CRIT	`csvlog`	different	`csvlog`
TINY	`csvlog`	different	`csvlog`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = csvlog (dcs); OLAP: PG9.0–19 Beta 3 = csvlog (dcs); CRIT: PG9.0–19 Beta 3 = csvlog (dcs); TINY: PG9.0–19 Beta 3 = csvlog (dcs). Advice, pending human review — Editorial inference: csvlog provides a stable structured record for collection and SQL-oriented analysis across every profile.

Common pitfalls

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.

logging_collector · log_directory · log_filename · log_rotation_age · log_rotation_size