2025年9月25日: PostgreSQL 18 釋出！

PostgreSQL 每週新聞 - 2021 年 10 月 17 日

釋出於 2021-10-18，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 10 月 17 日

PostgreSQL 產品新聞

psycopg2 3.0.0，一個用於 PostgreSQL 的 Python 聯結器，已釋出

pg_partman 4.6.0，一個分割槽表管理系統，已釋出。

pgAdmin4 6.0，一個用於 PostgreSQL 的 Web 和原生 GUI 控制中心，已釋出。

Percona Distribution for PostgreSQL Operator 1.0.0，一個基於 Crunchy Data 的 Kubernetes Operator，用於 PostgreSQL，已釋出。

10 月份的 PostgreSQL 工作崗位

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

PostgreSQL 相關新聞

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

本週 PostgreSQL 週報由 David Fetter 提供。

請在太平洋標準時間（PST8PDT）週日晚上3:00之前將新聞和公告發送至 david@fetter.org。

已應用補丁

Tom Lane 提交

  • 文件：更新 src/test/perl/README 中的測試配方。之前的文字未能清楚解釋我們關於 TAP 測試可移植性的策略。perlbrew 的使用配方也有一些問題：它導致了一個非共享的 libperl（阻止了 plperl 的測試），並且它導致了一些模組被更新到最新版本，而配方的目的是構建一箇舊環境。討論：https://postgr.es/m/E1mYY6Z-0006OL-QN@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/3eb1f4d09745433c70ccac411cad24d0374b9c3b

  • 進一步修復 EXPLAIN 中 SEARCH BREADTH FIRST 查詢的處理。Commit 3f50b8263 有一個疏漏：以前，要反解析附加到計劃節點上的表示式，只需要在呼叫 set_deparse_plan 時更新 deparse_namespace ancestors 列表。現在，需要 *先* 更新 ancestors 列表，因為 set_deparse_plan 會查詢它，而有一個呼叫點在這方面出錯了。大多數情況下，這個錯誤被掩蓋了，因為 explain.c 只使用一個 List 物件作為 ancestors 列表，在掃描計劃時就地更新它，所以我們會在需要 dpns->ancestors 之前意外地將其分配給正確的 List。只有當 WorkTableScan 節點是我們嘗試反解析其子表示式的第一個節點時，才會失敗。根據 Markus Winand 的報告。與之前的補丁一樣，向 v14 回溯。討論：https://postgr.es/m/648B0505-AA57-42C2-A2DA-E551DE46FA15@winand.at https://git.postgresql.org/pg/commitdiff/39ae0ef8561362304ee512963aa51d5a705e5616

  • 使 configure 檢查 IPC::Run 的最低必需版本。根據關於 3eb1f4d09 的討論，讓 configure 驗證可用的 IPC::Run 版本至少為 0.79，這是商定的最低版本。這不太可能再咬到任何人，但作為文件很有用。（基於此，回溯的必要性不大。）為了保持一致性，還為我們有顯式檢查的另一個 Perl 模組 Time::HiRes 提供了一個最低版本。我使用了隨 Perl 5.8.3 提供的版本。討論：https://postgr.es/m/E1mYY6Z-0006OL-QN@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/4a235efddaa78ec78a47614ddc6161644e089290

  • 修復將子查詢表示式提取到函式 RTE 中的 planner 錯誤。如果 FROM 中的函式透過 lateral 引用 FROM 子句中較早的某個子 SELECT 的輸出，並且我們可以將該子 SELECT 展平到外層查詢中，那麼複製到函式 RTE 中的表示式就未能透過 eval_const_expressions 進行處理。如果這些表示式包含命名引數的函式呼叫語法或帶有預設引數的函式，這會導致執行時出現問題和可能的崩潰。查詢包含任何顯式 JOIN 語法時，此 bug 會被掩蓋，這也許可以解釋為什麼我們沒有注意到。根據 Bernd Dorn 的 bug #17227。這是 commit 7266d0997 中的疏漏，因此回溯到 v13（該 commit 引入了此功能）。討論：https://postgr.es/m/17227-5a28ed1512189fa4@postgresql.org https://git.postgresql.org/pg/commitdiff/4d5f651f1d651c6fa79f9188e7b9a04654c7125a

  • 使 pg_dump 在轉儲分割槽表時獲取鎖。一直以來，它的意圖很明顯是這樣做，但最初的編碼錯誤地檢查了錯誤的陣列元素。我們在 403a3d91c 中順帶修復了這個問題，但後來被撤銷了，我們忘記了保留這個 bug 修復。大多數情況下，這可能相對無害，因為一旦我們鎖定任何分割槽表的葉子分割槽，就足以防止對分割槽表本身進行重大 DDL 操作。然而，一個沒有子分割槽的分割槽表將被完全不加任何相關鎖地轉儲，可能導致轉儲失敗或輸出不一致。與 403a3d91c 不同，沒有版本相容性問題，因為所有支援分割槽表的伺服器版本都允許您鎖定它們。回溯到引入分割槽表的 v10。討論：https://postgr.es/m/1018205.1634346327@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e2ff7d9a83d4b489806281dc6dfce88510b40ad7

  • 避免在從 pre-8.3 伺服器轉儲時 pg_dump 核心轉儲。Commit f0e21f2f6 未能在 getTriggers 的查詢中為 pre-8.3 伺服器新增 tgisinternal 輸出列。像該 commit 一樣，回溯到 v11。 https://git.postgresql.org/pg/commitdiff/40dfac4fc4776213a02291f13046d36e318f2629

