E.6. 版本9.2.2 · PostgreSQL 中文文檔 9.3

# E.6\. 版本9.2.2 > **發布日期:** 2012-12-06 這個版本包含9.2.1的各種修復。有關9.2主要版本的新功能的信息，參閱 [Section E.8](#calibre_link-137)。 ## E.6.1\. 遷移到版本9.2.2 為了運行9.2.X不需要轉儲/恢復。然而，你可能需要執行`REINDEX`操作以調整并發建立索引問題，正如下面描述的第一個changelog項。同時，如果你正在從版本9.2.0更新，那么請參閱9.2.1的發布說明。 ## E.6.2\. 變化 * 修復與`CREATE/DROP INDEX CONCURRENTLY`相關的多個錯誤(Andres Freund, Tom Lane, Simon Riggs, Pavan Deolasee) 當在`CREATE INDEX CONCURRENTLY`最初階段添加`DROP INDEX CONCURRENTLY` 允許不正確索引決定，引入錯誤；因此通過該命令建立的索引可能敗壞。在應用該更新后推薦使用`CREATE INDEX CONCURRENTLY`在9.2.X中重新建立索引。另外，當改變索引的`pg_index`行狀態時，修復`CREATE/DROP INDEX CONCURRENTLY`使用合適更新。這避免競爭條件導致并發會話錯過更新目標索引，因此再次導致敗壞同時創建索引。同時，修復各種其他操作以確保他們忽略了一個來自失敗的`CREATE INDEX CONCURRENTLY`命令的無效索引。最重要的是`VACUUM`，因為在采用調整動作以修復或者刪除無效索引之前在表上可以很容易啟動自動清理。同時修復`DROP INDEX CONCURRENTLY`用來不禁用插入到目標索引直到所有查詢使用它。如果取消`DROP INDEX CONCURRENTLY`:先前編碼可以留下未刪除的索引，修復不正當操作。 * 為了`DROP INDEX CONCURRENTLY`調整謂詞鎖 (Kevin Grittner) 先前，在錯誤的時間處理SSI謂詞鎖，可能導致與`DROP`并行執行的可串行化事務不正確操作。 * 在WAL回放期間修復緩沖區鎖定(Tom Lane) 當回放WAL記錄影響超過一頁時，那么WAL回放編碼不能仔細鎖定緩沖區。這可能導致熱備份查詢瞬時看到不一致狀態，導致錯誤結果或者意外失敗。 * 修復GIN索引在WAL產生邏輯中的錯誤(Tom Lane) 這可能導致索引敗壞，如果發生破損頁失敗。 * 修復SP-GiST索引在WAL回放邏輯錯誤(Tom Lane) 這可能導致崩潰后索引敗壞，或者是在備用服務器上。 * 在WAL恢復期間修復基礎備份位置的不正確檢查(Heikki Linnakangas) 數據庫達到一致狀態之前該錯誤允許熱備份模式啟動。 * 當推動熱備服務器正常運行時，正常刪除啟動進程的虛擬XID鎖(Simon Riggs) 該監督可以防止某種操作的后續執行比如`CREATE INDEX CONCURRENTLY`。 * 避免備用模式中假冒的"失序時間線ID"錯誤(Heikki Linnakangas) * 在它接收到關機信號之后阻止postmaster發起新的子進程(Tom Lane) 該錯誤可能導致比較長的關閉，或者即使從來沒有完成沒有額外用戶操作。 * 當`log_rotation_age`超過2^31毫秒時（大約25天），那么修復syslogger進程而不會失敗。(Tom Lane) * 當請求的超時過期的時候，那么修復`WaitLatch()`以及時返回(Jeff Janes, Tom Lane) 與以前的編碼，非等待終止中斷的穩定流可能會延遲從`WaitLatch()` 無限期的返回。這已被證明是一個自動清理發射進程中的問題，可能會導致其他地方的麻煩。 * 當內存不足的時候避免內部哈希表的敗壞(Hitoshi Harada) * 防止已刪除表文件描述符在以前事務結束中保持打開(Tom Lane) 這應該減少長期以來已刪除的表繼續占用磁盤空間問題。 * 當一個新的子進程無法為它的閉鎖創建一個管道的時候，防止數據庫端的崩潰和重啟(Tom Lane) 雖然新的進程失敗了，沒有充分的理由強迫數據庫端重新啟動，所以要避免。當內核差不多超出文件描述符的時候，這提高了魯棒性。 * 避免與加入不平的子查詢的規劃器崩潰(Tom Lane) * 修復外連接上的非嚴格等價從句的規劃(Tom Lane) 規劃器可以獲得來自分句等同于其他一些的非嚴格構建的不正確的約束，例如 `WHERE COALESCE(foo, 0) = 0`，當`foo`來自外連接的空側。 9.2顯示了比以前的版本更多的情況下的這種類型錯誤，但是基本的錯誤已經有很長時間。 * 使用繼承樹上的索引優化`MIN`/`MAX`修復`SELECT DISTINCT` (Tom Lane) 該計劃在給定的這些因素的結合"未能重新找到MinMaxAggInfo記錄"可能失敗。 * 確保規劃器將隱式和顯式轉換出于所有目的看作等效的，除了少數情況下實際上是一個語義差異(Tom Lane) * 當考慮是否部分索引可用于查詢時，包含join子句(Tom Lane) 嚴格的join子句可以充分建立一個 `_x_` `IS NOT NULL`斷言，比如。修復9.2中的規劃器回歸分析，因為先前版本可能做了可比較推理。 * 當同一索引中有很多可索引join子句時，限制規劃器時間的增長(Tom Lane) * 提高規劃器的能力以證明等價類的排除約束(Tom Lane) * 修復散列子規劃中的部分行匹配以正確處理交叉類型例子(Tom Lane) 這影響到多列`NOT IN`子規劃，比如`WHERE (a, b) NOT IN (SELECT x, y FROM ...)` 當例如`b`和`y`分別為`int4`和`int8`時。這個錯誤導致錯誤結果或依據所涉及的具體數據類型崩潰。 * 修復btree 標記/恢復函數以處理數組鍵(Tom Lane) 這種疏忽可能導致來自內側是使用`_indexed_column_` = ANY(`_array_`)條件的索引掃描的合并聯接中的錯誤結果。 * 為采用更少快照恢復補丁(Tom Lane) 減少查詢執行中采取的快照數的9.2變化導致一些在以前版本中沒有見過的異常行為，因為執行會繼續在鎖定查詢使用的表之前獲得的一個快照。因此，例如，查詢將不保證能夠看到前面事務提交的更新即使該事務有排他鎖。我們可能會在未來版本中重新審視它，但同時把它以9.2之前方式放回到原處。 * 當為`AFTER ROW UPDATE/DELETE`觸發器重新讀取舊的元組時，獲取緩沖鎖(Andres Freund) 在十分特殊的情況下，這可能會導致傳遞不正確的數據到一個觸發器`WHEN`條件，或對一個外鍵執行觸發器重新檢測邏輯。這可能導致崩潰，或在錯誤決定情況下觸發觸發器。 * 修復`ALTER COLUMN TYPE`正確處理繼承的檢查約束(Pavan Deolasee) 這在以前8.4版本中正常工作，并且現在在8.4及以后版本中也正常工作。 * 修復`ALTER EXTENSION SET SCHEMA`的錯誤以移動一些附屬對象到新模式中(álvaro Herrera, Dimitri Fontaine) * 在擴展查詢協議中正確處理`CREATE TABLE AS EXECUTE` (Tom Lane) * 不要在`DROP RULE IF NOT EXISTS` and `DROP TRIGGER IF NOT EXISTS`中修改輸入解析樹(Tom Lane) 如果重新執行這些類型之一的已緩存語句，那么可能產生錯誤。 * 修復`REASSIGN OWNED`處理表空間上的授權(álvaro Herrera) * 忽略視圖系統列錯誤的`pg_attribute`項(Tom Lane) 視圖沒有任何系統列。然而，當轉換表到視圖時我們忘了刪除該項。在9.3以及以后被正確修復，但在以前的分支中我們需要防衛現有的錯誤轉換視圖。 * 修復規則輸出以正確轉儲`INSERT INTO` `_table_`DEFAULT VALUES(Tom Lane) * 當在一個查詢中有太多`UNION`/`INTERSECT`/`EXCEPT`子句時，防止堆棧溢出(Tom Lane) * 當使用-1區分盡可能低的整數值時，避免平臺相關錯誤(Xi Wang, Tom Lane) * 修復日期分析中可能訪問以前的字符串末尾(Hitoshi Harada) * 如果在檢查點期間發生XID概括并且`wal_level`是`hot_standby`，那么修復錯誤以提前XID時代(Tom Lane, Andres Freund) 當這個錯誤對PostgreSQL自身沒有特別的影響時，對于依賴于`txid_current()`和相關函數是一個壞的應用：TXID值將出現回退。 * 修復`pg_terminate_backend()`和`pg_cancel_backend()` 不要為非存在的目標過程拋出錯誤(Josh Kupershmidt) 當通過超級用戶調用的時候，該種情況已經按照預期進行，但是當通過普通用戶調用的時候并不這樣。 * 修復頁面邊界`pg_stat_replication`.`sync_state`的顯示(Kyotaro Horiguchi) * 如果為了Unix域套接字的路徑名長度超過特定平臺限制，那么產生可理解的錯誤消息(Tom Lane, Andrew Dunstan) 以前這可能導致一些無用的東西，比如"域名解析不可恢復故障" * 當發送復合列值給客戶端時，修復內存泄露(Tom Lane) * 通過提交時不搜索子事務鎖節省一些周期(Simon Riggs) 在事務中持有許多排他鎖，這些無效活動可能是相當昂貴的。 * 使得pg_ctl關于讀取`postmaster.pid`文件更加健壯(Heikki Linnakangas)。這將修復競爭條件和可能的文件描述符泄漏。 * 如果提出錯誤編碼數據，并且`client_encoding`設置是客戶端編碼，比如SJIS，那么可能在psql中崩潰(Jiang Guiqing) * 在數據不是歸檔預先數據段中使得pg_dump備份`SEQUENCE SET`項(Tom Lane) 這種修復了`--data-only`和`--section=data`意義之間不良的不一致，并修復備份被標記為可擴展配置表序列。 * 修復`--clean`模式中`DROP DATABASE`命令的pg_dump的處理(Guillaume Lelarge) 9.2.0開始，`pg_dump --clean`提出`DROP DATABASE`，根據使用場景這是無用的或者危險的。現在不再是這樣了。這種變化也將修復`--clean`和`--create`的結合以正常運行，即，發出`DROP DATABASE`然后重新連接目標數據庫之前發出`CREATE DATABASE`。 * 為了循環依賴的視圖和沒有關系的選項修復pg_dump(Tom Lane) 當視圖涉及沒有選項不正常工作的情況下的循環依賴時，先前修復是備份關系選項。它發出`ALTER VIEW foo SET ()`，這是無效的語法。 * 修復通過`tar`輸出格式中pg_dump發出的`restore.sql`腳本中的錯誤(Tom Lane) 該腳本在名字包括大寫字母的表上可能失敗。同時，使腳本在`--inserts`模式中和規則COPY模式中能夠恢復數據。 * 修復pg_restore接受符合POSIX標準的`tar`的文件(Brian Weaver, Tom Lane) pg_dump的`tar`輸出模式的原始編碼產生不能與POSIX標準完全一致的文件。這是9.3版本的修正。這個補丁更新以前的分支，以致于它們會接受不正確的和正確的格式，為了避免9.3出現的兼容性問題。 * 修復通過pg_basebackup發出的`tar`文件到符合POSIX標準(Brian Weaver, Tom Lane) * 當給出了數據目錄相應路徑時，修復pg_resetxlog以正確定位`postmaster.pid`(Tom Lane) 這個錯誤可能導致pg_resetxlog沒有注意到使用數據目錄的一個活躍postmaster。 * 修復libpq的`lo_import()`和`lo_export()`函數以正確報告文件I/O錯誤(Tom Lane) * 修復嵌套結構指針變量的ecpg處理(Muhammad Usama) * 修復ecpg的`ecpg_get_data`函數以正確處理數組(Michael Meskes) * 防止pg_upgrade試圖處理系統目錄的TOAST表(Bruce Momjian) 當`information_schema`已被刪除或重新創建時，這修復了發現的錯誤。其他錯誤也是可能的。 * 通過設置新群集中`synchronous_commit`到`off`提升pg_upgrade性能(Bruce Momjian) * 使得`contrib/pageinspect`的btree頁檢查函數當檢查頁時采用緩沖鎖(Tom Lane) * 解決`malloc(0)`和`realloc(NULL, 0)`不可移植操作(Tom Lane) 平臺上這些調用返回`NULL`，一些代碼錯誤地認為內存不足。對數據庫不包含用戶自定義聚合已損壞的pg_dump是已知的。可能還有其他的情況。 * 確保`make install`為擴展創建`extension`安裝目錄(Cédric Villemain) 以前，如果在擴展的Makefile中設置`MODULEDIR`，可以省略該步。 * 修復pgxs支持AIX上編譯可加載模塊(Tom Lane) 編譯不在AIX上運行的初始源碼樹外部模塊。 * 為了Cuba, Israel, Jordan, Libya, Palestine, Western Samoa以及Brazil區域中DST變化規律更新時區數據文件到tzdata版本2012j。