How PostgreSQL Handles Uncommitted Data During Crash Recovery

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=200andxid=201), physically putting those rows back onto the disk data files.The Checklist Update: Postgres looks for
COMMITrecords for those transactions at the end of the WAL. Finding none, it goes to the CLOG (Commit Log) bitmap in memory and instantly marksxid=200andxid=201as ABORTED.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.
MVCC Visibility Check: When a user runs a
SELECTquery later, Postgres performs an MVCC check by reading the row’sxminand looking it up in the CLOG. Seeing it is marked “Aborted,” Postgres instantly hides the row from the user.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.