{"Entry":{"collection":"guc","key":"backend_flush_after","name":"backend_flush_after","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Resource Usage / I/O","category_zh":"","changed_in":["18"],"changes":[{"documentation_changed":false,"fields":{},"from":"9.5","status":"added","to":"9.6"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":false,"fields":{"category":{"from":"Resource Usage / Asynchronous Behavior","to":"Resource Usage / I/O"},"extra_desc":{"from":null,"to":"0 disables forced writeback."}},"from":"17","status":"changed","to":"18"}],"content_hash":"8c86c3c5662d03ca674085ad921f3aa312bc95ed78d8831b74e054dbad641bea","context":"","default_changed_in":[],"default_history":[{"from":"9.6","to":"19","value":"0 B (0 × 8kB)"}],"editorial":{"advice":{"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."},"mechanism":["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."],"pitfalls":["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."],"references":[{"title":"PostgreSQL 19 Beta 4: backend_flush_after","url":"https://www.postgresql.org/docs/19/runtime-config-resource.html#GUC-BACKEND-FLUSH-AFTER"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["bgwriter_flush_after","checkpoint_flush_after","bgwriter_delay","shared_buffers","track_io_timing"],"summary":"backend_flush_after — Number of pages after which previously performed writes are flushed to disk. Observed in PG9.6–19 Beta 4; its last measured boot default is 0 B (0 × 8kB) in PG19 Beta 4, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"9.6","group":"Resource Usage","group_slug":"resource","imported_at":"2026-09-27T17:57:30.856552+08:00","intro_commit":{"authored_at":"2016-02-19T12:13:05-08:00","discussion":[],"hash":"428b1d6b29ca599c5700d4bc4f4ce4c5880369bf","subject":"Allow to trigger kernel writeback after a configurable number of writes.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=428b1d6b29ca599c5700d4bc4f4ce4c5880369bf"},"key":"backend_flush_after","last_version":"20","max_val":"","min_val":"","name":"backend_flush_after","position":38,"present_in":["9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"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.","short_desc_zh":"","source_rev":"english-manuals:81ddfa95a19eb5d91245cfe3ca98d0678a969b54256c5affc56ab5442e5cfcea","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"backend_flush_after","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"backend_flush_after","SourceRevision":"english-manuals:81ddfa95a19eb5d91245cfe3ca98d0678a969b54256c5affc56ab5442e5cfcea","Facts":{"boot_val":"0","category":"Resource Usage / I/O","context":"user","description":"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.)","doc":{"anchor":"GUC-BACKEND-FLUSH-AFTER","file":"runtime-config-resource.html","lang":"en","sha256":"2e207c599f0884dfbe594558c478a2c7c132578981071e980e2015f31dfce28c","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"0 disables forced writeback.","lang":"en","max_val":"256","metadata_version":"18","min_val":"0","name":"backend_flush_after","short_desc":"Number of pages after which previously performed writes are flushed to disk.","source":"pg-settings-source-snapshot","unit":"8kB","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-BACKEND-FLUSH-AFTER","file":"runtime-config-resource.html","lang":"en","sha256":"2e207c599f0884dfbe594558c478a2c7c132578981071e980e2015f31dfce28c","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"backend_flush_after","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"backend_flush_after","Summary":"","BodyHTML":"\u003cp\u003e每当单个后端写出的数据超过此数量时，就尝试强制操作系统将这些写操作发往底层存储。这样可以限制内核页缓存中的脏数据量，降低在检查点结束时调用 \u003ccode\u003efsync\u003c/code\u003e，或操作系统在后台以较大批次写回数据时发生停顿的可能性。通常，这能大幅降低事务延迟，但在某些情况下性能可能下降，尤其是工作负载大于\u003ca href=\"/docs/18/runtime-config-resource.html#GUC-SHARED-BUFFERS\" rel=\"nofollow\"\u003eshared_buffers\u003c/a\u003e而小于操作系统页缓存时。此设置在某些平台上可能没有效果。如果未指定单位，则以块为单位，即 \u003ccode\u003eBLCKSZ\u003c/code\u003e 字节，通常为 8kB。有效范围为 \u003ccode\u003e0\u003c/code\u003e（禁用强制写回）至 \u003ccode\u003e2MB\u003c/code\u003e。默认值为 \u003ccode\u003e0\u003c/code\u003e，即不强制写回。（如果 \u003ccode\u003eBLCKSZ\u003c/code\u003e 不是 8kB，最大值将按比例变化。）\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"36ccae4416d6dc293fb5b0d4d1251da4b8feb86ab03f83535b2c8032f85623f6","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e每当单个后端写出的数据超过此数量时，就尝试强制操作系统将这些写操作发往底层存储。这样可以限制内核页缓存中的脏数据量，降低在检查点结束时调用 \u003ccode class=\"function\"\u003efsync\u003c/code\u003e，或操作系统在后台以较大批次写回数据时发生停顿的可能性。通常，这能大幅降低事务延迟，但在某些情况下性能可能下降，尤其是工作负载大于\u003ca href=\"/docs/18/runtime-config-resource.html#GUC-SHARED-BUFFERS\"\u003eshared_buffers\u003c/a\u003e而小于操作系统页缓存时。此设置在某些平台上可能没有效果。如果未指定单位，则以块为单位，即 \u003ccode class=\"symbol\"\u003eBLCKSZ\u003c/code\u003e 字节，通常为 8kB。有效范围为 \u003ccode class=\"literal\"\u003e0\u003c/code\u003e（禁用强制写回）至 \u003ccode class=\"literal\"\u003e2MB\u003c/code\u003e。默认值为 \u003ccode class=\"literal\"\u003e0\u003c/code\u003e，即不强制写回。（如果 \u003ccode class=\"symbol\"\u003eBLCKSZ\u003c/code\u003e 不是 8kB，最大值将按比例变化。）\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}