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, a DELETE operation does not immediately erase data from disk. The MVCC mechanism retains deleted rows as dead tuples, and reading these dead tuples is one viable approach to data recovery. However, this approach has a clear time limitation: once autovacuum completes its cleanup, the dead tuples are physically removed, and recovery methods based on data files become ineffective. At this point, the WAL (Write-Ahead Log) offers an alternative recovery path. Specifically, the FPW (Full Page Write) mechanism within WAL is the foundation of this approach. PostgreSQL DELETE recovery tools — including PDU (PostgreSQL Data Unloader) — rely on this technique. Its key property: as long as the WAL files generated during the deletion period still exist, the data can be fully recovered regardless of how much time has passed. 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.