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

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

發布於 2021-07-12，由 PWN
PWN

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

本週人物

PostgreSQL 產品新聞

pg-wrapper 1.0.0，PHP 的 pgsql 擴充功能的包裝器，已發布。

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

Ora2Pg 22.1，一個用於將 Oracle 數據庫遷移到 PostgreSQL 的工具，已發布。 https://github.com/darold/ora2pg/blob/master/changelog

credcheck 0.1.1，一種用於純文本密碼的密碼檢查機制，已發布

pg_builder 1.0.0，一個用於 PostgreSQL 的 PHP 查詢構建器，已發布。

PG-Strom 3.0，一個使用 GPU 和相關硬件來加速 OLAP 查詢的 PostgreSQL 擴充功能，已發布。

Datasentinel Version 2021.05，一個監控和報告（除其他外）PostgreSQL 的應用程式，已發布

7 月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

本週的 PostgreSQL 每週新聞由 David Fetter 帶給您

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

已應用的補丁

Amit Kapila 推送

Peter Eisentraut 推送

Dean Rasheed 推送

Tom Lane 推送

  • 重新思考 detach-partition-concurrently-[34] 中封鎖註解的處理方式。在 741d7f104 中，我嘗試讓取消步驟的報告在 pg_cancel_backend() 步驟之後出現，因為這以前是最常見的順序。然而，這並不能確保取消的步驟不會更晚才報告，正如 buildfarm 成員 idiacanthus 最近出現的錯誤所示。与其使用更多的註解使事情變得更加複雜，不如直接強制先報告取消的結果。這並不是不自然的。回溯修補到 v14，這些測試案例首次出現的地方。報告： https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2021-07-02%2001%3A40%3A04 https://git.postgresql.org/pg/commitdiff/c04c767059b8460b99f6aa4aae5450ab3ee257a3

  • 減少 LookupOpclassInfo() 中 cache-clobber 測試的開銷。 Commit 03ffc4d6d 新增了邏輯，在啟用 CLOBBER_CACHE_ALWAYS 時繞過 LookupOpclassInfo 中的所有快取行為。我似乎沒有停下來思考這會付出什麼代價，但最近的調查顯示代價是巨大的：它大約使 cache-clobber 測試運行的時間加倍。當嘗試測試 opclass-cache 加載邏輯本身時，這種行為似乎確實有價值，但對於其他目的而言，成本過高。因此，讓我們退回到僅在 debug_invalidate_system_caches_always 至少為 3 時才執行此操作；或者在較舊的分支中，當定義了 CLOBBER_CACHE_RECURSIVELY 時。在此同時，清理 LookupOpclassInfo 中的一些其他小問題。重新排序程式碼，以便在極不可能發生 OOM (記憶體不足) 的情況下，當我們嘗試為新條目分配空間時，不會留下損壞的快取條目（導致後來的核心傾印）。（這似乎是我在 03ffc4d6d 中的疏忽。）此外，在 >= v13 中，停止分配多餘的一個陣列條目。這顯然是 851b14b0c 中草率回退遺留下來的。回溯修補到所有支援的分支，主要是為了減少 cache-clobbering buildfarm 動物的運行時間。討論： https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9753324b7d9eba0aaf7e12942f52c240bfc7da7c

  • 文件：新增關於帶有小數分鐘 UTC 偏移的時間戳記的信息。我們的程式碼長期以來都支援小數分鐘 UTC 偏移，但主要文件中沒有提及這種可能性，只有附錄 B 中非常間接的引用。改善這一點。討論： https://postgr.es/m/162543102827.697.5755498651217979813@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/ab2e19987ff66f83dfb99b5c541d9e05e8b0ede3

  • 避免在 postgres_fdw 的 conversion_error_callback 中進行目錄查詢。與 50371df26 一樣，這是一個壞主意，因為回呼實際上無法知道正在拋出的錯誤是什麼，因此無法判斷嘗試目錄存取是否安全。与其將這些存取推入主線程式碼中，在那裡它們通常會浪費週期，不如查看查詢的 rangetable。此更改確實意味著我們將列印查詢別名（如果使用了任何別名），而不是表格或欄位的真實名稱。但這似乎不是一件壞事：例如，這在自我連接案例中肯定是一個更有用的定義。無論如何，似乎不太可能有任何應用程式依賴此細節，因此更改它是安全的。由我修補。最初由 Andres Freund 投訴； Bharath Rupireddy 指出了與 conversion_error_callback 的連接。討論： https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/c7b7311f6177b90fe5033b8ed2c10dfcbb863eb6

  • 降低規劃深度巢狀檢視表的成本。 Joel Jacobson 報告說，對簡單（可扁平化）檢視表的深度巢狀會導致 N 深度巢狀的規劃時間呈 O(N^3) 增長。事實證明，這個成本的很大一部分來自於複製每個檢視表的 RTE_SUBQUERY RTE 的「子查詢」子樹。但是，一旦我們成功地扁平化了子查詢，我們就不再需要它了，因為規劃器不會對該 RTE 執行任何其他有趣的操作。我們已經在 setrefs.c 期間刪除了子查詢指標（參見 add_rte_to_flat_rtable），但在此之前它也是無用的累贅。在 pull_up_simple_subquery 完成 RTE 後立即清除指標會將成本從 O(N^3) 降低到 O(N^2)；這仍然不是很好，但它已經好多了。進一步的改進將需要重新思考 RTE 資料結構，這將在另一個執行緒中考慮。由我修補；感謝 Dean Rasheed 的審閱。討論： https://postgr.es/m/797aff54-b49b-4914-9ff9-aa42564a4d7d@www.fastmail.com https://git.postgresql.org/pg/commitdiff/64919aaab45076445051245c9bcd48dd84abebe7

  • 允許 CustomScan 提供者說明它們是否支援投影。以前，所有 CustomScan 提供者都必須支援投影，但在某些情況下這可能不方便。新增一個標誌位來說明是否支援。發行說明的重要項目：這是非向後相容的，因為預設現在是假設 CustomScan 提供者無法投影，而不是假設它們可以投影。它是 fail-soft 的，但可能會因添加不必要的 Result 節點而導致明顯的效能損失。 Sven Klemm，由 Aleksander Alekseev 審閱；由我進行了一些外觀修飾。討論： https://postgr.es/m/CAMCrgp1kyakOz6c8aKhNDJXjhQ1dEjEnp+6KNT3KxPrjNtsrDg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/955b3e0f9269639fb916cee3dea37aee50b82df0

  • 修復 postgres_fdw 中對於可證明為空的遠端 UPDATE/DELETE 的崩潰。在 86dc90056 中，我編寫 find_modifytable_subplan 時假設，如果 ModifyTable 的直接子節點是一個 Result，它必須是一個帶有子計劃的投影 Result。但是，如果 UPDATE 或 DELETE 具有可證明為恆假的 WHERE 子句，情況就不是這樣：我們將生成一個沒有子節點的 Result 的虛擬子計劃。新增缺少的 null-check，以便我們不會在這種情況下崩潰。根據 Alexander Pyhalov 的報告。討論： https://postgr.es/m/b9a6f53549456b2f3e2fd150dcd79d72@postgrespro.ru https://git.postgresql.org/pg/commitdiff/b9734c13f168ef0d487aa122e486ca9b6dd6aa59

  • 拒絕 WITH 中的查詢重寫為僅 NOTIFY 的情況。由於執行器無法處理作為計劃樹節點出現的公用程式語句，因此我們無法支援重寫規則將 NOTIFY 插入到較大查詢的 WITH 子句中出現的 INSERT/UPDATE/DELETE 命令中的情況。（可以想像解決這個問題的方法，但這將是一個新功能而不是錯誤修復，到目前為止還沒有人提出要求。）RewriteQuery 檢查了這一點，但它遺漏了 DML 命令重寫為僅 NOTIFY 的情況。這將導致稍後在規劃中崩潰。新增遺漏的檢查，並提高對此區域的測試水準。根據 Yaoguang Chen 的錯誤 #17094。自引入 WITH 以來一直存在問題，因此回溯修補到所有支援的分支。討論： https://postgr.es/m/17094-bf15dff55eaf2e28@postgresql.org https://git.postgresql.org/pg/commitdiff/a9da1934e971b38ab360ce80a352fbfc4d2d986b

  • 更新 configure 對 libldap 的探測以與 OpenLDAP 2.5 配合使用。單獨的 libldap_r 已經消失，libldap 本身現在始終是執行緒安全的。不幸的是，似乎沒有簡單的方法可以通過檢查來判斷 libldap 是否是執行緒安全的，因此我們必須相信如果沒有 libldap_r，libldap 是執行緒安全的。這應該是可以的，因為看起來 libldap_r 至少在過去 20 年一直是安裝的標準部分。由 Adrian Ho 報告和修補。回溯修補到所有支援的分支，因為人們可能會嘗試使用較新的 OpenLDAP 來構建它們中的任何一個。討論： https://postgr.es/m/17083-a19190d9591946a7@postgresql.org https://git.postgresql.org/pg/commitdiff/d0a02bdb8c2576b5aa607f127320e444080bd579

  • 避免建立標記為 LATERAL 的 RESULT RTE。Commit 7266d0997 加入了程式碼，可提取簡單常數函數的結果，將 RTE_FUNCTION RTE 轉換為虛擬的 RTE_RESULT RTE，因為不再需要掃描它。但我忘記清除 RTE 上設定的 LATERAL 旗標。如果該函數簡化為常數，它肯定不包含任何橫向參考，因此這種簡化在邏輯上是可行的。之所以需要這樣做，是因為其他許多地方都會斷言 RESULT RTE 並非 LATERAL。根據 Yaoguang Chen 提出的錯誤 #17097。回溯修補到引入錯誤程式碼的 v13 版本。討論：https://postgr.es/m/17097-3372ef9f798fc94f@postgresql.org https://git.postgresql.org/pg/commitdiff/d23ac62afa646b7073a7f0db0a137308459a263b

  • 修正 AIX 建置失敗的問題。在 commit d0a02bdb8 中，我假設統一探測 ldap_bind 會使意圖更清楚。然而，由於某些不明原因（也許它在 AIX 上是一個巨集？），這似乎在 AIX 上不起作用。恢復到先前的行為，即針對執行緒安全案例探測 ldap_simple_bind，否則探測 ldap_bind。根據 buildfarm 成員 hoverfly。討論：https://postgr.es/m/17083-a19190d9591946a7@postgresql.org https://git.postgresql.org/pg/commitdiff/31e8cfac5845fa57e1805f4ff81e00ab78dff025

  • 再次修正 AIX 建置失敗的問題。我錯誤地診斷了 hoverfly 不開心的原因。仔細觀察，除非 libssl 也存在，否則它似乎無法連結 libldap；所以問題是我在檢查之前清除 LIBS 的想法。恢復到基本上原始的程式碼，除了當 libldap_r 不存在時，改為使用 libldap 而不是失敗。根據 buildfarm 成員 hoverfly。討論：https://postgr.es/m/17083-a19190d9591946a7@postgresql.org https://git.postgresql.org/pg/commitdiff/53c38a086a8001d63401671755638bc95c7fa1c7

  • 修正 ldap_initialize 的錯誤測試。唉...我期望 AC_CHECK_LIB 做一些它沒有做的事情，也就是更新 LIBS。這導致找不到 ldap_initialize。透過移動 ldap_initialize 的探測來修正。在某種意義上，這無論如何都更正確，因為（至少目前）我們關心的是 ldap_initialize 是否存在於 libldap 而不是 libldap_r 中。根據 buildfarm 成員 elver 和本地測試。討論：https://postgr.es/m/17083-a19190d9591946a7@postgresql.org https://git.postgresql.org/pg/commitdiff/9f6be2e79f88c65cef7cfeb0580e8b2ba74974f6

  • 在 ALTER EXTENSION ADD/DROP 期間鎖定擴充功能。雖然我們小心地鎖定了要新增或刪除的物件，但我們未能獲得擴充功能本身的任何類型的鎖定。這允許 ALTER 與 DROP EXTENSION 並行進行，這會導致幾個問題。如果兩個命令都成功，我們將在 pg_depend 中留下一個懸空的連結，這將在以後引起問題。此外，如果 ALTER 因為某些原因而失敗，它可能會嘗試列印擴充功能的名稱，這可能會導致崩潰，或者（在較舊的分支中）導致一個愚蠢的錯誤訊息，抱怨擴充功能「(null)」。根據 Alexander Lakhin 提出的錯誤 #17098。回溯修補到所有支援的分支。討論：https://postgr.es/m/17098-b960f3616c861f83@postgresql.org https://git.postgresql.org/pg/commitdiff/626731db26ae2617e41536678440c3817128a006

