PG以page(大小默认为8K)为基本的存储单元，但OS的存取单元（block）不一定是8k，常见的是4k，而且物理持久化存储块设备扇区大小是512字节，这些不一致的情况会导致PG page的读写不是原子操作，也就是说可能会出现page的部分写问题：
在写一个page的时候，部分写入成功但部分写入失败，这时候的page中的内容是不一致的，也就是说这个page已经被损坏（corrupted page）。为了解决这个问题，PG引入了full-page-write的机制。
一、full-page-write的机制
考察以下的情况（为方便起见，省略了buffer等相关的信息）：
full-page-write
在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），则整页替换，通过这种机制解决了部分写的问题。
二、full-page-write的代价
当然这种机制不是免费的，其主要的负面影响是写放大。
由于整页写，不可避免的出现冗余数据；考虑这么一种情况：如果数据库很繁忙，而且数据的热点分散在不同的table上，同时checkpoint执行间隔较短，那非常多的page就会通过full-page-write写入的WAL中，导致日志空间快速膨胀。在极端情况下，page“满载”（基本没有空闲空间）的情况下更新其中一条记录都会导致整页写入WAL。
关于这部分的机制和解决方案，参考资料中的《如何遏制PostgreSQL WAL的疯狂增长》有详细论述。
三、参考资料
Write Ahead Logging — WAL
如何遏制PostgreSQL WAL的疯狂增长
PostgreSQL 可靠性分析 - 关于redo block原子写
网友评论