先看看pg都有哪些后端進程
[postgres@mingfan bin]$ ps -ef |grep postgres postgres 389889 1 0 22:11 ? 00:00:00 /usr/local/pgsql/bin/postgres -D ../data postgres 389891 389889 0 22:11 ? 00:00:00 postgres: checkpointer postgres 389892 389889 0 22:11 ? 00:00:00 postgres: background writer postgres 389893 389889 0 22:11 ? 00:00:00 postgres: walwriter postgres 389894 389889 0 22:11 ? 00:00:00 postgres: autovacuum launcher postgres 389895 389889 0 22:11 ? 00:00:00 postgres: stats collector postgres 389896 389889 0 22:11 ? 00:00:00 postgres: logical replication launcher
可以看到PostgreSQL后端是由稱為Postmaster（postgres）的主進程派生出來的進程的集合。
checkpoint的作用
checkpointer進程稱為檢查點進程，checkpoint操作會將某個時間點之前的臟數據都刷新到磁盤。
PostgreSQL在崩潰恢復時會以最近的checkpoint為基礎，不斷應用這之后的WAL日志。
簡單來講
我的數據庫突然崩潰了，數據庫重新啟動的時候會去讀取檢查點，假定最近的檢查點在10min前，則數據庫會從該檢查點開始應用檢查點之后的wal日志進行數據恢復，假定最近的檢查點在5min前，那數據庫只需要重放數據庫崩潰前5min的wal日志就能成功恢復數據了，這樣做的目的是為了縮短數據庫故障后的恢復時間
checkpoint的相關參數
postgresql.conf文件中的相關參數如下：
# - Checkpoints - #checkpoint_timeout = 5min # range 30s-1d max_wal_size = 1GB min_wal_size = 80MB #checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0 #checkpoint_flush_after = 256kB # measured in pages, 0 disables #checkpoint_warning = 30s # 0 disables
lcheckpoint_timeout：此參數配置檢查點的執行周期。默認值是5分鍾。這意味着每隔5分鍾就會出現一個檢查點，或者在即將超過max_wal_size時。默認是1 GB。
lmax_wal_size：此參數設置檢查點發生前的WAL的最大值。
lmin_wal_size：此參數設置了需要回收的以備將來使用的WAL文件總大小的最小值
lcheckpoint_completion_target：為了避免大量的頁面寫入對I/O造成沖擊，在檢查點期間寫入臟緩沖區的過程會分散一段時間。該周期由checkpoint_completion_target控制，它是檢查點間隔的一部分，默認為0.5，也就是說每個checkpoint需要在checkpoints間隔時間的50%內完成。
lcheckpoint_flush_after：當檢查點發生時，檢查點寫入的頁面大小超過本參數值時，將刷新到磁盤。否則，這些頁面可能會保存在操作系統的頁面緩存中。默認值為256kB。
lcheckpoint_warning：檢查點的操作是非常昂貴的。該參數在檢查點之間配置一個閾值，如果由於填充WAL segment files而導致的檢查點發生間隔小於本參數值，系統將在服務器日志中輸出一個警告，建議用戶增加max_wal_size，可以通過設置為0禁用。
checkpoint的發生時機
-
超級用戶（其他用戶不可）執行CHECKPOINT命令
-
數據庫shutdown
-
數據庫recovery完成
-
XLOG日志量達到了觸發checkpoint閾值
-
周期性地checkpoint
-
需要刷新所有臟頁
如何查看checkpoint相關信息
可以通過pg_controldata進行查看
pg_controldata ../data --- [postgres@iZbp1fpui5cmgd2buwhk5fZ bin]$ ./pg_controldata ../data/ pg_control version number: 1300 Catalog version number: 202007201 Database system identifier: 6893496605411273979 Database cluster state: in production pg_control last modified: Tue 10 Nov 2020 11:32:32 PM CST Latest checkpoint location: 0/155E200 Latest checkpoint's REDO location: 0/155E1C8 Latest checkpoint's REDO WAL file: 000000010000000000000001 Latest checkpoint's TimeLineID: 1 Latest checkpoint's PrevTimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0:486 Latest checkpoint's NextOID: 24576 Latest checkpoint's NextMultiXactId: 1 Latest checkpoint's NextMultiOffset: 0 Latest checkpoint's oldestXID: 478 Latest checkpoint's oldestXID's DB: 1 Latest checkpoint's oldestActiveXID: 486 Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 1 Latest checkpoint's oldestCommitTsXid:0 Latest checkpoint's newestCommitTsXid:0 Time of latest checkpoint: Tue 10 Nov 2020 11:32:32 PM CST Fake LSN counter for unlogged rels: 0/3E8 Minimum recovery ending location: 0/0 Min recovery ending loc's timeline: 0 Backup start location: 0/0 Backup end location: 0/0 End-of-backup record required: no wal_level setting: replica wal_log_hints setting: off max_connections setting: 100 max_worker_processes setting: 8 max_wal_senders setting: 10 max_prepared_xacts setting: 0 max_locks_per_xact setting: 64 track_commit_timestamp setting: off Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Maximum size of a TOAST chunk: 1996 Size of a large-object chunk: 2048 Date/time type storage: 64-bit integers Float8 argument passing: by value Data page checksum version: 0 Mock authentication nonce: 947e012a07d79fb1072fe46c80a49cdb772cf39fdbf2fe47863ac82d1b0ef2c4