Whenever the checkpointer starts, it writes a XLOG record called checkpoint record to the current WAL segment. (1) A checkpointer, a background process, periodically performs checkpointing. ‘ TABLE_A's LSN’ shows the value of pd_lsn within the page-header of TABLE_A. In fact, the database recovery processing is strongly linked to the checkpoint processing and both of these processing are inseparable. LSN of record is used as the unique id of XLOG record.īy the way, when we consider how database system recovers, there may be one question what point does PostgreSQL start to recover from? The answer is REDO point that is, the location to write the XLOG record at the moment when the latest checkpoint is started (checkpoint in PostgreSQL is described in Section 9.7). The details will be described in Section 9.5.) LSN (Log Sequence Number) of XLOG record represents the location where its record is written on the transaction log. (To be precise, the writing of XLOG records may occur in other cases. They are immediately written into a WAL segment file on the storage when a transaction commits/aborts. XLOG records are written into the in-memory WAL buffer by change operations such as insertion, deletion, or commit action. In PostgreSQL, the history data are known as XLOG record(s) or WAL data. PostgreSQL writes all modifications as history data into a persistent storage, to prepare for failures. In this subsection, some keywords and key concepts, and then the writing of WAL data and the recovering of the database are described. To deal with the system failures mentioned above without compromising performance, PostgreSQL supports the WAL. The logical and physical structures of the WAL (transaction log).In the subsequent sections, the following topics are described: In the first section, the overall picture of the WAL has been provided, introducing some important concepts and keywords. So the complete explanation of WAL in PostgreSQL is made as follows. It also made possible the implementation of the Point-in-Time Recovery (PITR) and Streaming Replication (SR), both of which are described in Chapter 10 and Chapter 11 respectively.Īlthough understanding of the WAL mechanism is essential for system integrations and administrations using PostgreSQL, the complexity of this mechanism makes it impossible to summarize its description in brief. The WAL mechanism was first implemented in version 7.1 to mitigate the impacts of server crashes. Though this is a little confusing, in this document the PostgreSQL definition has been adopted. There the term is used as synonym of transaction log, and also used to refer to an implemented mechanism related to writing action to a transaction log (WAL). In the field of computer science, WAL is an acronym of Write Ahead Logging, which is a protocol or a rule to write both changes and actions into a transaction log, whereas in PostgreSQL, WAL is an acronym of Write Ahead Log. As the log contains sufficient information about each transaction executed already, the database server should be able to recover the database cluster by replaying changes and actions in the transaction log in case of the server crash. It is a history log of all changes and actions in a database system so as to ensure that no data has been lost due to failures, such as a power failure, or some other server failure that causes the server crash. Transaction log is an essential part of database, because all of the database management system is required not to lose any data even when a system failure occurs. 11.4 Detecting Failures of Standby Servers.11.3 Managing More Than One Standby Server.11.1 Starting the Streaming Replication.10.4 Point-in-Time Recovery with Timeline History File.10.3 timelineId and Timeline History File.
#Postgresql stat transfer cross reference archive
9.10 Continuous Archiving and Archive Logs.9.2 Transaction Log and WAL Segment Files.Heap Only Tuple (HOT) and Index-Only Scans 5.3 Inserting, Deleting, and Updating Tuples.Foreign Data Wrappers (FDW) and Parallel Query 3.6 Creating the Plan Tree of Multiple-Table Query.3.3 Creating the Plan Tree of a Single-Table Query.3.2 Cost Estimation in Single-Table Query.1.4 The Methods of Writing and Reading Tuples.1.3 Internal Layout of a Heap Table File.1.2 Physical Structure of Database cluster.1.1 Logical Structure of Database cluster.