发布日期:. 2015-06-12
这个版本包含少量来自9.4.3的补丁。关于9.4主版本的新特性信息,请查看第 E.36 节。
运行9.4.X版本的用户不需要转储/恢复。
不过,如果你正在升级一个以前使用9.3.0到9.3.4之间的pg_upgrade 版本升级的安装,请查看下面的第一个更新日志条目。
另外,如果你从一个早于9.4.2的版本升级而来,请查看第 E.34 节。
修复可能的失败,以便从一个不一致的数据库状态中恢复 (Robert Haas)
最近的PostgreSQL版本引入了防范multixact概括的机制, 但是一些代码并没有说明数据库不在一个一致的状态时,它需要在崩溃恢复期间运行的可能性。 这会导致崩溃后未能重启或未能启动辅助服务器。在pg_upgrade 中以前修复的一个bug一直存在的影响也会导致这样的失败, 在曾经使用版本9.3.0和9.3.4的pg_upgrade的安装中。
正在讨论的pg_upgrade bug,可以设置pg_control
中的
oldestMultiXid
为1,即使真值应该更高些。由于在这些版本中引入的修复,
这样的情况将导致立即紧急清理,直到可以确定一个正确的oldestMultiXid
值。
如果这会造成困难,用户可以在升级到这个版本之前,通过手动清理来避免。详细:
检查pg_controldata是否报告“最近检查点的oldestMultiXid”为1。 如果不,则什么都不用做。
查看PGDATA/pg_multixact/offsets
,看看是否有一个名为0000
的文件。
如果有,则什么都不用做。
否则,对于每个表都有pg_class
.relminmxid
等于1,
vacuum_multixact_freeze_min_age和
vacuum_multixact_freeze_table_age都设置为零VACUUM
该表。
(你可以使用第 19.4.4 节
中描述的清理开销延迟参数来降低对当前会话的性能影响。)
修复关系缓存初始化文件失效的罕见失败 (Tom Lane)
由于并发活动正好发生在错误的时间,在一个系统目录上的VACUUM
FULL
可能会未能更新用于避免新会话缓存加载工作的“初始化文件”。
这会导致稍后的会话不能访问该目录。这是一个非常老的bug,
但是它非常难以触发,一直没有看到可复制的情况直到最近。
避免传入的会话和CREATE/DROP DATABASE
之间的死锁 (Tom Lane)
在数据库中开始的新会话是DROP DATABASE
命令的目标,
或者是CREATE DATABASE
命令的模板,会导致命令等待5秒钟然后失败,
即使新的会话在这之前退出。
改善半连接和反连接内部索引扫描的规划器的开销估计 (Tom Lane, Tomas Vondra)
当所有连接子句都用作索引扫描条件时,这种类型的规划是相当便宜的, 即使内部扫描将名义上获取许多行,因为执行器将在获得一行之后停止。 规划器只是部分的解释那个影响,并且因此高估开销, 导致它有可能选择一些其他更小影响的规划类型。