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

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

發布於 2021-02-10，作者：PWN
PWN

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

pg_probackup 2.4.9 已發布，這是一個用於管理 PostgreSQL 資料庫叢集備份和復原的工具。https://github.com/postgrespro/pg_probackup/releases/tag/2.4.9

pitrery 3.3 已發布，這是一組用於管理 PostgreSQL 的 PITR 備份的 Bash 腳本。http://dalibo.github.io/pitrery/

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

PostgreSQL 產品新聞

二月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已應用的補丁

Alexander Korotkov 推送了

Tom Lane 推送了

  • 修復新 jsonbsubs 程式碼中的可移植性問題。在 sizeof(Datum) > sizeof(Oid) 的機器上（即任何 64 位元平台），如果 nupper 為奇數，先前的編碼將計算出錯誤對齊的 workspace->index 指標。不允許錯誤對齊存取的架構將會失敗。這似乎解釋了為什麼 thorntail 不高興，但其他 buildfarm 成員沒有。https://git.postgresql.org/pg/commitdiff/7c5d57caed4d8af705d0cc3131d0d8ed72b7a41d

  • 修改 make_partition_pruneinfo，使其不再使用其 partitioned_rels 輸入。 原因是 allpaths.c 中 [Merge]AppendPath.partitioned_rels 的計算有誤，有時會省略相關的非葉子分割區，導致 commit a929e17e5a8 增加的斷言觸發。 與其修復它，不如直接擺脫這些欄位。 我們實際上直到 create_plan 的時候才需要這些資訊，而且為選定的計畫計算一次，應該比為我們考慮的每個 append path 計算一次更便宜。 第一步，教導 make_partition_pruneinfo 為自己收集相關的分割表。 通過使用 AppendRelInfo 連結從子表向上遍歷到父表，這並不難做到。 在這裡，進行一些小的樣式改進；主要是，不要將 "Relids" 別名用於不是規劃器考慮的任何關係的標識的 bitmapsets。 嘗試更好地記錄邏輯。 沒有 backpatch，因為在 a929e17e5a8 之前似乎沒有實際問題。 也沒有新的迴歸測試； 存在錯誤的代碼將在本修補程式系列的結尾處消失，因此紀念該問題似乎有點毫無意義。 Tom Lane 和 David Rowley，根據 Andreas Seltenreich 和 Jaime Casanova 的報告。 討論：https://postgr.es/m/87sg8tqhsl.fsf@aurora.ydns.eu 討論：https://postgr.es/m/CAJKUy5gCXDSmFs2c=R+VGgn7FiYcLCsEFEuDNNLGfoha=pBE_g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/fb2d645dd53ff571572d830e830fc8c368063802

  • 移除對 partitioned_rels 列表的附帶依賴。 原因是 allpaths.c 中 [Merge]AppendPath.partitioned_rels 的計算有誤，有時會省略相關的非葉子分割區，導致 commit a929e17e5a8 增加的斷言觸發。 與其修復它，不如直接擺脫這些欄位。 我們實際上直到 create_plan 的時候才需要這些資訊，而且為選定的計畫計算一次，應該比為我們考慮的每個 append path 計算一次更便宜。 此修補程式取消了對 partitioned_rels 值的幾個非常小的使用。 createplan.c 正在測試 nil-ness 以優化掉 make_partition_pruneinfo() 的準備工作。 如果檢查幾乎免費，那麼這值得做，但不值得花費大量精力來避免。 create_append_path() 正在測試 nil-ness，作為決定如何為 AppendPath 設定 ParamPathInfo 的一部分。 我用對 appendrel 的父關係是否被分割的檢查代替了它。 這並不完全相同，但應該涵蓋大多數情況。 如果我們注意到任何有趣的優化損失，我們可以將其簡化為僅在父級是 baserel 時始終使用更昂貴的方法。 討論：https://postgr.es/m/87sg8tqhsl.fsf@aurora.ydns.eu 討論：https://postgr.es/m/CAJKUy5gCXDSmFs2c=R+VGgn7FiYcLCsEFEuDNNLGfoha=pBE_g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5076f88bc985a7728eea337cbabae0e034b064b1

  • 移除 [Merge]AppendPath.partitioned_rels。 原因是 allpaths.c 中 [Merge]AppendPath.partitioned_rels 的計算有誤，有時會省略相關的非葉子分割區，導致 commit a929e17e5a8 增加的斷言觸發。 與其修復它，不如直接擺脫這些欄位。 我們實際上直到 create_plan 的時候才需要這些資訊，而且為選定的計畫計算一次，應該比為我們考慮的每個 append path 計算一次更便宜。 前面兩個 commit 消除了對 partitioned_rels 值的所有使用； 此 commit 只是機械地移除欄位和計算它們的代碼。 討論：https://postgr.es/m/87sg8tqhsl.fsf@aurora.ydns.eu 討論：https://postgr.es/m/CAJKUy5gCXDSmFs2c=R+VGgn7FiYcLCsEFEuDNNLGfoha=pBE_g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f003a7522bfa11177dc52c65eb97273a1057dfba

  • 文件：在 regex 匹配的初始範例上多下功夫。 在 POSIX regex 的開頭和結尾寫入不必要的 '.*' 除了使讀者感到困惑之外，並不能做什麼，他們會懷疑這是否是必要的。 使表 9.16 中的範例更具真實感，並嘗試將下一組範例變成獨立的範例。 根據 rmzgrimes 的抱怨。 Back-patch 到 v13，因為它很容易。 討論：https://postgr.es/m/161215841824.14653.8969016349304314299@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/9522085ac917af66dba29939af328ae67300f10a

  • 修復 contrib/auto_explain 中的舊記憶體洩漏。 ExecutorEnd 鉤子在一個可能存在很長時間的上下文中被調用，而不是像我們認為的 executor 自己的每個查詢上下文。 因此，在產生 EXPLAIN 輸出時產生的任何垃圾都可能在多個查詢中累積。 如果 log_nested_statements 啟用，這可能導致驚人的洩漏，即使沒有它，我很驚訝以前沒有人抱怨。 為了修復，只需切換到 executor 的上下文，以便當 standard_ExecutorEnd 釋放 executor 狀態時，我們分配的任何東西都會被釋放。 我們不妨也刪除該代碼對 explain 輸出字串的零售 pfree； 這對於需求來說是可笑的不夠。 Japin Li，根據 Jeff Janes 的報告。 這個錯誤很舊，所以 back-patch 到所有支持的分支。 討論：https://postgr.es/m/CAMkU=1wCVtbeRn0s9gt12KwQ7PLXovbpM8eg25SYocKW3BT4hg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5c0f7cc5442108e113d4fb88c952329b467e2c6a

  • 移除 plpgsql 的 FOR 循環語句計數器的額外增量。 這在內部語句編號中留下了間隙，這不是非常有害的（否則我們早就注意到了），但也不是很好。 bbd5c207b 中的疏忽； backpatch 到 v12，它是在那裡引入的。 Pavel Stehule 討論：https://postgr.es/m/CAFj8pRDXyQaJmpotNTQVc-t-WxdWZC35V2PnmwOaV1-taidFWA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/dfcc46fe3030b0114b7a5715d5fa40819561c04b

  • 文件：一致地識別可以為零的 OID 目錄欄位。 並非所有可以包含零（表示“無參考”）的 OID 參考欄位都在 catalogs.sgml 中明確標記。 修復它，並嘗試使樣式更一致一些 --- 例如，在這些情況下一致地寫“zero”而不是“0”。 Joel Jacobson 和 Tom Lane 討論：https://postgr.es/m/4ed9a372-7bf9-479a-926c-ae8e774717a8@www.fastmail.com https://git.postgresql.org/pg/commitdiff/479331406e8403cc2e75d1082f8c613e7669c113

  • 在目錄中加入一些關於外鍵關係的知識。這遵循 commit dfb75e478 的精神，該 commit 建立了主鍵和唯一性約束，以提高系統目錄上施加的約束的可見性。雖然我們的目錄包含許多類似外鍵的關係，但它們並不完全遵循 SQL 語義，因為省略參考的慣例是寫零而不是 NULL。此外，我們在某些情況下有陣列，每個元素都應該是一個外鍵參考；SQL 沒有辦法對此建模。因此，我們無法建立實際的外鍵約束來描述這種情況。儘管如此，我們可以收集並使用關於這些關係的知識。因此，這個 patch 在目錄標頭檔中加入了註釋，以宣告外鍵關係。（BKI_LOOKUP 註釋涵蓋了簡單的情況，但我們之前沒有區分哪些欄位允許包含零；我們也需要新的標記來標記多欄位的外鍵參考。）然後，Catalog.pm 和 genbki.pl 被教導將這些資訊收集到一個新的生成標頭 "system_fk_info.h" 中的表格中。目前，唯一的使用者是一個新的 SQL 函數 pg_get_catalog_foreign_keys()，它將表格暴露給 SQL。oidjoins 回歸測試被重寫以使用 pg_get_catalog_foreign_keys() 來找出要檢查的欄位。除了移除對該測試腳本的手動維護需求之外，這還允許它涵蓋許多未被舊的基於 findoidjoins 的實現所檢查的關係。（截至此 commit，測試檢查了 217 個關係，而之前為 181 個。）討論：https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/62f34097c88433ef1f3de604714fe7e7024f2fdf

  • 淘汰 findoidjoins。在 commit 62f34097c 之後，我們不再需要這個工具。討論：https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ef3d4613c0204ab2b87ffa7e8e9551d74f932816

  • 移除 namespace 和 role OID 的特殊 BKI_LOOKUP 魔法。現在 commit 62f34097c 將 BKI_LOOKUP 註釋附加到目錄中的所有 namespace 和 role OID 欄位，沒有真正的理由保留魔法 PGNSP 和 PGUID 符號。放棄它們，轉而根據 genbki.pl 的正常模式來實現這些查詢。這意味著在目錄標頭中，BKI_DEFAULT(PGNSP) 變為 BKI_DEFAULT(pg_catalog)，這看起來更透明。BKI_DEFAULT(PGUID) 變為 BKI_DEFAULT(POSTGRES)，這可能較不明顯；但你可以查看 pg_authid.dat 以發現 POSTGRES 是啟動超級使用者的 nonce 名稱。這個改變也意味著如果我們需要在初始目錄資料中交叉引用除 POSTGRES 之外的任何其他內建角色，或除 pg_catalog 之外的任何其他內建 schema，我們可以這樣做。這裡沒有 catversion 的變更，因為 postgres.bki 的內容沒有實際變化。討論：https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ba0faf81c65ac99dd42ce192f3257d4d2231ea50

  • 避免在 prepared statement 中回滾時崩潰。如果使用 portal 來執行包含 ROLLBACK 的 prepared CALL 或 DO 語句，PortalRunMulti 會失敗，因為 portal 的語句列表被回滾清空。（由於語法不允許在 PREPARE 中使用 CALL/DO，因此到達這個問題的唯一簡單方法是透過擴展查詢協定，該協定將所有輸入視為 prepared statements。）由於資源管理問題，很難避免提前重置 portal，因此透過教導 PortalRunMulti 警惕 portal->stmts 突然變為 NIL 來解決這個問題。僅在 v13 和 HEAD 中觀察到崩潰（由於 commit 1cff1b95a 添加了額外的 portal->stmts）。但即使在那之前，涉及的程式碼也觸摸了一個 portal 不再擁有任何所有權的 List。在手頭的測試案例中，由於快取計畫上的另一個 refcount，該 List 仍然存在；但我遠不相信控制回到 PortalRunMulti 時，不可能刪除快取計畫。因此，回溯到添加巢狀交易的 v11。Thomas Munro 和 Tom Lane，根據 James Inform 的 bug #16811。討論：https://postgr.es/m/16811-c1b599b2c6c2d622@postgresql.org https://git.postgresql.org/pg/commitdiff/9624321ec502f4e4f4722290b358694049447f95

  • 修復 YA 增量排序錯誤。如果 switchToPresortedPrefixMode() 在一個 fullsort 群組的最後一個 tuple 檢測到批次邊界，則會發生錯誤。最初報告的症狀是“在有界排序中檢索到太多 tuple”錯誤，但在此 patch 之前，此處添加的測試案例只是默默地給出錯誤的答案。我 (tgl) 對於在沒有增量排序作者審查的情況下提交此 patch 感到不太高興，但他們似乎失聯了，而且我們正面臨發布截止日期。無論如何，這確實顯著地改善了一些情況。根據 Yoran Heling 的 bug #16846。回溯到引入增量排序的 v13。Neil Chen 討論：https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org https://git.postgresql.org/pg/commitdiff/82e0e29308dedbc6000e73329beb112ae7e1ad39

  • 修復 HashAgg 選擇性欄位溢出邏輯中的錯誤。Commit 230230223 教導 nodeAgg.c，當在一個過大的 hash aggregation 中將 tuples 從記憶體溢出時，它只需要溢出節點的 tlist 和 quals 中參考的輸入欄位。不幸的是，這是錯誤的：我們還必須儲存 grouping 欄位。在常見情況下，由於 grouping 欄位也出現在 tlist 中，因此錯誤被遮蔽了，但這不一定是真的。它不是真的的主要計畫類別似乎來自 semijoins ("WHERE outercol IN (SELECT innercol FROM innertable)")，其中 innercol 需要一個隱式提升才能與 outercol 進行比較。Grouping 欄位將是 "innercol::promotedtype"，但該表達式不會出現在 Agg 節點自己的 tlist 和 quals 中；只有裸 "innercol" 出現在 tlist 中。我花了很多時間尋找適合此的迴歸測試案例，但沒有取得太大的成功。如果 innercol 的不同值的數量大到足以發生溢出，planner 傾向於選擇非 HashAgg 計畫，至少對於在迴歸測試中使用是合理的的問題大小而言。因此，沒有新的迴歸測試。但是，此 patch 確實明顯地修復了最初報告的測試案例。根據來自 s.p.e (at) gmx-topmail.de 的報告。回溯到引入麻煩程式碼的 v13。討論：https://postgr.es/m/trinity-1c565d44-159f-488b-a518-caf13883134f-1611835701633@3c-app-gmx-bap78 https://git.postgresql.org/pg/commitdiff/0ff865fbe50e82f17df8a9280fa01faf270b7f3f

  • 禁止將繼承子資料表轉換為檢視表。 一般來說，繼承樹的成員必須是普通的資料表（或者，在較新的版本中，是外部資料表）。 ALTER TABLE INHERIT 拒絕建立在任一端具有檢視表的繼承關係。 當 DefineQueryRewrite 嘗試將一個關係轉換為檢視表時，它已經有檢查禁止對分割父表或子表以及傳統繼承父表執行此操作...但它忽略了檢查傳統繼承子表是否正在被轉換。 由於規劃器假設任何繼承子表都是資料表，這導致產生嘗試對檢視表執行物理掃描的計畫，導致失敗（甚至在較新的版本中崩潰）。 人們可以想像嘗試通過正常展開檢視表來支援這種情況，但由於重寫器在規劃器執行繼承展開之前運行，因此需要一些非常基本的重構才能使其成為可能。 系統的許多其他部分可能也無法很好地處理這種情況。 目前，先禁止它。 根據 Yang Lin 提出的錯誤 #16856。 回溯修補到所有支援的分支。（在 v10 之前的版本中，這包括回溯修補 commit 501ed02cf 中添加 has_superclass() 的部分。 或許缺少該基礎設施部分解釋了缺少檢查。） 討論： https://postgr.es/m/16856-0363e05c6e1612fd@postgresql.org https://git.postgresql.org/pg/commitdiff/dd705a039f6cd41921529fa4e971d70b224be052

  • 將 CTE 屬性標誌在複製 CTE 列表到規則中時傳播。 rewriteRuleAction() 忽略了這個步驟，儘管它小心地傳播了其他類似的標誌，例如 hasSubLinks 或 hasRowSecurity。 忽略傳輸 hasRecursive 目前只是表面上的問題，但忽略 hasModifyingCTE 是一個實際的錯誤，因為執行器肯定會查看它。 提議的測試案例僅在 v10 之後才會失敗，但由於執行器也在 9.x 中檢查 hasModifyingCTE，我懷疑可以設計一個在較舊的分支中失敗的測試案例。 考慮到發布截止日期臨近，我不打算花時間尋找更好的測試。 Greg Nancarrow 報告並提供修補程式，我進行了外觀上的更改。 討論： https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ed290896335414c6c069b9ccae1f3dcdd2fac6ba

  • 還原 "將 CTE 屬性標誌在複製 CTE 列表到規則中時傳播。"。 這會還原 commit ed290896335414c6c069b9ccae1f3dcdd2fac6ba 以及等效的回溯分支 commit。 問題比我想像的要微妙，而且遠非是新的問題，所以在發布截止日期之前不應該處理它。 我們會更仔細地考慮該怎麼做。 討論： https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d1d2979852538d7021cc809a40ef127d59747697

Michaël Paquier 推送了

Peter Eisentraut 推送了

Robert Haas 推送了

Heikki Linnakangas 推送了

  • 修正 COPY FROM 進度報告中的小錯誤。已處理的位元組數量的累計略有錯誤。在將更多資料載入到輸入緩衝區後，我們將緩衝區中的位元組數新增到總和中。但是在多位元組字元或轉義字元的情況下，緩衝區中可能會有來自先前載入的一些未處理位元組。這些位元組被計算了兩次。 https://git.postgresql.org/pg/commitdiff/2f86ab305e7fbc7b84960079551cf9cafd29684f

  • 修正 COPY FROM 中使用反斜線轉義多位元組字元的問題。如果在 TEXT 模式輸入中使用反斜線轉義多位元組字元，並且編碼是僅限於客戶端的編碼之一，其中第一個位元組之後的位元組可以在字元中「嵌入」ASCII 位元組，則我們沒有正確跳過該字元。在反斜線之後，我們只跳過了下一個字元的第一個位元組，因此如果它是一個多位元組字元，我們將嘗試將其第二個位元組作為單獨的字元處理。如果它是具有特殊含義的字元之一，例如 '\n'、'\r' 或另一個 '\'，則會導致問題。一個這樣的例子是 Big5 編碼中的位元組序列 '\x5ca45c2e666f6f'。它應該是 [反斜線][雙位元組字元][.][f][o][o]，但由於雙位元組字元的第二個位元組是 0x5c，因此我們錯誤地將其視為另一個反斜線。由於下一個字元是一個點，我們將其解析為複製結束標記，並拋出「複製結束標記已損壞」錯誤。向所有支援的版本進行回溯修補。審閱人：John Naylor, Kyotaro Horiguchi 討論：https://postgres.tw/message-id/a897f84f-8dca-8798-3139-07da5bb38728%40iki.fi https://git.postgresql.org/pg/commitdiff/c444472af5c202067a9ecb0ff8df7370fb1ea8f4

