有没有被突发的IO惊到过，有没有见到过大量的autovacuum for prevent wrap。
本文依依解开这些头痛的问题。
PostgreSQL 的版本冻结是一个比较蛋疼的事情，为什么要做版本冻结呢？
因为PG的版本号是uint32的，是重复使用的，所以每隔大约20亿个事务后，必须要冻结，否则记录会变成未来的，对当前事务"不可见"。
冻结的事务号是2
src/include/access/transam.h
#define InvalidTransactionId ((TransactionId) 0)
#define BootstrapTransactionId ((TransactionId) 1)
#define FrozenTransactionId ((TransactionId) 2)
#define FirstNormalTransactionId ((TransactionId) 3)
#define MaxTransactionId ((TransactionId) 0xFFFFFFFF)
现在，还可以通过行的t_infomask来区分行是否为冻结行
src/include/access/htup_details.h
/*
* information stored in t_infomask:
*/
#define HEAP_XMIN_COMMITTED 0x0100 / t_xmin committed /
#define HEAP_XMIN_INVALID 0x0200 / t_xmin invalid/aborted /
#define HEAP_XMIN_FROZEN (HEAP_XMIN_COMMITTED|HEAP_XMIN_INVALID)
表的最老事务号则是记录在pg_class.relfrozenxid里面的。
执行vacuum freeze table，除了修改t_infomask，还需要修改该表对应的pg_class.relfrozenxid的值。
那么系统什么时候会触发对表进行冻结呢？
当表的年龄大于autovacuum_freeze_max_age时（默认是2亿），autovacuum进程会自动对表进行freeze。
freeze后，还可以清除掉比整个集群的最老事务号早的clog文件。
那么可能会出现这样的情形：
可能有很多大表的年龄会先后到达2亿，数据库的autovacuum会开始对这些表依次进行vacuum freeze，从而集中式的爆发大量的读IO（DATAFILE）和写IO（DATAFILE以及XLOG）。
如果又碰上业务高峰，会出现很不好的影响。
为什么集中爆发很常见？
因为默认情况下，所有表的autovacuum_freeze_max_age是一样的，并且大多数的业务，一个事务或者相邻的事务都会涉及多个表的操作，所以这些大表的最老的事务号可能都是相差不大的。
这样，就有非常大的概率导致很多表的年龄是相仿的，从而导致集中的爆发多表的autovacuum freeze。
PostgreSQL有什么机制能尽量的减少多个表的年龄相仿吗？
目前来看，有一个机制，也许能降低年龄相仿性，但是要求表有发生UPDATE，对于只有INSERT的表无效。
vacuum_freeze_min_age 这个参数，当发生vacuum或者autovacuum时，扫过的记录，只要年龄大于它，就会置为freeze。因此有一定的概率可以促使频繁更新的表年龄不一致。
那么还有什么手段能放在或者尽量避免大表的年龄相仿呢？
为每个表设置不同的autovacuum_freeze_max_age值，从认为的错开来进行vacuum freeze的时机。
例如有10个大表，把全局的autovacuum_freeze_max_age设置为5亿，然后针对这些表，从2亿开始每个表间隔1000万事务设置autovacuum_freeze_max_age。 如2亿，2.1亿，2.2亿，2.3亿，2.4亿....2.9亿。
除非这些表同时达到 2亿，2.1亿，2.2亿，2.3亿，2.4亿....2.9亿。 否则不会出现同时需要vacuum freeze的情况。
但是，如果有很多大表，这样做可能就不太合适了。
建议还是人为的在业务空闲时间，对大表进行vacuum freeze。
建议
1. 分区，把大表分成小表。每个表的数据量取决于系统的IO能力，前面说了VACUUM FREEZE是扫全表的， 现代的硬件每个表建议不超过32GB。
2. 对大表设置不同的vacuum年龄.
alter table t set (autovacuum_freeze_max_age=xxxx);
3. 用户自己调度 freeze，如在业务低谷的时间窗口，对年龄较大，数据量较大的表进行vacuum freeze。
4. 年龄只能降到系统存在的最早的长事务即 min pg_stat_activity.（backend_xid, backend_xmin）。 因此也需要密切关注长事务。