支援的版本: 目前版本 (17)

E.2. 版本 17.1 #

發布日期: 2024-11-14

此版本包含版本 17.0 的各種修復。 關於主要版本 17 中的新功能資訊,請參閱第 E.3 節

E.2.1. 遷移至版本 17.1 #

對於執行 17.X 的使用者,不需要執行轉儲/還原。

但是,如果您曾經從具有外部鍵參考到另一個分割資料表的分割資料表中分離一個分割區,並且沒有刪除前一個分割區,那麼您可能需要修復目錄和/或資料損毀,如下面第五個變更日誌條目中所詳述。

此外,在資料庫的 LC_CTYPE 設定為 C 而其 LC_COLLATE 設定為其他地區設定的罕見情況下,文字欄位上的索引應該重新索引,如下面第六個變更日誌條目中所述。

E.2.2. 變更 #

  • 確保當 RLS 應用於非最上層資料表參考時,快取的計畫會標記為依賴於呼叫的角色 (Nathan Bossart) §

    如果查詢中的 CTE、子查詢、子連結、安全呼叫者視窗或強制轉換投影參考具有列層級安全原則的資料表,我們忽略將產生的計畫標記為可能依賴於正在執行它的角色。 這可能會導致稍後在同一會話中執行查詢時使用錯誤的計畫,然後傳回或隱藏應該隱藏或傳回的列。

    PostgreSQL 專案感謝 Wolfgang Walther 報告此問題。 (CVE-2024-10976)

  • libpq 捨棄在 SSL 或 GSS 協定協商期間收到的錯誤訊息 (Jacob Champion) §

    在完成加密協商之前收到的錯誤訊息可能是由中間人注入的,而不是真正的伺服器輸出。 報告它會為各種安全風險打開大門; 例如,該訊息可能會欺騙查詢結果,而粗心的使用者可能會將其誤認為是正確的輸出。 最佳答案似乎是捨棄此類資料,並且僅依賴 libpq 自己的連線失敗報告。

    PostgreSQL 專案感謝 Jacob Champion 報告此問題。 (CVE-2024-10977)

  • 修正 SET SESSION AUTHORIZATIONSET ROLE 之間的非預期互動 (Tom Lane) § §

    SQL 標準規定 SET SESSION AUTHORIZATION 具有執行 SET ROLE NONE 的副作用。 我們對此的實作存在缺陷,導致兩個設定之間的互動超出預期。 值得注意的是,回滾已執行 SET SESSION AUTHORIZATION 的交易會將 ROLE 還原為 NONE,即使那不是先前的狀態,因此有效的使用者 ID 現在可能與交易之前不同。 在 SET 子句的函數中暫時設定 session_authorization 具有類似的效果。 相關的錯誤是,如果平行工作程序檢查 current_setting('role'),它會看到 none,即使它應該看到其他內容。

    PostgreSQL 專案感謝 Tom Lane 報告此問題。 (CVE-2024-10978)

  • 防止受信任的 PL/Perl 程式碼變更環境變數 (Andrew Dunstan, Noah Misch) § § §

    操作程序環境變數(例如 PATH)的能力為攻擊者提供了執行任意程式碼的機會。 因此,受信任的 PL 不得提供執行此操作的能力。 若要修正 plperl,請將 %ENV 替換為綁定的雜湊,該雜湊會拒絕任何嘗試修改並發出警告。 不受信任的 plperlu 保留變更環境的能力。

    PostgreSQL 專案感謝 Coby Abrams 報告此問題。 (CVE-2024-10979)

  • 修正附加或分離資料表分割區時外部鍵條件約束的目錄狀態更新 (Jehan-Guillaume de Rorthais, Tender Wang, Álvaro Herrera) § §

    如果被參考的資料表已分割,那麼獨立的參考資料表與作為分割區的參考資料表需要不同的目錄條目。ATTACH/DETACH PARTITION 命令未能正確執行此轉換。 特別是,在 DETACH 之後,現在獨立的資料表將缺少外部鍵強制觸發程序,這可能導致該資料表稍後包含未能通過外部鍵條件約束的列。 隨後的重新 ATTACH 也可能因令人驚訝的錯誤而失敗。

    修正此問題的方法是在現在獨立的資料表上,針對每個有缺陷的條件約束執行 ALTER TABLE DROP CONSTRAINT,然後重新新增條件約束。 如果重新新增條件約束失敗,則表示已滲入一些錯誤的資料。 您需要手動重新建立參考資料表和被參考資料表之間的一致性,然後重新新增條件約束。

    此查詢可用於識別損壞的條件約束並建構重新建立它們所需的命令

    SELECT conrelid::pg_catalog.regclass AS "constrained table",
           conname AS constraint,
           confrelid::pg_catalog.regclass AS "references",
           pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;',
                             conrelid::pg_catalog.regclass, conname) AS "drop",
           pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;',
                             conrelid::pg_catalog.regclass, conname,
                             pg_catalog.pg_get_constraintdef(oid)) AS "add"
    FROM pg_catalog.pg_constraint c
    WHERE contype = 'f' AND conparentid = 0 AND
       (SELECT count(*) FROM pg_catalog.pg_constraint c2
        WHERE c2.conparentid = c.oid) <>
       (SELECT count(*) FROM pg_catalog.pg_inherits i
        WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND
          EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table
                  WHERE partrelid = i.inhparent));
    

    由於一個或多個 ADD CONSTRAINT 步驟可能會失敗,因此您應該將查詢的輸出儲存在檔案中,然後嘗試執行每個步驟。

  • 修正在 LC_COLLATELC_CTYPE 不同時,C 地區設定的測試 (Jeff Davis) §

    當使用 libc 作為預設排序規則提供者時,用於查看 C 地區設定是否用於排序的測試意外地檢查了 LC_CTYPE 而不是 LC_COLLATE。 如果這些設定相同,或者兩者都不是 C (也不是其別名 POSIX),則這沒有影響。 但是,如果 LC_CTYPEC,而 LC_COLLATE 是其他地區設定,則可能會出現錯誤的查詢結果,並且可能會損毀字串上的索引。 安裝此更新後,具有此類設定的資料庫的使用者應該重新索引受影響的索引。 相反的情況是,如果 LC_COLLATEC,而 LC_CTYPE 是其他地區設定,則會導致效能下降,但不會出現實際錯誤。

  • 如果金鑰欄位的查詢排序規則與分割區金鑰的排序規則不符,則不要使用分割區式聯結或分組 (Jian He, Webbo Han) § §

    此類計畫可能會產生不正確的結果。

  • 避免在將 NOT NULL 欄位上的 IS NULL 測試轉換為常數 FALSE 之後,規劃器失敗 (Richard Guo) §

    這個錯誤通常會導致類似「variable not found in subplan target lists」的錯誤訊息。

  • 避免在嵌入 SQL 函數(其參數包含某些與陣列相關的結構)時,可能發生的規劃器崩潰 (Tom Lane, Nathan Bossart) §

  • 修正 MERGE ... WHEN NOT MATCHED BY SOURCE 操作可能產生的錯誤答案或「wrong varnullingrels」規劃器錯誤 (Dean Rasheed) § §

  • 修正當 UNION ALL 成員查詢的輸出需要排序,且排序欄位是一個表達式時,可能發生的「could not find pathkey item to sort」錯誤 (Andrei Lepikhov, Tom Lane) §

  • 修正 B-tree ScalarArrayOp 索引掃描中的邊緣案例 (Peter Geoghegan) §

    當具有此類計劃的可滾動游標備份到其起點,然後再次向前執行時,可能會產生錯誤的答案。

  • 修正 COPY (query) TO ... 的斷言失敗或令人困惑的錯誤訊息,當 queryDO INSTEAD NOTIFY 規則重寫時 (Tender Wang, Tom Lane) §

  • 修正 COPYFORCE_NOT_NULLFORCE_NULL 選項的驗證 (Joel Jacobson) §

    一些不正確的用法現在被拒絕,因為它們本來就應該被拒絕。

  • 修正當 json_objectagg() 呼叫包含一個不穩定的函數時,伺服器崩潰的問題 (Amit Langote) §

  • 修正平行雜湊連接期間的傾斜資料偵測 (Thomas Munro) §

    在重新分割雜湊連接的內部之後,因為一個分割區累積了過多的元組,我們會檢查是否所有分割區的元組都進入了同一個子分割區,這表示它們都具有相同的雜湊值,並且進一步的重新分割無法改善情況。這個檢查在某些情況下會發生故障,導致重複無用的重新分割,最終會以資源耗盡錯誤告終。

  • 避免當使用 ALTER DATABASE SET 設定需要基於搜尋路徑查找的伺服器參數(例如 default_text_search_config)時發生的崩潰 (Jeff Davis) §

  • 避免在分割資料表上建立新索引時重複查找運算子類別和定序 (Tom Lane) §

    這主要是因為某些查找將使用受限制的 search_path 進行,如果 CREATE INDEX 命令引用了 pg_catalog 之外的物件,則會導致意外的失敗。

    此修復程式還防止將父分割索引上的註解複製到子索引。

  • 添加從分割資料表到 CREATE TABLE ... USING 中指定的非內建存取方法的遺漏依賴關係 (Michael Paquier) §

    當存在依賴於該存取方法的資料表時,應該阻止刪除該存取方法,但實際上並沒有,從而導致後續的奇怪行為。請注意,此修復程式僅防止在此更新後建立的分割資料表的問題。

  • 不允許包含非 ASCII 字元的語言環境名稱 (Thomas Munro) §

    這僅在 Windows 上是一個問題,因為其他地方沒有使用此類語言環境名稱。它們存在問題,因為非常不清楚此類名稱以何種編碼表示(因為語言環境本身定義了要使用的編碼)。在最近的 PostgreSQL 版本中,由於對此感到困惑,可能會發生 Windows 運行時庫中的中止。

    遇到新錯誤訊息的任何人,都應該使用 Windows Locale Builder 建立一個新的具有僅 ASCII 名稱的複製語言環境,或者考慮使用符合 BCP 47 的語言環境名稱,例如 tr-TR

  • 修正提交可序列化事務中的競爭條件 (Heikki Linnakangas) §

    錯誤處理最近提交的事務可能會導致斷言失敗或「could not access status of transaction」錯誤。

  • 修正 COMMIT PREPARED 中導致孤立 2PC 檔案的競爭條件 (wuchengwen) §

    並發的 PREPARE TRANSACTION 可能導致 COMMIT PREPARED 無法刪除已完成事務的磁碟二階段狀態檔案。沒有立即的不良影響,但是隨後的崩潰和恢復可能會失敗,並顯示「could not access status of transaction」,需要手動刪除孤立的檔案才能恢復服務。

  • 避免在 VACUUM FULL 期間跳過無效的 toast 索引後,發生無效的記憶體存取 (Tender Wang) §

    在這個程式碼路徑中,追蹤尚未重建索引的清單沒有被正確更新,從而冒著稍後發生斷言失敗或崩潰的風險。

  • 修正在「in place」目錄更新可能會遺失的方式 (Noah Misch) § § § § § § §

    正常的資料列更新會寫入資料列的新版本,以保留事務的可回滾性。但是,某些系統目錄更新是有意非事務性的,並且是通過對資料列進行就地更新來完成的。這些修補程式修正了可能導致就地更新的效果遺失的競爭條件。例如,可能會忘記將 pg_class.relhasindex 設置為 true,從而阻止更新新索引,進而導致索引損壞。

  • 在恢復結束時重置目錄快取 (Noah Misch) §

    這可以防止由於使用來自目錄快取的過時資料而可能遺失就地目錄更新的情況。

  • 避免在關閉中斷時使用平行查詢 (Francesco Degrassi, Noah Misch, Tom Lane) § §

    這種情況通常不會發生,但是可以使用測試場景(例如使用 SQL 語言函數作為 B-tree 支援)來實現(這對於生產用途來說太慢了)。如果確實發生,將導致無限期等待。

  • 忽略 pg_cursors 視圖中尚未定義的 Portal (Tom Lane) §

    當設置新的游標時,可能會呼叫檢查此視圖的使用者定義程式碼,如果發生這種情況,將會導致空指標取消引用。透過定義視圖以排除不完整設置的游標來避免此問題。

  • 避免在解碼涉及插入欄位預設值的交易時發生logical decoding 期間出現 unexpected table_index_fetch_tuple call錯誤 (Takeshi Ideriha, Hou Zhijie) § §

  • 減少邏輯解碼的記憶體消耗 (Masahiko Sawada) §

    使用較小的預設區塊大小來儲存邏輯複製期間接收的 tuple 資料。這減少了記憶體浪費,據報告在處理長時間運行的交易時非常嚴重,甚至導致記憶體不足的失敗。

  • 修復從 CALL 語句的引數列表呼叫的 stable 函數的行為,當 CALL 位於 PL/pgSQL EXCEPTION 區塊中時 (Tom Lane) §

    如同我們先前季度版本中的類似修復,這種情況允許將錯誤的快照傳遞給這些函數,導致它們看到自外部交易開始以來已修改的列的過時值。

  • 以與其他整數值選項相同的方式解析 libpqkeepalives 連線選項 (Yuto Sasaki) §

    此處使用的編碼拒絕選項值中的尾隨空白,這與其他情況不同。事實證明,這在 ecpg 的使用中存在問題,例如。

  • ecpglib 中,修復解析不正確的日期時間輸入時的越界讀取 (Bruce Momjian, Pavel Nekrasov) §

    可能嘗試讀取剛好在常數陣列開始之前的位置。但實際後果似乎很小。

  • 修復 psql 的 describe 命令,使其再次適用於 9.4 之前的伺服器 (Tom Lane) §

    由於使用了這些版本中不存在的函數,因此涉及顯示 ACL(權限)欄位的指令在非常舊的 PostgreSQL 伺服器上會失敗。

  • 避免在 psql\watch 命令中指定小於 1 毫秒的時間間隔時掛起 (Andrey Borodin, Michael Paquier) §

    相反,將其視為與零的時間間隔相同(執行之間沒有等待)。

  • 修復在 ~/.pgpass 中找不到複製密碼的問題 (Tom Lane) §

    如果未提供 -d--dbname 參數,則 pg_basebackuppg_receivewal 無法匹配 ~/.pgpass 中資料庫名稱欄位包含 replication 的條目。 這會導致意外的密碼提示。

  • pg_combinebackup 中,如果增量備份檔案出現在應該包含完整備份的目錄中,則丟出錯誤 (Robert Haas) §

  • pg_combinebackup 中,不要建構包含雙斜線的檔名 (Robert Haas) §

    這不會導致功能問題,但重複的斜線會顯示在錯誤訊息中,這可能會造成混淆。

  • 避免嘗試在 vacuumdb 和並行 reindexdb 中重新索引臨時表格和索引 (VaibhaveS, Michael Paquier, Fujii Masao, Nathan Bossart) § § §

    重新索引其他會話的臨時表格是不可行的,但在某些程式碼路徑中缺少跳過它們的檢查,導致不必要的失敗。

  • 修復 ARM64 平台上 LLVM 產生的錯誤程式碼 (Thomas Munro, Anthonin Bonnefoy) §

    在 ARM 平台上使用 JIT 編譯時,產生的程式碼可能不支援超過 32 位的重定位距離,允許產生的程式碼的不幸放置導致大型記憶體系統上的伺服器崩潰。

  • 修復一些假設流程啟動時間 (表示為 time_t) 將適合 long 值的問題 (Max Johnson, Nathan Bossart) §

    long 為 32 位的平台上(尤其是 Windows),此編碼將在 2038 年之後失敗。大多數失敗似乎只是表面上的,但值得注意的是 pg_ctl start 會掛起。

  • 將時區資料檔案更新至 tzdata release 2024b (Tom Lane) § §

    tzdata 版本將舊的 System-V 相容性區域名稱更改為複製相應的地理區域;例如 PST8PDT 現在是 America/Los_Angeles 的別名。 主要的明顯後果是,對於標準化時區引入之前的時間戳記,該區域被認為代表命名位置的當地平均太陽時間。 例如,在 PST8PDT 中,timestamptz 輸入(例如 1801-01-01 00:00)之前會被呈現為 1801-01-01 00:00:00-08,但現在它被呈現為 1801-01-01 00:00:00-07:52:58

    此外,還有針對墨西哥、蒙古和葡萄牙的歷史修正。 值得注意的是,Asia/Choibalsan 現在是 Asia/Ulaanbaatar 的別名,而不是一個單獨的區域,主要是因為發現這些區域之間的差異是基於不可靠的資料。

提交更正

如果您在文件中發現任何不正確、與特定功能的使用體驗不符或需要進一步澄清的地方,請使用此表單來報告文件問題。