pg_lsn. Values can be compared to calculate the volume of WAL data that separates them, so they are used to measure the progress of replication and recovery.
pg_walunder 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-blocksizeconfigure option). The log record headers are described in
access/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 at
000000010000000000000001. The numbers do not wrap, but it will take a very, very long time to exhaust the available stock of numbers.
pg_waldirectory 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.
pg_control. Therefore, at the start of recovery, the server first reads
pg_controland then the checkpoint record; then it performs the REDO operation by scanning forward from the log location indicated in the checkpoint record. Because the entire content of data pages is saved in the log on the first page modification after a checkpoint (assuming full_page_writes is not disabled), all pages changed since the checkpoint will be restored to a consistent state.
pg_controlis corrupt, we should support the possibility of scanning existing log segments in reverse order — newest to oldest — in order to find the latest checkpoint. This has not been implemented yet.
pg_controlis 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 read
pg_controlitself. So while it is theoretically a weak spot,
pg_controldoes not seem to be a problem in practice.