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

PostgreSQL 每週新聞 - 2021 年 4 月 18 日

發表於 2021-04-19，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 4 月 18 日

本週人物：https://postgresql.life/post/devrim_gunduz/

PostgreSQL 產品新聞

pgmetrics 1.11，PostgreSQL 指標的命令行工具，已發布。https://pgmetrics.io/

hypopg 1.2.0，一個實現假設索引的擴展，已發布。https://github.com/HypoPG/hypopg/releases

四月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

請在太平洋標準時間下午 3:00 前（PST8PDT）將新聞和公告提交至 david@fetter.org。

已套用的補丁

Tom Lane 推送了

  • 消除一些 Coverity 警告並改善程式碼一致性。 Coverity 抱怨說，在類似於 intresult = tm->tm_sec * 1000000 + fsec 的表達式中可能發生溢位；理由是在擴展到 int64 結果之前，乘法運算將以 32 位元算術進行。 我認為這些都是誤報，因為 tm_sec 的可能範圍有限； 但儘管如此，當附近的行以 64 位元常數寫入相同的計算時，這樣拼寫似乎很愚蠢。 ...或者更準確地說，使用 LL 常數，這不是專案風格。 像我們在其他地方所做的那樣，讓所有這些都使用 INT64CONST()。 這都是來自 a2da77cdb 的新程式碼，因此無需進行後續修補。https://git.postgresql.org/pg/commitdiff/6277435a8a89c59f716c111200c072d1454b8ff2

  • 修正強制轉換 COLLATE 表達式結果的舊錯誤。 parse_coerce.c 中有一些技巧可以將請求的強制轉換下推到可能出現的任何 CollateExpr 之下。 但是，即使請求的資料類型不可排序，我們也會這樣做，從而導致無效的表達式樹，其中 CollateExpr 應用於不可排序的類型。 此修復程式只是完全刪除 CollateExpr，理由是它沒有用。 這個錯誤已經十年了，可以追溯到最初新增 COLLATE 支援的時候。 缺少現場投訴表明沒有太多使用者可見的後果。 我們注意到這個問題是因為如果無效的結構作為視圖的輸出列出現，它會觸發 DefineVirtualRelation 中的斷言； 但是，在非斷言版本中，您不會看到崩潰，只會看到關於將排序規則應用於不可排序類型的（稍微不正確的）投訴。 我發現透過將不正確的結構進一步放置在視圖中，我可以建立一個視圖定義，該定義將會導致 dump/reload 失敗，如新增的回歸測試案例所示。 但是 CollateExpr 在執行時不會執行任何操作，因此這可能不會導致任何真正令人興奮的後果。 根據 Yulin Pei 的報告。 後續修補到所有支援的分支。 討論：https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com https://git.postgresql.org/pg/commitdiff/c402b02b9fb53aee2a26876de90a8f95f9a9be92

  • 刪除不再相關的測試案例。 collate.icu.utf8.sql 正在測試列舉比較表達式的排序規則相依性的記錄，但是這樣的表達式從一開始就不應該具有任何排序規則相依性。 在我於提交 c402b02b9 中修復該問題後，測試開始失敗。 我們不再需要測試該情境，因此只需刪除現在無用的測試步驟即可。 （此測試案例是 HEAD 中的新增內容，因此無需進行後續修補。） 討論：https://postgr.es/m/3044030.1618261159@sss.pgh.pa.us 討論：https://postgr.es/m/HK0PR01MB22744393C474D503E16C8509F4709@HK0PR01MB2274.apcprd01.prod.exchangelabs.com https://git.postgresql.org/pg/commitdiff/cf0020080a3de20287217621da57bfd840e9a693

  • 避免 heap_update 期間不太可能發生的 PANIC。 heap_update 需要清除舊元組頁面（以及新頁面，如果不同）上的任何現有「全部可見」標誌。 根據編碼規則，為此，它必須在不持有獨佔緩衝區鎖定的情況下，在適當的可見性對應頁面上取得釘選； 這會產生競爭條件，因為當我們沒有持有緩衝區鎖定的情況下，其他人可以隨時設定該標誌。 該程式碼應該透過在取得緩衝區鎖定後重新檢查該標誌並在設定該標誌時重試來處理該問題。 但是，heap_update 本身的一條程式碼路徑，以及其子常式 RelationGetBufferForTuple 中的一條程式碼路徑，未能執行此操作。 最終結果是，在並行 VACUUM 在我們暫時未持有鎖定的情況下設定了該標誌的罕見情況下，會發生非重複發生的「PANIC：傳遞給 visibilitymap_clear 的緩衝區錯誤」錯誤。 自最近的 VACUUM 變更新增了可以在僅持有獨佔緩衝區鎖定的情況下設定全部可見標誌的程式碼路徑以來，在 buildfarm 中已經多次看到這種情況。 以前，該標誌（通常？）僅在執行 LockBufferForCleanup 後才設定，這將堅持緩衝區釘選計數為零，從而防止在 heap_update 中途設定該標誌。 但是，很明顯是 heap_update 而不是 VACUUM 在這裡存在錯誤。 不太清楚的是，這些錯誤在已發布的分支中是否存在任何風險。 heap_update 肯定違反了 API 預期，但是如果沒有程式碼路徑可以在沒有清理鎖定的情況下設定全部可見標誌，那麼這只是一個潛在的錯誤。 但這並非 100% 確定，除此之外，我們還應該擔心可能引入此類程式碼路徑的擴展或未來的後續修補程式。 我選擇後續修補到 v12。 在此之前修復 RelationGetBufferForTuple 還需要後續修補舊修復程式的部分內容（尤其是 0d1fe9f74），與修復假設問題相比，這會產生更多的程式碼變動。 討論：https://postgr.es/m/2247102.1618008027@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/34f581c39e97e2ea237255cf75cccebccc02d477

  • 重新設計 get_cached_rowtype() 完成的快取。 以前，get_cached_rowtype() 快取了來自 typcache 的參考計數元組描述符的指標，依靠 ExprContextCallback 機制在銷毀使用 tupdesc 的表達式樹時釋放 tupdesc refcount。 這在設計時工作正常，但是 DO 區塊內的 COMMIT 的引入打破了它。 refcount 記錄在交易生命週期資源所有者中，但是 plpgsql 不會銷毀在 DO 區塊內（在其第一次提交之前）建立的簡單表達式，直到退出 DO 區塊。 這會在 COMMIT 銷毀原始資源所有者時導致關於洩漏的 tupdesc refcount 的警告，然後在銷毀表達式時導致關於活動資源所有者未持有相符 refcount 的錯誤。 為了修復，透過快取相關 typcache 條目的指標，完全擺脫了對關閉回呼的需求。 這些條目在後端生命週期內存在，因此我們不必擔心指標變得過時。 （對於已註冊的 RECORD 類型，我們仍然可以快取 tupdesc 的指標，因為我們知道它在後端生命週期內不會變更。） 自提交 4b93f5799 以來，此機制已在 plpgsql 和 expandedrecord.c 中使用，並且似乎工作良好。 此變更需要修改相關表達式步驟類型使用的 ExprEvalStep 結構，這對於後續修補來說有點令人擔憂。 但是，似乎沒有充分的理由讓擴展熟悉這些特定子結構的細節。 根據 Rohit Bhogate 的報告。 後續修補到 v11，其中 DO 區塊內的 COMMIT 成為現實。 討論：https://postgr.es/m/CAAV6ZkQRCVBh8qAY+SZiHnz+U+FqAGBBDaDTjF2yiKa2nJSLKg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c2db458c1036efae503ce5e451f8369e64c99541

  • 修正了部分不適當禁止的 ALTER ROLE/DATABASE SET 用法。大多數檢查資料庫狀態的 GUC 檢查鉤子，針對源頭 (source) == PGC_S_TEST 時，會加入特殊檢查以避免因狀態相關問題而拋出嚴重錯誤。例如，允許在尚未建立 "foo" 配置時執行 "ALTER DATABASE d SET default_text_search_config = foo"。若沒有這個機制，在 dump/reload 或 pg_upgrade 期間會發生問題，因為 pg_dump 無法得知 GUC 值的可能依賴性，也無法確保安全的還原順序。然而，check_role() 和 check_session_authorization() 並未注意到這一點，仍然會拋出嚴重錯誤。雖然 "ALTER ROLE x SET role = y" 的使用案例並不完全清楚，但我們已經收到兩起關於它妨礙升級的獨立投訴，顯然有些人正在使用它。因此，修正這兩個函式，使其行為更像其他具有類似需求的檢查鉤子。（但我沒有改變它們堅持必須在交易中執行的要求，因為從配置檔案設定這兩個 GUC 仍然不見得是明智之舉。）同時也修正了 check_temp_buffers，它也存在類似的問題，即在沒有 PGC_S_TEST 例外的情況下進行狀態相關的檢查。對其他 GUC 檢查鉤子的粗略調查並未發現更多類似問題。（PGC_POSTMASTER 和 PGC_SIGHUP GUC 之間存在許多相互依賴性，這可能不是一個好主意，但它們與目前的關注點無關，因為它們無法透過 ALTER ROLE/DATABASE 設定。）根據 Charlie Hornsby 和 Nathan Bossart 的報告。回溯修補到所有支援的分支。討論：https://postgr.es/m/HE1P189MB0523B31598B0C772C908088DB7709@HE1P189MB0523.EURP189.PROD.OUTLOOK.COM 討論：https://postgr.es/m/20160711223641.1426.86096@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/69d5ca484b69771073380e234e5377b6d6a5ebaf

  • 允許在 ON CONFLICT ... WHERE 子句中使用表限定的變數名稱。先前，您只能在這裡使用非限定的變數名稱。雖然這不是功能上的缺陷，因為只能引用目標表，但這與部分索引謂詞的規則存在令人驚訝的不一致，而此語法理應以此為模型。解決此問題並不困難，只需將 addToRelNameSpace = true 傳遞給 addNSItemToQuery。然而，transformOnConflictArbiter 和 transformOnConflictClause 完全不應該干涉目標表的命名空間項目。這並非它們的職責，導致命名空間項目重複建立，而且 transformOnConflictClause 甚至沒有正確地執行（該編碼導致目標表出現兩個 nsitem，因為它沒有清除現有的那個）。因此，讓 transformInsertStmt 負責為這些子句和 RETURNING 設定目標 nsitem 一次。此外，安排在執行 transformOnConflictArbiter 之前，將 ON CONFLICT ... UPDATE 的 "excluded" 偽關係新增到 rangetable。如果有人在 arbiter 運算式中撰寫 "excluded.col"，這將產生更有幫助的 HINT。根據 Lukas Eder 提出的錯誤 #16958。雖然我同意這是一個錯誤，但後果並不嚴重，因此不進行回溯修補。討論：https://postgr.es/m/16958-963f638020de271c@postgresql.org https://git.postgresql.org/pg/commitdiff/6c0373ab77359c94b279c4e67c91aa623841af65

  • 修正引用已過時的 JoinPathExtraData.extra_lateral_rels 的註解。該欄位已在提交 edca44b15 中移除，但提交 45be99f8c 似乎重新引入了一些提及它的註解。由 James Coleman 指出，雖然這不完全是他提議的新措辭。也感謝 Justin Pryzby 的軟體考古學。討論：https://postgr.es/m/CAAaqYe8fxZjq3na+XkNx4C78gDqykH-7dbnzygm9Qa9nuDTePg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e1623b7d86812ee6ab98a42f38b43a192c149988

  • 穩定最近新增的 information_schema 測試查詢。如果核心系統或並行執行的測試腳本建立任何會出現在 information_schema 檢視中的函式，這些查詢可能會顯示意外的條目。將它們限制為僅顯示屬於此測試的 schema 的函式，就像更早期的附近測試案例一樣。根據將一些內建函式轉換為 SQL 函式主體樣式的實驗。 https://git.postgresql.org/pg/commitdiff/3157cbe974846729d49a1ee081944eee1839bdd8

  • 撤銷允許 pg_proc.prosrc 為 NULL 的決定。提交 e717a9a18 變更了長期以來的規則，即 prosrc 不得為 NULL，因為當 SQL 語言函式以 SQL 標準樣式撰寫時，我們目前沒有任何有用的內容可以放入其中。但這似乎是一個糟糕的決定，因為它很容易對外部 PL 產生負面影響（例如，使它們容易發生過去不會發生的崩潰）。SQL 函式相關的程式碼可以像測試 "is prosqlbody not null" 一樣輕鬆地測試 "is prosrc null"，因此也沒有真正的優勢。因此，恢復移除 NOT NULL 標記並調整相關邏輯。目前，我們只是將一個空字串放入 SQL 標準函式的 prosrc 中。也許我們稍後會有更好的主意，儘管像 pg_attrdef.adsrc 之類的歷史表明，維護節點樹的字串等價物並不容易。這也增加了對 standard_ExecutorStart 的斷言 queryDesc->sourceText != NULL。我們已經默默地依賴它一段時間了，所以讓我們讓它不那麼沉默。同時也修正了一些被忽略的文件和測試案例。討論：https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/1111b2668d89bfcb6f502789158b1233ab4217a6

  • 還原 "Cope with NULL query string in ExecInitParallelPlan()."。這會還原提交 b3ee4c503872f3d0a5d6a7cbde48815f555af15b。在前面提交之後，我們不需要它了，該提交增加了一個上游檢查，以確保 querystring 不為 null。討論：https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/83efce7a1ebc5bae79617ddba12a64790141725c

  • 在解析 SQL 標準函式主體時提供查詢來源文字。如果沒有這個，我們將會遺失錯誤游標位置，如修改後的迴歸測試結果所示。討論：https://postgr.es/m/2197698.1617984583@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/409723365b2708acd3bdf2e830257504bdefac4b

  • 修正兩個 ExplainPropertyFloat 呼叫中的錯誤單位。這只是一個潛在的錯誤，因為這些呼叫僅適用於非文字輸出格式，而且目前沒有任何格式會列印單位。儘管如此，我們應該在這種情況發生變化時修正它。Justin Pryzby 討論：https://postgr.es/m/20210415163846.GA3315@telsasoft.com https://git.postgresql.org/pg/commitdiff/f90c708a048667befbf6bbe5f48ae9695cb89de4

  • 修正了錯誤的定序版本記錄邏輯。`recordMultipleDependencies` 函數中 "version" 變數的作用域不正確，導致版本標籤從其所屬的定序條目洩漏到後續的非定序條目。這相對難以觸發，因為輸入通常會以 OID 降序排列：後續的非定序項目通常會被釘選（pinned）。但是，使用自訂定序可以很容易地展示這個問題。此外，不要特殊處理預設定序，而是在找到定序的版本後忽略其釘選狀態。這樣可以避免創建無用的 pg_depend 條目，並消除一個不太具有前瞻性的假設，即 C、POSIX 和 DEFAULT 是唯一被釘選的定序。一個小問題是，由於預設定序可能具有也可能沒有版本，因此迴歸測試無法對是否會為其創建依賴項條目做出任何假設。不過，這似乎沒有問題，因為現在它與其他定序的處理方式相同，而且我們有版本化和未版本化定序的測試案例。修正了 commit 257836a75 中的疏忽。感謝 Julien Rouhaud 的審閱。討論：https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ef387bed87f2787b1012e68e9a33607a1074c123

  • 將函數定義從 system_views.sql 分割到一個新檔案中。創建新的 system_functions.sql 來存放之前位於 system_views.sql 中的函數定義。函數定義已經佔了檔案的四分之一，而且即將變得更多，因此將它們放在自己的檔案中似乎更合適。順便一提，修正了 dfb75e478 中的一個疏忽：它忽略了對 system_constraints.sql 調用 check_input()。討論：https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e80949372564c126c92aa7d64de483e04c0ef95e

  • 將內建的 SQL 語言函數轉換為 SQL 標準主體（SQL-standard-body）風格。對於所有內建的 SQL 語言函數和 information_schema 函數，採用新的預解析表示形式，除了少數因具有多型參數而目前無法轉換的函數。這消除了這些函數在搜尋路徑安全性方面的殘餘風險，並且可能通過降低解析成本帶來一些小的效能優勢。為 SQL 標準主體功能提供更多的測試覆蓋範圍也似乎很有用。討論：https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/767982e36298be4da44a063e36261e9cfdc0bf49

  • 更新虛擬的 prosrc 值。糟糕，在 767982e36 的這部分忘記執行 s/system_views.sql/system_functions.sql/g 了。我認為不需要額外的 catversion 變更，因為這些字串在 initdb 完成時就不存在了。討論：https://postgr.es/m/3956760.1618529139@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8a2df442b652f83b1c189822737091b90f343965

  • 重新思考定序依賴性的提取。就目前而言，find_expr_references_walker() 關注葉節點定序欄位，而忽略實際函數和運算符節點的輸入定序。從語義角度來看，這似乎完全相反，並且導致報告的依賴關係實際上與表達式的行為無關。因此，重寫為查看函數輸入定序。這也不是完全完美的；它無法解釋 record_eq 及其同類項的行為。（先前的程式碼至少給出了一個近似值，但我認為它可以很容易地被欺騙，從而考慮不相關的複合類型列。）我們可能稍後可以對此進行改進，但目前這應該可以滿足不喜歡 ef387bed8 的建置農場成員。順便一提，修正 GetTypeCollations() 中的一些疏忽，並擺脫其重複的去重複。 （我擔心它仍然可能是 O(N^2) 或更糟，但這使其更好一些。）討論：https://postgr.es/m/3564817.1618420687@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/f24b156997059c257c697b825f022d115825091d