Michaël Paquier 推送了

David Rowley 推送了

  • 減少建立分割區邊界時的 palloc 數量。在 LIST、RANGE 和 HASH 分割的每個 create_*_bound() 函式中，都有大量的 palloc 呼叫，可以減少到更少的數量。在每個函式中，都會建立一個陣列，以便我們可以在建立 PartitionBoundInfo 之前對其進行 qsort 排序。對於 LIST 和 HASH 分割，會配置一個指標陣列，然後在該陣列中配置每個元素。由於每個維度的項目數量事先已知，因此我們只需為此分配單個記憶體區塊即可。同樣地，對於所有分割策略，我們都能減少建立 ->datums 欄位的分配數量。這是一個 Datum 指標的陣列，但每個元素指向的 Datums 沒有必要個別分配。一個大的記憶體區塊就足夠了。對於 RANGE 分割，PartitionBoundInfo->kind 欄位也可以獲得相同的處理。我們可以將相同的最佳化應用於 partition_bounds_copy()。這樣做可能會對在分割區修剪或對分割表執行 DML 期間搜尋正確分割區時的快取效能產生很小的影響。但是，這種影響可能很小，而且主要目的是減少 palloc 的開銷。作者：Nitin Jadhav、Justin Pryzby、David Rowley。審閱者：Justin Pryzby、Zhihong Yu。討論：https://postgr.es/m/flat/CAMm1aWYFTqEio3bURzZh47jveiHRwgQTiSDvBORczNEz2duZ1Q@mail.gmail.com https://git.postgresql.postgresql.org/pg/commitdiff/53d86957e980efa06f15232b8cff430d4cc6dd64

  • 修正註解中的錯字。作者：James Coleman。討論：https://postgr.es/m/CAAaqYe8f8ENA0i1PdBtUNWDd2sxHSMgscNYbjhaXMuAdfBrZcg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9ee91cc583802c6507fbc31c348a79e63a10f956

  • 使用雜湊表加速 NOT IN(values)。與 50e17ad28 類似，它允許使用雜湊表處理帶有一組常數的 IN 子句，這裡我們為 NOT IN 子句新增了相同的功能。NOT IN 的求值結果與以下相同：WHERE a <> v1 AND a <> v2 AND a <> v3。顯然，如果我們使用雜湊表，我們必須與其完全等效，並且返回相同的結果，同時考慮到條件的任何一側都可能包含 NULL。這需要一些特殊的處理才能與雜湊表版本一起使用。處理 NOT IN 時，ScalarArrayOpExpr 的運算子將是 <> 運算子。為了能夠建立和查詢雜湊表，我們必須使用 <> 的求反運算子。規劃器檢查它是否存在且是否可雜湊，並在 ScalarArrayOpExpr 中設定相關欄位，以指示執行器使用雜湊。作者：David Rowley、James Coleman。審閱者：James Coleman、Zhihong Yu。討論：https://postgr.es/m/CAApHDvoF1mum_FRk6D621edcB6KSHBi2+GAgWmioj5AhOu2vwQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/29f45e299e7ffa1df0db44b8452228625479487f

  • 修正 pg_size_pretty(bigint) 中的錯誤傳回值。由於 pg_size_pretty(bigint) 的實作方式，當給定一個負數的位元組數時，傳回值可能與給定等效的正數的位元組數時的正數傳回值不符。這是由於兩個獨立的問題。1. 該函式使用位元移位將位元組數轉換為更大的單位。位元移位執行的捨入與除法不同。例如，-3 >> 1 = -2，但 -3 / 2 = -1。這兩個運算只有在正數時才等效。2. half_rounded() 巨集朝正無限大捨入。這意味著負數朝零捨入，而正數則遠離零捨入。這裡我們通過除法而不是位元移位來修正 #1。我們通過調整 half_rounded 巨集始終遠離零捨入來修正 #2。此外，調整 pg_size_pretty(numeric) 函式，使其更明確地使用除法而不是位元移位。一個隨意的觀察者可能認為使用了位元移位，因為一個靜態函式名為 numeric_shift_right。然而，該函式正在根據位元數計算除數並執行除法。在這裡，我們使它更加清楚。這個更改只是表面上的，不會影響函式的數值版本的傳回值。在這裡，我們還為 pg_size_pretty() 的兩個版本添加了一組迴歸測試，這些測試直接測試了函式在切換到下一個單位之前和之後的值。此錯誤是在 8a1fab36a 中引入的。在此之前，負數值始終以位元組為單位顯示。作者：Dean Rasheed、David Rowley。討論：https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com 向後移植：9.6，錯誤在此版本中引入。https://git.postgresql.org/pg/commitdiff/55fe609387685de1c754332e260b2d0e17d257dc

  • 在 pg_size_pretty 和 pg_size_bytes 中使用查找表來表示單位。多年來，我們已經發展了 2 個版本的 pg_size_pretty，一個用於 BIGINT，另一個用於 NUMERIC。兩者都應該輸出相同的內容，但由於兩個函式都沒有共享關於使用哪些單位以及如何轉換到下一個最大單位的真實來源，因此保持它們同步比需要的更難。在這裡，我們新增一個靜態陣列，用於定義我們識別的單位，並且讓 pg_size_pretty 和 pg_size_pretty_numeric 都使用它。這將使未來新增任何單位成為一項非常簡單的任務。該表包含所需的所有資訊，以便我們也可以修改 pg_size_bytes 以使用查找表，因此也對其進行調整。這裡沒有行為上的變更。作者：David Rowley。審閱者：Dean Rasheed、Tom Lane、David Christensen。討論：https://postgr.es/m/CAApHDvru1F7qsEVL-iOHeezJ+5WVxXnyD_Jo9nht+Eh85ekK-Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/56ff8b29919f75a078969766393b9e20871a75c8

  • 教導 pg_size_pretty 和 pg_size_bytes 關於 PB (petabytes)。有人談論添加一直到 yottabytes 的單位，但似乎不太可能有人需要這些單位。由於如此大的單位並不常見，因此 pg_size_pretty 輸出大於 petabytes 的單位實際上對任何人都有幫助的可能性似乎不大。由於 petabytes 即將來臨，讓我們只添加這些單位。也許有一天我們會添加額外的單位，但可能需要一段時間才能考慮到資料庫的大小超過 petabytes。作者：David Christensen。討論：https://postgr.es/m/CAOxo6XKmHc_WZip-x5QwaOqFEiCq_SVD0B7sbTZQk+qqcn2qaw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ca2e4472ba7b6e5e8cd8955eacffb90e4d88d085

Álvaro Herrera 推送了

Fujii Masao 推送了

  • postgres_fdw：收緊了 batch_size、fetch_size 選項允許的值。以前，諸如 '100$%$#$#', '9,223,372,' 之類的值會被接受，並被視為 postgres_fdw 選項 batch_size 和 fetch_size 的有效整數。然而，fdw_startup_cost 和 fdw_tuple_cost 選項並非如此，對於這些選項會拋出錯誤。這是因為在使用 strtol 將字串轉換為整數時，未使用 endptr。此提交變更了邏輯，使其使用 parse_int 函式而不是 strtol，因為它可以透過在無法將字串轉換為整數時傳回 false 來達到目的。請注意，此函式還會將諸如 '100.456' 之類的值四捨五入為 100，並將 '100.567' 或 '100.678' 四捨五入為 101。同時，對 fdw_startup_cost 和 fdw_tuple_cost 選項使用 parse_real。由於 reloptions 和 GUC 正在使用 parse_int 和 parse_real，因此在 postgres_fdw 中使用它們比直接使用 strtol 和 strtod 更合適。回溯修補至 v14。作者：Bharath Rupireddy 審閱者：Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao 討論：https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d854720df6df68cfe1432342e33c9e3020572a51

  • doc：修正了關於 pg_stat_statements.track_planning 的描述。此提交修正了 track_planning 選項描述中的錯誤措辭，例如 "a fewer kinds"。回溯修補至 v13，即新增 pg_stat_statements.track_planning 的版本。作者：Justin Pryzby 審閱者：Julien Rouhaud, Fujii Masao 討論：https://postgr.es/m/20210418233615.GB7256@telsasoft.com https://git.postgresql.org/pg/commitdiff/9d2a7757347cb1adb48599fce4dcde0f1fc9e9ae

Daniel Gustafsson 推送了

Thomas Munro 推送了

Jeff Davis 推送了

待處理的修補程式

Jie Zhang 提交了一個修補程式，使 libpq 的 PQsendFlushRequest 按照文檔記錄傳回 0，而不是像程式碼一樣傳回 false。

Gilles Darold 提交了另一個修訂的修補程式，以新增可以在 xact 回呼中捕獲的新事件 XACT_EVENT_COMMAND_START 和 SUBXACT_EVENT_COMMAND_START，當要執行新命令時。

Ranier Vilela 提交了一個修補程式，以修正在 src/backend/utils/adt/varlena.c 中可能未初始化的變數宣告。

Ronan Dunklau 和 Ranier Vilela 交換了修補程式，以允許 Sort 節點使用快速的 "single datum" tuplesort。

Andrey V. Lepikhov 提交了另兩個修訂的修補程式，以教導最佳化器考慮將非分割表與分割表的每個分割區進行 partitionwise join，並且不允許用於連接兩個分割（或附加）關係的非對稱機制，因為它可能在 NestLoop 路徑的重新參數化期間導致 CPU 和記憶體的巨大消耗。

Victor Spirin 提交了兩個修訂的修補程式，以使 Windows 上的重新命名操作具有原子性。

Peter Smith 提交了一個修補程式，以增加 psql 的 CREATE PUBLICATION 的 tab 完成的細微程度。

Amit Langote 提交了另一個修訂的修補程式，以匯出 get_partition_for_tuple()，並使用相同的方法來避免對某些 RI 檢查使用 SPI。

Hou Zhijie 提交了另一個修訂的修補程式，使其可以將表註解為安全地允許（或不允許）平行 DML，並在使 INSERT ... SELECT 中可以使用平行查詢時使用相同的方法，並新增 pg_get_table_parallel_dml_safety(regclass) 函式。

Dilip Kumar 提交了一個修補程式，使 CREATE DATABASE 成為 WAL 記錄的動作，以避免檢查點和寫入風暴，這些使得先前的實作變得繁重。

Zeng Wenjing 提交了一個修補程式，以更早地檢查同步備用伺服器。

Vigneshwaran C 提交了另一個修補程式版本，用於識別在 CREATE/ALTER SUBSCRIPTION 期間從發布者遺漏的出版品。

Dipesh Pandit 提交了一個修補程式，透過維護目前正在歸檔的日誌片段編號，並將其遞增 '1' 以取得下一個 WAL 檔案，來緩解 WAL 封存器中 O(N^2) 的目錄掃描。

Justin Pryzby 提交了一個修補程式，在 procarray.c 中新增了一些 ASSERTION，並在 pg_resetwal.c 中新增了一個新的 oldest-transaction-id 可選參數。

