Future Benefits

PostgreSQL 7.4.18 Documentation
Prev | Fast Backward | Chapter 25. Write-Ahead Logging (WAL) | Fast Forward | Next

# 25.2. Future Benefits

The UNDO operation is not implemented. This means that changes made by aborted transactions will still occupy disk space and that a permanent `pg_clog` file to hold the status of transactions is still needed, since transaction identifiers cannot be reused. Once UNDO is implemented, `pg_clog` will no longer be required to be permanent; it will be possible to remove `pg_clog` at shutdown. (However, the urgency of this concern has decreased greatly with the adoption of a segmented storage method for `pg_clog`: it is no longer necessary to keep old `pg_clog` entries around forever.)

With UNDO, it will also be possible to implement savepoints to allow partial rollback of invalid transaction operations (parser errors caused by mistyping commands, insertion of duplicate primary/unique keys and so on) with the ability to continue or commit valid operations made by the transaction before the error. At present, any error will invalidate the whole transaction and require a transaction abort.

WAL offers the opportunity for a new method for database on-line backup and restore (BAR). To use this method, one would have to make periodic saves of data files to another disk, a tape or another host and also archive the WAL log files. The database file copy and the archived log files could be used to restore just as if one were restoring after a crash. Each time a new database file copy was made the old log files could be removed. Implementing this facility will require the logging of data file and index creation and deletion; it will also require development of a method for copying the data files (operating system copy commands are not suitable).

A difficulty standing in the way of realizing these benefits is that they require saving WAL entries for considerable periods of time (e.g., as long as the longest possible transaction if transaction UNDO is wanted). The present WAL format is extremely bulky since it includes many disk page snapshots. This is not a serious concern at present, since the entries only need to be kept for one or two checkpoint intervals; but to achieve these future benefits some sort of compressed WAL format will be needed.

Prev | Home | Next
Write-Ahead Logging (WAL) | Up | WAL Configuration