PostgreSQL 每週新聞 - 2021 年 1 月 3 日

由 PWN 發表於 2021-01-03
PWN

PostgreSQL 每週新聞 - 2021 年 1 月 3 日

PostgreSQL 每週新聞祝您新年快樂!

PostgreSQL 產品新聞

Database Lab 2.1 發布,這是一個用於快速複製大型 PostgreSQL 數據庫以構建非生產環境的工具:https://postgres.ai/blog/dle-2.1-release/

一月份的 PostgreSQL 工作

https://archives.postgresql.org/pgsql-jobs/2021-01/

PostgreSQL 新聞

Planet PostgreSQL: https://planet.postgresql.org/

PostgreSQL 每週新聞由 David Fetter 本週為您帶來

請在太平洋標準時間 (PST8PDT) 星期日下午 3:00 之前將新聞和公告提交至 david@fetter.org。

已應用的補丁

Jeff Davis 推送

Bruce Momjian 推送

Fujii Masao 推送

  • postgres_fdw:修復連接洩漏。在 postgres_fdw 中,如果刪除用戶映射或外國伺服器(這些連接依賴於它們),則到外國伺服器的快取連接將不會關閉,直到本機連線結束。這些連接可能會洩漏。為了修復連接洩漏問題,在更改 pg_foreign_server 或 pg_user_mapping 目錄條目後,如果當前交易尚未使用這些連接,則此提交會使 postgres_fdw 立即關閉依賴於該條目的連線。否則,將這些連線標記為無效,然後在當前交易結束時關閉它們,因為它們無法在使用它們的交易過程中關閉。如果需要,關閉的連線將在下次有機會時重新建立。向所有支援的分支進行反向移植。作者:Bharath Rupireddy 審閱人:Zhihong Yu, Zhijie Hou, Fujii Masao 討論:https://postgr.es/m/CALj2ACVNcGH_6qLY-4_tXz8JLvA+4yeBThRfxMz7Oxbk1aHcpQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e3ebcca843a4703938b9f40a4811f43c4b315753

Michaël Paquier 推送

