# 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)