Im familiar with postresql WAL file and its purpose. Every transaction and the commit records of each transaction will be logged in this file .While recovery, it replays from the last checkpoint till the end to bring the database to a stable state. But there is a good chance that the uncommitted transactions would have made their way into the WAL files. How does postgres escape these uncommitted transaction records from being replayed? How is roll-backward recovery(UNDO ing the uncommitted transactions) implemented in postgresql?
-
2There are different types of entries in the WAL. One is that registers the commit (and nothing else). This, together with PostgreSQL's MVCC model, works in a way that the uncommitted changes are logged and replayed, but in the end never committed. The resulting tuples will be there but inaccessible to transactions.– András VácziCommented Apr 4, 2017 at 8:28
1 Answer
The uncommitted transactions are not escaped. They do get replayed. However, any process running across the new data from these transactions know to ignore them as they are not committed. And any data marked for removal by an uncommitted transaction is not ignored, because the removal has not yet been committed. This is the same way that in-progress transactions are ignored during normal operation, i.e., when there has been no crash.
Once the transaction is known to be aborted, then anyone who stumbles upon data from that transaction can clean it up. Once recovery has finished, any transaction which has not had its commit record replayed by the end of recovery is known to be aborted.
-
How does any of the other database handles such case, any idea? Commented Apr 11, 2017 at 12:45