Gilles Darold 提交了另三個修補程式版本，用於將 CASE 子句的下推 (pushdown) 新增到 PostgreSQL FDW。

Bharath Rupireddy 和 Peter Smith 交換了修補程式，使 parse_subscription_options 函數負責預先清除 SubOpts 參數，而不是希望呼叫者會執行此操作，並刪除對 "supported_opts" 的多餘條件檢查，因為我們已經知道該選項必須受到支援。

Ajin Cherian、Amit Kapila 和 Peter Smith 交換了修補程式，以新增對邏輯複製的預先準備交易 (prepared transactions) 的支援。

Vigneshwaran C 提交了另兩個修補程式版本，以增強錯誤訊息，在重複選項錯誤的情況下包含選項名稱。

Greg Nancarrow 提交了另一個修補程式版本，以新增一個新的 "client_connection" 事件，以及針對相同事件的用戶端連線觸發器支援。

Gurjeet Singh 提交了一個修補程式，明確聲明 --sync-only 不會修改資料。

Kyotaro HORIGUCHI 提交了一個修補程式，使 FPI_FOR_HINT 遵循標準的 FPI 發射策略 (emitting policy)。

David Rowley 提交了另一個修補程式版本，以刪除 BIGINT 序列 MINVALUE/MAXVALUE 值上無用的 int64 範圍檢查。

Bharath Rupireddy 提交了另一個修補程式版本，透過更具體地說明物件無法新增到相同出版品的原因，來改善出版品錯誤訊息。

Andy Fan 提交了另一個修補程式版本，以擴展規劃器 (planner) 中唯一性的使用方式。

Gurjeet Singh 提交了一個修補程式，當 initdb 的 --sync-only 選項與其他選項混用時，發出警告。

Dean Rasheed 提交了另一個修補程式版本，以修復 NUMERIC 類型中指數運算的精度損失錯誤，並防止一些溢位錯誤。

