The background processes and what each one is responsible for · PostgreSQL

A cluster with no clients connected is still busy. Pages are being written, the write-ahead log is being flushed, dead rows are being reclaimed and statistics are being updated, all by processes that no client asked for and that no query is waiting on.

These processes matter to an operator for a specific reason: they are where a large fraction of unexplained I/O comes from. When a host shows write activity that no application accounts for, the answer is almost always one of the seven processes below, and knowing which one narrows the investigation immediately.

The inventory

flowchart TD
    P["postmaster\nlistens, forks, supervises"]
    P --> C["checkpointer\nbounds recovery time"]
    P --> B["background writer\nkeeps clean buffers ready"]
    P --> W["walwriter\nflushes WAL buffers"]
    P --> A["autovacuum launcher\nschedules workers"]
    A --> AW["autovacuum worker\nvacuums one table"]
    P --> L["logical replication launcher\nstarts subscription workers"]
    P --> IO["io worker x3\nasynchronous reads (18+)"]

checkpointer

Writes every dirty buffer to disk and records a point in the write-ahead log from which recovery may begin. It exists to bound recovery time: without checkpoints, crash recovery would have to replay the entire log from the beginning of time.

It is also the largest single source of write I/O on most clusters, and its work arrives in waves. The parameters that shape it — checkpoint_timeout, max_wal_size, checkpoint_completion_target — trade recovery time against write smoothness, and Part XII works through the trade properly.

Its statistics moved in PostgreSQL 17. They are now in pg_stat_checkpointer, and the columns older documentation names on pg_stat_bgwriter no longer exist there.

Read-only / Safethe checkpointer's own view, PostgreSQL 17 and later— num_timed against num_requested is the first question to ask about checkpoint behaviour.

$ psql -U postgres -c '\d pg_stat_checkpointer'

                     View "pg_catalog.pg_stat_checkpointer"
     Column        |           Type           | Collation | Nullable
---------------------+--------------------------+-----------+----------
num_timed           | bigint                   |           |
num_requested       | bigint                   |           |
num_done            | bigint                   |           |
restartpoints_timed | bigint                   |           |
restartpoints_req   | bigint                   |           |
restartpoints_done  | bigint                   |           |
write_time          | double precision         |           |
sync_time           | double precision         |           |
buffers_written     | bigint                   |           |
slru_written        | bigint                   |           |
stats_reset         | timestamp with time zone |           |

num_timed counts checkpoints that happened because checkpoint_timeout elapsed. num_requested counts those forced early, usually because WAL volume reached max_wal_size. A cluster where num_requested dominates is checkpointing on volume rather than on schedule, which means checkpoints are arriving faster than intended and each one is competing with the workload that caused it.

background writer

Writes some dirty buffers ahead of time so that backends looking for a free buffer find a clean one and do not have to write it themselves. It is a latency smoother, not a durability mechanism: it makes the read-causes-a-write path from the previous lesson rarer.

Read-only / Safewhat remains in pg_stat_bgwriter on PostgreSQL 18— Four columns. Every checkpoint counter that older material looks for here moved to pg_stat_checkpointer in 17.

$ psql -U postgres -c '\d pg_stat_bgwriter'

                      View "pg_catalog.pg_stat_bgwriter"
    Column      |           Type           | Collation | Nullable
------------------+--------------------------+-----------+----------
buffers_clean    | bigint                   |           |
maxwritten_clean | bigint                   |           |
buffers_alloc    | bigint                   |           |
stats_reset      | timestamp with time zone |           |

A monitoring query written before PostgreSQL 17 will fail here, not warn

If you inherit a dashboard or exporter that selects checkpoints_timed, checkpoints_req, buffers_checkpoint or buffers_backend from pg_stat_bgwriter, it does not degrade gracefully after an upgrade to 17 or 18. The column does not exist, so the query errors and the panel goes blank or the exporter drops the metric series entirely.

This is one of the most common post-upgrade monitoring failures, and it is easy to miss because the database is healthy — it is the observability of the database that broke. Part XVII treats verifying monitoring as part of upgrade validation for exactly this reason.

maxwritten_clean is worth knowing while you are here: it counts how often the background writer stopped early because it hit bgwriter_lru_maxpages. A rising value means it is being capped and backends are more likely to be evicting dirty buffers themselves.

walwriter

Flushes the write-ahead log buffers to disk periodically, so that committing backends usually find their WAL already written. Without it, every commit would do its own flush.

It matters most for synchronous_commit = off workloads, where it becomes the mechanism by which data eventually reaches disk, and it defines the window of transactions that can be lost in a crash. Part XII covers that trade explicitly.

autovacuum launcher and workers

The launcher is a scheduler. At intervals of autovacuum_naptime it examines the cluster and starts workers for tables whose dead-row counts have crossed their thresholds. The workers do the actual vacuuming and analysing, and they are the processes you will see appear and disappear.

The launcher is always present; workers are transient. Seeing no autovacuum worker at a given instant is normal. Seeing the maximum number of workers continuously, for hours, is the signature of autovacuum failing to keep up, which is Part VIII’s central subject.

PostgreSQL 18 changed the worker configuration in an operationally useful way. autovacuum_max_workers is now sighup context, so it can be raised on a running cluster, up to the autovacuum_worker_slots ceiling set at startup.

Read-only / Safethe PostgreSQL 18 autovacuum worker settings— max_workers is now adjustable at runtime; worker_slots is the restart-only ceiling.