Peter Geoghegan 推送了

  • 強化 nbtree 頁面刪除。在索引刪除的第二階段新增額外的防禦性檢查，以偵測並回報在 VACUUM 期間發生的索引損毀，並避免 VACUUM 在更多情況下卡住。即使存在循環的兄弟連結鏈，此程式碼仍然不夠強固，儘管尚不清楚這是否真的重要。這是對 commit 3a01f68e 的後續工作。新的防禦性檢查依賴於一個假設，即對於任何給定的索引，在任何給定的時間點最多只能有一個 VACUUM 操作正在執行。移除一個舊的註解，該註解表明需要在此處考慮多個並行的 VACUUM。由於我們顯然在其他幾個地方都依賴相同的假設，因此這種擔憂現在似乎不太可能具有任何實際有效性。例如，在同一個函數中出現了更近期的註解（由 commit efada2b8e92 新增），這些註解也做出了相同的假設。另外，將 CHECK_FOR_INTERRUPTS() 添加到相關的程式碼路徑。與 commit 3a01f68e 添加的註解相反，實際上可以在此處處理中斷，至少在常見的葉子層級處理的情況下。我們僅在葉子層級單步執行時才對 leafbuf/target 頁面進行 pin。由於在 commit 3a01f68e 向同一區域添加強化後沒有收到投訴，因此沒有進行回溯修補。https://git.postgresql.org/pg/commitdiff/c34787f910585f82320f78b0afd53a6a170aa229

  • 為了保持一致性，重新命名可移除 xid 函數。GlobalVisIsRemovableFullXid() 現在更名為 GlobalVisCheckRemovableFullXid()。這與處理 TransactionId 值的函數的 FullTransactionId 等效項的一般慣例一致。現在它與附近的 GlobalVisCheckRemovableXid() 函數相符，該函數對使用 TransactionId 值的呼叫者執行相同的檢查。這是 commit dc7420c2c92 中的疏忽。討論：https://postgr.es/m/CAH2-Wzmes12jFNDcVgpU89Vp=r6uLFrE-MT0fjSWGsE70UiNaA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/617fffee8a6f350ff03069e2843ecd039ea06ccc

