E.22.1. 迁移到版本 9.3.9

运行9.3.X版本的用户不需要转储/恢复。

不过，如果你正在升级一个以前使用pg_upgrade 版本9.3.0到9.3.4（包含）升级的安装，那么请查看下面的第一条修改日志项。

另外，如果你是从一个早于9.3.7的版本升级而来，请查看第 E.24 节。

E.22.2. 修改列表

• 修复从不一致的数据库状态恢复时可能的失败 (Robert Haas)

  最近的PostgreSQL版本引入了防卫multixact概括的机制， 但是这些代码没有考虑到当数据库在一个不一致的状态时， 它需要在崩溃恢复期间运行。这会导致在崩溃之后未能重启，或未能启动次要服务器。 之前在pg_upgrade中修复的bug，也会导致这样的失败， 在已经使用了pg_upgrade版本9.3.0到9.3.4的安装中。

  正在讨论的pg_upgrade错误将在pg_control 中将oldestMultiXid设置为1，即使实际值要高一些。 由于在这个版本中引入的修复，这样的情况将导致立即紧急的自动清理， 直到确定出一个正确的oldestMultiXid值。 如果这会造成困难，用户可以通过在升级到这个版本之前手动清理来避免它。 详细：

  1. 检查pg_controldata是否报告"Latest checkpoint's oldestMultiXid"为1。如果不，则什么也不需要做。

  2. 查看PGDATA/pg_multixact/offsets，看是否有个文件名叫0000。 如果有，则什么也不需要做。

  3. 否则，对于每个pg_class.relminmxid等于1的表， 将vacuum_multixact_freeze_min_age和 vacuum_multixact_freeze_table_age都设置为0， VACUUM该表。（你可以使用第 19.4.4 节 中描述的清理成本延迟参数，减少当前会话的性能后果。） 必须使用PostgreSQL 9.3.5或更高版本执行此步骤。

• 修复罕见的失败，无效关系缓存初始化文件 (Tom Lane)

  在错误的时间并发活动，系统目录上的VACUUM FULL可能会未能更新 "初始化文件"，初始化文件是用来避免新会话的缓存加载工作的。 这会导致稍后的会话完全不能访问该目录。这是一个非常老的bug， 但是因为很难触发它，所以直到最近才看到可再生的情况。

• 避免到来的会话和CREATE/DROP DATABASE之间的死锁 (Tom Lane)

  数据库中启动的一个新会话是DROP DATABASE命令的目标， 或者CREATE DATABASE命令的模板，会导致命令等待5秒钟然后失败， 即使新会话在此之前退出。

• 改善规划器对带有内部索引扫描的半连接和反连接的成本估计 (Tom Lane, Tomas Vondra)

  这种类型的规划在连接子句用作索引扫描条件时是相当便宜的， 即使内部扫描通常抓取很多行，因为执行器将在获取到一行之后停止。 规划器只负责部分结果，并且因此过高的评估成本， 导致它可能选择一些其他较低效率的规划类型。