PostgreSQL ACE & PostgreSQL Recovery Specialist
Creator of PDU (PostgreSQL Data Unloader) • Passionate about data recovery solutions and database reliability
Thoughts, stories, and ideas
After becoming a PostgreSQL ACE, Zhang Chen explains why he uses the title “PostgreSQL Database Recovery Expert” and how PDU evolved from offline extraction and WAL mining to fragment scanning and recovery without a data dictionary.
Starting from a ransomware recovery case, this article explains how PostgreSQL single-file-per-relation storage can make catalog recovery especially difficult, and compares that exposure with MySQL and Oracle.
In PostgreSQL, DELETE normally does not erase the tuple body immediately. MVCC first makes the old row version invisible to later transactions; before page cleanup, space reuse, or storage overwrite, those physical bytes may remain useful recovery evidence. That evidence has no fixed lifetime. VACUUM or page pruning can make the space reusable, and later writes can overwrite it. Surviving bytes alone do not guarantee trustworthy reconstruction of typed fields, TOAST values, or complete business rows. At this point, retained WAL may provide another source of physical evidence. In particular, a usable FPW (Full Page Write) can preserve an earlier image of a data page. PostgreSQL DELETE recovery tools — including PDU (PostgreSQL Data Unloader) — can evaluate these images together with relation files and relevant WAL records. WAL from the incident period is necessary for this path but is not sufficient by itself: an ordinary DELETE record does not guarantee a complete old row, and recoverability also depends on full_page_writes, checkpoint timing, page-image coverage, PostgreSQL version, TOAST data, and whether the underlying evidence was overwritten. This article dissects that recovery path function by function, based on PostgreSQL 18 source code.
It is 3 AM. A rogue DELETE just wiped 500,000 customer records. Traditional recovery takes hours and risks collateral damage. This guide shows you how to recover accidental DELETEs and UPDATEs in five steps using PDU — no kernel expertise, no downtime, data back in under a minute.
When the database cannot start and no backup is available, many teams assume recovery is over. In many cases the data is still on disk, but the data dictionary is no longer usable. This article examines core challenges in unconventional recovery: rebuilding table structures from damaged dictionaries, handling dropped columns and TOAST tables, continuing under imperfect conditions, and why recovery speed is itself part of the capability.
When people first hear about instant recovery, they often assume it is a replacement for backup—or worse, a risky shortcut only experts should attempt. But the truth is exactly the opposite. Instant recovery does not challenge any design boundary of PostgreSQL. It simply rejects a premise the kernel never promised - that the database must be in a bootable state. This article explains, from the perspective of PostgreSQL internals, why instant recovery is a capability that was always meant to exist, how it differs fundamentally from backup recovery, and why time itself is often the scarcest resource at an incident scene.
Most teams assume data loss means restore from backup. This article introduces the Instant Recovery mindset, explains why PostgreSQL makes it possible, and how PDU turns recoverability into a practical, predictable process.
Disk bad blocks damaged the data dictionary, leaving a 1.5TB PostgreSQL database unable to start and backups unusable. This article records how PDU completed the emergency recovery within 48 hours.
When pg_type and pg_attribute are partially destroyed, how do you piece together a corrupted database? This real-world case reveals an ingenious workaround that saved 46% of the data.
After a client accidentally ran rm -rf /* and lost the operating system and database, disk recovery specialists recovered the data files. PDU then completed adaptation and data recovery for the domestic PG database in 4 hours.
A comprehensive guide on debugging PostgreSQL source code using VSCode and Linux virtual machines, covering environment setup, Remote-SSH configuration, GDB debugging, and debugging peripheral tools like pg_waldump.