Tom Lane 推送

  • 修復 plpgsql 記憶體洩漏修復中的 thinko。提交 a6b1f5365 旨在將 CALL 語句的暫時性「目標」清單放置在函數的語句生命週期上下文中,但我搞砸了它,使用了 get_eval_mcontext() 而不是 get_stmt_mcontext()。eval_mcontext 屬於「簡單表達式」基礎結構,該基礎結構在交易結束時被銷毀。實際效果是,如果被呼叫的程序執行 COMMIT,則程序中對另一個具有 OUT 或 INOUT 參數的程序的 CALL 將失敗。根據 Peter Eisentraut 的報告。像先前的補丁一樣,反向移植到 v11。討論:https://postgr.es/m/f075f7be-c654-9aa8-3ffc-e9214622f02a@enterprisedb.com https://git.postgresql.org/pg/commitdiff/ea80d8d9437e80de6506dbfe3765d834653312bf

  • 進一步修復 plpgsql 記憶體洩漏修復中的 thinko。還有第二次呼叫 get_eval_mcontext() 也應該是 get_stmt_mcontext()。這實際上是死代碼,因為在切換回原始上下文之前不會發生任何有趣的分配,但我們應該使其與另一次呼叫保持同步,以防止將來可能出現的錯誤。討論:https://postgr.es/m/f075f7be-c654-9aa8-3ffc-e9214622f02a@enterprisedb.com https://git.postgresql.org/pg/commitdiff/5f2e09bcccd771629fb7a2885f8c468ae0f7fb33

  • 在 PQconndefaults() 中公開 channel_binding 的預設值。如果連接選項有靜態預設值,則應在 PQconninfoOptions 陣列中顯示它。Daniele Varrazzo 討論:https://postgr.es/m/CA+mi_8Zo8Rgn7p+6ZRY7QdDu+23ukT9AvoHNyPbgKACxwgGhZA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cf61b0734c61d93c62827fe4e44fa2162a533b8e

  • 修正 libpq 的 GSSAPI 加密支援中的錯誤。此處修正的關鍵問題是,如果成功建立 GSSAPI 加密連線,pqsecure_open_gss() 會清除 conn->allow_ssl_try,這是一種(不得不承認是個)權宜之計,目的是避免我們嘗試透過已加密的連線建立 SSL 加密通道。問題是,如果我們因為驗證失敗而放棄 GSSAPI 連線,我們就不會在下次嘗試與同一伺服器連線時嘗試 SSL 加密。這可能會導致意外的連線失敗,或在預期加密連線的情況下,靜默地建立一個未加密的連線。幸運的是,只有當客戶端和伺服器都在同一個 Kerberos 基礎架構中持有有效的票證時,我們才能成功建立 GSSAPI 加密連線,這是一種相對不常見的環境。儘管如此,這是一個非常嚴重的錯誤,具有潛在的安全後果。為了修復這個問題,不要重置這個 flag,而是在決定是否嘗試啟動 SSL 時,檢查 conn->gssenc 是否已經為真。同時,修正 libpq 的 GSSAPI 程式碼中的一些小問題:* 在放棄嘗試的 GSSAPI 連線時,使用 need_new_connection stanza,而不是部分複製該程式碼。這樣做的後果非常小:我認為它只會導致 auth_req_received 或 password_needed 在不應該設定時仍然設定,這並沒有太大的危害。* 修正 pg_GSS_error(),使其不要重複多次給定的 "mprefix",並注意 gss_display_status() 的任何失敗回傳。* 避免在 pg_GSS_load_servicename() 中不必要的依賴 NI_MAXHOST。根據 Mikael Gustavsson 的報告。回溯修補到引入此程式碼的 v12 版本。討論:https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se https://git.postgresql.org/pg/commitdiff/ff6ce9a3a691a96e8e47ed449bc51c5a178e6931

  • 修正後端 GSSAPI 加密支援中的各種問題。GSSAPI 加密檢測到的不可恢復的錯誤不能僅使用 elog(ERROR) 或 elog(FATAL) 報告,因為嘗試將錯誤報告傳送給客戶端很可能會導致無限遞迴或協議同步丟失。相反,讓此程式碼像 SSL 加密程式碼長期以來所做的那樣,只是將任何此類失敗報告到伺服器日誌(使用 elevel COMMERROR),然後透過回傳 errno = ECONNRESET 來假裝我們已經丟失了連線。同時,修正 pg_GSS_error() 或其呼叫者(後者應該這樣做)是否執行訊息翻譯的混淆,並使後端版本的函數更像前端版本。避免在需要之前分配 port->gss struct;我們肯定不需要在 postmaster 中分配它。改進啟用 GSS 時的“連線已授權”訊息的日誌記錄。(作為此操作的一部分,我回溯修補了 dc11f31a1 中的程式碼變更。)使 BackendStatusShmemSize() 考慮 CreateSharedBackendStatus() 將分配的與 GSS 相關的空間。這種遺漏可能會在高 max_connections 設定下導致共用記憶體不足的問題。刪除僅 GSS 身份驗證可用於 GSS 加密連線的任意、毫無意義的限制。改進文件;值得注意的是,記錄了 libpq 現在在可能的情況下更喜歡 GSS 加密而不是 SSL 加密的事實。根據 Mikael Gustavsson 的報告。回溯修補到引入此程式碼的 v12 版本。討論:https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se https://git.postgresql.org/pg/commitdiff/622ae4621ece72a9f64b5602c74d7aaf373c1631

  • 改進與 pg_hba.conf 不匹配連線相關的日誌訊息。包括 GSS 加密是否已啟用的詳細資訊;由於我們新增了 "hostgssenc" 類型的 HBA 條目,因此這是相關資訊。Kyotaro Horiguchi 和 Tom Lane。回溯修補到引入 GSS 加密的 v12 版本。討論:https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se https://git.postgresql.org/pg/commitdiff/3995c424984e991b1069a2869af972dc07574c0b

  • 抑制來自多個 SIGQUIT 關閉報告的日誌垃圾訊息。當 postmaster 向其子程序傳送 SIGQUIT 時,所有子程序都沒有真正需要記錄這一事實;postmaster 已經建立了一個關於它的日誌條目,因此新增可能數十個或數百個子程序日誌條目沒有增加任何價值。因此,讓我們引入一個新的 ereport 等級來指定“警告,但永遠不要傳送到日誌”,並將其用於這些訊息。在 commit 7e784d1dc 之前,這樣的變更並不可取,因為如果有人手動 SIGQUIT 一個後端,我們確實想要記錄它。但是現在我們可以合理地分辨出訊號是由 postmaster 發出的還是不是。在我們在這裡的時候,還要在 ereport'ing 之前清除 error_context_stack,以防止在訊號處理器上下文中調用錯誤回呼。這應該會降低在嘗試通知客戶端時掛斷的機率。根據 Andres Freund 的建議。討論:https://postgr.es/m/20201225230331.hru3u6obyy6j53tk@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/1f9158ba48122fa232db955a2ee324eec1848ba9

  • 文件:修正過寬表格欄位導致的 PDF 建置警告。將 multirange 資訊新增到表格 8.27 和 65.1 使它們開始在 PDF 文件建置中拋出“超出可用區域”警告。對於 8.27,調整現有的欄寬提示足以解決這個問題。對於 65.1,我稍微調整了一下寬度,但要真正解決它,我必須在表格中的每個逗號後插入一個空格,以允許在此處發生換行。(這似乎比插入 &zws;; 實體更容易閱讀和維護。)根據建置農場。https://git.postgresql.org/pg/commitdiff/f20dc2c8dd50a5c738d535205d5d44bff82d3f75

  • 修正 krb_server_keyfile GUC 參數的使用。secure_open_gssapi() 無條件地將 krb_server_keyfile 設定安裝為 KRB5_KTNAME,只要它不為空。但是,pg_GSS_recvauth() 僅在 KRB5_KTNAME 尚未設定時才安裝它,導致一個令人不安的不一致:從理論上講,客戶端可能會看到不同的伺服器主體名稱集,具體取決於他們是否使用 GSSAPI 加密。始終使用 krb_server_keyfile 似乎是正確的做法,因此讓兩個地方都這樣做。同時,修正 secure_open_gssapi() 缺乏對 setenv() 失敗的檢查---它肯定不太可能,但對於安全性至關重要的操作不應該草率。同時改進相關文件。此修補程式對 secure_open_gssapi() 使用 setenv() 沒有任何作用,實際上還會導致 pg_GSS_recvauth() 也使用它。這名義上違反了專案的可移植性規則,但由於此程式碼僅使用 --with-gssapi 建置,因此我認為沒有必要在後端分支中對此做任何事情。HEAD 即將推出修復程式。回溯修補到引入 GSSAPI 加密的 v12 版本。pg_GSS_recvauth() 中可疑的行為可以追溯到更遠,但它沒有任何不一致的地方,所以就讓它這樣吧。討論:https://postgr.es/m/2187460.1609263156@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/860fe27ee1e2a4a1c36c2f874c37656533cccce9

  • 優先使用 setenv() 而非 putenv()。至少從 2001 年起,我們一直使用 putenv() 並避免使用 setenv(),理由是後者不具備可攜性且不在 POSIX 標準中。然而,POSIX 在同一年加入了 setenv(),而現在情況已經逆轉:setenv() 可能比 putenv() 更具可攜性,因為 POSIX 現在將後者視為非核心功能。而且 setenv() 也具有更清晰的語意。因此,讓我們推翻舊的策略。此提交為任何落後者新增了一個簡單的 src/port/ setenv() 實作(我們在 buildfarm 中有一個,但我如果該程式碼從未在實際環境中使用也不會感到驚訝)。更重要的是,擴展 win32env.c 以同時支援 setenv()。然後,將 putenv() 的使用替換為 setenv(),並擺脫一些 ad-hoc 的 setenv() 仿製品。此外,調整我們的 src/port/ unsetenv() 實作,以遵循 POSIX 規範,使其返回錯誤指標,而不是按照古代 BSD 慣例返回 void。我認為沒有必要讓所有呼叫點都檢查錯誤,但可攜性存根應該符合實際的應用情況。討論:https://postgr.es/m/2065122.1609212051@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/7ca37fb0406bc2cbbd864a2ffdbdb4479e338c0c

  • 更多針對 pg_upgrade 跨版本測試的修正。提交 7ca37fb04 從 regress.so 函式庫中移除了 regress_putenv,因此重新載入依賴於該函式的 SQL 函式將無法運作。以類似於 52202bb39 的方式進行修復。根據 buildfarm。https://git.postgresql.org/pg/commitdiff/091866724cb3ee7251fa56e2517248c4b7796ca8

  • 文件:明確說明日期/時間類型的比較行為。日期/時間資料類型之間的跨類型比較行為實際上沒有在任何地方解釋。如果你能識別出其他地方關於資料類型轉換的註解的適用性,你可能會推斷出它,但似乎值得明確的文件化。根據 Dana Burd 的錯誤 #16797。討論:https://postgr.es/m/16797-f264b0b980b53b8b@postgresql.org https://git.postgresql.org/pg/commitdiff/319f4d54e82d15d4a0c3f4cc1328c40dba024b5c

  • 文件:改進 EXTRACT(EPOCH) 對於沒有時區的時間戳記的說明。嘗試更清楚地說明這裡實際發生的計算。根據 Dana Burd 的錯誤 #16797。討論:https://postgr.es/m/16797-f264b0b980b53b8b@postgresql.org https://git.postgresql.org/pg/commitdiff/4d3f03f42227bb351c2021a9ccea2fff9c023cfc

