# E.16\. 發布9.1.3 > **發布日期:** 2012-02-27 該發布包含了9.1.2的各種修復。 為了9.1主要版本的新功能的更多信息， 參閱[Section E.19](#calibre_link-148)。 ## E.16.1\. 遷移到版本9.1.3 為運行9.1.X不需要轉儲/恢復。 然而，如果你從9.1.2的更早版本更新， 請參閱9.1.2的發布說明。 ## E.16.2\. 變化 * 需要為`CREATE TRIGGER`觸發器函數上的執行權限(Robert Haas) 這個丟失檢查可能允許其他用戶執行帶有偽造輸入數據的觸發器函數， 通過安裝它到它擁有的表上。 對于觸發器函數標記`SECURITY DEFINER`是唯一重要的， 因為否則觸發器函數運行為表所有者。(CVE-2012-0866) * 刪除SSL證書中常見名稱長度的任意限制(Heikki Linnakangas) libpq和服務器截斷從32字節SSL證書中提取的通用名。 這通常會導致沒有什么比一個意想不到的驗證失敗更糟糕的，但是有一些 令人難以置信的情況，它可能允許一個證書持有者模仿另外一個。 該受害者必須有32字節長的通用名。并且攻擊者必須說服可信任CA發布證書， 其中通用名有字符串作為前綴。 偽裝服務器也需要一些額外的開發重定向客戶端連接。(CVE-2012-0867) * 在名字寫入pg_dump說明中轉換新行到空白(Robert Haas) pg_dump關于審查輸出腳本中SQL注釋發出的對象名是不謹慎的。 包含換行符的名字至少使得腳本語法上不正確。 當腳本被重新加載時，惡意制作對象名可能出現SQL注射風險。(CVE-2012-0868) * 修復來自并行清理插入的btree索引崩潰(Tom Lane) 通過插入引起的索引頁分裂有時可以導致同時運行`VACUUM` 而錯過刪除本應該刪除的索引項。相應表行被刪除后， 該懸掛索引項可能導致錯誤（比如"不能讀取文件中塊N..."）或者更糟， 無關行后默默的錯誤查詢結果被重新插入到當前自由表位置。 這個錯誤自從發布8.2就出現了， 但是發生如此罕見以致它沒有被診斷直到現在。 如果你有理由懷疑它已經在你的數據庫中發生， 那么重新索引受影響索引將修復這問題。 * 修復WAL回放期間共享緩沖區臨時調零(Tom Lane) 重放邏輯有時歸零并且重填共享緩沖區，因此內容瞬時無效。 在熱備模式中這可以導致正在并行執行的查詢看到垃圾數據。 可能導致不同癥狀， 但是最常見的是"無效內存分配請求大小"。 * 修復`READ COMMITTED`復查中數據修改`WITH`子計劃處理(Tom Lane) 如果父`UPDATE`或者`DELETE`命令需要被重新評估一行或多行， 由于`READ COMMITTED`模式中并發更新，那么包含 `INSERT`/`UPDATE`/`DELETE` 的`WITH`子句可能崩潰。 * 修復SSI事務清理中困境情況(Dan Ports) 當結束一個讀寫串行化事務時，如果所有剩余的活躍的可串行化事務是 只讀的，那么可能產生崩潰。 * 在熱備份崩潰后修復postmaster以嘗試重啟(Tom Lane) 當在熱備模式中進行操作時如果任何后端進程崩潰，那么 邏輯錯誤導致postmaster終止，而不是嘗試重啟集群。 * 修復通過最新更新行擁有的toast值的 `CLUSTER`/`VACUUM FULL`的處理(Tom Lane) 這種疏忽可能導致"重復關鍵值違背唯一約束"錯誤 被報告給這些命令之一中的 toast表的索引。 * 當改變表所有者時，更新每列權限，不僅僅每個表權限(Tom Lane) 不這樣做就意味著 任何先前已授權列權限 仍然顯示為已被舊的所有者授權。 這意味著既不是新所有者也不是 超級用戶可以撤銷目前難以尋找的到表所有者權限。 * 支持外數據封裝和`REASSIGN OWNED`中的外服務器(Alvaro Herrera) 如果它需要改變任何對象的所有權， 那么該命令伴隨"意外數字"錯誤失敗。 * 允許`ALTER USER/DATABASE SET`中 一些設置的不存在值(Heikki Linnakangas) 允許`default_text_search_config`， `default_tablespace`和`temp_tablespaces` 被設置為不知道的名字。 這是因為它們可能在另一個數據庫中已知， 該設置打算使用的地方， 或者為了表空間情況因為表空間可能不會被創建。 同樣問題是先前已確認為`search_path`， 并且這些設置像那一個。 * 修復`INSERT`表達式中通過`COLLATE`產生的 "不支持節點類型"錯誤(Tom Lane) * 當我們刪除后提交表文件有問題時，避免崩潰(Tom Lane) 刪除表導致事務提交之后刪除底層磁盤文件。 在失敗的情況中（比如，由于錯誤文件權限） 那么該代碼應該發出警告信息并且繼續， 因為它太晚了而終止了事務。 這個邏輯已作為發布8.4被打破， 導致這種情況引起PANIC和不可重新啟動的數據庫。 * 在`DROP TABLESPACE`的WAL回放期間從發生的錯誤中恢復(Tom Lane) 重播將嘗試刪除該表空間目錄，但是 可能會失敗的原因是多方面的（例如，這些目錄上不正確的 所有權和權限）。以前該重播代碼會恐慌， 導致數據庫沒有手冊干預不能重新啟動。 似乎記錄問題并且繼續是更好的，因為 刪除該目錄失敗的唯一結果是一些浪費的磁盤空間。 * 修復為熱備在記錄AccessExclusiveLocks中的競爭條件(Simon Riggs) 有時鎖可能被記錄為通過"事務零"持有。 這對于從服務器上產生斷言失敗至少是已知的， 并且可能是更嚴重問題的原因。 * 在WAL回放期間正確跟蹤OID計數器，即使當它包圍周圍(Tom Lane) 先前OID計數器可以保持在較高的值上直到系統退出回放模式。 實際結果通常為零，但是存在這樣一種情況， 備用服務器提升到主服務器可能需要很長時間 增加OID計數器到一個合理值，一旦該值是必須的。 * 在崩潰恢復開始時阻止發出誤導性的 "一致的恢復狀態到達" 日志信息(Heikki Linnakangas) * 修復`pg_stat_replication`.`replay_location` 的初始值(Fujii Masao) 以前，顯示的值可能是錯誤的直到至少一個WAL記錄已被回放。 * 修復帶有`*`附屬的正則表達式逆向引用(Tom Lane) 而不是執行一個確切的字符串匹配， 該代碼有效地接受任何滿足模式子表達式引用逆向引用符號的字符串。 類似問題仍然困擾著被嵌入到大的量化表達式中的逆向引用，而不是量詞的直接主題。 這將在未來PostgreSQL發布中得以解決。 * 修復`inet`/`cidr`值處理中最新引進的內存泄露(Heikki Linnakangas) PostgreSQL的2011年12月份發布的補丁 導致了這些操作中內存泄露，這可能是重要情況比如在這樣的列上 編譯btree索引。 * 修復規劃器的能力通過`UNION ALL`推動索引表達式限制(Tom Lane) 優化這種類型通過9.1.2中另一個問題修復被無意識禁用。 * 修復引用繼承表上`UPDATE`/`DELETE`中的 `WITH`子句規劃(Tom Lane) 這個錯誤導致"不能找到CTE規劃"錯誤。 * 修復GIN估計成本以處理`column IN (...)`索引條件(Marti Raudsepp) 如果這一條件與GIN索引一起使用，那么這種疏忽通常導致崩潰。 * 當退出打開的失敗事務會話，防止斷言失敗(Tom Lane) 這個錯誤對正常編譯未啟用斷言沒有影響。 * 修復SQL語言函數中 `CREATE TABLE AS`/`SELECT INTO`之后的懸掛指針(Tom Lane) 在大多數情況中這導致斷言啟用編譯中斷言失敗， 但是更糟結果是可能的。 * 避免Windows上syslogger中文件句柄的雙關閉(MauMau) 通常這個錯誤是無形的，但是當在Windows的調試版本上運行時，它可能導致異常。 * 修復plpgsql中I/O轉換關系內存泄露(Andres Freund, Jan Urbanski, Tom Lane) 某些操作可能泄露內存直到當前函數結束。 * 解決perl的SvPVutf8()函數中的錯誤(Andrew Dunstan) 當操作的typeglob或者某個只讀對象比如`$^V`時，該函數崩潰。 使得plperl避免傳遞這些給它。 * 在pg_dump中，如果擴展本身沒有被備份， 那么不備份擴展的配置表的內容(Tom Lane) * 提升繼承表列的pg_dump的處理(Tom Lane) pg_dump處理不當的情況下，一個子列 比它的父列有不同的缺省表達式。 如果缺省文本上與父類的缺省是相同的，但不是真的 相同（例如，由于模式搜索路徑的差異）不會被認為是不同的， 所以在轉儲和恢復后 子類可以被允許繼承父的缺省。在它們的父類不能微妙地錯誤地被恢復的地方 子列`非空`。 * 為了INSERT形式表數據修復pg_restore的 直接到數據庫模式(Tom Lane) 當使用發布日期2011年九月或者十二月的pg_restore的時候， 從歸檔文件中恢復直接到數據庫伴隨 `--inserts`或者`--column-inserts`選項而失敗， 作為另外一個問題修復的疏忽結果。 歸檔文件本身沒有錯，而且文本模式輸出是好的。 * pg_upgrade處理plpython 的共享庫的重命名(Bruce Momjian) 更新包含plpython的9.1之前數據庫可能失敗，因為這種疏忽。 * 允許pg_upgrade處理包含`regclass`列的表(Bruce Momjian) 因為pg_upgrade現在負責保存`pg_class` OID， 這一限制沒有任何理由。 * 當正在尋找SSL客戶端證書文件時，使得 libpq忽略`ENOTDIR`錯誤(Magnus Hagander) 這允許建立SSL連接，雖然沒有證書， 即使當用戶的家目錄被設置為像`/dev/null`的目錄。 * 修復ecpg的SQLDA區域中 一些字段對齊問題(Zoltan Boszormenyi) * 在ecpg`DEALLOCATE`語句 中允許`AT`選項(Michael Meskes) 支持這個的基礎設施已有一段時間了， 但由于疏忽仍然有拒絕這種情況的錯誤檢查。 * 當在ecpg中定義varchar結構時，不要使用變量名(Michael Meskes) * 修復`contrib/auto_explain`的 JSON模式以產生有效的JSON(Andrew Dunstan) 當它使用花括號時，該輸出使用頂層方括號。 * 修復`contrib/intarray`的`int[] &int[]`操作符 中的錯誤(Guillaume Lelarge) 如果最小整數的兩個輸入數組中常見的是1， 并且在其中之一數組中有較小的值，然后將1 從結果中錯誤地省略。 * 修復`contrib/pgcrypto`的 `encrypt_iv()`和`decrypt_iv()`中的錯誤檢查(Marko Kreen) 這些函數沒有成功報告無效輸入錯誤的某些類型， 并且反而為不正確輸入返回隨機垃圾值。 * 修復`contrib/test_parser`中一字節緩沖區超出范圍(Paul Guyot) 該代碼將嘗試讀取比它應該的又一個字節，這將在困境情況下崩潰。 因為`contrib/test_parser`只是示例代碼， 這本身不是一個安全問題，但不好的例子代碼仍然是差的。 * 如果可用，那么 在ARM上為spinlocks使用`__sync_lock_test_and_set()` (Martin Pitt) 這個函數替換`SWPB`指令先前用法，它已經廢棄并且在ARMv6和之后的不可用。 報告建議該舊代碼在最新ARM上以顯著方式使用， 但是不能簡單地連鎖并發訪問，導致多進程操作中的離奇失敗。 * 當編譯接受它的gcc版本時， 使用`-fexcess-precision=standard`選項(Andrew Dunstan) 這阻止各種各樣的情節，其中gcc最新版本將產生創造性結果。 * 允許FreeBSD上線程Python的使用(Chris Rees) 我們配置腳本先前認為這種組合不會允許；但是FreeBSD修復該問題， 因此刪除錯誤檢查。 * 允許MinGW建立使用標準命名OpenSSL庫(Tomasz Ostrowski)