E.13.版本 10.1

发布日期: 2017-11-09

此版本包含自 10.0 起的各种修复程序。有关主要版本 10 中新功能的信息,请参阅Section E.14

E.13.1. 迁移到版本 10.1

运行 10.X 的用户不需要转储/还原。

但是,如果使用 BRIN 索引,请参阅下面的第四个更改日志条目。

E.13.2. Changes

INSERT ... ON CONFLICT DO UPDATE的更新路径需要对仲裁者索引的列具有SELECT权限,但是在由约束名称指定的仲裁者的情况下,它无法进行检查。此外,对于启用了行级安全性的表,它无法根据表的SELECT策略检查更新的行(无论如何指定仲裁索引)。 (CVE-2017-15099)

这些函数使用FROM ... AS子句中指定的结果行类型,而不检查它是否与提供的 Tuples 值的实际行类型匹配。如果不这样做,通常也可能导致崩溃,尽管服务器内存内容的泄漏似乎也可能出现。 (CVE-2017-15098)

以前,postmaster 日志文件是在仍以 root 用户身份运行时打开的。因此,数据库所有者可以通过将$PGLOG设置为某个其他文件的符号链接来对另一个系统用户发起攻击,然后通过附加日志消息来破坏该文件。

默认情况下,这些脚本未安装在任何地方。使用它们的用户将需要手动重新复制它们,或将相同的更改应用于其修改后的版本。如果现有的$PGLOG文件是 root 所有者的文件,则需要使用正确的脚本重新启动服务器之前,将其删除或重命名。 (CVE-2017-12172)

以前,竞争条件允许某些表行从索引中省略。可能需要重新索引现有的 BRIN 索引,以从以前出现的此问题中恢复过来。

这些竞争条件可能会导致错误,例如“无效索引 offnum”或“不一致的范围图”。

以前,除非表也具有BEFORE ROW UPDATE触发器,否则此操作不会发生。

这将还原附加到 DML 命令的 CTE 的 v10 之前的行为。

这将还原 v10 之前的版本(和 SQL 标准)的行为。

缺少这些依赖关系可能会使列或数据类型DROP在应该失败的情况下通过,从而导致以后使用视图或规则来获取错误。该修补程序不执行任何保护现有视图/规则的操作,仅用于将来创建的视图/规则。

计划者错误地假定可以将任何范围类型进行哈希处理以用于哈希联接或哈希聚合,但是实际上,它必须检查范围的子类型是否具有哈希支持。这不会影响任何内置范围类型,因为它们都是可哈希的。

例如,这可以正确使用varchar列的扩展统计信息。

这会导致内置的有序集合聚合以及用户编写的聚合崩溃。 v11 及更高版本将包含安全处理此类情况的规定,但在已发布的分支中,只需禁用优化即可。

如果一个会话不执行任何查询,而仅侦听通知,则涉及超过 20 亿笔 Transaction,那么它将开始错过并发事务中的某些通知。

先前的错误修复无意中破坏了这种情况。

这样可以防止在安装 parray_ginextensions 时出现问题,因为它定义了一个冲突的运算符。

这在 Windows 上特别有用。

在 v10 中,尝试读取~/.pgpass时未能找到主目录被视为一个硬错误,但这只会导致找不到该文件。读取~/.pg_service.conf时,v10 和先前发行版分支都犯了相同的错误,尽管这种情况不太明显,因为除非指定了服务名称,否则不会查找该文件。

某些旨在像make check一样工作的非默认测试过程未能确保临时安装是最新的。

由于更改了工具链,因此 10.0 用户手册中的页面内锚点使用小写字符串,从而使某些外部链接中断了我们的网站文档。返回到我们以前使用大写字符串的约定。

上一章 首页 下一章