$ psql -U postgres -c "SELECT name, setting, context FROM pg_settings WHERE name LIKE 'autovacuum%worker%' ORDER BY name"

          name           | setting |  context
-------------------------+---------+------------
autovacuum_max_workers  | 3       | sighup
autovacuum_worker_slots | 16      | postmaster
(2 rows)

On PostgreSQL 16 and earlier, autovacuum_max_workers is postmaster context and raising it needs a restart. If you are writing a runbook that must work across an estate spanning versions, that difference is the sort of detail that decides whether the procedure works at 03:00.

logical replication launcher

Starts and supervises the workers that apply logical replication subscriptions. On a cluster with no subscriptions it does nothing at all, and its presence in the process list is not evidence that logical replication is configured.

io workers (PostgreSQL 18 and later)

New in 18. They execute asynchronous I/O requests submitted by backends, so that a backend can issue a read and continue working rather than blocking until the page arrives. The count is governed by io_workers, and the mechanism as a whole by io_method, which defaults to worker.

Read-only / Safethe PostgreSQL 18 asynchronous I/O settings— io_method defaults to worker. Setting it to sync restores pre-18 behaviour.

$ psql -U postgres -c "SELECT name, setting, context FROM pg_settings WHERE name IN ('io_method','io_combine_limit','effective_io_concurrency') ORDER BY name"

           name           | setting |  context
--------------------------+---------+------------
effective_io_concurrency | 16      | user
io_combine_limit         | 16      | user
io_method                | worker  | postmaster
(3 rows)

effective_io_concurrency defaulting to 16 is itself a change in 18; on earlier releases the default was far lower. A migration that compares I/O behaviour before and after an upgrade to 18 is comparing two different concurrency settings unless this is accounted for.

Mapping a symptom to a process

This is the table worth remembering, because it converts a vague complaint into a specific first query.

Symptom	Likely owner	First thing to read
Periodic write spikes, latency rising in waves	checkpointer	`pg_stat_checkpointer.num_timed` vs `num_requested`
Write I/O with no application activity	checkpointer or autovacuum worker	`pg_stat_activity` filtered to `backend_type`
Backends stalling on buffer allocation	background writer capped	`pg_stat_bgwriter.maxwritten_clean`
Commit latency higher than expected	walwriter, or the storage below it	`pg_stat_io` where `object = 'wal'`
Table growing while rows are deleted	autovacuum not keeping up	`pg_stat_user_tables.n_dead_tup`, `last_autovacuum`
Sustained maximum autovacuum workers	autovacuum losing the race	`pg_stat_progress_vacuum`
Unexplained reads at high queue depth	io workers, doing their job	`pg_stat_io` by `backend_type`

The single most useful habit is to split pg_stat_activity by backend_type before concluding anything about load. A cluster that looks busy is often busy with maintenance, and that is a completely different investigation from a cluster busy with queries.

psql -U postgres -c \
  "SELECT backend_type, count(*), count(*) FILTER (WHERE state = 'active') AS active
     FROM pg_stat_activity
    GROUP BY backend_type
    ORDER BY count(*) DESC"

Why the postmaster can restart these but not a backend

The previous lesson established that a backend dying abnormally forces the whole cluster into crash recovery, because the backend might have left shared memory inconsistent. The background processes are treated differently: if the background writer or the autovacuum launcher exits, the postmaster starts a replacement and the cluster carries on.

The difference is in what they touch and how. A client backend executes arbitrary user SQL and can hold buffer pins, heavyweight locks and partially applied changes across many shared structures at once. Its state at an arbitrary instant is not summarisable, so the only safe assumption after an abnormal death is that something is broken.

The background writer, by contrast, does one narrow thing repeatedly: find a dirty buffer, write it, mark it clean. It holds nothing across iterations. If it dies mid-write the buffer is simply still dirty, and being still dirty is a state the system already handles — someone else will write it later. The same reasoning applies to the checkpointer’s scanning and to the autovacuum launcher’s scheduling.

The exception worth knowing is that a checkpointer death is more serious than a background writer death, because an in-progress checkpoint that never completes means the recovery start point does not advance. The postmaster does restart it, but a cluster whose checkpointer is repeatedly dying will show a growing pg_wal and a lengthening recovery time, and the log is where the reason will be.

Production discipline

Split activity by backend_type before diagnosing load. Maintenance load and query load look identical in a host-level CPU or I/O graph and require opposite responses.
Check num_requested against num_timed whenever checkpoints are suspected. Volume-triggered checkpoints mean the configuration and the workload disagree.
Audit monitoring queries against the target version before an upgrade. The pg_stat_bgwriter column removals in 17 break dashboards silently, and a blank panel is easy to attribute to the wrong cause.
Do not read a transient autovacuum worker as a problem. Read a persistently saturated worker pool as one.
Record which processes your version should show. io workers from 18; no stats collector from 15. An unexpected process name is usually a version difference, not an intrusion.

Cross-course references

Observability for Production Sysadmins — Part LIX (Database observability) covers exporting these statistics, and Part XCIII (Upgrades) covers the pattern of validating that monitoring survived a version change.
Linux for Production Sysadmins — Part XLI (Disk performance) covers measuring the write behaviour these processes generate from outside the database.
Ceph & Distributed Storage — Part LXXIX (Slow ops) covers what a checkpoint write burst looks like from the storage platform’s side.