Chapter 11. Write-Ahead Logging (WAL)

11.1. the general description of the prewrite log (WAL) is a standard method for implementing transaction logs. A detailed description of the transaction can be found in most (if not all) related transactions. in short, the central idea of WAL is to modify data files (they are the carriers of tables and indexes) only after these modifications have recorded logs -- that is, after logging is flushed to permanent storage. if we follow this process, we do not need to fl data pages to the disk every time a transaction is committed, because we know that in the case of a crash, we can use logs to restore the database: Any record that has not been attached to the data page will be re-executed from the log record first (this is called forward rolling recovery, also called redo) then the changes made to those uncommitted transactions will be deleted from the data page (this is called Rollback Recovery-Undo ). 11.1.1. the first obvious advantage of using Wal from Wal is that it significantly reduces the number of disk writes. this is because only log files need to be flushed to the disk during log submission. In the user environment, the fsync () of log files can be used to commit many transactions. in addition, log files are written sequentially, so the overhead of log synchronization is far smaller than that of data pages. another benefit is the integrity of data pages. in fact, before Wal, PostgreSQL never guaranteed the integrity of data pages in the case of a crash. before Wal, any crashes during the write process may result in: index records point to a non-existent table. The row index records lose the completely crashed table and index page content during the split operation, because the data page only writes a part of the index (problem 1 and 2), it may have been fixed through an additional fsync () call, but if Wal is not available, there is no obvious way to deal with the third case; WAL stores the content of the entire data page in the log-if the content needs to ensure the integrity of the data page after crash recovery. 11.1.2. more benefits undo operations have not yet been implemented. This means that the modification made by the exited transaction will still occupy disk space, so we still need a permanent pg_clog file to save the transaction status, because we cannot recycle the transaction identifier. once Undo is implemented, pg_clog is no longer required to be permanent. We may delete pg_clog when it is disabled. (However, the urgency of this aspect has been reduced as we adopt the multipart storage method for pg_clog-we no longer need to keep the pg_clog record permanently .) with undo, we may also implement savepoints, so that part of the back-to-volume for illegal transaction operations can be allowed (because of the analyzer error caused by misrunning the command, inserts duplicate primary keys, unique key words, and so on. At the same time, the transaction can continue or commit legal operations before an error occurs. at present, any errors will make the entire transaction illegal and require the transaction to exit. wal also provides a new method for online database backup and recovery (bar. to use this method, we may need to regularly save data files to another disk, tape or another host, and back up Wal log files. therefore, database file copying and log archiving can be used to restore data as in disaster recovery. after the new database file is completed, the old log file can be deleted. to implement this facility, you may need to record the data files and index creation and deletion logs. At the same time, you also need to develop a method to copy the data files (which is not suitable for operating system copy commands ). one difficulty with understanding these things is that they require Wal logs to be saved within a considerable period of time (that is, if the transaction Undo is required, so it is as long as the longest possible transaction time ). the current Wal format is quite large because it includes images on multiple disk pages. at present, this is not a serious problem, because these logs only need to keep one or two checkpoint intervals. However, to implement these logs, we may need some compressed Wal format in the future.