Michaël Paquier 推送了

Amit Kapila pushed

Fujii Masao pushed

Peter Eisentraut pushed

Thomas Munro 推送

Noah Misch 推送

Robert Haas 推送

Peter Geoghegan 推送

Tomáš Vondra 推送

Andrew Dunstan 推送

  • 允許 TestLib::slurp_file 跳過內容，並根據需要使用。為了避免取得舊的日誌檔內容，PostgresNode 中的某些函數正在做以下兩件事之一。在 Windows 上，它旋轉日誌檔並重新啟動伺服器，而在其他地方，它截斷日誌檔。這兩者都是不必要的。我們從 buildfarm 借鑒了這種做法：在開始之前記下日誌檔的大小，然後在擷取日誌檔時，跳到該位置，然後累積內容。在 Windows 上，這拼寫不同，但效果相同。這主要集中在 TestLib 的 slurp_file 函數中，該函數有一個新的可選參數，即在開始讀取檔案之前要跳過的偏移量。用戶端中的程式碼變得更加簡潔。反向移植到所有活動分支。Michael Paquier，由我略作修改。Discussion: https://postgr.es/m/YHajnhcMAI3++pJL@paquier.xyz https://git.postgresql.org/pg/commitdiff/3c5b0685b921533f37622345beb0f8dd49200c01

