log_directory

log_directory is the PostgreSQL setting that defines the destination directory for log files.

Note

Fact — official short description: “Sets the destination directory for log files.”

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 , Valuelog: log

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–9.6	`pg_log`	—	pg_log
PG10–19 Beta 3	`log`	—	log

How it works

log_directory sets the destination directory for log files. Can be specified as relative to the data directory or as absolute path. A relative path is resolved below the data directory, while an absolute path can place collector-managed files on a separate filesystem.

log_directory 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_directory 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_directory path for bursty analytical output and verify that rotation or downstream ingestion cannot stall database processes.
Small nodes	Use a bounded, easily rotated log_directory 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	`/pg/log/postgres`	different	`{{ pg_log_dir }}`
OLAP	`/pg/log/postgres`	different	`{{ pg_log_dir }}`
CRIT	`/pg/log/postgres`	different	`{{ pg_log_dir }}`
TINY	`/pg/log/postgres`	different	`{{ pg_log_dir }}`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = /pg/log/postgres (dcs); OLAP: PG9.0–19 Beta 3 = /pg/log/postgres (dcs); CRIT: PG9.0–19 Beta 3 = /pg/log/postgres (dcs); TINY: PG9.0–19 Beta 3 = /pg/log/postgres (dcs). Advice, pending human review — Editorial inference: A dedicated /pg/log/postgres path separates PostgreSQL logs from the data directory and matches the managed filesystem layout.

Common pitfalls

Editing log_directory 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_directory globally without a rollback plan and a client or operational compatibility test.

logging_collector · log_destination · log_filename · log_rotation_age · log_rotation_size