2024 年 11 月 21 日： PostgreSQL 17.2、16.6、15.10、14.15、13.18 和 12.22 已發布！

PostgreSQL 每週新聞 - 2021 年 9 月 26 日

張貼於 2021-09-27 作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 9 月 26 日

PostgreSQL 14 Release Candidate 1 已發布。 測試！

PostgreSQL 產品新聞

JDBC 42.2.24 已發布 https://jdbc.postgresql.org/documentation/changelog.html#version_42.2.24

check_pgbackrest 2.1，一個相容於 Nagios 的 pgBackRest 監控程式已發布。https://github.com/dalibo/check_pgbackrest/releases

sqlite_fdw 2.1.0 已發布。

九月份的 PostgreSQL 工作

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

PostgreSQL 新聞報導

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

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

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

已應用補丁

Tomáš Vondra 推出了

  • 不允許在系統欄位上使用擴展統計資訊。自引入擴展統計資訊以來，我們已不允許引用系統欄位。因此，例如 CREATE STATISTICS s ON ctid FROM t; 將會失敗。但是透過表示式上的擴展統計資訊，可以很容易地繞過此限制 CREATE STATISTICS s ON (ctid::text) FROM t; 這是 a4d75c86bf 中的一個疏忽，透過新增一個簡單的檢查來修正。向後移植到 PostgreSQL 14，該版本引入了對表示式上的擴展統計資訊的支援。向後移植：14 討論：https://postgr.es/m/20210816013255.GS10479%40telsasoft.com https://git.postgresql.org/pg/commitdiff/c9eeef2a15c02ff7dd2bf3251dbee925b050fc0f

  • 在建置每個統計物件後釋放記憶體。到目前為止，給定關係上的所有擴展統計資訊都是在相同的記憶體上下文中建置的，而沒有重置。某些記憶體已明確釋放，但並非全部 - 例如，在反解凍值時分配的記憶體很難釋放。自 PostgreSQL 10 中引入擴展統計資訊以來，一直都是這樣運作的，但是新增對表示式上的擴展統計資訊的支援使問題變得更糟，因為它增加了要建置的統計資訊的數量。透過新增一個記憶體上下文來修正，該上下文在建置每個統計物件（包括其中的所有統計資訊種類）後會重置。在建置每個統計資訊種類後重置它會更好，但是它需要更多侵入性變更和結果複製，使其更難以向後移植。向後移植到 PostgreSQL 10，該版本引入了擴展統計資訊。作者：Justin Pryzby 報告人：Justin Pryzby 審閱人：Tomas Vondra 向後移植：10 討論：https://postgres.tw/message-id/20210915200928.GP831%40telsasoft.com https://git.postgresql.org/pg/commitdiff/83772cc78e0392a247231ba510c61b6612b93b3f

  • 釋放 dependency_degree 分配的記憶體。計算函數依賴的程度可能會分配大量記憶體 - 我們已經釋放了大部分明確分配的記憶體，但是例如，反解凍的 varlena 值被遺留下來。這可能是一個問題，因為我們考慮了很多依賴性（所有組合），並且每次都可能再次進行反解凍。透過在專用上下文中呼叫 dependency_degree() 並在每次呼叫後重置它來修正。我們只需要計算出的依賴程度，因此我們不需要複製任何內容。向後移植到 PostgreSQL 10，該版本引入了擴展統計資訊。向後移植：10 討論：https://postgres.tw/message-id/20210915200928.GP831%40telsasoft.com https://git.postgresql.org/pg/commitdiff/ad8a166ca86846ab691bd6dafc695e0f7dd96012

Tom Lane 推出了

Álvaro Herrera 推出了

Andres Freund 推送了

