Wiki / 配置参数

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.

英文手册覆盖始于 PostgreSQL 7.4. 来源历史与运行验证各自保留独立版本边界。

此版本暂无所选语言的定义，以下显示原始英文内容。

boot val

off

category

Developer Options

context

superuser

documented

true

enumvals

未知

lang

en

max val

未知

metadata version

18

min val

未知

name

zero_damaged_pages

short desc

Continues processing past damaged page headers.

source

pg-settings-source-snapshot

unit

未知

vartype

bool

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.