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, and it can only be changed by a superuser.
- Re: Corrupted data due to system power failure
- Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
- Corrupted data due to system power failure
- Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept
- Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS