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

PostgreSQL 每週新聞 - 2021 年 11 月 21 日

釋出於 2021-11-23，作者 PWN
PWN

PostgreSQL 每週新聞 - 2021 年 11 月 21 日

2022 Nordic PGDay 將於2022年3月22日在芬蘭赫爾辛基的希爾頓赫爾辛基斯特蘭德酒店舉行。論文徵集（CfP）將於2021年12月31日截止，請 在此 提交。

PostgreSQL 產品新聞

PGroonga 2.3.4，一個支援所有語言的全文字搜尋平臺，已釋出。

Pgpool-II 4.2.6、4.1.9、4.0.16、3.7.21 和 3.6.28，一個用於 PostgreSQL 的連線池和語句複製系統，已 發 布 了。

Ora2Pg 23.0，一個用於將 Oracle 資料庫遷移到 PostgreSQL 的工具，已釋出。https://github.com/darold/ora2pg/blob/master/changelog

BigAnimal，Azure 上的託管 PostgreSQL 資料庫，已釋出。

pgAdmin4 6.2，一個用於 PostgreSQL 的 Web 和本地 GUI 控制中心，已釋出。

11月 PostgreSQL 工作機會

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

PostgreSQL 相關新聞

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

本週 PostgreSQL 週報由 David Fetter 提供。

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

已應用補丁

Robert Haas 提交

Amit Kapila 提交

Álvaro Herrera 提交

Michaël Paquier 提交

Peter Eisentraut 提交

Daniel Gustafsson 提交