待處理的修補程式

Andy Fan 送出一個修補程式，以記錄 RelOptInfo.partexprs 和 nullable_partexprs 的增強功能，並將 gen_prune_steps_from_exprs 分成更小的區塊。

Luc Vlaming 送出另一個修訂版的修補程式，以新增明確的部分 UNION ALL 路徑並改善並行子查詢列數和成本計算。

Luc Vlaming 送出另一個修訂版的修補程式，透過不發出 LLVMPassManagerBuilderUseInlinerWithThreshold 傳遞並在第一次呼叫時延遲產生 IR 程式碼來改善 JIT 編譯效能。

Amul Sul 送出另一個修訂版的修補程式，以實作 ALTER SYSTEM ... READ {ONLY | WRITE}。

James Coleman 送出一個修補程式，以新增對 NOT IN 的 HashedScalarArrayOp 支援。

Amit Langote 送出一個修補程式，以修正 PartitionDesc includes_detached 中的一個筆誤。

Masahiko Sawada 送出一個修補程式，以修復 REFRESH MATERIALIZED VIEW 的效能退化問題。

Peter Smith 提交了另一個修補程式版本，以新增對內建邏輯複製的預備交易支援，並為串流交易新增預備 API 支援。

Vigneshwaran C 和其他人交換了修補程式，以識別 CREATE/ALTER SUBSCRIPTION 中發布者遺失的發布項目。

