在T1，数据库成功执行checkpoint；
在T2，执行DML语句，这时候相关的数据会写入到WAL中（此处忽略了WAL buffer）；
在T3，提交该事务；
在T4，bgwriter把dirty pages写入到Data file中，但在写入过程中机器出现故障导致Crash（如掉电等），出现了部分写的情况。
为了应对这种情况，PG在T2写入WAL的时候，会把出现变化的page整页写入到WAL中，而不仅仅是tuple data。在数据库重启执行恢复的时候，在Redo point开始回放WAL时，如发现XLOG Record是FPI（full-page-image），则整页替换，通过这种机制解决了部分写的问题。
创新互联公司-专业网站定制、快速模板网站建设、高性价比龙潭网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式龙潭网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖龙潭地区。费用合理售后完善，十多年实体公司更值得信赖。
当然这种机制不是免费的，其主要的负面影响是写放大。
由于整页写，不可避免的出现冗余数据；考虑这么一种情况：如果数据库很繁忙，而且数据的热点分散在不同的table上，同时checkpoint执行间隔较短，那非常多的page就会通过full-page-write写入的WAL中，导致日志空间快速膨胀。在极端情况下，page“满载”（基本没有空闲空间）的情况下更新其中一条记录都会导致整页写入WAL。
关于这部分的机制和解决方案，参考资料中的《如何遏制PostgreSQL WAL的疯狂增长》有详细论述。
Write Ahead Logging — WAL
如何遏制PostgreSQL WAL的疯狂增长
PostgreSQL 可靠性分析 - 关于redo block原子写
