E.9. 版本 9.4.4

E.9.1. 迁移到版本 9.4.4

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

不过，如果你正在升级一个以前使用9.3.0到9.3.4之间的pg_upgrade 版本升级的安装，请查看下面的第一个更新日志条目。

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

E.9.2. 修改列表

• 修复可能的失败，以便从一个不一致的数据库状态中恢复 (Robert Haas)

  最近的PostgreSQL版本引入了防范multixact概括的机制， 但是一些代码并没有说明数据库不在一个一致的状态时，它需要在崩溃恢复期间运行的可能性。 这会导致崩溃后未能重启或未能启动辅助服务器。在pg_upgrade 中以前修复的一个bug一直存在的影响也会导致这样的失败， 在曾经使用版本9.3.0和9.3.4的pg_upgrade的安装中。

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

  1. 检查pg_controldata是否报告"最近检查点的oldestMultiXid"为1。 如果不，则什么都不用做。

  2. 查看PGDATA/pg_multixact/offsets，看看是否有一个名为0000的文件。 如果有，则什么都不用做。

  3. 否则，对于每个表都有pg_class.relminmxid等于1， vacuum_multixact_freeze_min_age和 vacuum_multixact_freeze_table_age都设置为零VACUUM该表。 （你可以使用第 18.4.4 节 中描述的清理开销延迟参数来降低对当前会话的性能影响。）

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

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

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

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

• 改善半连接和反连接内部索引扫描的规划器的开销估计 (Tom Lane, Tomas Vondra)

  当所有连接子句都用作索引扫描条件时，这种类型的规划是相当便宜的， 即使内部扫描将名义上获取许多行，因为执行器将在获得一行之后停止。 规划器只是部分的解释那个影响，并且因此高估开销， 导致它有可能选择一些其他更小影响的规划类型。