Alexander Korotkov 推送了

Noah Misch 推送了

Amit Kapila 推送了

  • 擴展輸出外掛程式 API 以允許解碼準備好的 xact。這會向輸出外掛程式 API 新增六種方法,從而在準備時新增對雙階段交易變更串流的支援。* begin_prepare * filter_prepare * prepare * commit_prepared * rollback_prepared * stream_prepare 其中大部分是對現有方法的簡單擴展,語意上的差異在於交易尚未提交,並且可能會稍後中止。到目前為止,雙階段交易在訂閱者上被翻譯成常規交易,並且 GID 沒有轉發給它。沒有任何雙階段命令傳達給訂閱者。此修補程式提供基礎架構,以便邏輯解碼外掛程式被告知具有相應 GID 的雙階段命令,例如 PREPARE TRANSACTION、COMMIT PREPARED 和 ROLLBACK PREPARED 命令。這也擴展了 'test_decoding' 外掛程式,實作了這些新方法。此提交僅新增這些新的 API,即將到來的修補程式「允許在 ReorderBuffer 中進行準備時的解碼」將使用這些 API。作者:Ajin Cherian 和 Amit Kapila,基於 Nikhil Sontakke 和 Stas Kelvich 的先前工作。審閱者:Amit Kapila、Peter Smith、Sawada Masahiko 和 Dilip Kumar。討論:https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru https://postgr.es/m/CAMGcDxeqEpWj3fTXwqhSwBdXd2RS9jzwWscO-XbeCfso6ts3+Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0aa8a01d04c8fe200b7a106878eebc3d0af9105c

