Movatterモバイル変換

WAL is automatically enabled; no action is required from the administrator except ensuring that the disk-space requirements for theWAL files are met, and that any necessary tuning is done (seeSection 28.5).

WAL records are appended to theWAL files as each new record is written. The insert position is described by a Log Sequence Number (LSN) that is a byte offset into the WAL, increasing monotonically with each new record.LSN values are returned as the datatypepg_lsn. Values can be compared to calculate the volume ofWAL data that separates them, so they are used to measure the progress of replication and recovery.

WAL files are stored in the directorypg_wal under the data directory, as a set of segment files, normally each 16 MB in size (but the size can be changed by altering the--wal-segsizeinitdb option). Each segment is divided into pages, normally 8 kB each (this size can be changed via the--with-wal-blocksize configure option). The WAL record headers are described inaccess/xlogrecord.h; the record content is dependent on the type of event that is being logged. Segment files are given ever-increasing numbers as names, starting at000000010000000000000001. The numbers do not wrap, but it will take a very, very long time to exhaust the available stock of numbers.

It is advantageous if the WAL is located on a different disk from the main database files. This can be achieved by moving thepg_wal directory to another location (while the server is shut down, of course) and creating a symbolic link from the original location in the main data directory to the new location.

The aim ofWAL is to ensure that the log is written before database records are altered, but this can be subverted by disk drives that falsely report a successful write to the kernel, when in fact they have only cached the data and not yet stored it on the disk. A power failure in such a situation might lead to irrecoverable data corruption. Administrators should try to ensure that disks holdingPostgreSQL'sWAL files do not make such false reports. (SeeSection 28.1.)

After a checkpoint has been made and the WAL flushed, the checkpoint's position is saved in the filepg_control. Therefore, at the start of recovery, the server first readspg_control and then the checkpoint record; then it performs the REDO operation by scanning forward from the WAL location indicated in the checkpoint record. Because the entire content of data pages is saved in the WAL on the first page modification after a checkpoint (assumingfull_page_writes is not disabled), all pages changed since the checkpoint will be restored to a consistent state.

To deal with the case wherepg_control is corrupt, we should support the possibility of scanning existing WAL segments in reverse order — newest to oldest — in order to find the latest checkpoint. This has not been implemented yet.pg_control is small enough (less than one disk page) that it is not subject to partial-write problems, and as of this writing there have been no reports of database failures due solely to the inability to readpg_control itself. So while it is theoretically a weak spot,pg_control does not seem to be a problem in practice.