How PostgreSQL Handles Uncommitted Data During Crash Recovery

How PostgreSQL Handles Uncommitted Data During Crash Recovery

  1. The Replay (REDO): Upon restarting after a crash, Postgres reads the WAL files forward from the last checkpoint and re-applies all changes (like xid=200 and xid=201), physically putting those rows back onto the disk data files.

  2. The Checklist Update: Postgres looks for COMMIT records for those transactions at the end of the WAL. Finding none, it goes to the CLOG (Commit Log) bitmap in memory and instantly marks xid=200 and xid=201 as ABORTED.

  3. The Logical Rollback: Postgres does not waste time physically erasing the data from the disk during recovery; the “rollback” happens entirely inside the CLOG checklist by flipping that status bit.

  4. MVCC Visibility Check: When a user runs a SELECT query later, Postgres performs an MVCC check by reading the row’s xmin and looking it up in the CLOG. Seeing it is marked “Aborted,” Postgres instantly hides the row from the user.

  5. Vacuum Cleanup: Because these replayed rows are permanently invisible, they are classified as dead tuples. The background Autovacuum process will later scan the table, clear those dead rows out of the page, and reclaim the disk space for future inserts.

Caution: Your use of any information or materials on this website is entirely at your own risk. It is provided for educational purposes only. It has been tested internally, however, we do not guarantee that it will work for you. Ensure that you run it in your test environment before using.
Thank you
Rajasekhar Amudala