Second, process system and memory layout
Process system
PostgreSQL is a multi-process DBMS. The PostgreSQL server is managed by a set of server processes
- The PostgreSQL Server process is the parent of all PG-related processes.
- Each Backend process manages all execution statements and state at the connection end.
- Background processes Perform database management, such as VACUUM and Checkpoint.
- In the flow replication process, you are responsible for flow replication operations
- In worker processes, user related processing can be performed.
Master server process
Slave service process
General layout
The Postgres service process
Run the pg_ctl command line tool to start the PG service. Next, shared memory is allocated in memory, and several background processes, stream replication processes and, if there is a client connection, the WORKER process of PG is started. Whenever a new request is received from the client, a new back-end process is started.
The back-end process
With a client connection, a new Postgres process is forked; One TCP connection corresponds to one process. A process can only operate on one database, which is specified in the connection configuration item when connecting to the Pg server. Pg allows simultaneous connections to multiple clients. The maximum number of client connections is set in the configuration file (max_connections). Pg has no connection pool, but has pgBouncer and PGPool2 middleware.
Background processes
The process of | describe |
---|---|
background writer | In this process, dirty page data in the shared buffer is periodically written to the hard disk |
checkpointer | checkpoint |
autovacuum launcher | Periodically run the vacuum command |
WAL writer | Periodically write and refresh WAL data from the WAL buffer => disks |
statistics collector | Collect statistics, such as data stored in pg_stat_activity or pg_stat_database |
logging collector | Write error logs to log files |
archiver | Performing archiving operations |
Memory layout
The memory layout of PostgreSQL can be divided into two sections
- Process memory area, which is allocated for use by each background process
- Shared memory domain, common to PG server processes.
A block of memory in a back-end process
The name |
---|
temp_buffers |
work_mem |
maintenance_work_mem |
Memory blocks in shared memory
The name |
---|
shared buffer pool |
wal buffer |
CommitLog(CLOG) |
A block of memory within a process
Each back-end process allocates a block of memory for query processing; Each region is isolated by a number of subdomains, each of which may be fixed or variable in size.
Subdomain said | describe |
---|---|
work_mem | Used for Order BY, Distinct, table join, etc |
maintenance_work_mem | Perform administrative operations, such as VACUUM and REINDEX |
temp_buffers | Used to store temporary tables |
Memory blocks that share memory
Shared memory is allocated when the Pg service is started. Multiple memory blocks are distributed in shared memory.
Subdomain said | describe |
---|---|
shared buffer pool | Pg loads “pages” directly from the hard drive into memory |
wal buffer | To ensure that data is not lost in the event of a service crash, PG uses WAL technology. Wal data (also known as Xlog records) is the transaction log in PG; Wal Buffer is the buffer before WAL data is written to disks |
commit log | CLOG keeps all transaction states, such as IN_PROGRESS, COMMITTED, aborted, for concurrency control |
In addition, PG also allocates several blocks for display:
- Access controls such as semaphores, lightweight locks, shared locks, and exclusive locks
- Checkpointer, autovacuum
- Save point, two-phase commit