Introduction
This document describes how to compile and install PostgreSQL on a Kunpeng server running CentOS or openEuler, and provides solutions to faults that may occur during PostgreSQL compilation and installation.
Overview
Figure 1 shows the PostgreSQL architecture. Table 1 describes the major processes.
Type |
Name |
Description |
|---|---|---|
Main process |
Postmaster |
As the first process to be started, Postmaster controls all the backend processes and is responsible for accepting and closing the database connections. By default, this process listens on UNIX domain sockets and TCP/IP port 5432 and waits for the frontend to process the connections. You can change the listening port number in the postgresql.conf file of PostgreSQL. |
Session service process |
Postgres |
This subprocess determines whether to allow a connection according to the security policy defined by the pg_hba.conf file. According to the security policy, this subprocess rejects certain IP addresses and networks, allows only certain users to connect to databases, or allows connections only to certain databases. Postgres receives the query from the frontend, retrieves data in the target database, and returns the result. It also updates the database. The updated data is recorded in transaction logs (also called WAL logs in PostgreSQL). When the system is powered off, or the server breaks down or is restarted, the logs can be used for data restoration. In addition, the logs can also be used for data restoration in other scenarios. In PostgreSQL 9.0 or later, WAL logs can be transferred to other PostgreSQL systems to implement real-time database replication. |
Auxiliary process |
Syslogger (system log process) |
The main process starts the Syslogger auxiliary process only when logging_collection in the Postgres.conf file is set to on. |
BgWriter (background write process) |
This process writes dirty pages from the shared memory to drives to improve the performance of data insertion, update, and deletion. |
|
WalWriter (write-ahead log process) |
This process writes modification operations into drives before data is modified so that the data does not need to be persisted into files in subsequent real-time data updates. |
|
PgArch (archiving process) |
WAL logs are recycled. The PgArch process is responsible for backing up WAL logs before they are overwritten. Starting from version 8.x, these WAL logs are used for Point-In-Time-Recovery (PITR), which restores the database state to a certain state at certain period of time. |
|
AutoVacuum (automatic clearing process) |
After performing a DELETE operation for a table in the PostgreSQL database, the old data is not deleted at once. In addition, when data is being updated, the old data is not directly updated but a new row of data is generated. Instead, the data will be marked as deleted by PostgreSQL's multi-version mechanism. If these old versions of data are being accessed by other transactions, it is necessary to retain them temporarily. After the transaction is submitted, the old versions of the data are no longer required (dead tuples) and the AutoVacuum process cleans up the data to make room. |
|
PgStat (statistics collection process) |
This process collects statistical information, such as the number of table additions, deletions, or updates, the number of data blocks, and changes in indexes. The collected statistical information is used for the query optimizer to make correct judgment and choose the best execution plan. The pg_statistic catalog stores the information collected by the PgStat process. |
|
CheckPoint (checkpoint process) |
The checkpointer is a sequence of transaction points set by the system. Setting the checkpoint ensures that the WAL log information before the checkpoint is flushed to drives. |
Development language: C/C++
Brief description: object-relational database management system
Recommended Software Version
PostgreSQL 11.3
