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

PostgreSQL 每週新聞 - 2021 年 6 月 13 日

發布於 2021-06-14，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 6 月 13 日

本週人物

PostgreSQL 產品新聞

pg_statement_rollback v1.2，一個擴充套件，增加了伺服器端事務，可以在語句級別回滾，已發布。

六月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已套用的補丁

Tomáš Vondra 推送了

Tom Lane 推送了

  • 修正 FuncCall.funcformat 的 equalfuncs.c 行為不一致。equalfuncs.c 中其他關於 CoercionForm 欄位的檢查使用 COMPARE_COERCIONFORM_FIELD (這使得它們不執行任何操作)，但 commit 40c24bfef 忽略了讓 _equalFuncCall 也這樣做。修正它。只有在 FuncCall.funcformat 沒有語義影響，而只是決定 ruleutils.c 顯示格式時，這才是嚴格正確的。40c24bfef 在解析分析中新增了一些可能會破壞該規則的檢查；但經過仔細檢查，它們是多餘的，所以直接移除它們。根據 Noah Misch 的報告。討論：https://postgr.es/m/20210606063331.GC297923@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/a65e9f3f1405b786673feec131879843432bf9a6

  • 修正客戶端程式碼中對可能編碼錯誤字串的不小心處理。字串末尾附近編碼錯誤的多位元組字元可能導致各種處理迴圈超出字串的終止 NUL 運行，導致的結果範圍從未檢測到問題到程式崩潰，取決於後面的記憶體中是什麼。這在伺服器中不是問題，因為我們在對字串進行任何有趣的處理之前會注意驗證字串的編碼。但是，這種缺乏謹慎洩漏到了客戶端程式碼中，客戶端程式碼不應假設任何人已驗證其輸入的編碼。雖然這確實是一個值得修復的錯誤，但 PG 安全團隊選擇不將其視為安全問題，主要是因為任何不受信任的文字都應在使用 PQescapeLiteral 或類似工具合併到 SQL 或 psql 命令中之前進行清理。（如果應用程式未能這樣做，則可以使用相同的技術來導致 SQL 注入，其後果可能比僅僅客戶端程式崩潰更可怕。）這些函數已經證明可以防禦此類問題，請參閱 CVE-2006-2313。為了修復，發明了 PQmblenBounded()，它類似於 PQmblen()，只是它返回的值不會超過字串中剩餘的位元組數。在 HEAD 中，我們可以將其設為一個新的 libpq 函數，就像 PQmblen() 一樣。但更改穩定分支中的 libpq API 似乎是不明智的，因此在後端分支中，將 PQmblenBounded 定義為需要它的檔案中的巨集。（請注意，僅僅更改 PQmblen 的行為不是一個好主意；值得注意的是，它會完全破壞轉義函數對此類問題的防禦。因此，我們只需要一個版本來處理那些沒有任何更好方法來處理此問題的呼叫者。）根據 houjingyi 的私人報告。向所有支援的分支進行向後移植。https://git.postgresql.org/pg/commitdiff/42f94f56bf9559f0a3cf5f3ffde50655834694ee

  • 穩定 contrib/seg 回歸測試。如果 autovacuum 在我們用一些資料填滿表 test_seg 後立即出現，它將更新統計資料到我們更喜歡普通索引掃描而不是位圖掃描的程度，從而破壞了預期的輸出（以及測試案例的要點）。為了修復，只需強制在此處選擇位圖掃描。自 commit de1d042f5 以來，這顯然是錯誤的。目前尚不清楚為什麼我們最近才看到由它引起的任何 buildfarm 失敗；但 prairiedog 在過去的一周中已經兩次在此測試中失敗。因此，向後移植到 v11，這個測試案例是在 v11 中引入的。https://git.postgresql.org/pg/commitdiff/d16ebfbff74b30c83a4669a1df318cacfa7e52ca

  • 修正 SQL 標準函式主體中遇到空語句時崩潰的問題。gram.y 應該在組裝 routine_body_stmt_list 時，像處理其他種類的語句列表一樣，捨棄 NULL 指標（空語句）。由 Julien Rouhaud 和 Tom Lane 修正，根據 Noah Misch 的報告。討論：https://postgr.es/m/20210606044418.GA297923@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/bfeede9fa464ab707eb5ac5704742bf78bd7ac9e

  • 避免在持久化非穩定游標時發生錯誤行為。PersistHoldablePortal 長期以來假設它應該儲存要持久化的查詢的完整輸出，這需要倒帶並重新讀取輸出。如果查詢是不穩定的，這會產生問題：我們可能會得到不同的行內容，甚至不同數量的行，這會嚴重混淆游標狀態。如果游標是 NO SCROLL，這很容易解決：只需儲存剩餘的查詢輸出，無需任何倒帶，並調整入口的游標狀態以匹配即可。除了消除語義問題之外，這可能比儲存整個輸出更有效率。如果游標是可滾動的，我們能做的並不多，但滾動不穩定查詢的結果已經非常不安全。我們只需更清楚地說明，無法保證從中獲得正確的結果。已經存在禁止將 SCROLL 與 FOR UPDATE/SHARE 一起使用的規定，這是 SELECT 查詢產生不穩定結果的一種方式。我們可以想像當查詢包含不穩定函數時禁止 SCROLL，但這將需要昂貴的執行成本。此外，如果使用者忘記將函數標記為穩定，則可能會破壞運行良好的應用程式。因此，決定記錄這個風險。雖然這個問題以某種形式存在了很長時間，但在 v11 中變得更加嚴重，v11 引入了持久化 plpgsql 游標（可能是隱式的）的可能性，即使它們違反了可以標記為 WITH HOLD 的規則。因此，我選擇回溯修補到 v11，但不再往前。根據 Алексей Булгаков 提出的 bug #17050。討論：https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org https://git.postgresql.org/pg/commitdiff/ba2c6d6cec000f0aeaeda4d56a23a335f6164860

  • 強制 plpgsql 的隱式游標使用 NO SCROLL。進一步思考 bug #17050 表明，對於 plpgsql FOR-over-query 迴圈開啟的隱式游標，使用 CURSOR_OPT_NO_SCROLL 是個好主意。這確保了如果有人在迴圈內提交，PersistHoldablePortal 不會嘗試倒帶並重新讀取游標。雖然如果查詢中出現 FOR UPDATE/SHARE，我們無論如何都會選擇 NO_SCROLL，但使用不穩定函數也存在其他風險；而且在任何情況下，花費精力儲存我們確定不需要的行是很愚蠢的。（順便說一句，改進 exec_run_select 中的註釋，它對於何時可以使用並行模式的理由有點困惑。游標操作對於無名入口來說不是風險。）這在 v11 之前不是問題，v11 引入了持久化這些游標的可能性。因此，回溯修補到 v11。根據 Алексей Булгаков 提出的 bug #17050。討論：https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org https://git.postgresql.org/pg/commitdiff/be90098907475f3cfff7dc6d590641b9c2dae081

  • 避免 ECPG 測試在某些具有 GSS 功能的環境中失敗。Buildfarm 成員 hamerkop 報告說，connect/test5.pgc 中的兩個案例顯示的錯誤訊息與測試預期的不同，因為自 commit ffa2e4670 以來，libpq 的連接失敗訊息暴露了嘗試 GSS 加密連接但失敗的事實。這本身就是非常有趣的訊息，我當然不想責怪報信者，但我們需要做些什麼來穩定 ECPG 結果。對於這兩個失敗案例中的第二個，我們可以新增 gssencmode=disable 選項來防止差異。但是，該解決方案對於第一個失敗案例來說是有問題的，因為該案例唯一特殊之處在於它正在測試一個完全省略的連接目標；沒有地方可以新增選項而不影響測試案例的意義。在經過一番對具有不良副作用的替代修復方案的折騰後，最可行的答案是放棄並刪除該測試案例。如果我們弄清楚 GSS 代碼在 hamerkop 環境中為何行為不端，也許我們可以稍後恢復此操作。感謝 Michael Paquier 對替代方案的探索。討論：https://postgr.es/m/YLRZH6CWs9N6Pusy@paquier.xyz https://git.postgresql.org/pg/commitdiff/9bb5eecce645dd72853e3ed262bef7bf11cae566

  • 在 LockRows 節點到達末尾時關閉 EvalPlanQual 機制。先前，我們讓 EPQ 子執行器保持運行，直到 ExecEndLockRows。這導致它可能持有的任何緩衝區釘選或其他資源一直保持到 ExecutorEnd，在某些代碼路徑中，這意味著它們一直保持到入口關閉。這可能會導致使用者可見的問題，例如阻塞 VACUUM；並且這與普通表掃描節點的行為不同，普通表掃描節點在返回 EOF 指示時將釋放所有緩衝區釘選。我們可以通過在返回 NULL 之前調用 EvalPlanQualEnd 使 LockRows 的工作方式更像其他計劃節點。我們仍然需要在 ExecEndLockRows 中調用它，以防節點沒有運行完成，但在正常情況下，第二次調用不會執行任何操作並且代價很小。根據 Yura Sokolov 的報告。原則上這是一個長期存在的 bug，但考慮到缺乏其他投訴和後果的低嚴重性，我選擇不回溯修補。討論：https://postgr.es/m/4aa370cb91ecf2f9885d98b80ad1109c@postgrespro.ru https://git.postgresql.org/pg/commitdiff/bb4aed46a5aeb00d2f1d8b8160feed339f4eaf12

  • 更進一步地重新安排 logrep 工作者的快照處理。事實證明，worker.c 中 TRUNCATE 的代碼路徑在執行使用者定義代碼時也疏忽了建立快照，導致 commit 84f5c2908 新增的檢查在觸發器在該上下文中觸發時失敗。我們只需將 Push/PopActiveSnapshot 包裹在 truncate 調用周圍，但似乎最好建立一個在複製步驟的整個執行過程中保持快照的策略。為了幫助實現這一點以及可能的未來需求，請將之前的 ensure_transaction 調用替換為 begin/end_replication_step 調用對。根據 Mark Dilger 的報告。像之前的更改一樣，回溯修補到 v11。討論：https://postgr.es/m/B4A3AF82-79ED-4F4C-A4E5-CD2622098972@enterprisedb.com https://git.postgresql.org/pg/commitdiff/3a09d75b4f6cabc8331e228b6988dbfcd9afdfbe

  • 重新考慮程序 OUT 參數的處理方式。Commit 2453ea142 重新定義了 pg_proc.proargtypes，使其僅包含程序的 OUT 參數類型。雖然這對於實現 SQL 規範中 DROP PROCEDURE 的行為有一些優勢，但從許多其他角度來看，卻是災難性的。 值得注意的是，由於 pg_proc 的主鍵是 name + proargtypes，因此這使得擁有具有相同名稱 + 輸入參數但輸出參數類型不同的多個程序成為可能。 這將導致無法僅通過編寫 NULL（或"?"，或任何其他無資料類型標記）作為輸出參數來調用任何一個程序。 此更改似乎也可能讓檢查 pg_proc 並期望 proargtypes 的傳統定義的客戶端應用程序感到非常困惑。 因此，將 proargtypes 的定義恢復到原來的狀態，並撤銷為支持該定義而添加的許多複雜之處。 為了支持 SQL 規範中 DROP PROCEDURE 的行為，當命令的參數列表中沒有 argmode 標記時，我們將以兩種方式執行查找（即，同時匹配 proargtypes 和 proallargtypes），如果我們只得到一個唯一的匹配項，則成功。 原則上，這可能會導致在使用兩個規則中的任何一個時都不會發生的模糊函數失敗。 但是，程序名稱的重載被認為是一種非常罕見的用法，因此這不應在實踐中引起太多問題。 Postgres 特定的程式碼（例如 pg_dump）可以通過小心地為所有程序參數指定 argmodes 來防禦任何此類失敗的可能性。 這也修復了 CALL 語句中帶有名稱參數的一些其他錯誤，並稍微改進了文檔。 強制 catversion 升級，因為帶有 OUT 參數的程序的表示形式發生了變化。 討論：https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e56bce5d43789cce95d099554ae9593ada92b3b7

  • 修復分割表複製邏輯中的多個崩潰錯誤。 apply_handle_tuple_routing() 在檢測到並報告它需要更新的 tuple 不存在後，仍然嘗試更新該 tuple，從而導致空指針解引用。 logicalrep_partition_open() 無法確保它為分割區構建的 LogicalRepPartMapEntry 完全獨立於分割區根目錄的 LogicalRepPartMapEntry，如果在稍後釋放或重建根目錄條目，則會導致問題。 同時，在發布者端，pgoutput_change() 有時會嘗試將 execute_attr_map_tuple() 應用於 NULL tuple。 其中第一個錯誤由 Sergey Bernikov 在錯誤 #17055 中報告； 我在為這個可悲的未經充分測試的程式碼開發一些測試案例時發現了其他兩個錯誤。 第一個問題的診斷和補丁由 Amit Langote 提供； 其他問題的補丁由我提供； 新的測試案例由我提供。 Back-patch 到引入此邏輯的 v13。 討論：https://postgr.es/m/17055-9ba800ec8522668b@postgresql.org https://git.postgresql.org/pg/commitdiff/ab55d742eb7162c22ee60f1e15e07d2a60063c4e

  • 不要使用 Assert 來檢查複製協議的違規行為。 使用 Assert 來檢查傳入消息的有效性是一個非常糟糕的決定。 在 debug 版本中，一個損壞或惡意的遠程客戶端不應該那麼容易導致 logrep worker 崩潰。 在非 debug 版本中，後果可能更糟，因為這些版本根本不會進行此類檢查，從而導致誰知道會發生什麼樣的錯誤行為。 因此，將每個可能由錯誤或亂序的複製消息觸發的 Assert 提升為完整的測試和 ereport。 為了避免擴大翻譯團隊必須應對的消息集，制定一項策略，即複製協議違規錯誤報告不需要翻譯。 因此，此處的所有新消息都使用 errmsg_internal()。 為了保持一致性，也同樣更改了一些舊消息。 順便說一句，修復了一些非慣用或完全錯誤的 hash_search() 用法。 這些錯誤中的大多數是 "streaming replication" 補丁（commit 464824323）中的新錯誤，但有些錯誤可以追溯到很久以前。 根據需要進行 Back-patch。 討論：https://postgr.es/m/1719083.1623351052@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/fe6a20ce54cbbb6fcfe9f6675d563af836ae799a

  • 確保 pg_filenode_relation(0, 0) 返回 NULL。 以前，relfilenode 的零值會導致關於「意外重複」的令人困惑的錯誤消息。 此函數為其他無效的 relfilenode 值返回 NULL，因此零也應同樣對待。 一直都是這樣，因此 back-patch 到所有受支持的分支。 Justin Pryzby 討論：https://postgr.es/m/20210612023324.GT16435@telsasoft.com https://git.postgresql.org/pg/commitdiff/1250aad42520fd5a3db68d6381997b7e1f9bb4aa

  • 恢復等待 postmaster 重啟的 TAP 測試的穩健性。 幾個 TAP 測試使用 poll_query_until() 等待 postmaster 重啟。 他們正在檢查一個簡單的查詢（例如 "SELECT 1"）是否成功。 但是，在 commit 11e9caff8 之後，這是個問題，因為現在我們通過 stdin 將上述查詢提供給 psql，如果 psql 在讀取查詢之前退出，我們可能會遇到 IPC::Run 抱怨 SIGPIPE 失敗的情況。 因此，在我們需要等待連線失敗停止發生的情況下，我們不能使用非空查詢。 按照 commit c757a3da0 和 6d41dd045 的先例，我們可以將 "undef" 作為此類情況下的查詢傳遞，以確保 IPC::Run 沒有任何可寫的內容。 但是，我們必須說預期的輸出為空，這暴露了 poll_query_until 中的缺陷：如果 psql 完全失敗並返回空的 stdout，poll_query_until 會將其視為成功！ 這是因為，與其文檔相反，它沒有對 psql 失敗進行實際檢查，既沒有查看退出狀態，也沒有查看 stderr。 為了修復這個問題，調整 poll_query_until 以堅持要求空的 stderr 以及 stdout 匹配。 （我嘗試過檢查退出狀態，但似乎 psql 通常會在我們需要考慮成功的情況下執行 exit(1)。 這可能是有一天需要修復的事情，但這將是一個不可 back-patch 的行為更改。） Back-patch 到 v10。 需要此更改的測試案例僅存在於 v11 中，但似乎明智的做法是在 v10 中保持 poll_query_until 的行為相同，以防我們將來 back-patch 另一個此類測試案例。 （9.6 目前不需要此更改，因為在該分支中無法告訴 poll_query_until 接受空的 stdout 作為成功案例。） 根據各種 buildfarm 失敗，主要是在 hoverfly 上。 討論：https://postgr.es/m/CAA4eK1+zM6L4QSA1XMvXY_qqWwdUmqkOS1+hWvL8QcYEBGA1Uw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f452aaf7d4a96cfcecd6c60ccd294ffe7b8ea088

Etsuro Fujita 推送

Amit Kapila 推送

Michaël Paquier 推送

Peter Eisentraut 推送

Bruce Momjian pushed

Robert Haas pushed

  • 修正新的備用伺服器追隨新的主要伺服器時發生的邊角案例失敗。 只有在以下情況下才會發生：(1) 新的備用伺服器在本地沒有可用的 WAL，(2) 新的備用伺服器從舊的時間線開始，(3) 升級發生在新的備用伺服器啟動的 WAL 片段中，(4) 新時間線的時間線歷史檔案可以從歸檔中取得，但 WAL 檔案不可用（即，這是一個競爭條件），(5) 新時間線的 WAL 檔案可透過流式傳輸取得，以及 (6) recovery_target_timeline='latest'。 Commit ee994272ca50f70b53074f0febaec97e28f83c4e 引入了此邏輯，並且比之前的程式碼有所改進，但它錯誤地處理了這種情況。如果 recovery_target_timeline='latest' 且設定了 restore_command，validateRecoveryParameters() 可以將 recoveryTargetTLI 更改為與 receiveTLI 不同。如果在之後嘗試串流，expectedTLEs 會使用錯誤時間線的歷史記錄初始化。它應該是一個解釋如何到達目標時間線的條目列表，但在這種情況下，它最終會得到一個解釋如何到達新備用伺服器原始時間線的條目列表，這是不對的。Dilip Kumar 和 Robert Haas 審閱，Kyotaro Horiguchi 審閱。Discussion: http://postgr.es/m/CAFiTN-sE-jr=LB8jQuxeqikd-Ux+jHiXyh4YDiZMPedgQKup0g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/caba8f0d43fb679c6f9643456080408a6bc370e8

  • 調整新的測試案例以設定 wal_keep_size。根據 buildfarm 成員 conchuela 和 Kyotaro Horiguchi 的說法，連鎖備用伺服器需要的 WAL 片段可能會被過快移除。希望這能防止這種情況發生。Kyotaro Horiguchi Discussion: http://postgr.es/m/20210610.101240.1270925505780628275.horikyota.ntt@gmail.com https://git.postgresql.org/pg/commitdiff/4dcb1d087aebc6fc2477ce4458ea82f548e2c1ee

David Rowley pushed

Noah Misch pushed

Álvaro Herrera pushed

Andres Freund 推送

Andrew Dunstan 推送

  • 修復用於 msys 的新還原測試。Commit caba8f0d43 對於 msys 來說不太正確，正如包括 jacana 和 fairywren 在內的幾個建置場動物所證明的那樣。我們需要在封存命令中使用 msys perl，但以 Windows 可以理解路徑的方式呼叫它。此外，在複製腳本中，我們需要將 Windows 路徑轉換為 msys 路徑。https://git.postgresql.org/pg/commitdiff/c3652f976b7696a96a9c5606cc2d613af77e2e63

  • 進一步調整 stuck_on_old_timeline 還原測試。翻譯目標目錄路徑上的路徑斜線。這使舊分支感到困惑，但為了統一性，它已應用於所有分支。Perl 完全能夠理解帶有正斜線的路徑。一路走來，根據 Tom Lane 的抱怨，為了與其他測試保持一致，恢復先前的 archive_wait 查詢。https://git.postgresql.org/pg/commitdiff/9d97c3408319b43718e4b85bc694697db1af32c6

待處理的修補程式

Ranier Vilela 發送了另一個修補程式修訂版本，以減少 detoasted 值的開銷。

Takamichi Osumi 發送了三個修補程式修訂版本，以記錄同步邏輯解碼中可能出現的死鎖。

Andrey V. Lepikhov 發送了另一個修補程式修訂版本，以實作大量 COPY FROM 到外部資料表。

侯志杰發送了另一個修補程式修訂版本，以適應性地快取分割區邊界偏移。

Nathan Bossart 發送了一個預先分配 WAL 段的修補程式。

Tomáš Vondra 發送了兩個修補程式修訂版本，使邏輯解碼可以複製序列。

Justin Pryzby 發送了一個在 ps 顯示中顯示「同步資料目錄」的修補程式。

Anastasia Lubennikova 發送了兩個修補程式修訂版本，以測試迴歸測試的重播。

Aleksander Alekseev 和 Michaël Paquier 交換了修補程式，以修復 pg_event_trigger_ddl_commands 中丟棄物件的處理。

Dilip Kumar 和 Amit Langote 交換了修補程式，以修復推測性中止的解碼。

Peter Eisentraut 發送了一個自動產生節點支援函式的修補程式。

Kyotaro HORIGUCHI 和 Amit Kapila 交換了修補程式，旨在修復一個錯誤，該錯誤表現為邏輯複製中的 keepalive 洪水。

Quan Zongliang 發送了一個從 KnownAssignedTransactionIdes 子模組中移除未使用程式碼的修補程式。

Emre Hasegeli 發送了一個在 btree_gist 中支援 bool 的修補程式。

