E.31. 版本 9.0.3 · PostgreSQL 中文文檔 9.3

# E.31\. 版本 9.0.3 > **發布日期:** 2011-01-31 這個版本包含各種自9.0.2以來的修復。要想獲得關于9.0主版本的新特性，請參閱[Section E.34](#calibre_link-163)。 ## E.31.1\. 遷移到版本 9.0.3 運行9.0.X版本的用戶不需要轉儲/恢復。 ## E.31.2\. 修改列表 * 在退出walreceiver之前，確保所有接收到的WAL同步到磁盤 (Heikki Linnakangas) 否則備用服務器會重放一些未同步的WAL，想象的到，如果系統正好在此時崩潰，則會導致數據損壞。 * 避免walreceiver中過度的同步活動 (Heikki Linnakangas) * 需要時使`ALTER TABLE`的唯一性和排除約束重新生效 (Noah Misch) 這在9.0中，由于試圖在`VACUUM FULL`和`CLUSTER`期間抑制重新生效而壞掉了，但是無意間也影響到了`ALTER TABLE`。 * 為繼承樹的`UPDATE`修復EvalPlanQual，該繼承樹中的表并不都是相似的 (Tom Lane) 表行類型（包括只在一些子表中出現的少量的字段）的任何變化都將使EvalPlanQual代碼混亂，導致錯誤行為甚至崩潰。因為EvalPlanQual只在并發更新到相同的行時執行，該問題只能間歇的看到。 * 避免`EXPLAIN`試圖顯示一個簡單形式的`CASE`表達式時的失敗 (Tom Lane) 如果`CASE`的測試表達式是一個常量，那么規劃器將簡化`CASE` 為一個困惑表達式顯示代碼的形式，導致"unexpected CASE WHEN clause"錯誤。 * 修復現有下標范圍之前的數組切片的分配 (Tom Lane) 如果新添加的下標和原先存在的下標之間存在一個缺口，代碼錯誤估算了需要多少條目從老數組的空位圖中拷貝，可能導致數據損壞或崩潰。 * 避免為了非常遠的日期值在規劃器中意外的轉換溢出 (Tom Lane) `date`類型比`timestamp`類型支持更大范圍的日期，但是規劃器假設它可以總是不受懲罰的轉換一個日期為時間戳。 * 修復一個數組包含空條目時的PL/Python損壞 (Alex Hunsaker) * 為定義一個數組維度的常量刪除ecpg的固定的長度限制 (Michael Meskes) * 修復包含`... & !(subexpression) | ...` 的`tsquery`值的錯誤解析 (Tom Lane) 包含這些操作符的組合的查詢沒有正確的執行。相同的錯誤存在于`contrib/intarray` 的`query_int`類型和`contrib/ltree`的`ltxtquery`類型。 * 修復`contrib/intarray`的`query_int`類型輸入函數中的緩沖區溢出 (Apple) 這個錯誤是一個安全風險，因為該函數的返回地址會被重寫。感謝Apple Inc的安全團隊報告這個問題并提供了該修復。 (CVE-2010-4015) * 修復`contrib/seg`的GiST picksplit算法中的錯誤 (Alexander Korotkov) 這可能會導致大量的低效，盡管不是實際上錯誤的答案，在`seg`字段上的GiST索引中。如果你有這樣的一個索引，那么考慮在安裝這個更新之后`REINDEX`它。（這與之前更新的`contrib/cube`中修復的錯誤相同。）