4.2Recovering a corrupted cluster

When the cluster itself is corrupted—filesystem damage, an accidental DROP, or a looming transaction ID wraparound crisis—an ordinary startup or backup restore may not be enough. Gold requires understanding both halves of the picture: dedicated recovery tools (PITR, pg_resetwal, startup flags, single-user mode) for restoring a broken cluster to a working state with as little data loss as possible, and VACUUM FREEZE, which prevents the catastrophic event of wraparound from happening in the first place.

4.2.1PITR and startup troubleshooting

• PITR (point-in-time recovery)—applies the WAL archive on top of a base backup to restore the cluster to an arbitrary point in time (e.g., just before a mistaken operation). Its biggest advantage: after an accident like "a production table was mistakenly DROPped," you can roll back to the instant just before that operation.
• pg_resetwal—a last-resort tool that forcibly rebuilds WAL control information (the contents of pg_control). Use it only when WAL is corrupted and normal startup or crash recovery is impossible; running it forfeits consistency guarantees from that point on and can involve data loss, so it is the option of last resort when nothing else works.
• Startup troubleshooting flags—ignore_system_indexes (attempts to start up while ignoring corrupted indexes on system catalogs) and ignore_checksum_failure (continues instead of erroring out when a checksum mismatch is detected, with data-checksums enabled). Both are temporary emergency measures for rescuing data from a corrupted cluster, not settings for permanent operation.