数据页损坏是数据库管理员最不愿意遇到的故障之一。当磁盘出现坏道、服务器异常断电或者文件系统出错后，PostgreSQL在查询时可能抛出类似 invalid page in block 1234 of relation base/16384/16385 的错误，严重时甚至导致整个实例无法启动。面对这种情况，PostgreSQL 提供了一个非常规的数据抢救参数 zero_damaged_pages，它允许服务器把损坏的数据页当作全零页面来处理，让查询跳过坏页继续执行，为数据导出争取宝贵的时间窗口。
zero_damaged_pages的工作原理是什么
要理解这个参数的行为，首先要知道 PostgreSQL 的最小存储单元是数据页（page），默认大小为 8KB。每个数据页头部包含页校验信息、空闲空间指针、行指针数组等元数据，表中的所有行数据都存放在这些页面里。当页面因为磁盘故障而损坏时，页头部的校验或结构信息不再合法，PostgreSQL 的读取代码会认为这是一个不可用的页面，直接报告错误并中止当前查询。
开启 zero_damaged_pages 之后，读取逻辑的行为发生变化：一旦检测到页面损坏，后端进程不会抛出错误，而是记录一条 WARNING 日志，然后返回一个全零页面给上层调用者。这里有一个巧妙的设计——在 PostgreSQL 的内部约定中，一个不包含任何行指针的全零页面被视为空页面，读取它是合法且无害的操作。也就是说，这个参数并没有真正修复损坏的页面，而是欺骗上层代码，让它以为这个页面里没有数据，从而绕过错误继续执行。
需要特别强调的是，这是一种破坏性读取行为。被跳过的坏页中的数据将无法通过查询获取，相当于这些行被静默丢弃。因此官方文档明确指出该参数只能用于数据恢复场景，比如从失效的备份中导出数据，或者抢救一个页头损坏的表，绝对不能在正常运行的生产库上长期开启。
如何配置和开启zero_damaged_pages
该参数的类型是布尔值，默认值为 off，可以在配置文件、命令行或者会话级别灵活设置。由于它属于用户可在线修改的参数（USERSET 级别），最推荐的方式是在会话级别按需开启，这样影响范围可控，不会波及其他业务连接。
方式一：修改配置文件。编辑 postgresql.conf，加入如下配置后重载即可：
# postgresql.conf 中添加 zero_damaged_pages = on # 重载配置（无需重启） pg_ctl reload -D /var/lib/pgsql/data
方式二：会话级别设置，这是数据抢救时最常用的做法。连接到数据库后执行：
-- 仅在当前会话中生效，不影响其他连接 SET zero_damaged_pages = on; -- 确认参数已生效 SHOW zero_damaged_pages; -- 找出损坏的表并导出可读数据 CREATE TABLE rescued_orders AS SELECT * FROM orders WHERE id < 500000; -- 完成后记得关闭，避免后续操作静默丢数据 RESET zero_damaged_pages;
如果实例因为系统表损坏而无法正常启动，还可以在启动命令中临时指定参数：
pg_ctl start -D /var/lib/pgsql/data -o "-c zero_damaged_pages=on"
还有一种更底层的做法：当实例完全起不来时，先用 pg_resetwal 强制重置事务日志，再用单用户模式配合 zero_damaged_pages 导出关键表。不过 pg_resetwal 本身就是高危操作，可能导致数据不一致，务必在拷贝出来的数据目录副本上操作，不要直接在原库上执行。
zero_damaged_pages与ignore_checksum_failure的区别
从版本开始，如果建库时开启了 checksums（初始化集群时指定 initdb --data-checksums，或通过 pg_checksums 工具启用），每个页面尾部都会存储校验和。读取时校验失败会报 checksum failure 错误，这时需要另一个参数 ignore_checksum_failure 配合使用。
两个参数的分工很清晰：ignore_checksum_failure 决定遇到校验和错误时是否继续读取该页面，而 zero_damaged_pages 决定遇到结构性损坏的页面时是否以全零页替代。如果坏页只是校验和不匹配但页结构完整，开启 ignore_checksum_failure 后可以直接读到页内数据，丢失的只是坏掉的那部分字节；如果页头已经损坏到无法解析，就需要 zero_damaged_pages 把整页当作空页跳过。实际抢救时通常两个参数一起开启：
SET zero_damaged_pages = on; SET ignore_checksum_failure = on; -- 尝试导出，坏页所在行会被跳过 COPY orders TO '/tmp/orders_dump.csv' WITH CSV HEADER;
两者的风险等级也不同。校验和失败可能只意味着个别比特翻转，数据大体可用；而需要 zero 化的页面通常是整页损毁，跳过就意味着整页数据丢失。管理员在操作前应该对数据目录做完整拷贝，例如直接 cp -a 或者 pg_basebackup 一份冷备，确保操作可回退。导出过程中要持续关注日志中的 WARNING 记录，每条警告都对应一个被放弃的坏页，这些日志可以用来估算数据损失范围，评估事后是否需要从其他渠道补数。导出完成后，应尽快重建表、恢复备份，并排查底层磁盘和文件系统的健康状况，毕竟坏页往往是硬件故障的信号，不解决根因，类似故障还会再次发生。
PostgreSQLzero_damaged_pages数据恢复修改时间：2026-09-15 09:26:31