发布日期：. 2015-06-12
这个版本包含少量自9.3.8以来的修复。 关于9.3主版本的新特性信息，请查看第 E.57 节。
运行9.3.X版本的用户不需要转储/恢复。
不过，如果你正在升级一个以前使用pg_upgrade 版本9.3.0到9.3.4（包含）升级的安装，那么请查看下面的第一条修改日志项。
另外，如果你是从一个早于9.3.7的版本升级而来，请查看第 E.50 节。
修复从不一致的数据库状态恢复时可能的失败 (Robert Haas)
最近的PostgreSQL版本引入了防卫multixact概括的机制， 但是这些代码没有考虑到当数据库在一个不一致的状态时， 它需要在崩溃恢复期间运行。这会导致在崩溃之后未能重启，或未能启动次要服务器。 之前在pg_upgrade中修复的bug，也会导致这样的失败， 在已经使用了pg_upgrade版本9.3.0到9.3.4的安装中。
正在讨论的pg_upgrade错误将在pg_control
中将oldestMultiXid设置为1，即使实际值要高一些。
由于在这个版本中引入的修复，这样的情况将导致立即紧急的自动清理，
直到确定出一个正确的oldestMultiXid值。
如果这会造成困难，用户可以通过在升级到这个版本之前手动清理来避免它。
详细：
检查pg_controldata是否报告“Latest checkpoint's oldestMultiXid”为1。如果不，则什么也不需要做。
查看PGDATA/pg_multixact/offsets，看是否有个文件名叫0000。
如果有，则什么也不需要做。
否则，对于每个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)
这种类型的规划在连接子句用作索引扫描条件时是相当便宜的， 即使内部扫描通常抓取很多行，因为执行器将在获取到一行之后停止。 规划器只负责部分结果，并且因此过高的评估成本， 导致它可能选择一些其他较低效率的规划类型。