Peter Geoghegan 推送了

  • 修正索引刪除時 latestRemovedXid 的錯誤。在 REDO 例程中,用於決定最新移除 XID 以產生復原衝突的邏輯存在細微的錯誤。它無法追蹤 HOT 鏈的連結,因此在某些情況下無法考慮所有相關的堆積元組標頭。為了修正此問題,擴展處理 LP_REDIRECT 行指標的迴圈,使其也能處理 HOT 鏈。新版本的迴圈大致基於 heap_prune_chain() 中的類似迴圈。這個錯誤的影響可能非常有限,因為 horizon 程式碼必然處理由 LP_DEAD 設定的索引元組所指向的堆積元組。設定 LP_DEAD 索引元組的過程 (例如,在 kill_prior_tuple 機制中) 與機會性修剪指向的堆積元組高度相關。此外,產生復原衝突的問題通常是在索引元組 LP_DEAD 位元最初設定後一段時間才會出現,這與堆積修剪不同,堆積修剪會在修剪操作時產生 latestRemovedXid (堆積修剪沒有延遲的 "would-be page split" 風格處理,會懶惰地產生衝突)。僅回溯修補到 Postgres 12,這是第一個在此邏輯在原始執行期間運行的版本 (在 commit 558a9165e08 之後)。索引 latestRemovedXid 機制自 10 多年前首次出現以來 (在 commit a760893d 中) 就存在相同的錯誤,但現在回溯修補到所有支援的版本似乎不是一個好主意。在復原期間運行新的改進程式碼似乎有風險,尤其是在沒有收到來自現場的投訴的情況下。作者:Peter Geoghegan pg@bowt.ie 討論:https://postgr.es/m/CAH2-Wz=Eib393+HHcERK_9MtgNS7Ew1HY=RDC_g6GL46zM5C6Q@mail.gmail.com 回溯修補:12- https://git.postgresql.org/pg/commitdiff/422881744997417944634a7f84af7a66a608de9a

  • 在持有緩衝區鎖定的情況下取得堆積頁面最大偏移量。進一步思考後,在取得頁面的緩衝區鎖定後呼叫 PageGetMaxOffsetNumber() 似乎更好。這實際上應該沒有關係,但這樣做更乾淨。Commit 42288174 的後續行動。回溯修補:12-,就像 commit 42288174 一樣 https://git.postgresql.org/pg/commitdiff/32d6287d2eef6b6a4dde07e0513f3e4f321792ad