Michaël Paquier 提交

  • 清理更多使用 "(expr) ? true : false" 的程式碼。這與 fd0625c 類似，處理了任何剩餘的值得清理的程式碼路徑。這也改變了一些使用相反表示式模式的情況。作者：Justin Pryzby, Masahiko Sawada 討論：https://postgr.es/m/CAD21AoCdF8dnUvr-BUWWGvA_XhKSoANacBMZb6jKyCk4TYfQ2Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/68f7c4b57a27dbcd3e93ba3ff7b0b49664b25e09

  • 在 TAP 測試中新增更多的 $Test::Builder::Level。增加報告的呼叫堆疊級別有助於除錯，因為它允許控制測試中確切哪個部分失敗，尤其是當測試結構化為包含呼叫 Test::More 例程的子例程時。這增加了更多的 $Test::Builder::Level 增量，其中除錯得到了改進（例如，對於 pg_rewind 中使用長子例程的某些路徑，這沒有意義）。基於 Andrew Dunstan 的建議和我們兩人的措辭，在 src/test/perl/README 中添加了關於此的說明。Test::Builder::Level 的使用已在 12 中普及，因此向下回溯到此版本。審閱者：Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson 討論：https://postgr.es/m/YV1CCFwgM1RV1LeS@paquier.xyz 回溯至：12 https://git.postgresql.org/pg/commitdiff/f9c4cb686800d46ef9e9e90ed5133493b23962af

  • 修復 pg_upgrade 跨不同主版本測試。這修復了一系列問題，這些問題在使用 pg_upgrade 的 test.sh 進行跨不同主版本升級時會導致各種中斷或煩惱：- 當使用 v14 作為新版本時，由於 Makefile 規則移除了 testtablespace/，test.sh 完全中斷。舊版本的 pg_regress 不支援 --make-tablespacedir，阻止了表空間的建立。為了解決這個問題，在指令碼本身中建立這些目錄很簡單，但僅在涉及舊版本時才這樣做。HEAD 和 REL_14_STABLE 需要此修復。- 當使用 PG <= v11 作為舊版本時，由於 v12 中不支援 WITH OIDS 關係，該指令碼會失敗。為了解決這個問題，它從 buildfarm 中竊取了一個方法，該方法使用 DO 塊來更改所有標記為 WITH OIDS 的關係，從而允許 pg_upgrade 透過。這比使用 ALTER TABLE 查詢有問題的關係更具可移植性。此修復回溯到 v12，最初由 Andrew Dunstan 編寫。- 當使用 v11 作為舊版本時，不使用 --extra-float-digits=0 會導致轉儲中出現大量差異，使整個轉儲難以閱讀。僅在使用 v11 作為舊版本時執行此操作。此修復回溯到 v12。buildfarm 程式碼已在使用此。請注意，新增 --wal-segsize 和 --allow-group-access 會在 initdb 時使用 v10 或更早版本中斷指令碼，因為這些選項在 11 中被新增。10 將於明年EOL，並且尚未有人抱怨這些問題，因此對此不做任何處理。這意味著此 commit 修復了使用 v11 作為最低舊版本、直到 HEAD 的 upgrade 測試，並且將其向下應用到 12 就足夠了。舊轉儲和新轉儲仍然會產生差異，仍然需要手動檢查，並且還可以做更多工作來減少噪音，但這允許測試以最少的干擾執行。我已經測試了此 commit 和 test.sh，使用 v11 作為最低版本，並應用於所有相關分支。請注意，此 commit 對正常使用 "make check" 的 pg_upgrade 測試執行沒有影響。作者：Justin Pryzby, Andrew Dunstan, Michael Paquier 討論：https://postgr.es/m/20201206180248.GI24052@telsasoft.com 回溯至：12 https://git.postgresql.org/pg/commitdiff/fa66b6dee0843d2bca5bf9c9b8b7be32defbffae

  • 修復 CREATE TYPE 中多範圍型別的使用後釋放。程式碼釋放了儲存在解析樹中的多範圍型別函式的名稱，但不應該這樣做。例如，事件觸發器可能會使用 ddl_command_end 事件檢視這種損壞的解析樹。作者：Alex Kozhemyakin, Sergey Shinderuk 審閱者：Peter Eisentraut, Michael Paquier 討論：https://postgr.es/m/d5042d46-b9cd-6efb-219a-71ed0cf45bc8@postgrespro.ru 回溯至：14 https://git.postgresql.org/pg/commitdiff/5b0e7fe1d67235a092be1132bc5c97f1d7f29aaf

Peter Geoghegan 提交

Fujii Masao 提交

  • 使 autovacuum launcher 對 pg_log_backend_memory_contexts() 更加響應。以前，當 pg_log_backend_memory_contexts() 向 autovacuum launcher 傳送請求時，記錄其記憶體上下文可能需要幾秒鐘。因為處理 autovacuum launcher 收到的任何新中斷的函式（HandleAutoVacLauncherInterrupts）沒有處理記錄記憶體上下文的請求。此 commit 更改了該函式，使其能夠處理該請求，從而使 autovacuum launcher 對 pg_log_backend_memory_contexts() 更加響應。回溯到新增 pg_log_backend_memory_contexts() 的 v14。作者：Koyu Tanigawa 審閱者：Bharath Rupireddy, Atsushi Torikoshi 討論：https://postgr.es/m/0aae3e074face409b35153451be5cc11@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/e3e29cec10d15bbcedc6b41887d8f4e138d719bd

Peter Eisentraut 提交

Robert Haas 提交

Etsuro Fujita 推送

Álvaro Herrera 提交

Jeff Davis 推送

Andrew Dunstan 推送