Vigneshwaran C 提交了一個修補程式，以修正監控統計資料文件中的不一致之處。

Bruce Momjian 提交了兩個修補程式版本，以修正最近新增到 pg_stat_activity 的查詢 ID 中的一些命名問題。

Mark Dilger 提交了另外兩個修補程式版本，用於 pg_amcheck 應用程式，以新增 TOAST 指標損壞檢查。

Melanie Plageman 提交了一個修補程式，以新增一個系統檢視表 pg_stat_buffers_written，顧名思義，它可以執行其標籤上的功能。

Fujii Masao、Kyotaro HORIGUCHI 和 Justin Pryzby 交換了修補程式，以修正新的 TRUNCATE 在外部資料表功能中的一些不完善之處。

Justin Pryzby 提交了另外兩個修補程式版本，以改善版本 14 的文件。

Amit Langote 提交了一個修補程式，以根據需要初始化 WITH CHECK OPTIONS 和 RETURNING 表達式。

Ekaterina Sokolova 提交了另一個修補程式版本，以新增巢狀迴圈解釋的額外統計資料。

Haiying Tang 提交了另一個修補程式版本，以支援使用 psql 中大寫字元輸入的查詢結果進行 Tab 鍵自動完成。

Dave Page 提交了一個修補程式，以修正 sepgsql 中的記錄問題。

