我知道 PostgreSQL 检查点是什么以及它何时发生。
我需要一些关于参数产生的日志的额外信息log_checkpoints = on，所以请向我解释一下它的一些要点：
2017-09-09 16:31:37 EEST [6428-6524] LOG: checkpoint complete: wrote 30057 buffers (22.9%); 0 transaction log file(s) added, 0 removed, 47 recycled; write=148.465 s, sync=34.339 s, total=182.814 s; sync files=159, longest=16.143 s, average=0.215 s
- 我知道 22.9% 的共享缓冲区被写入（我有 1024 MB
shared_buffers，这意味着 234 MB 被写出）。 - 我知道有 47 个 WAL 文件被回收，即不再需要它们来进行崩溃恢复，因为来自它们的真实数据已经在磁盘上。
问题A。但是write=148.465 s和sync=34.339呢？有什么区别？什么是write，为什么它的时间远远超过fsync()操作？
问题B。是什么sync files？哪些文件：WAL 文件？为什么sync files是159个，而回收的文件却只有47个？这些之间有什么关系？
谢谢！
写入和同步阶段意味着完全不同的事情（不幸的是）。在检查点的中间阶段，它会从共享缓冲区中写出所有脏缓冲区。它以节流的方式执行此操作，主要由 checkpoint_completion_target 调节。此处报告的时间是写入这些缓冲区所花费的时间，以及为了调节缓冲区写入速率而花费的睡眠时间。所以并不是所有的“写”时间都花在了积极的写作上。在不知道您的其他设置是什么的情况下，写入阶段花费的时间长度（2.5 分钟）并没有任何意义。
在同步阶段，它会同步它刚刚写入的所有文件（以及其他进程可能写入的任何数据文件）。这个阶段是不受限制的，它会尽可能快地同步它们。这需要 34 秒，其中一个文件需要 16.143 秒，这表明您的 IO 硬件无法满足您投入的工作负载。
159个同步文件是指自上一个checkpoint结束后被弄脏的数据文件数，因此需要在本次结束前同步。47 指的是 WAL 文件，而不是数据文件。WAL 文件包含对数据文件所做更改的引用。47 个 WAL 文件很容易包含 159 个数据文件（或就此而言，15,900 个数据文件）的引用。但这并不是那么简单，因为被回收的 WAL 文件是来自两个检查点之前的文件，所以 47 和 159 之间的关系是一个类比，而不是具体的计数。
对于您的问题A：“写”和“同步”的意思正是他们所说的；它是从 Postgres 缓冲池中对脏页进行缓冲（如在文件系统 I/O 缓冲区中）写入的序列，然后
fsync()（通常）确保文件系统缓冲区实际上已写入磁盘。写入受到限制并在后台发生，因此它们可能需要更长的时间。对于您的问题 B：
sync files告诉您检查点影响了多少操作系统文件。由于每个表和索引都存储在自己的文件中，因此该数字可以让您了解检查点影响了多少数据库对象。WAL 在刷新 WAL 缓冲区时同步，即在检查点之前；这就是为什么它被称为“提前写”。