Bruce Momjian 提交了另三個修補程式版本，以修復一個會損毀可見性地圖 (visibility map) 的錯誤。

Dagfinn Ilmari Mannsåker 提交了一個修補程式，在適當的地方使用 l*_node() 系列函數。

Li Japin 和 Ranier Vilela 交換了修補程式，以驗證 parse_subscription_options 中的 slot_name。

Yugo Nagata 提交了另一個修補程式版本，以避免一些 pgbench 錯誤。

Euler Taveira de Oliveira 和 Greg Nancarrow 交換了修補程式，以實現邏輯複製的列篩選 (row filtering)。

Takamichi Osumi 提交了一個修補程式，以修復一個導致交易統計資訊無法衡量邏輯複製進度的錯誤。

Fabien COELHO 提交了另兩個修補程式版本，以用更好的 PRNG 取代 rand48。

Masahiko Sawada 提交了一個修補程式，以闡明 ALTER SUBSCRIPTION 中關於 refresh_option 選項的說明文件。

Robert Haas 提交了另一個修補程式版本，以重構 basebackup.c。

Seino Yuki 提交了一個修補程式，以追蹤實體化視圖 (materialized views) 的統計資訊。

Georgios Kokolatos 提交了另一個修補程式版本，以教導 pg_receivewal 使用 lz4 壓縮。

Kyotaro HORIGUCHI 提交了兩個修補程式版本，以嚴格拒絕命令列上無效的數值參數，並抱怨環境變數中應為數值的相同參數。

Alexander Lakhin 和 Michaël Paquier 交換了修補程式，以修復 pg_ls_dir。

Quan Zongliang 提交了四個修補程式版本，以修復當 blocksize 為 32k 時，pageinspect 的 page_header 函數返回負數的錯誤。

Bharath Rupireddy 提交了另一個修補程式版本，以消除使用 "non-negative" 的錯誤訊息的歧義。

Atsushi Torikoshi 提交了另一個修補程式版本，新增一個函數來記錄未截斷的查詢字串及其針對在具有指定進程 ID 的後端上目前正在執行的查詢的計畫。

Hou Zhijie 提交了另一個修補程式版本，新增對發布的架構層級支援。

Bertrand Drouvot 提交了另一個修補程式版本，以修復一個錯誤，該錯誤表現為使用 toast 的關係重寫 (relation rewrite) 的邏輯解碼不會重置 toast_hash。

Georgios Kokolatos 提交了一個修補程式，以在 pg_receivewal 中測試 gzip 壓縮。

Pavel Borisov 提交了另一個修補程式版本，以透過 LIST 和 HASH 自動產生分割區。

Amul Sul 提交了另一個修補程式版本，以新增一個 RelationGetSmgr 內聯函數。

David Rowley 提交了另一個修補程式版本，以在 RelOptInfo 中追蹤未修剪的分割區 (non-pruned partitions)，並允許在更多情況下進行有序分割區掃描。

Dagfinn Ilmari Mannsåker 提交了一個修補程式，以將 CREATE SCHEMA 的 Tab 補全新增到 psql。

Zhihong Yu 提交了一個修補程式，以縮短 find_hash_columns() 中對所需欄位的測試。

Nathan Bossart 提交了另一個修補程式版本，以預先分配 WAL 片段。

Tomáš Vondra 提交了另一個修補程式版本，以使 pg_dump 可以單獨傾印函數。

Peifeng Qiu 提交了一個修補程式，以支援 postgres_fdw 的 Kerberos 驗證。

Erik Rijkers 提交了一個修補程式，將 JSON 操作包含為 JIT 編譯的候選者。

Fabien COELHO 提交了另一個修補程式版本，以分解 psql 中的 echo 程式碼。

David Rowley 提交了一個修補程式，以將 Result Cache 節點的名稱更改為 Memoize。

Soumyadeep Chakraborty 提交了另一個修補程式版本，以在 pg_stats 中顯示長度和邊界直方圖 (length and bounds histograms)。

Ranier Vilela 提交了一個修補程式，透過檢查陣列項目的最大限制，來防止 src/backend/access/nbtree/nbtxlog.c 中可能的記憶體損壞。

Thomas Munro 提交了另一個修補程式版本，為 psql 的 \watch 命令新增 PSQL_WATCH_PAGER 設定。