Thomas Munro 已推送

Etsuro Fujita 已推送

  • postgres_fdw: 修正 estimate_path_cost_size() 中的 assertion。 Commit 08d2d58a2 新增了一個 assertion，假設 foreign relation 的 retrieved_rows 估算值（用於透過 local stats 來評估預先排序的 foreign paths 的成本）在 estimate_path_cost_size() 中至少設定為一行，這是不正確的，因為如果 relation 是一個 tuples=0 的 foreign table，則在使用遠端估算時，該估算值將在該處設定為 0。根據 Alexander Lakhin 的錯誤 #16807。回溯修補至 v13，該 commit 在此版本中引入。作者：Etsuro Fujita 審閱者：Kyotaro Horiguchi 討論：https://postgr.es/m/16807-9fe4e08fbaa5c7ce%40postgresql.org https://git.postgresql.org/pg/commitdiff/5e7fa189ee92d5ecf42a295c336625d71bfe876d

Tatsuo Ishii 已推送

待處理的修補程式

Kyotaro HORIGUCHI 提交了另一個版本的修補程式，使其可以按照 X.509 規範使用 CRL（憑證撤銷清單）目錄。

Zeng Wenjing 提交了另一個版本的修補程式，以實作全域暫存表。

Scott Mead 提交了一個修補程式，允許將 cost_limit 重新計算到允許的最大值（目前為 10,000）。這具有讓使用者重新載入組態變更的效果，並且可以透過設定 cost_limit 或 cost_delay 來「加速」正在進行的 vacuum 作業。

Paul Martinez 提交了另一個版本的修補程式，以釐清 pg_hba.conf 規則拒絕的是邏輯或物理複製連線。

Thomas Munro 提交了另一個版本的修補程式，以使用全域屏障來修正 Windows 上的 DROP TABLESPACE，並使用條件變數來處理 ProcSignalBarriers。

Euler Taveira de Oliveira 提交了另一個版本的修補程式，以實作邏輯複寫的列篩選。

Aleksey Kondratov 和 Michaël Paquier 交換了修補程式，以啟用 CLUSTER、VACUUM FULL 和 REINDEX 來動態變更 tablespace。

Etsuro Fujita 提交了另一個版本的修補程式，以在 postgres_fdw 節點上實作非同步 Append。

Hou Zhijie 和 Greg Nancarrow 交換了修補程式，以新增一個 GUC 和功能來平行執行 DML。

Daniel Gustafsson 和 Jacob Champion 交換了修補程式，使其可以使用 NSS 作為 libpq 的 TLS 後端。

Heikki Linnakangas 提交了另兩個版本的修補程式，以在更大的區塊中執行 COPY FROM 編碼轉換。

Bruce Momjian 提交了另一個版本的修補程式，以實作金鑰管理。

John Naylor 提交了兩個版本的修補程式，以使用 SIMD 指令驗證 UTF-8。

Amit Kapila、Peter Smith 和 Takamichi Osumi 交換了修補程式，以啟用 tablesync worker 並行執行。

Pavel Stěhule 提交了另一個版本的修補程式，以實作 schema 變數。

Justin Pryzby 提交了一個修補程式，以移除已棄用的 v8.2 包含運算符。

Noah Misch 提交了一個修補程式，以修正 KeepFileRestoredFromArchive() 和 restartpoint 之間的競爭條件。

Peter Eisentraut 提交了一個修補程式，透過新增一個詳細訊息來顯示涉及的特定數字，以改進新的 hash 分區界限檢查錯誤訊息。

Iwata Aya 提交了另一個版本的修補程式，以向 libpq 新增追蹤功能。

Julien Rouhaud 提交了三個版本的修補程式，以允許 HEAP_XMAX_LOCK_ONLY 和 HEAP_KEYS_UPDATED 組合。先前此 hint bits 的組合被檢測為一種形式的損壞，但可以透過一些 SELECT ... FOR UPDATE 和 UPDATE 查詢的組合來獲得。

Atsushi Torikoshi 和 Fujii Masao 交換了修補程式，以將 wait_start 欄位新增至 pg_locks。

Greg Nancarrow 提交了另兩個版本的修補程式，以平行實作 INSERT ... SELECT。

Mark Rofail 提交了另四個版本的修補程式，以實作 foreign key 陣列。

Álvaro Herrera 提交了另一個版本的修補程式，以新增 pg_atomic_monotonic_advance_u64，並使用相同的方法使 LogwrtResult 成為原子操作。

