E.83. 版本8.4.11

E.83.1. 迁移到版本8.4.11

运行8.4.X不需要备份/恢复。

然而，如果你从8.4.10更早版本更新，参阅第 E.84 节。

E.83.2. 修改列表

• 需要为CREATE TRIGGER触发器函数上的执行权限(Robert Haas)

  这个丢失检查可能允许其他用户执行带有伪造输入数据的触发器函数， 通过安装它到它拥有的表上。 对于触发器函数标记SECURITY DEFINER是唯一重要的， 因为否则触发器函数运行为表所有者。(CVE-2012-0866)

• 删除SSL证书中常见名称长度的任意限制(Heikki Linnakangas)

  libpq和服务器截断从32字节SSL证书中提取的通用名。 这通常会导致没有什么比一个意想不到的验证失败更糟糕的，但是有一些 令人难以置信的情况，它可能允许一个证书持有者模仿另外一个。 该受害者必须有32字节长的通用名。并且攻击者必须说服可信任CA发布证书， 其中通用名有字符串作为前缀。 伪装服务器也需要一些额外的开发重定向客户端连接。(CVE-2012-0867)

• 在名字写入pg_dump说明中转换新行到空白(Robert Haas)

  pg_dump关于审查输出脚本中SQL注释发出的对象名是不谨慎的。 包含换行符的名字至少使得脚本语法上不正确。 当脚本被重新加载时，恶意制作对象名可能出现SQL注射风险。(CVE-2012-0868)

• 修复来自并行清理插入的btree索引崩溃(Tom Lane)

  通过插入引起的索引页分裂有时可以导致同时运行VACUUM 而错过删除本应该删除的索引项。相应表行被删除后， 该悬挂索引项可能导致错误（比如"不能读取文件中块N..."）或者更糟， 无关行后默默的错误查询结果被重新插入到当前自由表位置。 这个错误自从发布8.2就出现了， 但是发生如此罕见以致它没有被诊断直到现在。 如果你有理由怀疑它已经在你的数据库中发生， 那么重新索引受影响索引将修复这问题。

• 当改变表所有者时，更新每列权限，不仅仅每个表权限(Tom Lane)

  不这样做就意味着任何先前已授权列权限 仍然显示为已被旧的所有者授权。 这意味着既不是新所有者也不是 超级用户可以撤销目前难以寻找的到表所有者权限。

• 允许ALTER USER/DATABASE SET中 一些设置的不存在值(Heikki Linnakangas)

  允许default_text_search_config， default_tablespace和temp_tablespaces 被设置为不知道的名字。 这是因为它们可能在另一个数据库中已知， 该设置打算使用的地方， 或者为了表空间情况因为表空间可能不会被创建。 同样问题是先前已确认为search_path， 并且这些设置像那一个。

• 当我们删除后提交表文件有问题时，避免崩溃(Tom Lane)

  删除表导致事务提交之后删除底层磁盘文件。 在失败的情况中（比如，由于错误文件权限） 那么该代码应该发出警告消息并且继续， 因为它太晚了而终止了事务。 这个逻辑已作为版本8.4被打破， 导致这种情况引起PANIC和不可重新启动的数据库。

• 在WAL回放期间正确跟踪OID计数器，即使当它包围周围(Tom Lane)

  先前OID计数器可以保持在较高的值上直到系统退出回放模式。 实际结果通常为零，但是存在这样一种情况， 备用服务器提升到主服务器可能需要很长时间 增加OID计数器到一个合理值，一旦该值是必须的。

• 修复带有*附属的正则表达式逆向引用(Tom Lane)

  而不是执行一个确切的字符串匹配， 该代码有效地接受任何满足模式子表达式引用逆向引用符号的字符串。

  类似问题仍然困扰着被嵌入到大的量化表达式中的逆向引用，而不是量词的直接主题。 这将在未来PostgreSQL发布中得以解决。

• 修复inet/cidr值处理中最新引进的内存泄露(Heikki Linnakangas)

  PostgreSQL的2011年12月份发布的补丁 导致了这些操作中内存泄露，这可能是重要情况比如在这样的列上 编译btree索引。

• 修复SQL语言函数中 CREATE TABLE AS/SELECT INTO之后的悬挂指针(Tom Lane)

  在大多数情况中这导致断言启用编译中断言失败， 但是更糟结果是可能的。

• 避免Windows上syslogger中文件句柄的双关闭(MauMau)

  通常这个错误是无形的，但是当在Windows的调试版本上运行时，它可能导致异常。

• 修复plpgsql中I/O转换关系内存泄露(Andres Freund, Jan Urbanski, Tom Lane)

  某些操作可能泄露内存直到当前函数结束。

• 提升继承表列的pg_dump的处理(Tom Lane)

  pg_dump处理不当的情况下，一个子列 比它的父列有不同的缺省表达式。 如果缺省文本上与父类的缺省是相同的，但不是真的 相同（例如，由于模式搜索路径的差异）不会被认为是不同的， 所以在转储和恢复后 子类可以被允许继承父的缺省。在它们的父类不能微妙地错误地被恢复的地方 子列非空。

• 为了INSERT形式表数据修复pg_restore的 直接到数据库模式(Tom Lane)

  当使用发布日期2011年九月或者十二月的pg_restore的时候， 从归档文件中恢复直接到数据库伴随 --inserts或者--column-inserts选项而失败， 作为另外一个问题修复的疏忽结果。 归档文件本身没有错，而且文本模式输出是好的。

• 在ecpgDEALLOCATE语句 中允许AT选项(Michael Meskes)

  支持这个的基础设施已有一段时间了， 但由于疏忽仍然有拒绝这种情况的错误检查。

• 修复contrib/intarray的int[] &int[]操作符 中的错误(Guillaume Lelarge)

  如果最小整数的两个输入数组中常见的是1， 并且在其中之一数组中有较小的值，然后将1 从结果中错误地省略。

• 修复contrib/pgcrypto的 encrypt_iv()和decrypt_iv()中的错误检查(Marko Kreen)

  这些函数没有成功报告无效输入错误的某些类型， 并且反而为不正确输入返回随机垃圾值。

• 修复contrib/test_parser中一字节缓冲区超出范围(Paul Guyot)

  该代码将尝试读取比它应该的又一个字节，这将在困境情况下崩溃。 因为contrib/test_parser只是示例代码， 这本身不是一个安全问题，但不好的例子代码仍然是差的。

• 如果可用，那么 在ARM上为spinlocks使用__sync_lock_test_and_set() (Martin Pitt)

  这个函数替换SWPB指令先前用法，它已经废弃并且在ARMv6和之后的不可用。 报告建议该旧代码在最新ARM上以显著方式使用， 但是不能简单地连锁并发访问，导致多进程操作中的离奇失败。

• 当编译接受它的gcc版本时， 使用-fexcess-precision=standard选项(Andrew Dunstan)

  这阻止各种各样的情节，其中gcc最新版本将产生创造性结果。

• 允许FreeBSD上线程Python的使用(Chris Rees)

  我们配置脚本先前认为这种组合不会允许；但是FreeBSD修复该问题， 因此删除错误检查。