{"Entry":{"collection":"guc","key":"full_page_writes","name":"full_page_writes","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Write-Ahead Log / Settings","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"8.0","status":"added","to":"8.1"},{"documentation_changed":true,"fields":{},"from":"8.1","status":"changed","to":"8.2"},{"documentation_changed":true,"fields":{},"from":"8.2","status":"changed","to":"8.3"},{"documentation_changed":true,"fields":{},"from":"8.4","status":"changed","to":"9.0"},{"documentation_changed":true,"fields":{},"from":"9.5","status":"changed","to":"9.6"},{"documentation_changed":true,"fields":{},"from":"13","status":"changed","to":"14"},{"documentation_changed":true,"fields":{},"from":"16","status":"changed","to":"17"}],"content_hash":"09d7d2012c7849a8b78338fb50b2e1b2ef1a799d28e7e25d2072ed5397de1bd3","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"on"}],"editorial":{"advice":{"olap":"Bulk loads still need recoverability. Use explicitly rebuildable UNLOGGED/temporary staging to narrow the durability scope rather than disabling protection cluster-wide.","oltp":"Keep full_page_writes=on for persistent production data. Address storage latency, checkpoints, WAL compression, and batching instead of exchanging crash safety for throughput.","small":"Keep it on for persistent small instances too. Only a clearly isolated, disposable cluster may make an exception after explicitly accepting rebuild risk."},"mechanism":["Writes full pages to WAL when first modified after a checkpoint. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","After each checkpoint, the first change to a data page logs a complete page image, preventing torn-page recovery from combining old and new sectors. The extra WAL is concentrated after checkpoints and is affected by wal_compression; disabling it is unsafe unless the storage stack provides an equivalent atomic-page guarantee.","Monitor and change full_page_writes together with data_sync_retry, restart_after_crash, recovery_init_sync_method. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value."],"pitfalls":["Disabling it without an end-to-end atomic-page guarantee.","Confusing its WAL-volume cost with logging every page on every change.","Ignoring the post-checkpoint full-page-image burst.","Assuming a reload retroactively protects WAL records that were generated while full_page_writes was off.","Benchmarking with it disabled without an end-to-end crash, recovery, and torn-page test."],"references":[{"title":"PostgreSQL 19 Beta 4: full_page_writes","url":"https://www.postgresql.org/docs/19/runtime-config-wal.html#GUC-FULL-PAGE-WRITES"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["data_sync_retry","restart_after_crash","recovery_init_sync_method","fsync","wal_sync_method","synchronous_commit"],"summary":"full_page_writes — Writes full pages to WAL when first modified after a checkpoint. Observed in PG9.0–19 Beta 4; its last measured boot default is on in PG19 Beta 4, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"8.1","group":"Write-Ahead Log","group_slug":"wal","imported_at":"2026-09-27T17:57:31.299293+08:00","intro_commit":{},"key":"full_page_writes","last_version":"20","max_val":"","min_val":"","name":"full_page_writes","position":152,"present_in":["8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint.","short_desc_zh":"","source_rev":"english-manuals:b1cbc2041fd7924079ddb88ad9f69b585e55866b878b0c6044fc506bd331f454","unit":"","vartype":"bool"}},"Definition":{"Collection":"guc","Key":"full_page_writes","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"full_page_writes","SourceRevision":"english-manuals:b1cbc2041fd7924079ddb88ad9f69b585e55866b878b0c6044fc506bd331f454","Facts":{"boot_val":"on","category":"Write-Ahead Log / Settings","context":"sighup","description":"When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint. This is needed because a page write that is in process during an operating system crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WAL will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at the price of increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.) Turning this parameter off speeds normal operation, but might lead to either unrecoverable data corruption, or silent data corruption, after a system failure. The risks are similar to turning off fsync, though smaller, and it should be turned off only based on the same circumstances recommended for that parameter. Turning off this parameter does not affect use of WAL archiving for point-in-time recovery (PITR) (see Section 25.3). This parameter can only be set in the postgresql.conf file or on the server command line. The default is on.","doc":{"anchor":"GUC-FULL-PAGE-WRITES","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"},"documented":true,"enumvals":null,"extra_desc":"A page write in process during an operating system crash might be only partially written to disk.  During recovery, the row changes stored in WAL are not enough to recover.  This option writes pages when first modified after a checkpoint to WAL so full recovery is possible.","lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"full_page_writes","short_desc":"Writes full pages to WAL when first modified after a checkpoint.","source":"pg-settings-source-snapshot","unit":null,"vartype":"bool"},"ManualEvidence":{"doc":{"anchor":"GUC-FULL-PAGE-WRITES","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"full_page_writes","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"full_page_writes","Summary":"","BodyHTML":"\u003cp\u003e启用此参数时，\u003cspan\u003ePostgreSQL\u003c/span\u003e服务器会在检查点之后首次修改每个磁盘页面时，将该页面的全部内容写入 WAL。这样做是因为，操作系统崩溃时正在进行的页面写入可能只完成了一部分，导致磁盘页面混有新旧数据。通常存储在 WAL 中的行级变更数据不足以在崩溃恢复时完整还原这样的页面。保存整页镜像能保证正确恢复页面，但会增加必须写入 WAL 的数据量。（由于 WAL 重放总是从检查点开始，只需在检查点之后首次修改每个页面时这样做。因此，减少整页写入开销的一种方法是增大检查点间隔参数。）\u003c/p\u003e\u003cp\u003e关闭此参数可以加快正常操作，但系统故障后可能出现不可恢复的数据损坏或静默数据损坏。风险与关闭\u003ccode\u003efsync\u003c/code\u003e类似，虽然较小，但也只有在建议关闭\u003ccode\u003efsync\u003c/code\u003e的相同情形下，才应关闭此参数。\u003c/p\u003e\u003cp\u003e关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见\u003ca href=\"/docs/18/continuous-archiving.html\" rel=\"nofollow\"\u003e第 25.3 节\u003c/a\u003e）。\u003c/p\u003e\u003cp\u003e这个参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。默认值是\u003ccode\u003eon\u003c/code\u003e。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"f0269625dd71a2cff23393760b6d0252b63a1d911b813ae522479186b0c61565","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e启用此参数时，\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e服务器会在检查点之后首次修改每个磁盘页面时，将该页面的全部内容写入 WAL。这样做是因为，操作系统崩溃时正在进行的页面写入可能只完成了一部分，导致磁盘页面混有新旧数据。通常存储在 WAL 中的行级变更数据不足以在崩溃恢复时完整还原这样的页面。保存整页镜像能保证正确恢复页面，但会增加必须写入 WAL 的数据量。（由于 WAL 重放总是从检查点开始，只需在检查点之后首次修改每个页面时这样做。因此，减少整页写入开销的一种方法是增大检查点间隔参数。）\u003c/p\u003e\u003cp\u003e关闭此参数可以加快正常操作，但系统故障后可能出现不可恢复的数据损坏或静默数据损坏。风险与关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e类似，虽然较小，但也只有在建议关闭\u003ccode class=\"varname\"\u003efsync\u003c/code\u003e的相同情形下，才应关闭此参数。\u003c/p\u003e\u003cp\u003e关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见\u003ca href=\"/docs/18/continuous-archiving.html\" title=\"25.3. 持续归档和时间点恢复（PITR）\"\u003e第 25.3 节\u003c/a\u003e）。\u003c/p\u003e\u003cp\u003e这个参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。默认值是\u003ccode class=\"literal\"\u003eon\u003c/code\u003e。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}