E.10. 版本 9.4.17 #
发布日期:. 2018-03-01
本发行版包含对 9.4.16 的多项修复。有关 9.4 主版本中新功能的信息,请参见第 E.27 节。
E.10.1. 迁移到版本 9.4.17
对于运行 9.4.X 的用户,不需要转储/恢复。
不过,如果你运行的安装中并非所有用户都相互信任,或者你维护打算在任意场合使用的应用或扩展,强烈建议阅读下面第一条变更日志条目所述的文档更改,并采取适当步骤确保你的安装或代码安全。
另外,下面第二条变更日志条目所述的更改可能导致索引表达式或物化视图中使用的函数在自动分析期间或从转储重新装载时失败。升级之后,请监控服务器日志中此类问题,并修复受影响的函数。
另外,如果你是从 9.4.13 之前的版本升级,参见第 E.14 节。
E.10.2. 变更
记录如何配置安装和应用以防受其他用户依赖 search_path 的特洛伊木马攻击(Noah Misch)
使用包含任何可被恶意用户写入的模式的
search_path设置,会使该用户能够截获查询的控制,然后以被攻击用户的权限运行任意 SQL 代码。虽然可以写出能防范此类劫持的查询,但记法上很繁琐,而且很容易遗漏漏洞。因此,我们现在推荐不把任何不受信任模式放入搜索路径的配置。相关文档见第 5.7.6 节(面向数据库管理员和用户)、第 31.1 节(面向应用作者)、第 35.15.1 节(面向扩展作者)和CREATE FUNCTION(面向SECURITY DEFINER函数的作者)。(CVE-2018-1058)避免在 pg_dump 和其他客户端程序中使用不安全的
search_path设置(Noah Misch、Tom Lane)pg_dump、pg_upgrade、 vacuumdb 等 PostgreSQL 自带的应用本身也容易受到上一条变更日志条目所述劫持的影响;由于这些应用通常由超级用户运行,它们是特别有吸引力的目标。为使它们无论整个安装是否已被加固都安全,修改它们使其
search_path设置只包含pg_catalog模式。自动清理工作者进程现在也同样如此。当用户提供的函数被这些程序间接执行时(例如索引表达式中的用户提供函数),更严格的
search_path可能导致错误,需要通过调整这些用户提供的函数使其不对被调用时的搜索路径做任何假定来更正。这从来都是良好实践,但现在这是正确行为的必要条件。(CVE-2018-1058)修复子计划中出现 CTE 引用时并发更新重检查的错误行为(Tom Lane)
如果 CTE(
WITH子句引用)被用于 InitPlan 或 SubPlan,且查询因试图更新或锁定并发更新的行而需要重检查,可能得到错误结果。修复外连接中重叠 mergejoin 子句导致的规划器失败(Tom Lane)
这些错误在边界情况下导致 “left and right pathkeys do not match in mergejoin” 或 “outer pathkeys do not match mergeclauses” 规划器错误。
修复 pg_upgrade 未能为物化视图保留
relfrozenxid的问题(Tom Lane、Andres Freund)这一疏漏可能导致升级后物化视图中的数据损坏,表现为 “could not access status of transaction” 或 “found xmin from before relfrozenxid” 错误。很少刷新的物化视图,或只用
REFRESH MATERIALIZED VIEW CONCURRENTLY维护的物化视图更可能出现问题。如果观察到这种损坏,可以通过刷新物化视图(不带
CONCURRENTLY)来修复。修复错误
CONTEXT栈中 PL/Python 函数名的错误报告(Tom Lane)嵌套 PL/Python 函数调用(即通过 SPI 查询从另一个 PL/Python 函数到达的调用)中发生的错误会导致栈跟踪把内层函数名显示两次,而不是预期的结果。此外,嵌套 PL/Python
DO块中的错误在某些平台上可能导致空指针解引用崩溃。允许
contrib/auto_explain的log_min_duration设置范围达到INT_MAX,即约 24 天而不是 35 分钟(Tom Lane)