UNDO 操作は実装されていません。 このためアボートしたトランザクションは依然としてディスク領域を使っており、トランザクションの状態を記録するために永続的なpg_clogファイルを必要としています。 何故なら、トランザクション識別子を再利用することができないからです。 UNDOが実装されれば、pg_clogを永続的に保持する必要はありません。 pg_clog をシャットダウン時に削除することができるようになります。 (しかし、この問題の緊急性は pg_clog にセグメント分割格納方式を適用する、つまり、古いpg_clogの項目を永遠に保持する必要をなくすことで大きく減少します。)
またUNDOによって、savepointsを実装することができます。 そうすれば、不正なトランザクション処理（コマンド入力ミスによるパースエラー、重複したプライマリ/一意キーへの挿入、など）を部分的にロールバックすることができます。 savepointsはトランザクションのエラーになる前に実行された有効な操作を継続またはコミットすることができます。 今のところ、どんなエラーもトランザクション全体を無効にするので、トランザクションのアボートが必要になります。
WALによって、データベースのオンラインバックアップとリストア（BAR）を行うための新しい方法を実装できる可能性があります。 この方法では、定期的にデータファイルを他のディスク、テープ、あるいは他のホストに保存し、またWALのログファイルをアーカイブする必要があります。 データファイルのコピーとアーカイブされたログを使って、クラッシュの後にリカバリを行ったのと同じ状態にリストアすることができます。 データベースファイルのコピーを作るたびに古いログファイルを削除してもかまいません。 この機能を実装するためには、データファイルとインデックスの生成と削除をロギングすることが必要です。 また、データファイルをコピーする手法を開発する必要があります（オペレーティングシステムの提供するコピーコマンドは使えません）。
これらの利点を実現する上での問題は、WAL エントリの保存を(例えば、トランザクションのUNDO を行う場合は起こり得るトランザクションの最長実行期間など)起こり得る期間行う必要があるということです。 現在の WAL の書式は、ディスクページのスナップショットを多く持つため、かなり大きなものです。 現時点では、保持する必要があるのは高々1,2回のチェックポイント期間分だけですので、これはあまり深刻な問題ではありませんが、この将来のメリットを達成するためには、何らかの圧縮された WAL 書式というものが必要になるものと考えています。