# E.42\. 發布8.4.11 > **發布日期:** 2012-02-27 該發布包含8.4.10各種修復。關于8.4主要發布的新功能的信息， 參閱[Section E.53](#calibre_link-49)。 ## E.42.1\. 遷移到版本8.4.11 運行8.4.X不需要備份/恢復。 然而，如果你從8.4.10更早版本更新，參閱8.4.10發布說明。 ## E.42.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就出現了， 但是發生如此罕見以致它沒有被診斷直到現在。 如果你有理由懷疑它已經在你的數據庫中發生， 那么重新索引受影響索引將修復這問題。 * 當改變表所有者時，更新每列權限，不僅僅每個表權限(Tom Lane) 不這樣做就意味著任何先前已授權列權限 仍然顯示為已被舊的所有者授權。 這意味著既不是新所有者也不是 超級用戶可以撤銷目前難以尋找的到表所有者權限。 * 允許`ALTER USER/DATABASE SET`中 一些設置的不存在值(Heikki Linnakangas) 允許`default_text_search_config`， `default_tablespace`和`temp_tablespaces` 被設置為不知道的名字。 這是因為它們可能在另一個數據庫中已知， 該設置打算使用的地方， 或者為了表空間情況因為表空間可能不會被創建。 同樣問題是先前已確認為`search_path`， 并且這些設置像那一個。 * 當我們刪除后提交表文件有問題時，避免崩潰(Tom Lane) 刪除表導致事務提交之后刪除底層磁盤文件。 在失敗的情況中（比如，由于錯誤文件權限） 那么該代碼應該發出警告信息并且繼續， 因為它太晚了而終止了事務。 這個邏輯已作為發布8.4被打破， 導致這種情況引起PANIC和不可重新啟動的數據庫。 * 在WAL回放期間正確跟蹤OID計數器，即使當它包圍周圍(Tom Lane) 先前OID計數器可以保持在較高的值上直到系統退出回放模式。 實際結果通常為零，但是存在這樣一種情況， 備用服務器提升到主服務器可能需要很長時間 增加OID計數器到一個合理值，一旦該值是必須的。 * 修復帶有`*`附屬的正則表達式逆向引用(Tom Lane) 而不是執行一個確切的字符串匹配， 該代碼有效地接受任何滿足模式子表達式引用逆向引用符號的字符串。 類似問題仍然困擾著被嵌入到大的量化表達式中的逆向引用，而不是量詞的直接主題。 這將在未來PostgreSQL發布中得以解決。 * 修復`inet`/`cidr`值處理中最新引進的內存泄露(Heikki Linnakangas) PostgreSQL的2011年12月份發布的補丁 導致了這些操作中內存泄露，這可能是重要情況比如在這樣的列上 編譯btree索引。 * 修復SQL語言函數中 `CREATE TABLE AS`/`SELECT INTO`之后的懸掛指針(Tom Lane) 在大多數情況中這導致斷言啟用編譯中斷言失敗， 但是更糟結果是可能的。 * 避免Windows上syslogger中文件句柄的雙關閉(MauMau) 通常這個錯誤是無形的，但是當在Windows的調試版本上運行時，它可能導致異常。 * 修復plpgsql中I/O轉換關系內存泄露(Andres Freund, Jan Urbanski, Tom Lane) 某些操作可能泄露內存直到當前函數結束。 * 提升繼承表列的pg_dump的處理(Tom Lane) pg_dump處理不當的情況下，一個子列 比它的父列有不同的缺省表達式。 如果缺省文本上與父類的缺省是相同的，但不是真的 相同（例如，由于模式搜索路徑的差異）不會被認為是不同的， 所以在轉儲和恢復后 子類可以被允許繼承父的缺省。在它們的父類不能微妙地錯誤地被恢復的地方 子列`非空`。 * 為了INSERT形式表數據修復pg_restore的 直接到數據庫模式(Tom Lane) 當使用發布日期2011年九月或者十二月的pg_restore的時候， 從歸檔文件中恢復直接到數據庫伴隨 `--inserts`或者`--column-inserts`選項而失敗， 作為另外一個問題修復的疏忽結果。 歸檔文件本身沒有錯，而且文本模式輸出是好的。 * 在ecpg`DEALLOCATE`語句 中允許`AT`選項(Michael Meskes) 支持這個的基礎設施已有一段時間了， 但由于疏忽仍然有拒絕這種情況的錯誤檢查。 * 修復`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修復該問題， 因此刪除錯誤檢查。