待處理的修補程式

Noah Misch 送出了一個修補程式,將相似的演算法合併到 roles_is_member_of() 中。

Vigneshwaran C 在現有的修補程式之上送出了一個修補程式,以平行化 COPY 的部分,該修補程式將尋找行邊界的任務委派給 worker。

Bharath Rupireddy 送出了一個修補程式,以實作 REFRESH MATERIALIZED VIEW 的 EXPLAIN [ANALYZE]。

Masahiko Sawada 送出了另一個修訂版本的修補程式,以新增新的 FDW API 來支援 2PC、引入全域交易管理器,並在 PostgreSQL FDW 中實作這些 FDW API。

Peter Geoghegan 送出了另一個修訂版本的修補程式,以進行 btvacuumstrategy() 由下而上的索引刪除變更。

Bharath Rupireddy 送出了另外兩個修訂版本的修補程式,使 CTAS 可以使用平行插入。

Luc Vlaming 送出了兩個修訂版本的修補程式,以延遲產生 JIT IR 程式碼,這個問題出現在為分割表不必要地產生大量 JIT IR 程式碼的情況下,其中許多分割區的 IR 從未執行,因為這些分割區被修剪了。

Thomas Munro 送出了另一個修訂版本的修補程式,使其可以使用平行雜湊來執行 Full 和 Right JOIN。

Andrey Borodin 送出了另一個修訂版本的修補程式,以將 LZ4 新增為 WALL FPI 的可能壓縮方案。

David Rowley 送出了另外兩個修訂版本的修補程式,以減少在 Windows 上建置 contrib 模組的特殊情況數量。

Noah Misch 送出了一個修補程式,以傾印 public schema 的所有權和安全性標籤。

Paul Martinez 送出了一個修補程式,以簡化 user.c 中的權限檢查邏輯。

Bharath Rupireddy 送出了另一個修訂版本的修補程式,允許在規劃 REFRESH MATERIALIZED VIEW 時使用平行模式。

Thomas Munro 送出了另一個修訂版本的修補程式,以在共享記憶體中追蹤關係大小,此功能由新的 GUC smgr_shared_relation 控制,該 GUC 限制了新引入的 SMgrSharedRelation 物件池的數量,並為 smgrnblocks() 提供無鎖定的快速路徑。

Peter Smith 送出了另一個修訂版本的修補程式,允許 table-sync worker 使用多個交易。

Andrey V. Lepikhov 送出了另一個修訂版本的修補程式,透過在 FDW API 中新增三個新的例程來加速 COPY,以處理具有外部分割區的表的情況:BeginForeignCopy、EndForeignCopy 和 ExecForeignCopy,並將相同的例程新增到 PostgreSQL FDW。