Jacob Champion 發送了一個 PoC 修補程式，以使用 OAUTHBEARER 實作聯合驗證/授權。

Jeff Davis 發送了另一個修補程式修訂版本，以追蹤上次還原 LSN、時間和總計數，這將使您可以從其他節點看到未記錄的資料表重置。

侯志杰發送了一個修補程式，以移除 get_qual_from_partbound 中現在未使用的函式參數。

侯志杰發送了兩個修補程式修訂版本，使 INSERT ... SELECT 可以在平行執行。

Peter Geoghegan 和 Matthias van de Meent 交換了修補程式，以修復 GetOldestNonRemovableTransactionId 中的一個錯誤。GetOldestNonRemovableTransactionId(rel) 沒有傳回與 GlobalVisTestFor(rel) 一致的值。現在已更新，並新增了一些斷言以確保此問題案例不會傳回。

Peter Smith 和 Ajin Cherian 交換了修補程式，以將對準備交易的支援新增到內建邏輯複製、新增串流交易的準備 API 支援，並跳過邏輯複製的空交易。

Ajin Cherian 發送了三個修補程式修訂版本，以新增一個選項來在 CREATE_REPLICATION_SLOT 命令中設定兩階段，並在 pg_recvlogical 中新增對兩階段解碼的支援。

