checkpoint_flush_after — PostgreSQL configuration parameter

Whenever more than this amount of data has been written while performing a checkpoint, attempt to force the OS to issue these writes to the underlying storage.

At a glance

What it does

Whenever more than this amount of data has been written while performing a checkpoint, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel’s page cache, reducing the likelihood of stalls when an fsync is issued at the end of the checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS’s page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 256kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the postgresql.conf file or on the server command line.

(Description quoted from the official PostgreSQL documentation.)

How to apply a change

Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.

Inspect the current value and source with SHOW checkpoint_flush_after; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'checkpoint_flush_after';.

Tuning guidance

The default smooths checkpoint writes by requesting OS writeback after this many bytes; lower it to spread I/O further on write-heavy systems, 0 to disable. Tune with checkpoint_completion_target.

Reference

PostgreSQL documentation — checkpoint_flush_after.