E.10.版本 10.4

发布日期： 2018-05-10

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

E.10.1. 迁移到版本 10.4

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

但是，如果使用adminpackextensions，则应按照下面的第一个更新日志条目对其进行更新。

同样，如果下面第二和第三条变更日志条目中提到的标记错误的功能影响您，您将需要采取步骤来更正数据库目录。

另外，如果要从 10.3 之前的版本升级，请参见Section E.11。

E.10.2. Changes

pg_logfile_rotate()是核心函数pg_rotate_logfile()的弃用包装器。当该函数更改为依靠 SQL 特权进行访问控制而不是硬编码的超级用户检查时，pg_logfile_rotate()也应该也已更新，但是错过了这样做的需要。因此，如果安装了adminpack，则任何用户都可以请求轮换日志文件，从而产生较小的安全性问题。

安装此更新后，Management 员应通过在每个安装了adminpack的数据库中执行ALTER EXTENSION adminpack UPDATE来更新adminpack。 (CVE-2018-1115)

函数query_to_xml，cursor_to_xml，cursor_to_xmlschema，query_to_xmlschema和query_to_xml_and_xmlschema应该标记为易失性，因为它们执行用户提供的查询，其中可能包含易失性操作。否则，可能导致错误的查询优化风险。通过更正初始目录数据已针对新安装修复了该问题，但是现有安装将 continue 包含不正确的标记。实际使用这些功能似乎没有什么危害，但是在出现故障的情况下，可以通过手动更新这些功能的pg_proc条目(例如ALTER FUNCTION pg_catalog.query_to_xml(text, boolean, boolean, text) VOLATILE)来解决。 (请注意，这需要在安装的每个数据库中完成.)另一种选择是将数据库 pg_upgrade 到一个包含更正后的初始数据的版本。

函数brin_summarize_new_values，brin_summarize_range，brin_desummarize_range，gin_clean_pending_list，cursor_to_xml，cursor_to_xmlschema，ts_rewrite，ts_stat，binary_upgrade_create_empty_extension和pg_import_system_collations应当标记为不安全；一些原因是因为它们直接执行数据库修改，而其他原因是因为它们执行用户提供的查询，而这样做可能会这样做。它们被标记为并行限制，从而导致意外查询错误的风险。通过更正初始目录数据已针对新安装修复了该问题，但是现有安装将 continue 包含不正确的标记。除非打开force_parallel_mode，否则实际使用这些功能似乎没有什么危险。发生故障时，可以通过手动更新这些功能的pg_proc条目(例如ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass) PARALLEL UNSAFE)来解决。 (请注意，这需要在安装的每个数据库中完成.)另一种选择是将数据库 pg_upgrade 到一个包含更正后的初始数据的版本。

一旦 OID 计数器结束，就可以分配一个 OAST 值，该值的 OID 与同一 TOAST 表中先前删除的条目相匹配。如果该条目尚未被清除，则将导致“ Toast 值* nnnnn *出现意外的块号 0(预期的 1)”错误，该错误将一直持续到被VACUUM删除无效条目为止。通过在创建新的 TOAST 条目时不选择此类 OID 来解决。

以前，仅检查为整个分区表声明的约束。

以前，布尔分区列仅接受字串值。但是然后 pg_dump 将打印诸如TRUE或FALSE之类的值，从而导致转储/重新加载失败。

使用用户定义的运算符类作为分区键时，此错误可能导致崩溃。

以前，未通过ANALYZE实际扫描的页面被假定为保留其旧的 Tuples 密度。在ANALYZE仅对页面的一小部分进行采样的大表中，这意味着总体 Tuples 密度估计值不会发生很大变化，因此reltuples几乎与表的物理大小(relpages)的变化成比例地变化。实际发生在桌子上。已经观察到，这导致reltuples变得比实际情况大得多，从而有效地关闭了自动真空。要修复，假设ANALYZE的 samples 是表格的统计上无偏的 samples(应该如此)，并且只是将在这些页面内观察到的密度外推到整个表格。

此外，还添加INCLUDING STATISTICS选项，以更精细地控制是否发生这种情况。

在long是 32 位的平台(包括 64 位 Windows 以及大多数 32 位计算机)上，复制的序列参数将被截断为 32 位。

当该错误应为外部联接的原始条件“过滤器”时，可能导致将条件错误分类为外部联接的“联接过滤器”，从而导致错误的联接输出。

例如，这可以允许约束排除来排除不应从查询中排除的子表。

如果某些 Tuples 被锁定(但未删除)，则可能会发生这种情况。尽管查询仍然可以正常运行，但真空通常会忽略此类页面，这会长期影响 Tuples 永远不会被冻结。在最新版本中，这最终会导致错误，例如“从 relminmxid * nnnnn *之前找到 multixact * nnnnn *”。

从 9.2 或更早版本进行 pg_upgrade 的数据库中，这可能会导致错误的“无法冻结已提交的 xmax”故障。

先前的行为在具有多个表的数据库中导致潜在的工作程序并发性大量丢失。

以前，所谓的本地快照包含指向共享内存的指针，如果现有会话断开连接，则允许 Client 端主机名列发生意外更改。

application_name，client_hostname和query字段可能显示不正确的数据。

这样的搜索将在大多数非 C 语言环境中返回错误的行集。

以前，据报 Tuples 计数与基础表的计数相同，如果索引是部分索引，则这是错误的。

以前，它报告了估计的堆 Tuples 数，这可能是不准确的，并且如果索引是局部的，则肯定是错误的。

在处理错误消息之前(而不是之后)，丢弃先前的输出。在某些平台上，尤其是 Linux，这可能会影响应用程序的后续内存占用。

pg_dump 输出中未正确引用local_preload_libraries，session_preload_libraries，shared_preload_libraries和temp_tablespaces变量。如果这些变量的设置出现在CREATE FUNCTION ... SET或ALTER DATABASE/ROLE ... SET子句中，则将导致问题。

先前的修复导致 pg_recvologic 不管服务器版本如何都发出命令，但是该命令只能发布给 v10 及更高版本的服务器。

否则，可能导致目标上的数据不一致，特别是如果所涉及的文件是 WAL 段时。

先前的编码未能在某些非 gcc 编译器上检测到循环变量的溢出，从而导致无限循环。

修复可能从索引中删除表的最后一个 Tuples 的情况。如果它是部分索引，则正确计算索引 Tuples 的数量。

这修复了 zic 时区数据编译器以应对负的夏时制偏移量的问题。尽管 PostgreSQL 项目不会立即提供此类时区数据，但 zic 可能与直接从 IANA 获得的时区数据一起使用，因此现在更新 zic 似乎是审慎的做法。

上一章 首页 下一章