Julien Rouhaud 發送了兩個修補程式修訂版本，以新增一個用於可擴充剖析的 hook。

Kyotaro HORIGUCHI 和 Fabien COELHO 交換了修補程式，旨在修復一個錯誤，該錯誤表現為 pgbench 記錄 0 間隔日誌項目。

Alexander Pyhalov 發送了一個允許將 CASE 表達式推送到外部伺服器的修補程式。

Jeff Davis 發送了兩個修補程式修訂版本，以實作 ALTER TABLE ... SET ACCESS METHOD。

Nitin Jadhav 發送了另一個修補程式修訂版本，以追蹤啟動進度。

Atsushi Torikoshi 發送了另一個修補程式修訂版本，以新增一個函式，用於記錄目前在具有指定程序 ID 的後端上執行的查詢的完整查詢字串及其計畫。

Thomas Mannhart 發送了兩個修補程式修訂版本，以實作範圍合併聯結。

Thomas Munro 發送了一個調整 pg_regress 輸出的修補程式，以適用於新的長測試名稱。

Bharath Rupireddy 發送了兩個修補程式修訂版本，以重構 parse_subscription_options，並移除 parse_subscription_options 中類似的 ereport 呼叫。

Tomáš Vondra 發送了兩個修補程式修訂版本，以建立用於批次處理的描述符副本，並僅為批次處理初始化槽一次。