Tom Lane 提交

  • 修復 INSERT/SELECT 中 SQL 標準函式的引數顯示。如果 SQL 標準函式體包含 INSERT ... SELECT 語句，則 SELECT 中引用的任何函式引數始終以 $N 樣式列印，而不是使用引數名稱（如果存在）。雖然不是嚴格錯誤，但這並非預期，並且與在任何其他型別的語句中列印此類引數的方式不一致。原因是 get_query_def 從 get_insert_query_def 遞迴呼叫時，未能向下傳遞 context->namespaces 列表，而是傳遞了常量 NIL。這是一個非常古老的疏忽，但據我所知，在提交 e717a9a18 新增具有函式引數的最外層名稱空間之前，它沒有可見的影響。我們不允許 INSERT ... SELECT 作為子查詢，除非在頂層 WITH 子句中，在這種情況下，它不能包含任何可能需要訪問上層名稱空間的外部引用。因此，雖然這可能是一個錯誤，但在此之前更改它似乎沒有意義。順便，加固 e717a9a18 新增的程式碼，使其不會在 PARAM_EXTERN Param 出現在意外位置時崩潰。來自 Erki Eessaar 的報告。程式碼修復：我，迴歸測試用例：Masahiko Sawada。討論：https://postgr.es/m/AM9PR01MB8268347BED344848555167FAFE949@AM9PR01MB8268.eurprd01.prod.exchangelabs.com https://git.postgresql.org/pg/commitdiff/a8d8445a7b2f80f6d0bfe97b19f90bd2cbef8759

  • 在 pg_dump 和 pg_basebackup 中更健壯地處理 close() 失敗。Coverity 抱怨說，在 pg_basebackup 的一個地方，在失敗的 gzclose 後應用 get_gz_error 是不安全的。我認為它是正確的：該呼叫非常可能在觸控已釋放的記憶體。將其更改為檢查 errno，就像我們對其他 gzclose 呼叫所做的那樣。此外，請務必在任何我們關心的錯誤狀態的 gzclose() 呼叫之前立即將 errno 初始化為零。（有些呼叫我們不關心，因為我們在之前的步驟中已經失敗了。）這可以確保在 gzclose() 失敗但未設定 errno 時，我們不會得到誤導性的無關錯誤程式碼。我們可以更努力地做到這一點，但對我來說，如果我們不濫用 zlib，所有這些情況基本上都是不可能發生的，所以不值得額外的註釋。此外，修復了幾個根本沒有檢查關閉時錯誤的地點，大多數都在關閉或 gzclose 本身之外；還有一個地方檢查了但沒有報告 errno。向後移植到 v12。這些錯誤比這更老，但由於 v12 中發生的客戶端日誌 API 更改以及客戶端程式碼在此之前不能依賴 %m 的事實，補丁需要大量修改才能在舊分支上工作。考慮到缺乏相關的現場投訴，這樣做似乎不值得。補丁作者：我；感謝 Michael Paquier 的審閱。討論：https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3cac2c8caaefc642332e6994ce80032cc7d4cfdf

  • 清理 pg_basebackup 的 walmethods.c 中的錯誤處理。這裡的錯誤處理很混亂，原因是一個根本性的糟糕設計（依賴 errno 保持其值比假設的安全時間長得多），以及很多純粹的疏忽，包括根本注意不到錯誤以及報告不正確的 errno。此外，最近新增的 LZ4 壓縮完全破壞了事情，因為 liblz4 不使用 errno 來報告錯誤。為了改善這一點，將錯誤狀態儲存在 DirectoryMethodData 或 TarMethodData 結構中，並新增一個字串欄位，以便我們能夠處理不設定 errno 的情況。（tar 方法已經有了這個的版本，但可以更有效地完成，因為所有這些情況都使用恆定的錯誤字串。）使 dir 和 tar 方法以基本相同的方式處理錯誤，而以前不是。這需要在許多地方將 errno 複製到狀態結構中，這有點乏味，但優點是我們可以在許多地方擺脫儲存和恢復 errno 的臨時程式碼……更不用說它修復了其他本應儲存/恢復 errno 但忽略了的地方。順便，修復了一些無用地 static 的緩衝區為普通的區域性變數。fsync() 的錯誤處理仍然存在一個問題，但這似乎是另一個補丁的材料。雖然 LZ4 問題是新的，但其餘的都是針對舊錯誤的修復，所以向後移植到引入 walmethods.c 的 v10。補丁作者：我；感謝 Michael Paquier 的審閱。討論：https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/248c3a937dd018a72095f407cff727c9f08db0c1

  • 為 starts_with() 新增一個規劃器支援函式。這填補了規劃器對 starts_with() 和等效的 ^@ 運算子的一些支援空白：* 諸如 "textcol ^@ constant" 這樣的條件現在可以使用常規的 btree 索引，而不僅僅是 SP-GiST 索引，只要索引的排序規則是 C。（這就像 "textcol LIKE 'foo%'" 一樣。）* "starts_with(textcol, constant)" 可以像 "textcol ^@ constant" 一樣進行最佳化。* 固定字首 LIKE 和正則表示式模式在其他方面也更像 starts_with()：如果你將其應用於 SPGiST 索引的列，你將獲得一個使用 ^@ 的索引條件，而不是兩個帶有 >= 和 < 的索引條件。按 Shay Rojansky 的投訴。補丁作者：我；感謝 Nathan Bossart 的審閱。討論：https://postgr.es/m/232599.1633800229@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/a148f8bc04b9980f019ea0d4b89311cf0bdc22b7

  • 提供一個 simple_prompt() 的變體，可以被 ^C 中斷。到目前為止，你無法透過鍵入 control-C（或 SIGINT 的其他本地拼寫）來逃脫 psql 的 \password 命令。這很不使用者友好，所以改進它。要做到這一點，我們必須修改 pg_get_line.c 提供的函式；但我們不想幹擾 psql 的 SIGINT 處理程式設定，所以提供一個 API，讓該處理程式可以觸發取消。這依賴於我們不會透過 longjmp() 退出 fgets() 來造成重大損害的假設。雖然這顯然有點不可靠，但我們在主輸入迴圈中早已有了同樣的假設，並且報告的錯誤很少。psql 還有一些其他 simple_prompt() 呼叫也可能需要改進，但目前只處理 \password。作者：Nathan Bossart，我進行了一些小的調整。討論：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5f1148224bd78bcf3bf7d916b8fe85dd820c52c6

  • 編譯 bitcode 時使用適當的 -Wno-warning 開關。我們使用 "clang" 來編譯 LLVM 位碼檔案以進行內聯。這可能與構建的主 C 編譯器不同，因此它需要自己的一組編譯器標誌。為了簡化配置，我們不費心將任何 -W 開關新增到該標誌集中；因為主構建會向我們顯示任何警告，所以幾乎不需要。但是，如果我們不想看到不必要的警告，我們仍然必須新增我們通常與 clang 一起使用的任何 -Wno-warning 開關。在提交 9ff47ea41 之前，這被忽略了，該提交試圖新增 -Wno-compound-token-split-by-macro；使用不匹配的 CC 和 CLANG 的構建農場動物仍然顯示這些警告。我不確定為什麼我們從未注意到缺少 -Wno-unused-command-line-argument 的影響（也許它只在 -Wall? 啟用）。clang 目前不支援 -Wno-format-truncation 或 -Wno-stringop-truncation，儘管為了未來的相容性和一致性，我包含了這些測試。向後移植到 v11，在那裡我們開始構建位碼檔案。討論：https://postgr.es/m/2921539.1637254619@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/276517a96484f9e39a7a1095ab39fa76ef1ee8cc

  • 允許 psql 的其他 uses of simple_prompt() 被 ^C 中斷。這完成了 5f1148224 未完成的工作。\prompt 現在可以被取消，並且 \connect 在啟動時發出的密碼提示也可以被取消。（我們不需要為啟動時發出的密碼提示做任何事情，因為那時我們還沒有捕獲 SIGINT。）作者：Nathan Bossart 討論：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/46d665bc26ce57b5afecbc218c8fc3c6848211d8

  • 修復 SP-GiST 掃描初始化邏輯以適應二進位制相容情況。Commit ac9099fc1 重新排列了 spgGetCache() 中的邏輯，該邏輯確定索引的 attType（名義輸入資料型別）和 leafType（儲存在葉索引元組中的實際型別）。事實證明，這破壞了以下情況：(a) 實際輸入資料型別與名義型別不同，(b) opclass 的配置函式將 leafType 留空，並且 (c) opclass 沒有 "compress" 函式。（b）導致我們將實際輸入資料型別分配為 leafType，然後因為這不等於 attType，所以我們抱怨需要 "compress" 函式。對於非多型 opclasses，情況 (a) 出現在二進位制相容的情況下，例如對 varchar 列使用 SP-GiST text_ops，或對域使用任何 opclass（基於其名義輸入型別）。為了修復，當索引宣告的列型別與 attType 不同但二進位制相容時，使用 attType 作為 leafType。僅在 leafType 留空的情況下這樣做，以避免覆蓋 opclass 做的任何顯式選擇。按 Ilya Anfimov 的 bug #17294。向後移植到 v14。討論：https://postgr.es/m/17294-8f6c7962ce877edc@postgresql.org https://git.postgresql.org/pg/commitdiff/f4e7ae2b8a67ad6801726553a024a3306716ef80

  • 文件：更新與最小 Test::More 版本相關的某些內容。Commit 405f32fc4 中的疏忽。此外，新增一個（艱難發現的）技巧，關於如何在最新的 Linux 平臺上讓 Test::More 0.98 透過其迴歸測試。https://git.postgresql.org/pg/commitdiff/92e70796e91e2f9086fad0156e0e91513e54a66b

  • pg_receivewal, pg_recvlogical：允許取消初始密碼提示。以前，不可能透過 control-C 在這些程式提示輸入密碼時終止它們。我們可以透過將 SIGINT 處理程式的設定從初始 GetConnection() 呼叫之前移到之後來輕鬆修復它們的初始密碼提示。此修復程式不允許逃脫後續的重新提示，但這些提示應該極其罕見，因為在此期間使用者的密碼或伺服器的身份驗證設定可能會發生變化。我們曾考慮應用一個類似於 commit 46d665bc2 的修復程式，但這似乎比其價值更復雜。此外，這種方式可以向後移植，而那種不行。此行為存在於所有支援的版本中，因此向後移植到所有版本。作者：Tom Lane 和 Nathan Bossart 討論：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/282b6d00abf5cebece6f94c796a4ed807a0176db

Andres Freund 提交

Andrew Dunstan 推送