Andrey Borodin 送出了另一個修訂版本的修補程式,重新組織 pglz 壓縮程式碼,使其更有效率,方法是將巨集函式轉換為一般函式以提高可讀性,使用具有 uint16 索引而不是指標的更緊湊的雜湊表,避免雜湊表中的 prev 指標,並在搜尋中使用 4 位元組比較而不是 1 位元組比較。

Justin Pryzby 送出了另一個修訂版本的修補程式,以實作 CREATE TABLE (LIKE .. INCLUDING ACCESS METHOD)。

Luc Vlaming 送出了另一個修訂版本的修補程式,允許部分 UNION ALL,從而改善平行子查詢的成本估算。

Rui Zhao 送出了另一個修訂版本的修補程式,重構在 RelationIdGetRelation 之後呼叫 RelationClose 的方式。

Peter Eisentraut 送出了另一個修訂版本的修補程式,以實作來自程序的動態結果集。

David Fetter 送出了兩個修訂版本的修補程式,將 popcount 顯示到 SQL。

Joe Wildish 送出了另一個修訂版本的修補程式,允許在 FOR EACH STATEMENT 觸發器的 WHEN 表達式中使用查詢。

David Fetter 送出了另一個修訂版本的修補程式,使其可以從 initdb 設定 pg_hba.conf 參數。

Greg Sabino Mullane 送出了另一個修訂版本的修補程式,使 psql 的 \df 可以通過輸入類型來幫助選擇函數。

David Fetter 和 Krasiyan Andreev 交換了修補程式,以實作視窗函數的 NULL 處理。

Dmitry Dolgov 送出了另外三個修訂版本的修補程式,以將通用類型下標基礎結構用於 JSONB。

David Fetter 送出了一個 WIP 修補程式,以記錄 hooks 系統。

Michael Banck 送出了一個修補程式,以新增一個新的 PGC_ADMINSET guc context 和 pg_change_role_settings 預設角色,在 'superuser' 和 'user' 之間建立一個空間,用於 GUC context。

Álvaro Herrera 送出了另一個修訂版本的修補程式,以實作 MERGE。

Peter Geoghegan 送出了另一個修訂版本的修補程式,以傳遞一個 "邏輯上未更改的索引" 提示,並使用它來實作由下而上的索引刪除。

Soumyadeep Chakraborty 送出了另一個修訂版本的修補程式,以將一個例程新增到接受欄位投影列表的表 AM API。

Bruce Momjian 和 Michaël Paquier 交換了修補程式,以將其他十六進位函數移動到原始碼樹中的通用位置。

Etsuro Fujita 送出了另外兩個修訂版本的修補程式,以在 postgres_fdw 節點上實作非同步附加。

David Fetter 送出了一個修訂版的 patch,用於實作 TID 的範圍掃描。

Pavel Stěhule 送出了一個修訂版的 patch,用於減少 PL/pgSQL 中非原子模式下 CALL 陳述式的執行額外負荷。

Pavel Stěhule 送出了一個修訂版的 patch,用於實作 schema 變數。

Josef Šimánek 送出了一個修訂版的 patch,用於新增一個 pg_stat_progress_copy 視窗,顯示 COPY 進度報告。

Pavel Stěhule 送出了一個 patch,使 PLs 可以編寫 window functions,因為目前它們僅限於 C 語言。

Luc Vlaming 送出了一個 patch,透過為每個後端分配一組獨立的、屬於該後端的區塊,來提高 heap table 的大量載入效率,並透過移動邏輯來減少鎖定分割區緩衝區所花費的時間,使每組 128 個區塊使用相同的緩衝區分割區,然後新增一個自訂函數來專門用於擴充獲取緩衝區區塊,同時保持先前的分割區鎖定,從而減少了我們在 futexes 上花費的時間。

Michael Banck 送出了一個 patch,將 --data-checksums 移動到 initdb 的 --help 輸出中的通用選項。

Thomas Munro 送出了一個 patch 給 pgbench,為缺乏 pthread barrier 的平台新增 pthread barrier 模擬。