Background writer

For DBAs and operators

One round of BgBufferSync()

1. Read how many buffers were allocated since the last round (recent_alloc) and where the clock hand is.
2. Smooth it: if the new value is higher it is taken at once, otherwise the average decays over 16 rounds.
3. upcoming = smoothed_alloc × bgwriter_lru_multiplier, but at least a minimum so that the whole pool is scanned at least once every 2 minutes.
4. Scan forward from where the last round stopped (or from the clock hand if the hand has overtaken it). A buffer with usage_count = 0 and no pins is "reusable"; if it is dirty, write it. Stop when enough reusable buffers are ahead of the hand, or when bgwriter_lru_maxpages pages were written; the latter increments maxwritten_clean.

It does not decrement usage counts (only the backends' clock sweep does) and never writes recently used pages: those are written by the checkpointer, or by a backend when it finally evicts them. It also asks the kernel to start writing its data out every bgwriter_flush_after (512kB) on Linux, to avoid big write bursts later. With wal_level replica or higher it also logs a running-transactions snapshot into WAL every 15 seconds, which helps standbys and logical decoding get started.

Hibernation

If a round finds nothing to do and no buffers were allocated, it sleeps for bgwriter_delay × 50 instead (wait_event = BgwriterHibernate, otherwise BgwriterMain). The first backend that allocates a buffer wakes it up.

Monitoring

SELECT buffers_clean, maxwritten_clean, buffers_alloc, stats_reset
  FROM pg_stat_bgwriter;

-- who writes buffers? (PostgreSQL 16+)
SELECT backend_type, context, writes, evictions
  FROM pg_stat_io
 WHERE object = 'relation' AND writes > 0;

Since PostgreSQL 17 pg_stat_bgwriter has only these columns; checkpoint counters moved to pg_stat_checkpointer and the old buffers_backend / buffers_backend_fsync moved to pg_stat_io (rows for client backend).

Tuning

• maxwritten_clean growing steadily means the cap stopped the writer often: raise bgwriter_lru_maxpages (for example 400 to 1000) or the multiplier.
• Many backend writes in pg_stat_io (context normal) with a busy, write-heavy workload: same advice, or lower bgwriter_delay (for example 50ms).
• An aggressive writer may write the same hot page several times; that is extra I/O. Setting bgwriter_lru_maxpages = 0 disables background writing (the process still runs).
• Backend writes in context bulkread/bulkwrite/vacuum come from ring buffers and are not something the background writer can avoid.

Process facts

One process, postgres: background writer in ps, backend_type = 'background writer'. It starts with the postmaster (also during recovery on a standby). If killed with signal 9 the postmaster performs a crash restart: LOG: background writer process (PID 6069) was terminated by signal 9: Killed.