David Rowley 提交了另一個版本的修補程式，以實作 Result Cache 節點，並使用相同的方法來快取來自 subplans 的結果。

Vigneshwaran C 提交了另一個版本的修補程式，以使用新的 pg_print_backtrace() 函數（可供資料庫超級使用者存取）來列印指定 postgres 程序的 backtrace。

Peter Eisentraut 向 pg_dump 提交了一個修補程式，將 const 修飾詞新增至 dump 函數的 info 參數，以釐清它們不會修改該引數。

Daniel Gustafsson 提交了另一個版本的修補程式，以支援在執行中的實例中啟用/停用 checksum。

Peter Smith 提交了一個修補程式，旨在修正一個 bug，該 bug 表現為 DROP TABLE 會破壞 sync worker relid。

Heikki Linnakangas 提交了另兩個版本的修補程式，以移除伺服器和 libpq 對舊 FE/BE 協定版本 2 的支援，並透過強制前瞻來簡化 COPY FROM 解析。

Mark Dilger 提交了另兩個版本的修補程式，以實作 pg_amcheck。

Tomáš Vondra 提交了另一個版本的修補程式，以實作 BRIN multi-range indexes。

Bharath Rupireddy 提交了 postgres_fdw 的另一個修訂版本的補丁，該補丁在 FDW 和全域層級增加了 keep_connections GUC，用於指示不要快取連線。

David Rowley 提交了另一個修訂版本的補丁，用於實作 tid 掃描，與現有的 tid 探測不同。

Bertrand Drouvot 提交了另一個修訂版本的補丁，用於在備用伺服器上實作最小邏輯解碼。

Bruce Momjian 提交了兩個修訂版本的補丁，旨在修復一個錯誤，該錯誤表現為在單個檢查點中出現多個完整頁面寫入。

Amit Langote 提交了另一個修訂版本的補丁，使對繼承樹的更新和刪除能夠更好地擴展。

Ronan Dunklau 和 Michaël Paquier 交換了補丁，以在 REINDEX CONCURRENTLY 上保留 attstattarget。

Shenhao Wang、Kyotaro HORIGUCHI 和 Hayato Kuroda 交換了補丁，以修復 ecpg 連接字串中的解析錯誤。

Dilip Kumar 提交了另外三個修訂版本的補丁，以提供一個新的介面來取得恢復暫停狀態。

Peter Smith 和 Amit Kapila 交換了補丁，以使 pg_replication_origin_drop 在並發刪除時安全。

Amit Langote 提交了另一個修訂版本的補丁，以防止在跨分割區更新期間進行 FDW 插入批處理。

Li Japin 提交了另一個修訂版本的補丁，以實作 ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION。

Stephen Frost 提交了另一個修訂版本的補丁，以改善自動清理和自動分析的日誌記錄。

Jacob Champion 提交了一個補丁來調整 Kerberos 測試。

Dilip Kumar 提交了另外兩個修訂版本的補丁，以實作表格的自定義壓縮方法。

Masahiro Ikeda 提交了另一個修訂版本的補丁，以將 WAL 寫入/fsync 統計資訊新增到 pg_stat_wal。

Justin Pryzby 提交了另一個修訂版本的補丁，使 CLUSTER 可以在分割區索引上工作。

Heikki Linnakangas 提交了一個補丁，使 psql 的 \copy 以更大的區塊將資料傳送到伺服器。

Kazutaka Onishi 提交了另外兩個修訂版本的補丁，以通常在外部表格上以及特別是在 PostgreSQL FDW 中實作 TRUNCATE。

Tom Lane 提交了另一個修訂版本的補丁，以修復 postgres_fdw 校對處理。

Pavel Stěhule 提交了另一個修訂版本的補丁，通過返回變數內容的文字值來增強 PL/pgsql 除錯 API。

Haiying Tang 提交了一個補丁，以支援 psql 中大寫字元輸入的 Tab 鍵自動完成功能。

Atsushi Torikoshi 提交了另一個修訂版本的補丁，以將計畫類型新增到 pg_stat_statements。

Takamichi Osumi 提交了另外兩個修訂版本的補丁，以新增表格同步工作者的測試。

Michaël Paquier 提交了另一個修訂版本的補丁，以將 PROCESS_TOAST 選項新增到 VACUUM。