# E.64\. 發布8.3.13 > **發布日期:** 2010-12-16 該發布包含來自8.3.12的各種修復。關于8.3主要發布的新特性信息，參閱 [Section E.77](#calibre_link-34)。 ## E.64.1\. 遷移到版本8.3.13 運行8.3.X不需要備份/恢復。然而，如果從8.3.8更早版本更新， 參閱8.3.8發布說明。 ## E.64.2\. 變化 * 強迫缺省[`wal_sync_method`](#calibre_link-1432) 為Linux上`fdatasync`(Tom Lane, Marti Raudsepp) Linux上的缺省很多年一直`fdatasync`， 但最近的內核變化反而引起PostgreSQL到選擇`open_datasync`。 這一選擇不會引起任何性能改進，并且在某些文件系統造成徹底的失敗， 尤其是帶有`data=journal`安裝選項的`ext4`。 * 修復GIN索引WAL回放邏輯中各種錯誤(Tom Lane) 這可能導致"bad buffer id: 0"錯誤或者復制過程中索引內容的損壞。 * 當開始檢查點WAL記錄不在同一WAL段作為重做點，修復基礎備份恢復(Jeff Davis) * 當多個執行者長時間保持活躍，修復autovacuum持久延遲(Tom Lane) 為自動清理者的有效`vacuum_cost_limit`可能會刪除到幾乎為零， 如果它處理了足夠的表，導致它運行得非常慢。 * 添加支持檢測`IA64`上寄存器堆棧溢出(Tom Lane) `IA64`結構有兩個硬件堆棧。 全面預防堆棧溢出錯誤需要檢查兩者。 * 添加`copyObject()`中的堆棧溢出檢查(Tom Lane) 某些代碼路徑可能崩潰，因堆棧溢出產生一個足夠復雜的查詢。 * 修復臨時GiST索引中頁面拆分檢查(Heikki Linnakangas) 它可能在臨時索引中有一個"并發"頁拆分， 例如，當插入完成的時候，如果有一個打開的游標掃描索引， 當游標繼續執行的時候，GiST未能檢測這種情況，并因此可能提供錯誤的結果。 * 當`ANALYZE`復雜索引表達式的時候，避免內存泄露(Tom Lane) * 確保使用整行Var的索引仍然依賴于它的表(Tom Lane) 當刪除表的時候，聲明像`create index i on t (foo(t.*))`的索引可能不會自動被刪除。 * 不能"內聯"SQL函數與多個`OUT`參數(Tom Lane) 這避免可能崩潰，由于關于預期結果行類型信息缺失。 * 如果`ORDER BY`, `LIMIT`， `FOR UPDATE`或者`WITH`附屬于 `INSERT ... VALUES`的`VALUES`部分，則操作正確(Tom Lane) * 修復`COALESCE()`表達式的常數合并(Tom Lane) 規劃器可能有時嘗試評估實際上可能找不到的子表達式，可能導致意外錯誤。 * 當連接嘗試（`accept()`或者它之后立即調用）失敗時， postmaster與GSSAPI支持一起編譯(Alexander Chernikov) * 當`log_temp_files`是活躍的，修復臨時文件的忽略斷開(Tom Lane) 當嘗試發出日志信息的時候，如果發生錯誤，那么刪除鏈接不執行，導致臨時文件積累。 * 添加`InhRelation`節點輸出功能(Tom Lane) 當激活`debug_print_parse`，并且執行某種類型查詢的時候，避免錯誤。 * 修復從一個點到一個水平線段不正確計算(Tom Lane) 該錯誤影響了若干個不同幾何距離測量操作符。 * 修復"simple"表達式的PL/pgSQL處理可以在 遞歸或者錯誤恢復情況中執行(Tom Lane) * 修復集合返回函數的PL/Python的處理(Jan Urbanski) 在迭代器產生一組結果中嘗試調用SPI函數可能失敗。 * 修復`contrib/cube`的GiST picksplit算法中的錯誤(Alexander Korotkov) 這可能會導致相當大的效率低下，但實際上并不是錯誤結論，在GiST索引`cube`列中。 如果你有這樣一個索引，考慮在安裝此更新后`REINDEX`它。 * 不能發出`contrib/dblink`中"標識符被截斷"注意事項，除非 當創建新鏈接的時候(Itagaki Takahiro) * 修復`contrib/pgcrypto`中關于丟失公鑰上潛在核心轉儲(Marti Raudsepp) * 修復`contrib/xml2`的XPath查詢函數中的內存泄露(Tom Lane) * 為了Fiji和Samoa中DST變化更新時區數據文件到tzdata發布2010o； 同時為了Hong Kong歷史修正。