{"Entry":{"collection":"guc","key":"zero_damaged_pages","name":"zero_damaged_pages","aliases":[],"metadata":{"baseline":true,"boot_human":"Not specified","boot_val":null,"category":"Developer Options","category_zh":"","changed_in":["17"],"changes":[{"documentation_changed":true,"fields":{},"from":"7.4","status":"changed","to":"8.0"},{"documentation_changed":true,"fields":{},"from":"8.0","status":"changed","to":"8.1"},{"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.0","status":"changed","to":"9.1"},{"documentation_changed":true,"fields":{},"from":"14","status":"changed","to":"15"},{"documentation_changed":false,"fields":{"extra_desc":{"from":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to true causes the system to instead report a warning, zero out the damaged page, and continue processing. This behavior will destroy data, namely all the rows on the damaged page.","to":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting \"zero_damaged_pages\" to true causes the system to instead report a warning, zero out the damaged page, and continue processing. This behavior will destroy data, namely all the rows on the damaged page."}},"from":"16","status":"changed","to":"17"}],"content_hash":"f056a9027b68da7b3134b207dac04a674fd1231c2145308ab3358aabf8600e19","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"off"}],"derived_content_hash":"7192c815a4a9ffdd1bed55226ed1564c31e852f91f9e0b7381ee6f2ffce97e35","documentation_refresh":{"batch":"20261113","original_source_rev":"wiki-repair-20261023:739fcf3ebc084507c9c78180eac7ff118f78447bfe25f91b6da9660d849a3b12","versions":{"14":"14.25","15":"15.20","16":"16.16","17":"17.12","18":"18.7","19":"19rc2"}},"editorial":{"advice":{"olap":"Read-only analytics does not make zero_damaged_pages safe: corrupted pages can still poison results or structures. Use only on a disposable salvage copy with explicit acceptance of lost data.","oltp":"Never use zero_damaged_pages as tuning or a steady-state availability setting. Stop writes, preserve immutable copies, exhaust backup/storage repair, document expected data loss, salvage narrowly, rebuild, and validate before any return to service.","small":"Do not enable zero_damaged_pages merely because no replica exists. Preserve the original first and seek a clean backup; this switch can convert visible corruption into silent loss."},"mechanism":["When PostgreSQL detects a damaged page header, zero_damaged_pages substitutes an all-zero page in memory, emits a warning, and continues. Every row formerly on that page is thereby lost to the salvage read.","The zero page is not forced to disk automatically, so continuing to use the relation can produce inconsistent behavior. The table or index must be rebuilt after salvage.","This is a last-resort data-extraction switch after backups and storage recovery are exhausted. It must be used on a preserved copy, scoped narrowly, and turned off immediately afterward. Its superuser context permits an authorized session change without a server restart."],"pitfalls":["Leaving zero_damaged_pages enabled after the bounded diagnostic or recovery task.","Running the experiment on the only copy of production data.","Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.","Treating a server that merely starts or completes a query as proof that data and behavior are correct."],"references":[{"title":"PostgreSQL 19 Beta 4: zero_damaged_pages","url":"https://www.postgresql.org/docs/19/runtime-config-developer.html#GUC-ZERO-DAMAGED-PAGES"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["ignore_checksum_failure","ignore_invalid_pages","data_checksums","wal_consistency_checking"],"summary":"zero_damaged_pages — Continues processing past damaged page headers. Observed in PG9.0–19 Beta 4; its last measured boot default is off in PG19 Beta 4, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"7.4","group":"Developer Options","group_slug":"developer","imported_at":"2026-09-27T17:57:32.400915+08:00","intro_commit":{},"key":"zero_damaged_pages","last_version":"20","max_val":"","min_val":"","name":"zero_damaged_pages","position":490,"present_in":["7.4","8.0","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"],"repair_provenance":{"original_source_revision":"wiki-repair-20261023:82965ed2da801ba354d74fcbdd8c066dae3cef2e2a8aa03cb73492a2acf19573","receipt_sha256":"2b55ee94d24ed7dd8fe2278b3cc910a366262716d23284f2018e0e866bd1470e","repair":"wiki-repair-20261023"},"short_desc":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction.","short_desc_zh":"","source_rev":"wiki-repair-20261023:739fcf3ebc084507c9c78180eac7ff118f78447bfe25f91b6da9660d849a3b12","unit":"","vartype":"bool"}},"Definition":{"Collection":"guc","Key":"zero_damaged_pages","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"zero_damaged_pages","SourceRevision":"wiki-repair-20261023:739fcf3ebc084507c9c78180eac7ff118f78447bfe25f91b6da9660d849a3b12","Facts":{"boot_val":"off","category":"Developer Options","context":"superuser","description":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. However, it does allow you to get past the error and retrieve rows from any undamaged pages that might be present in the table. It is useful for recovering data if corruption has occurred due to a hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged pages of a table. Zeroed-out pages are not forced to disk so it is recommended to recreate the table or the index before turning this parameter off again. The default setting is off. Only superusers and users with the appropriate SET privilege can change this setting.","description_zh":"检测到损坏的页面头通常会导致 PostgreSQL 报告错误，中止当前事务。将 zero_damaged_pages 设置为 on 会导致系统报告警告，将内存中的损坏页面清零，并继续处理。这种行为会破坏数据，即损坏页面上的所有行。但是，它确实允许你跳过错误，并从表中可能存在的未损坏页面中检索行。如果由于硬件或软件错误而发生损坏，这对于恢复数据很有用。通常在放弃从表的损坏页面恢复数据的希望之前，不应将其设置为 on。清零的页面不会强制写入磁盘，因此建议在再次关闭此参数之前重新创建表或索引。默认设置为 off。只有超级用户和具有适当 SET 权限的用户才能更改此设置。","description_zh_html":"\u003cp\u003e\n        检测到损坏的页面头通常会导致 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 报告错误，中止当前事务。将 \u003ccode class=\"varname\"\u003ezero_damaged_pages\u003c/code\u003e 设置为 on 会导致系统报告警告，将内存中的损坏页面清零，并继续处理。这种行为\u003cspan class=\"emphasis\"\u003e\u003cem\u003e会破坏数据\u003c/em\u003e\u003c/span\u003e，即损坏页面上的所有行。但是，它确实允许你跳过错误，并从表中可能存在的未损坏页面中检索行。如果由于硬件或软件错误而发生损坏，这对于恢复数据很有用。通常在放弃从表的损坏页面恢复数据的希望之前，不应将其设置为 on。清零的页面不会强制写入磁盘，因此建议在再次关闭此参数之前重新创建表或索引。默认设置为 \u003ccode class=\"literal\"\u003eoff\u003c/code\u003e。只有超级用户和具有适当 \u003ccode class=\"literal\"\u003eSET\u003c/code\u003e 权限的用户才能更改此设置。\n       \u003c/p\u003e","doc":{"anchor":"GUC-ZERO-DAMAGED-PAGES","file":"runtime-config-developer.html","lang":"en","sha256":"a3f6a107ed6ba4edaf6df03e52f4a469bd09350d545e4ff419e62844025ec1cf","slug":"18"},"doc_html":"\u003cp\u003e\n        Detection of a damaged page header normally causes\n        \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e to report an error, aborting the current\n        transaction.  Setting \u003ccode class=\"varname\"\u003ezero_damaged_pages\u003c/code\u003e to on causes\n        the system to instead report a warning, zero out the damaged\n        page in memory, and continue processing.  This behavior \u003cspan class=\"emphasis\"\u003e\u003cem\u003ewill destroy data\u003c/em\u003e\u003c/span\u003e,\n        namely all the rows on the damaged page.  However, it does allow you to get\n        past the error and retrieve rows from any undamaged pages that might\n        be present in the table.  It is useful for recovering data if\n        corruption has occurred due to a hardware or software error.  You should\n        generally not set this on until you have given up hope of recovering\n        data from the damaged pages of a table.  Zeroed-out pages are not\n        forced to disk so it is recommended to recreate the table or\n        the index before turning this parameter off again.  The\n        default setting is \u003ccode class=\"literal\"\u003eoff\u003c/code\u003e.\n        Only superusers and users with the appropriate \u003ccode class=\"literal\"\u003eSET\u003c/code\u003e\n        privilege can change this setting.\n       \u003c/p\u003e","doc_same_as":"","documentation_revision":{"inputs":[{"file":"runtime-config-developer.html","kind":"same-version-reviewed-manual","locale":"en","sha256":"a3f6a107ed6ba4edaf6df03e52f4a469bd09350d545e4ff419e62844025ec1cf","version":"18.7"},{"file":"runtime-config-developer.html","kind":"same-version-reviewed-manual","locale":"zh-Hans","sha256":"e7e22aa5738a1d376b84af1adca796c5e14746266733f925eb50c3ef86a50655","version":"18.7"}],"release":"18.7","runtime_remeasured":false,"source_revision":"pgdoc:b9f0e7232f60f380d642ac9b99226606c254b552"},"documented":true,"enumvals":null,"extra_desc":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting \"zero_damaged_pages\" to true causes the system to instead report a warning, zero out the damaged page, and continue processing. This behavior will destroy data, namely all the rows on the damaged page.","lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"zero_damaged_pages","short_desc":"Continues processing past damaged page headers.","source":"pg-settings-source-snapshot","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-developer.html","sha256":"3c08bf624188bbb0733dc7854e61c0c251c2578311ac3dc8fa626ab21b7911d1"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":null,"vartype":"bool","zh_from":"same-version-manual"},"ManualEvidence":{"doc":{"anchor":"GUC-ZERO-DAMAGED-PAGES","file":"runtime-config-developer.html","lang":"en","sha256":"a3f6a107ed6ba4edaf6df03e52f4a469bd09350d545e4ff419e62844025ec1cf","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"zero_damaged_pages","SourceDatabase":"center","Version":"18","Locale":"en","Title":"zero_damaged_pages","Summary":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. However, it does allow you to get past the error and retrieve rows from any undamaged pages that might be present in the table. It is useful for recovering data if corruption has occurred due to a hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged pages of a table. Zeroed-out pages are not forced to disk so it is recommended to recreate the table or the index before turning this parameter off again. The default setting is off. Only superusers and users with the appropriate SET privilege can change this setting.","BodyHTML":"\u003cp\u003e\n        Detection of a damaged page header normally causes\n        \u003cspan\u003ePostgreSQL\u003c/span\u003e to report an error, aborting the current\n        transaction.  Setting \u003ccode\u003ezero_damaged_pages\u003c/code\u003e to on causes\n        the system to instead report a warning, zero out the damaged\n        page in memory, and continue processing.  This behavior \u003cspan\u003e\u003cem\u003ewill destroy data\u003c/em\u003e\u003c/span\u003e,\n        namely all the rows on the damaged page.  However, it does allow you to get\n        past the error and retrieve rows from any undamaged pages that might\n        be present in the table.  It is useful for recovering data if\n        corruption has occurred due to a hardware or software error.  You should\n        generally not set this on until you have given up hope of recovering\n        data from the damaged pages of a table.  Zeroed-out pages are not\n        forced to disk so it is recommended to recreate the table or\n        the index before turning this parameter off again.  The\n        default setting is \u003ccode\u003eoff\u003c/code\u003e.\n        Only superusers and users with the appropriate \u003ccode\u003eSET\u003c/code\u003e\n        privilege can change this setting.\n       \u003c/p\u003e","SourceRevision":"wiki-repair-20261023:739fcf3ebc084507c9c78180eac7ff118f78447bfe25f91b6da9660d849a3b12","ContentHash":"a32c1060245dd09636d366d1885ec6c2f0d6c6c35f2fc5912f1ae3b8ca65ad69","Payload":{"description":"Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. However, it does allow you to get past the error and retrieve rows from any undamaged pages that might be present in the table. It is useful for recovering data if corruption has occurred due to a hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged pages of a table. Zeroed-out pages are not forced to disk so it is recommended to recreate the table or the index before turning this parameter off again. The default setting is off. Only superusers and users with the appropriate SET privilege can change this setting."}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","7.4","8.0","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}