Whenever more than this amount of data has been written by a single backend, attempt to force the OS to issue these writes to the underlying storage.
At a glance
| Property | Value |
|---|---|
| Parameter | backend_flush_after |
| Category | Resource Consumption |
| Default | 0 |
| Value type | integer |
| Change scope | Per-session (SET) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
Whenever more than this amount of data has been written by a single backend, 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 a 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 0, i.e., no forced writeback. (If BLCKSZ is not 8kB, the maximum value scales proportionally to it.)
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Can be set per session with SET, per role/database with ALTER ROLE/DATABASE ... SET, or globally in postgresql.conf.
Inspect the current value and source with SHOW backend_flush_after; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'backend_flush_after';.
Tuning guidance
Set it (e.g. 256kB-2MB) to trigger writeback of dirty data sooner from a backend, smoothing checkpoint-time I/O spikes; 0 disables it. Tune alongside the bgwriter/checkpoint flush settings.