E.177. 版本8.3.1

E.177.1. 迁移到版本8.3.1
E.177.2. 变化

发布日期:. 2008-03-17

该发布包含来自8.3.0的各种修复。关于8.3主要发布中新特性信息, 参阅第 E.178 节

E.177.1. 迁移到版本8.3.1

运行8.3.X不需要备份/恢复。然而,如果你受到下面描述的Windows区域问题的影响。 在更新之后你可能需要文本列上REINDEX索引。

E.177.2. 变化

  • 修复认为不同字符组合是相同的Windows区域的字符串比较(Tom)

    当使用UTF-8数据库编码的时候,此修复程序仅适用于Windows。 相同的修复程序解决了2年前所有其他情况,但是使用UTF-8的Windows使用 未被更新的单独代码路径。如果你正使用认为非相同字符串是相同的区域, 你可能需要REINDEX以修复文本列上现有索引。

  • 修复VACUUM FULL中极端情况错误(Tom)

    8.2中介绍了不同的系统目录中并发VACUUM FULL操作之间的 潜在死锁。这已得到纠正。8.3执行的更糟糕, 因为死锁可能出现在关键代码部分,使其PANIC而不仅仅是ERROR条件。

    此外,VACUUM FULL通过清理系统目录中途失败可能会导致并发数据库会话中缓存损坏。

    当处理没有活元组页的时候, 8.3中介绍的另外一个VACUUM FULL可能导致崩溃或者内存不足报告。

  • 修复涉及character或者bit列的外键检查错误操作(Tom)

    如果引用列不同除兼容类型(比如varchar),那么错误强制约束。

  • 在无操作外键检查中避免不必要死锁错误(Stephan Szabo, Tom)

  • 当重新规划预备查询的时候,修复可能的核心转储(Tom)

    该错误只影响协议级别预备操作,而不是SQL PREPARE, 因此常常被认为JDBC, DBI以及大量使用预备语句的其它客户端驱动程序。

  • 当重新规划调用SPI使用函数的查询时,修复可能错误(Tom)

  • 修复逐行比较涉及不同数据类型列中的错误(Tom)

  • 修复长期存在的LISTEN/NOTIFY竞态条件(Tom)

    在极少数情况中执行LISTEN的会话中可能无法得到通知,即使可以被预计,因为 执行NOTIFY的并发事务被观察后提交。

    该修复的负面效果是已经执行尚未提交的LISTEN命令的事务 将不能看到任何pg_listenerLISTEN行, 应该选择查看;之前可能会。这种操作从来没有记录一种方式或者其它, 但是可能某些应用程序依赖于旧操作。

  • 在一个预备事务中不允许LISTENUNLISTEN(Tom)

    之前这是被允许的,但是尝试执行它有各种不好的结果,尤其是原始后台不能退出 只要UNLISTEN没有提交。

  • 不允许删除预备事务中临时表(Heikki)

    8.1中不允许,但是在8.2和8.3中无意中损坏了该检查。

  • 当在使用哈希索引的查询中发生错误的时候,修复罕见崩溃(Heikki)

  • 修复tsquery值的不正确比较(Teodor)

  • 修复单字节编码中非ASCII字符LIKE不正确操作(Rolf Jentsch)

  • 禁用xmlvalidate (Tom)

    该函数应该在8.3版本之前删除,但是无意中留在源代码中。它造成小的安全风险, 因为未授权用户可以使用它读取访问服务器任何文件的前几个字符。

  • 修复集合返回函数的某些用法的内存泄露(Neil)

  • 使用encode(bytea, 'escape')转换所有 高位字节值到\nnn八进制转义序列(Tom)

    当数据库编码是多字节时,有必要避免编码问题。 这种变化可能为预期从encode中指定结果的应用中产生兼容问题。

  • 修复公元前2月29号日期时间值的输入(Tom)

    关于哪一年是闰年前者编码是错误的。

  • 修复ALTER OWNER的一些变量中未知节点类型错误(Tom)

  • 避免CREATE TABLE LIKE INCLUDING INDEXES中表空间权限错误(Tom)

  • 当中断锁等待的时候,确保pg_stat_activity.waiting标志被清除(Tom)

  • 修复Windows Vista上进程权限的处理(Dave, Magnus)

    特别是,这个修复允许作为管理员用户启动服务器。

  • 更新时区数据文件到tzdata发布2008a(尤其是,最近Chile变化); 调整时区缩写VET (Venezuela)意味着UTC-4:30, not UTC-4:00 (Tom)

  • 修复数组ecpg问题(Michael)

  • 修复pg_ctl以正确从命令行选项中提取postmaster的端口号(Itagaki Takahiro, Tom)

    之前,pg_ctl start -w可能尝试联系错误端口上postmaster, 导致启动错误的虚假报告。

  • 使用-fwrapv防御最近gcc版本中可能的错误优化(Tom)

    当使用gcc 4.3或者更高版本编译PostgreSQL的时候, 这是必要的。

  • 启动使用MSVC 编译contrib/uuid-ossp(Hiroshi Saito)