Peter Geoghegan 推送了

  • 移除過於熱心的索引刪除斷言。即使偏移量數字指向頁面行指標陣列的末尾之後，損壞的 HOT 鏈也不是意外情況。heap_prune_chain() 並未（而且從未）將這種情況視為意外，因此 heap_index_delete_tuples() 中的衍生程式碼也不應如此。commit 4228817449 中的疏忽。斷言可能只會在 Postgres 14 和 master 上失敗。較早的版本沒有 commit 3c3b8a4b，它教導 VACUUM 截斷堆積頁面的行指標陣列。同樣回溯所有版本，以保持一致。作者：Peter Geoghegan pg@bowt.ie 回報者：Alexander Lakhin exclusion@gmail.com 討論：https://postgr.es/m/17197-9438f31f46705182@postgresql.org 回溯：12-，就像 commit 4228817449 一樣。 https://git.postgresql.org/pg/commitdiff/5e6716cde5749aea506dd3f30b099b6e9b4c5af8

  • 修正「單一值策略」索引刪除問題。當由自底向上的索引刪除傳遞觸發時，不適合將單一值策略應用於重複資料刪除。這浪費了週期，因為後續的自底向上刪除傳遞會過度解釋重複資料刪除實際上「按設計」跳過的較舊的重複 tuple。它也使得自底向上刪除對於恰好跨越無意義的「每個葉節點頁面索引具有單一鍵值」閾值的低基數索引的效果大大降低。為了修正，稍微縮小考慮重複資料刪除的單一值策略的條件。我們已經避免了針對唯一索引的策略，因為我們的高層次目標必須只是為 VACUUM 運行爭取時間（而不是節省空間）。現在，當我們剛剛進行了一個報告失敗的自底向上傳遞時，我們也將避免它。這兩種情況共享相同的高層次目標，並且已經顯著重疊，因此這種方法非常自然。commit d168b666 中的疏忽，它新增了自底向上索引刪除。作者：Peter Geoghegan pg@bowt.ie 討論：https://postgr.es/m/CAH2-WznaOvM+Gyj-JQ0X=JxoMDxctDTYjiEuETdAGbF5EUc3MA@mail.gmail.com 回溯：14-，自底向上刪除是在此版本中引入的。 https://git.postgresql.org/pg/commitdiff/dd94c2852e6e3a246b9fd64bf2d9c7fc01020905

  • 說明 heapam 行指標截斷的問題。在 commit 3c3b8a4b 之前，檢查偏移量數字是否超過堆積頁面的行指標陣列的末尾只是 HOT 鏈遍歷程式碼的防禦性健全性檢查。但是，現在嚴格來說是必要的。將引用該問題的註解新增到 heapam 中需要正確處理它的程式碼中。根據 Alexander Lakhin 的建議。討論：https://postgr.es/m/f76a292c-9170-1aef-91a0-59d9443b99a3@gmail.com https://git.postgresql.org/pg/commitdiff/c7aeb775df895db240dcd6f47242f7e08899adfb

  • nbtree README：新增有關 latestRemovedXid 的註解。指出索引 tuple 刪除通常需要刪除操作 WAL 記錄的 latestRemovedXid 值。現在，既然它在原始執行期間提前發生，這肯定是整個刪除操作中最昂貴的部分。這可以說是 commit 558a9165e08 中的一個疏忽，它將生成這些值所需的工作從索引刪除 REDO 常式移到了索引刪除操作的原始執行中。 https://git.postgresql.org/pg/commitdiff/48064a8d330db259076fb7b2300544fbf65f4109

  • vacuumlazy.c：移除過時的 'onecall' 註解。移除對 lazy_vacuum() 的 onecall 引數的過時引用。該函數引數已由 commit 3499df0dee 移除。同時移除引入環繞式容錯保護概念的相鄰註解區塊。在這裡談論容錯保護不再有意義，因為 lazy_vacuum()（和相關函數）不再是觸發容錯保護的唯一位置。自 commit c242baa4a8 教導 VACUUM 在其初始堆積掃描期間考慮觸發容錯保護機制以來，情況一直是如此。 https://git.postgresql.org/pg/commitdiff/c1a47dfe2e9f814e61377f47aa79a113a4c73a63

  • 更新過時的 nbtree 刪除註解。_bt_delitems_delete() 不再是由索引 tuple 驅動的索引 tuple 刪除使用的高階進入點，這些索引 tuple 的 LP_DEAD 位元已設定（現在稱為「簡單索引 tuple 刪除」）。在 commit d168b66682 之後，它變成了一個較低層級的常式，僅由 _bt_delitems_delete_check() 呼叫。 https://git.postgresql.org/pg/commitdiff/ce2a86053380f7e82dc8318ac48a22a7ab266398

Michaël Paquier 推送了

Amit Kapila pushed

Peter Eisentraut pushed

Fujii Masao pushed

Alexander Korotkov pushed

John Naylor pushed