Logger (logging collector)

For DBAs and operators

What it does

The postmaster creates a pipe before it forks anything else and redirects its own stderr into it, so every child inherits it. Backends write each message to the pipe in small chunks with a header (PID, length), and the logger reassembles chunks from different processes so that lines from concurrent processes are not interleaved mid-line. It then writes the result to the current stderr, csvlog (.csv) and/or jsonlog (.json, since PostgreSQL 15) file. CSV and JSON output need the collector: without it, those entries fall back to plain text on stderr. With the collector on, the plain .log file is always opened too, even when log_destination lists only csvlog/jsonlog; it receives output that does not go through the logging system.

When the collector starts, the postmaster itself still prints two lines on the original stderr:

When it wakes

• Whenever data arrives on the pipe (it sleeps in WaitEventSetWait on the pipe and its latch).
• At the next log_rotation_age boundary. Time-based rotation is aligned to the clock: with 1d a new file starts at midnight (in log_timezone).
• After every write it checks the file size against log_rotation_size.
• On SELECT pg_rotate_logfile();, pg_ctl logrotate, or a SIGHUP that changes log_directory/log_filename.

File names and truncation

log_filename is a strftime pattern; the default postgresql-%Y-%m-%d_%H%M%S.log gives a new name each rotation, so files accumulate forever. A pattern like postgresql-%a.log plus log_truncate_on_rotation = on keeps a rolling week of files. Truncation happens only on time-based rotation, never on size-based rotation or at server start (those append). The file permissions come from log_file_mode (0600).

Seeing it

The logger is not attached to shared memory, so it does not appear in pg_stat_activity. Use ps:

postgres  3296  3295  0 15:34 ?  00:00:00 postgres: logger

SHOW logging_collector;
SELECT pg_current_logfile();          -- first of: stderr, csvlog, jsonlog file
SELECT pg_current_logfile('csvlog');
SELECT * FROM pg_ls_logdir() ORDER BY modification DESC LIMIT 5;

current_logfiles in the data directory lists the files in use.

If it dies

The postmaster simply starts a new logger; it is not a crash of the cluster and other sessions are not affected. The new logger opens a log file named for the current time (with the default log_filename, a new file):

Support notes

• logging_collector needs a restart. Packages differ: Debian/Ubuntu (pg_ctlcluster) logs to /var/log/postgresql/ without the collector; other packages and container images may turn it on (then the files are in log/ inside PGDATA by default). Check before telling a customer where to look.
• A relative log_directory is relative to the data directory, so a full log disk can fill the data volume.
• If the logger cannot keep up (very verbose log_statement = all, slow disk), backends block writing to the pipe: queries slow down for no visible reason. Reduce logging or log to faster storage.
• For syslog/eventlog destinations the logger is not involved; messages go to the OS facility directly.