# E.76\. 发布8.3.1 > **发布日期:** 2008-03-17 该发布包含来自8.3.0的各种修复。关于8.3主要发布中新特性信息， 参阅[Section E.77](#calibre_link-34)。 ## E.76.1\. 迁移到版本8.3.1 运行8.3.X不需要备份/恢复。然而，如果你受到下面描述的Windows区域问题的影响。 在更新之后你可能需要文本列上`REINDEX`索引。 ## E.76.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_listener`中`LISTEN`行, 应该选择查看；之前可能会。这种操作从来没有记录一种方式或者其它， 但是可能某些应用程序依赖于旧操作。 * 在一个预备事务中不允许`LISTEN`和`UNLISTEN`(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)