E.3. 11.6 版

发布日期： 2019-11-14

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

E.3.1. 迁移到版本 11.6

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

但是，如果您将contrib/intarrayextensions 与 GiST 索引一起使用，并且依赖于<@运算符的索引搜索，请参阅下面的条目。

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

E.3.2. Changes

以前，这是允许的，因此对现在不同步的父级的查询将失败。

这种情况将导致VACUUM失败，直到旧事务终止。

此错误导致计划人员将太多模式视为固定前缀，因此从ILIKE子句派生的 indexscans 可能会丢失他们应找到的条目。

当偏移量是非平凡的表达式时，这种疏忽可能导致各种各样的失败。一个示例是，如果内联函数，则此类表达式中的函数参数引用将失败。

以前，这种用法可能会导致有关行类型不匹配的虚假错误。

该错误应表明权限被拒绝，但是这种情况在代码重构期间被破坏了。

如果该行的可见版本进行了 HOT 更新，则该锁可能会在其已死的前任上获得锁定，从而导致微不足道的故障，无法保证序列化。

某些代码路径在以只读方式打开文件后尝试执行此操作，但是在某些平台上会导致“错误的文件 Descriptors”或类似错误。

以前，Importing 字符串的硬性限制为 0.25GB，但现在只要转换后的输出不超过 1GB，它就可以使用。

在此不再需要检查未记录的索引，并且该检查在某些工作负载中导致了严重的性能问题。从理论上讲，也至少存在死锁的可能性。

在某些情况下，Tuples 存储将包括源表的所有列，而不仅仅是查询所需的列。

recovery_min_apply_delay通常不在此配置中使用，但应该可以使用。

如果在发布服务器上根本不存在一列，则在订阅服务器上将其声明为副本身份的一部分，将导致“负的 bitmapset 成员不允许”错误。

错误的逻辑阻止wal_receiver_timeout在逻辑复制部署中工作。

例如，这种疏忽导致了pg_stat_subscription。 last_msg_send_time通常读为 NULL。

该错误导致 assert 失败。目前尚不清楚生产版本中是否存在任何不良影响。

ALTER SYSTEM本身不会生成这种状态，但是修改postgresql.auto.conf的外部工具可以生成这种状态。现在将删除目标变量的重复条目，然后在末尾附加新设置(如果有)。

基于 libpq 的 Client 端通常在需要密码时会进行两次连接尝试，因为在第一次连接尝试失败之前，它们不会提示用户 Importing 密码。因此，当 Client 端在询问密码时关闭连接时，服务器被编码为不会产生无用的日志垃圾邮件。但是，PAM 身份验证代码尚未获得该备忘，并且会生成一些有关幻像身份验证失败的消息。

如果指定了时区 UTC 偏移量的时区，那么日期也必须是正确的，以便可以解决偏移量。根据使用的语法，在某些情况下不会强制执行此检查，从而导致产生伪造的输出。

当位串长度不是 8 的倍数时，位串右移运算符无法将结果的最后一个字节中存在的填充空间清零。尽管对于大多数操作不可见，但任何非零位都将导致意外的比较行为，因为位串比较不会费心忽略多余的位，期望它们始终为零。

如果由于将bitshiftright()的输出保存在表中而导致数据不一致，则可以使用以下方法修复它：

UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);

如果 record 参数为 NULL 并且没有声明的复合类型，请尝试使用AS子句。不建议使用此方法，但是它曾经可以使用，现在又可以使用。

如果相邻索引的 TID 之间的距离超过 16TB，则 GIN 发布列表项可能需要 7 个字节。逻辑中的一个步骤与此不同步，可能会尝试将值写入 6 字节缓冲区。原则上，这可能会导致堆栈溢出，但是在大多数体系结构上，下一个字节很可能是未使用的对齐填充，从而使该漏洞无害。无论如何，该错误都很难被发现。

如果为非空列值计算的某些距离是无穷大或 NaN，则查询的输出 Sequences 可能是错误的(不同于普通排序的结果)。

此风险是由错误放置的声明造成的：ecpg_gettext()对 Client 端代码不可见。

通常，这是不必要的，因为无论如何状态都是相同的。但这在某些情况下可能很重要，例如在哪里连接可能会导致几台服务器之一。此更改使 psql 重新发出启动时可能发出的任何交互式消息，例如有关是否正在使用 SSL 的消息。

以前，如果不同表上的两个触发器具有相同的名称，则将按基于 OID 的 Sequences 对其进行排序，这比按表名对它们进行排序不太可取。对于 RLS 策略也是如此。

先前的修复导致 pg_dump 始终尝试查询pg_opfamily，但是该目录在 8.3 版之前不存在。

这可以使 pg_restore 的行为与其他一些应用程序同步，特别是使 v12 之前的分支的行为类似于版本 12 的 pg_restore，从而简化了可在多个 PostgreSQL 版本中工作的转储/恢复脚本的创建。在进行此更改之前，pg_restore 将此开关解释为“输出到名为-的文件”的意思，但是很少有人希望这么做。

如果感兴趣的数据类型位于域或复合类型的存储列的下面，则可能会愚弄以前的编码。

如果 fsync 很慢，则先前的编码可能会导致超时失败。

涵盖在执行 PL/pgSQL 函数之间完全删除复合类型，然后创建同名新类型的情况。现在，复合类型的变量将更新以匹配新定义。

在此上下文中，未记录的索引不一定包含有效数据，因此请勿尝试对其进行检查。

诸如array_column <@ constant_array之类的子句被视为可索引的，但是索引搜索可能找不到空数组值。当然，此类条目应与搜索简单匹配。

唯一可行的可后补丁修补程序需要使<@索引搜索扫描整个索引，而此修补程序正是这样做的。这很不幸：这意味着查询性能可能比普通 Sequences 扫描要差。

性能受到此更改不利影响的应用程序有两种选择。他们可以切换到没有此错误的 GIN 索引，也可以将array_column <@ constant_array替换为array_column <@ constant_array AND array_column && constant_array。这将提供与以前几乎相同的性能，并且将找到给定常量数组的所有非空子集，这是查询之前可以可靠地期望的所有子集。

以前，如果用户将CFLAGS设置为-O0，它可能会失败。

先前的自旋锁编码允许编译器选择寄存器零，以与不接受该寄存器的汇编指令一起使用，从而导致构建失败。我们仅看到一个与此错误相符的长期报告，但是对于试图构建经过修改的 PostgreSQL 代码或使用非典型编译器选项的人来说，这可能会引起问题。

xlc 13 及更高版本以与我们的用法不兼容的方式解释此功能，从而导致无法使用 PostgreSQL。通过改用自定义汇编代码进行修复。

这避免了 xlc v16.1.0 的内部编译器错误，除了更改编译器错误消息的格式外，几乎没有其他后果。

上一章 首页 下一章