backend_flush_after

Definition PG 18 manual

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.)

How it works

After one backend has written more than backend_flush_after bytes, PostgreSQL asks the operating system to begin writing those dirty page-cache pages toward storage. Zero disables these writeback hints.

This is not fsync and does not make a transaction durable earlier. Its aim is to limit large dirty-page bursts and later stalls; support and effect depend on the operating system.

The threshold applies independently to each backend, so concurrent bulk writers can each generate writeback. It complements bgwriter_flush_after and checkpoint_flush_after, which cover different writer processes. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Operational considerations

Changing backend_flush_after without applying its documented unit and configuration context.

Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.

Assuming a configured value guarantees operating-system or storage behavior.

Failing to retest startup, failover, and workload latency after the change.

Workload guidance

OLAP: Benchmark backend_flush_after with representative bulk and scan phases. Include sustained throughput, spill/writeback, and interference with other sessions, not only one operation's elapsed time.

OLTP: Change backend_flush_after only after identifying the corresponding resource bottleneck under concurrency. Budget total memory, I/O, disk, or kernel capacity rather than optimizing one process in isolation.

SMALL: Keep backend_flush_after conservative on a small host and prefer the upstream default when evidence is weak. A setting copied from a large server can consume a disproportionate share of resources.