Nathan Bossart 發送了一個新增用於檢索 shmem 大小的 pg_ctl 選項的修補程式。

John Naylor 發送了另一個修補程式修訂版本，以加快 pg_utf8_verifystr 的重寫速度。

David Rowley 發送了一個在出現 "a SQL" 的地方使用 "an SQL" 的修補程式。

Alexander Korotkov 發送了四個修補程式修訂版本，以支援 UNNEST(multirange) 並將 multirange 轉換為範圍陣列。

Hayato Kuroda 發送了一個忽略 pgbench 中失敗線程的修補程式。

Amit Langote 再次提交了一個補丁的修訂版，以實作多欄位列表分割。

Jacob Champion 再次提交了一個補丁的修訂版，以將欄位投影列表添加到表格 AM API。

Bruce Momjian 提交了三個補丁的修訂版，以記錄某些彙總函式需要在升級後重新建立的事實。

Ranier Vilela 提交了一個補丁，將某些有符號類型更改為無符號類型。

Pavel Stěhule 再次提交了一個補丁的修訂版，以實作 schema 變數。

Thomas Munro 再次提交了一個補丁的修訂版，以新增用於 socket 關閉事件的 WL_SOCKET_CLOSED，並將 WL_SOCKET_CLOSED 用於 client_connection_check_interval。

Fabien COELHO 再次提交了一個補丁的修訂版，以將 SHOW_ALL_RESULTS 新增至 psql。

David Rowley 提交了一個補丁，以清理執行器中的一些彙總程式碼。

David Rowley 提交了一個補丁，通過將每次迭代時的緊密迴圈加倍替換為適當的 pg_nextpower2_32 或 pg_nextpower2_64，來改進一些將緩衝區大小加倍的位置。

David Rowley 提交了一個補丁，以添加對 ORDER BY / DISTINCT 彙總的正確規劃器支援。

Noah Misch 提交了一個補丁，以移除 pg_wait_for_backend_termination()。

Yugo Nagata 和 Fabien COELHO 交換了補丁，以防止 pgbench 因為跳過的交易而卡住。

Ranier Vilela 再次提交了一個補丁的修訂版，以減少 procarray 中不匹配的類型。

Thomas Munro 提交了三個補丁的修訂版，以將 tuple 層級的 SIREAD 鎖用於僅索引掃描，並在可能的情況下跳過 btree 頁面上的 SIREAD 鎖。

Alexander Korotkov 提交了一個補丁，將新文件章節的標題更改為 Range/Multirange Functions and Operators，這更清晰。

Bharath Rupireddy 提交了一個補丁，以增強 postgres_fdw 的批次插入測試案例。

Tomáš Vondra 提交了一個補丁，以縮短 postgres_fdw 測試的執行時間。

Tomáš Vondra 提交了一個補丁，以處理擴展統計信息中的 Expr op Expr 子句。