Andrei Zubkov 提交了另一個修補程式版本，以追蹤 pg_stat_statements 中的語句輸入時間戳記。

David Christensen 提交了一個修補程式，以擴展 pg_size_pretty(numeric) 知道的單位，包括高達 yottabytes 的單位。

Bharath Rupireddy 提交了另外兩個修補程式版本，以避免在 slot_store_error_callback 和 conversion_error_callback 中存取系統目錄。

Masahiko Sawada 和 Peter Geoghegan 交換了修補程式，以確保 VACUUM 會計處理的程式碼註解說明 LP_DEAD 會計處理。

Ajin Cherian 提交了另外兩個修補程式版本，以跳過邏輯複製的空交易。

Julien Rouhaud 提交了一個修補程式，以處理一些關於使用查詢 ID 記錄的特殊情況。這裡的問題是，一些查詢在語法上有效時可以被記錄，但缺少對目錄中它們引用的物件是否存在的檢查。該修補程式新增了一個 %Q 選項到 log_line_prefix，該選項會檢查是否實際找到了物件。

Zeng Wenjing 和 Shawn Wang 交換了修補程式，以實作全域臨時表。

Tom Lane 提交了一個修補程式，以使用固定範圍檢查來替換 pg_depend PIN 項目。

Amul Sul 提交了一個修補程式，以從 transformCreateStmt 中移除一個冗餘變數。

