先看看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