Pavel Stěhule 提交了另外兩個修補程式版本，以實作綱要變數。

Matthias van de Meent 提交了兩個修補程式版本，以記錄預設分割區的 ATTACH PARTITION 的鎖定行為。

Matthias van de Meent 提交了一個修補程式，以實作 _bt_binsrch* 的頁面級動態字首截斷，然後使用相同的方法來實作和使用索引元組屬性迭代。

James Coleman、Tomáš Vondra 和 Tom Lane 交換了旨在修正一個錯誤的修補程式，該錯誤表現為 TPC-DS 查詢 94-96 的 "could not find pathkey item to sort"。

Masahiro Ikeda 提交了另一個修補程式版本，以提高報告 WAL 統計資料的效能。

Tomáš Vondra 提交了一個修補程式，以在 generate_orderedappend_path 中產生部分最便宜的路徑。

Takamichi Osumi 和 Li Japin 交換了修補程式，以修正 TRUNCATE 和同步邏輯複製之間的不完善之處。

Michaël Paquier 提交了另一個修補程式版本，以修正邏輯複製工作程序中的 relcache 洩漏。

Mark Dilger 提交了兩個修補程式版本，以新增一個 --install-missing 選項到 pg_amcheck。

Sven Klemm 提交了一個修補程式，以修正 pg_event_trigger_ddl_commands，在同一個交易中刪除物件的情況下，它可能會查看無效的快取。

Andy Fan 提交了一個修補程式，以確保 set_append_rel_size 考慮到初始分割區修剪。

Tom Lane 提交了一個修補程式，以節省重複子查詢拉取中的一些週期。