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

PostgreSQL 每週新聞 - 2021 年 5 月 16 日

發布於 2021-05-17，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 5 月 16 日

安全性版本 13.3、12.7、11.12、10.17 和 9.6.22 已發布。請儘快升級。9.6 系列將於 2021 年 11 月 11 日停止接收修復。現在規劃主要版本升級。https://postgres.tw/about/news/postgresql-133-127-1112-1017-and-9622-released-2210/

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

五月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

本週的 PostgreSQL Weekly News 由 David Fetter 帶給您

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

已套用的修補程式

Tom Lane 推送了

  • 改進 pg_config_manual.h 中關於 USE_VALGRIND 的註解。這些註解給人一種印象，認為 USE_VALGRIND 對於 valgrind 測試來說並非真正必要。但這是錯誤的，正如我今天慘痛地學到的。討論：https://postgr.es/m/512778.1620588546@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8dc3d68cbe676deb5e74d1b1b565f57fffaf107e

  • 防止陣列下標計算中的整數溢位。雖然我們（大多）小心確保陣列的維度不夠大以至於導致整數溢位，但通常不檢查下限值。這會導致 lower_bound + dimension 溢位整數的情況。就陣列讀取而言，這似乎是無害的，除了下標名義上超過 INT_MAX 的陣列元素無法存取。但是，它會混淆各種陣列分配邏輯，從而導致記憶體踩踏的潛在可能。通過添加檢查來修復，確保陣列下限不夠大，以至於導致 lower_bound + dimension 溢位。（注意：這會導致不允許最後一個下標位置恰好為 INT_MAX 的情況。原則上，我們或許可以允許這種情況，但有很多計算 lower_bound + dimension 的程式碼需要調整。允許它似乎不值得麻煩/冒險。）在某種程度上獨立於此，array_set_element() 在檢查固定長度陣列的下標時，對可能的溢位粗心大意，從而創建了另一條記憶體踩踏的途徑。也修復了該問題。安全性：CVE-2021-32027 https://git.postgresql.org/pg/commitdiff/f02b9085ad2f6fefd9c5cdf85579cb9f0ff0f0ea

  • 修復 ON CONFLICT ... UPDATE tlists 中對 resjunk 欄位的錯誤處理。在 ON CONFLICT ... UPDATE 列表中擁有任何 resjunk 欄位是不常見的，但是當存在 MULTIEXPR_SUBLINK SubPlan 時，可能會發生這種情況。如果發生這種情況，ON CONFLICT UPDATE 程式碼路徑最終會儲存包含額外 resjunk 欄位值的元組。在短期內，這相當無害，但是如果將新欄位添加到表中，則這些值將變得可存取，如果它們與新欄位的資料類型不符，則可能會導致故障。由於缺少健全性檢查的影響，這沒有引起注意，其中包括：* 沒有交叉檢查提供給 heap_insert 或 heap_update 的元組是否與表格列類型匹配。雖然以合理的成本完全檢查它很困難，但是我們可以輕鬆地添加斷言，表明沒有太多的欄位。* execExprInterp.c 中的輸出欄位分配案例缺少對輸出欄位號碼的任何健全性檢查，考慮到對輸入欄位號碼進行了大量的斷言檢查，這似乎是一個疏忽。也在那裡添加斷言。* 我們未能將 nodeModifyTable 的 ExecCheckPlanOutput() 應用於 ON CONFLICT UPDATE tlist。這不會捕獲這個特定的錯誤，因為該函數被指定為忽略 resjunk 欄位；但是現在我們已經看到了這個錯誤，這似乎是一個糟糕的疏忽。在 HEAD 中，修復此問題的正確方法是使 ON CONFLICT UPDATE tlists 的處理方式與現在的常規 UPDATE tlists 相同，即不添加「SET x = x」條目，並使用 ExecBuildUpdateProjection 來評估 tlist 並將其與未設定欄位的舊值組合。這為 ExecBuildUpdateProjection 增加了一些複雜性，但允許從規劃器中刪除相當數量的現在已失效的程式碼。在後端分支中，最方便的解決方案似乎是 (a) 為實際匹配目標表格的 ON CONFLICT UPDATE 投影使用輸出槽，然後 (b) 發明 ExecBuildProjectionInfo 的變體，該變體可以被告知不儲存由 resjunk 欄位產生的值，因此它不會嘗試儲存到輸出槽的不存在的欄位中。（我們不能簡單地完全忽略 resjunk 欄位；必須對它們進行評估才能使 MULTIEXPR_SUBLINK 工作。）這適用於 v10。在 9.6 中，投影的工作方式大相逕庭，我們無法以較低的成本為它們提供這樣的選項。此修補程式的 9.6 版本通過在需要刪除 resjunk 欄位時插入 JunkFilter 來工作。此外，當嘗試在分割表格上執行 ON CONFLICT UPDATE 時，v11 及更高版本存在相反的問題。通過進一步的疏忽，adjust_partition_tlist() 在重新排序 ON CONFLICT UPDATE tlist 以匹配分割時丟棄了 resjunk 欄位。這意外地阻止了儲存虛假元組的問題，但代價是 MULTIEXPR_SUBLINK 案例不起作用，如果必須更新多個列，通常會崩潰。通過在該常式中保留 resjunk 欄位來修復。 （我未能抵禦在那裡添加更多斷言以及進行一些小的程式碼美化的誘惑。）根據 Andres Freund 的報告。向所有支援的分支進行回溯修補。安全性：CVE-2021-32028 https://git.postgresql.org/pg/commitdiff/049e1e2edb06854d7cd9460c22516efaa165fbf8

  • 用 C 程式碼替換 opr_sanity 測試的 binary_coercible() 函數。opr_sanity 的 binary_coercible() 函數一直旨在匹配剖析器對二進制強制轉換的概念，但它也一直是非常糟糕的剖析器實際規則的近似值（如 IsBinaryCoercible() 中所體現的）。到目前為止，這還沒有困擾我們，但是可以預見它最終會困擾我們。現在還出現了在 clobber-cache-always 測試中，以 plpgsql 實現此檢查的效能絕對糟糕。（或許我們可以對此做些什麼，但是我懷疑這只是意味著 plpgsql 正在最大限度地利用目錄緩存。）因此，讓我們用 C 填充程式替換 binary_coercible()，該填充程式直接調用 IsBinaryCoercible()，從而消除語義風險和效能問題。regress.c 的大多數 C 函數都在 create_function_1 中宣告，但是我們不能簡單地將其移動到 opr_sanity/type_sanity 之前，因為這些測試會抱怨由此產生的 shell 類型。我選擇將其拆分為 create_function_0 和 create_function_1。由於 create_function_0 現在作為並行組的一部分執行，而 create_function_1 不執行，因此將後者簡化為僅建立 opr_sanity 和 type_sanity 會抱怨的那些函數。為了在第二個並行測試組中為 create_function_0 騰出空間，請將 tstypes 移動到第三個並行組。順便說一句，清理 parallel_schedule 和 serial_schedule 之間的一些排序偏差。討論：https://postgr.es/m/292305.1620503097@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6303a5730914dfe6ef2709b28b225553315c573c

  • 移除個別的 serial_schedule 測試清單。維護兩份迴歸測試腳本清單已被證明容易出錯且令人煩惱。我們可以透過使用 "--max_connections=1" 執行 parallel_schedule 來達到 serial_schedule 的效果；所以執行此操作並移除 serial_schedule。這會導致進度輸出的外觀差異，但似乎不值得為了避免這種情況而重構 pg_regress。討論：https://postgr.es/m/899209.1620759506@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/1df3555acc78dedc3ca25eb5e83649b3da1f298f

  • 修正 vcregress.pl 中 "--max-connections" 的古老拼寫錯誤。我複製了現有的拼寫 "--max_connections"，但那是錯誤的 :-(。顯然，在這個腳本中設定 $ENV{MAX_CONNECTIONS} 從未真正起作用過。鑑於沒有人抱怨，可能不值得回溯修補程式。依照建置農場 (buildfarm)。討論：https://postgr.es/m/899209.1620759506@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0b85fa93e4575183aa5a71ebe3c6bae8d97704ed

  • 在 CLOBBER_CACHE_ALWAYS 模式下縮短 privileges.sql 測試的執行時間。 privileges 迴歸測試中的幾個查詢導致規劃器將 plpgsql 函數 "leak()" 應用於 atest12.b 直方圖的每個元素。由於 commit 0c882e52a 將該直方圖的大小增加到 10000 個條目，因此該測試調用了該函數超過 100000 次，這在 clobber-cache-always 模式下花費了絕對不合理的時間。但是，沒有真正的理由說明它必須是一個 plpgsql 函數：就此測試而言，重要的是它沒有被標記為 leakproof。因此，我們可以將 plpgsql 實作替換為直接呼叫 int4lt，它具有相同的行為並且速度快幾個數量級。預計這將減少 CCA 動物的建置農場週期時間數小時。它在正常的建置中也有一些積極的影響，儘管這可能在雜訊中消失。回溯修補到 v13，其中 0c882e52a 引入。討論：https://postgr.es/m/575884.1620626638@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e135743ef07ea59088d09c459f41ee2eaabe95c3

  • v14 的初始 pgindent 和 pgperltidy 執行。還有 "make reformat-dat-files"。唯一值得注意的更改是 pgindent 搞砸了 launcher.c 的 struct LogicalRepWorkerId 的格式，這讓我注意到該結構已不再使用，所以我直接將它刪除了。https://git.postgresql.org/pg/commitdiff/def5b065ff22a16a80084587613599fe15627213

  • 對目錄資料執行預先發布的整理。執行 renumber_oids.pl 以向下移動高編號的 OID，如 RELEASE_CHANGES 指定的預先 beta 任務。作為參考，該命令是 ./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6150 https://git.postgresql.org/pg/commitdiff/14472442861ca95cc9158518acdedf740c4bff55

  • 文件：更新 bki.sgml 關於 OID 範圍的敘述。Commit ab596105b 忽略了使文檔與代碼相符。https://git.postgresql.org/pg/commitdiff/1f9b0e6938054515b8c9df545437c3d347eed683

  • 在 system_constraints.sql/system_functions.sql 中使用雙倍空格分隔指令。 之前，後端在讀取 system_constraints.sql 時報告的任何錯誤都會報告整個文件，而不僅僅是它正在處理的特定指令。（問我怎麼知道的。）同樣，會有 system_functions.sql 的一些區塊會被讀取為一個指令，如果那裡發生任何錯誤，那將會很煩人。system_constraints.sql 的問題是 commit dfb75e478 的疏忽。 我沒有嘗試追蹤 system_functions.sql 中格式不良的開始位置，但它肯定與該文件開頭的建議相反。https://git.postgresql.org/pg/commitdiff/7dde98728a2ef6d48ef397ee783dd130fdb34e6b

  • 重構 CHECK_FOR_INTERRUPTS() 以增加靈活性。 分割 CHECK_FOR_INTERRUPTS() 以提供一個額外的巨集 INTERRUPTS_PENDING_CONDITION()，它只測試是否有中斷掛起，而不嘗試服務它。 這在呼叫者知道中斷被阻塞的情況下很有用，並且想知道是否值得取消阻塞它們。 另新增 INTERRUPTS_CAN_BE_PROCESSED()，它指示是否可以依賴 CHECK_FOR_INTERRUPTS() 來清除掛起的中斷。 此 commit 實際上沒有添加任何新巨集的使用，但後續的錯誤修復將會這樣做。 回溯修補到所有支援的分支，以提供該修復的基礎架構。Alvaro Herrera 和 Tom Lane 討論：https://postgr.es/m/20210513155351.GA7848@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/e47f93f981ccb70b4c4c5a0966e5fa0400e11a7e

  • 修復 spgdoinsert() 中的查詢取消處理。 知道有缺陷的 opclass 可能會導致無限插入迴圈，spgdoinsert() 旨在允許查詢取消來中斷其迴圈。 然而，這實際上從未起作用，因為在第一次迭代之後的迭代中，我們將持有緩衝區鎖定，這將導致 InterruptHoldoffCount 為正，從而阻止中斷服務。 為了修復，請檢查是否有中斷掛起，如果有，則跳出插入迴圈，並在釋放緩衝區後為中斷提供服務。 如果它確實是一個查詢取消，那麼這件事就結束了。 如果它是一個非取消中斷的原因，請利用現有條款來重試整個插入。（這並不像看起來那麼浪費，因為我們已經建立的任何上層索引元組都應該可以在下次嘗試中使用。） 雖然現有的發佈分支中沒有已知的此類錯誤實例，但將其回溯修補到所有支援的分支仍然是一個好主意，因為如果確實發生迴圈，行為相當糟糕 --- 不僅不可取消，而且會迅速消耗記憶體，直至出現 OOM 故障。 無論如何，此代碼肯定沒有按預期工作。 根據 Dilip Kumar 的報告。 討論：https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/eb7a6b9229432dcb791f4bf0c44fe97bab661134

  • 防止 spgdoinsert() 中發生無限插入迴圈。過去，我們僅依賴於宣告 longValuesOK 的運算子類別，最終會縮短葉節點的值，使其能符合索引頁面的大小。但自從引入 INCLUDE 欄位支援 (commit 09c1c6ab4) 後，這種方式就失效了，因為光是 INCLUDE 欄位就可能佔用超過一個頁面的空間，這表示無論如何壓縮葉節點資料都無法完成任務。至少對於 spgtextproc.c 來說，這會導致無限迴圈，因為 spgtextproc.c 無法在無法再縮短葉節點資料時拋出錯誤。為了修正此問題，同時又不影響原本可以正常運作的情況，我們在 spgdoinsert() 中添加了邏輯，以驗證每次「選擇」步驟後，葉節點的 tuple 大小是否正在減少。某些運算子類別可能不會在每個週期都減少大小，而且在任何情況下，tuple 大小的對齊進位都可能會掩蓋掉微小的減少量。因此，我們允許最多 10 個週期沒有額外的節省，然後才拋出錯誤。（這個數字可能需要調整，但目前看來相當寬裕。）既然我們已經開發了這個邏輯，就讓我們將它回溯修補。回溯分支沒有 INCLUDE 欄位需要擔心，但這似乎是對抗運算子類別中可能存在的錯誤的好方法。我們已經知道此處的無限迴圈非常令人不愉快，因此擁有防禦機制似乎比破壞東西的風險更重要。（請注意，spgtextproc.c 實際上是唯一已知的具有 longValuesOK 支援的運算子類別，因此無論如何，對於已知的非核心運算子類別來說，這一切都是沒有意義的。）根據 Dilip Kumar 的報告。討論：https://postgr.es/m/CAFiTN-uxP_soPhVG840tRMQTBmtA_f_Y8N51G7DKYYqDh7XN-A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c3c35a733c77b298d3cf7e7de2eeb4aea540a631

  • 在釋放 BackgroundWorkerSlots 時，更加注意障礙 (barriers)。ForgetBackgroundWorker 完全沒有任何記憶體障礙，而 BackgroundWorkerStateChange 有一個，但在障礙之後卻無法解釋地對 slot->in_use 進行了額外的操作。AFAICS，規則必須是障礙緊接在設定或清除 slot->in_use 之前。看起來早在 9.6 撰寫 ForgetBackgroundWorker 時，可能存在一些不需要障礙的情況，但我對此不太相信 --- bgw_notify_pid 的載入在呼叫者中似乎不能保證沒有記憶體排序問題。所以也修補 9.6。很可能這不能修復 Intel 硬體上的任何可觀察到的錯誤，但具有較弱記憶體排序規則的機器可能會在此處遇到問題。討論：https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/30d8bad494ad1f604295033e4f4de4b8f258fe74

Michaël Paquier 推出了

Thomas Munro 推出了

Bruce Momjian 推送了

Peter Eisentraut 推送了

David Rowley 推送了

Andrew Dunstan 推送了

Fujii Masao 推送了

Etsuro Fujita 推送了

  • 修正 EXPLAIN ANALYZE 對於支援非同步節點的問題。 對於與 postgres_fdw 關聯的支援非同步 ForeignScan 節點的 EXPLAIN ANALYZE 僅透過使用從節點的回呼呼叫的 ExecProcNode() 的檢測來完成，導致以下問題： 1) 如果要掃描的遠端表為空，則即使執行了節點，該命令也會錯誤地將該節點視為「從未執行過」，因為在這種情況下，ExecProcNode() 根本沒有從節點的回呼中呼叫。 2) 該命令無法收集節點中完成的 ExecProcNode() 以外的其他事情的計時，例如為節點的遠端查詢建立游標。 為了修正這些問題，為支援非同步節點添加檢測，並相應地修改 postgres_fdw。 我在提交 27e1f1456 中的疏忽。 同時，更新 execnodes.h 中 AsyncRequest 結構的註解以及 fdwhandler.sgml 中 ForeignAsyncRequest API 的文件，以符合 nodeAppend.c 中 ExecAsyncAppendResponse() 中的程式碼，並修正 nodeAppend.c 中註解的錯字。 根據 Andrey Lepikhov 的報告，雖然我沒有使用他的修補程式。 Reviewed-by: Andrey Lepikhov Discussion: https://postgr.es/m/2eb662bb-105d-fc20-7412-2f027cc3ca72%40postgrespro.ru https://git.postgresql.org/pg/commitdiff/a363bc6da96b14d27e1cae1bae97242eb6ade5e6

  • 防止直接修改外部資料表的非同步執行。提交 27e1f1456 和 86dc90056（兩者是獨立討論的）會在啟用非同步執行的情况下執行繼承的外部 UPDATE/DELETE 查詢時導致崩潰。在這種情況下，Append 節點（Append node）的子節點（它是 ModifyTable 節點的直接/間接子節點）會被重寫，以便透過 postgresPlanDirectModify() 直接修改外部資料表。由於直接修改是以非同步方式執行的，但目前非同步執行不支援這種方式。透過在該函數中停用直接修改的非同步執行來修復此問題。作者：Etsuro Fujita 審閱者：Amit Langote 討論：https://postgr.es/m/CAPmGK158e9sJOfuWxfn%2B0ynrspXQU3JhNjSCbaoeSzMvnga%2Bbw%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/a784859f4480ceaa05a00ca35311071ca33483d1

Álvaro Herrera 推送了

Amit Kapila 推送了

Alexander Korotkov 推送了

Peter Geoghegan 推送了

待處理的補丁

Amit Langote 發送了另一個修訂版的補丁，以允許在跨分割區更新期間批次插入。

Nitin Jadhav 發送了一個補丁，以使 src/backend/utils/activity/backend_status.c 中註解中的檔案路徑與實際檔案路徑匹配。

Bharath Rupireddy 發送了一個補丁，以使 PostgreSQL FDW 快取連線函數測試更有意義。

Thomas Munro 發送了一個補丁，以覆蓋 HASH_REMOVE 釋放的記憶體，並避免在釋放本地鎖定後存取它們。

Andres Freund 發送了一個補丁，以在 walreceiver 中清零部分頁面。

Peter Smith 發送了一個補丁，以確保 GetSubscriptionRelations 僅宣告 1 個掃描鍵。

Vigneshwaran C 發送了另三個修訂版的補丁，以在邏輯複製訊息描述中包含使用的實際資料類型。

Tang 發送了另三個修訂版的補丁，以使 psql 中 DELETE FORM 和 INSERT INTO 的 Tab 鍵完成保持一致。

Vigneshwaran C 發送了另三個修訂版的補丁，以使錯誤訊息更能提供有關實際錯誤的資訊。

Kyotaro HORIGUCHI 發送了另兩個修訂版的補丁，以根據 recoveryTargetTLI 正確設定 expectedTLEs。

Etsuro Fujita 發送了另一個修訂版的補丁，以修復能夠進行非同步處理的節點的 EXPLAIN ANALYZE。

Hou Zhijie 發送了另一個修訂版的補丁，以檢查 fmgr_info 中的 UDF 並行安全性、修復測試案例中的 UDF 並行安全性標籤、檢查 fmgr_info 中的內建函數並行安全性以及修復測試案例中的內建並行安全性標籤。

Honza Horak 發送了一個補丁，以修復 Python 3.10 的子交易測試。

Masahiko Sawada 發送了另一個修訂版的補丁，以引入外部交易的交易管理器，並使用相同的管理器來處理涉及它們的兩階段提交。

Masahiro Ikeda 發送了另兩個修訂版的補丁，以提高報告 wal 統計資料的效能。

侯志杰提交了兩個版本的補丁，使使用者可以宣告一個資料表允許平行資料修改，啟用平行 select for insert，實作一個工具函式 pg_get_parallel_safety(regclass)，該函式返回 (objid, classid, parallel_safety) 的紀錄，代表決定指定資料表平行安全性的物件的平行安全性，並更新迴歸測試以包含相同內容。

Pavel Stěhule 提交了兩個版本的補丁，以實作綱要變數。

Pavel Stěhule 提交了另一個版本的補丁，使 pg_dump 可以從檔案讀取資料表名稱。

Pavel Stěhule 提交了另一個版本的補丁，使 psql 中的 \watch 可以指定單獨的分頁程式。

曾文靜提交了另一個版本的補丁，以實作全域臨時資料表。

Tom Lane 提交了另一個版本的補丁，以使用固定範圍檢查替換 pg_depend PIN 條目。

Atsushi Torikoshi 提交了一個補丁，添加了一個 pg_log_current_plan(pid) 函式，允許使用者取得目前正在執行的查詢的計畫。

Mark Dilger 提交了另一個版本的補丁，將 GUC 變數的設定委派給一些新建立的 ROLE。

Michail Nikolaev 提交了兩個版本的補丁，以在備用伺服器上添加對索引 LP_DEAD hint bits 的完整支援。

Amul Sul 提交了兩個版本的補丁，以實作 ALTER DATABASE READ {ONLY | WRITE}。

Vigneshwaran C 和 Bharath Rupireddy 交換了補丁，以澄清 ALTER SUBSCRIPTION ... DROP PUBLICATION 的訊息和文件。

Ranier Vilela 提交了一個補丁，以修復 src/backend/commands/tablecmds.c 中的顯式 NULL 指標解參考。

Michaël Paquier 提交了一個補丁，添加了 vacuum_cleanup_index_scale_factor GUC。

Vigneshwaran C 提交了兩個版本的補丁，旨在修復一個錯誤，該錯誤表現為訊息文字失敗，方法是檢查 pg_replication_slot 中的 active 欄位，而不是 pg_stat_replication，pg_replication_slot 測試更可靠。

Bharath Rupireddy 提交了一個補丁，以重新措辭平行 VACUUM 的錯誤訊息和文件。

Nathan Bossart 提交了一個補丁，允許在 pg_hba.conf 中指定直接的角色成員關係。

Peter Smith 和 Ajin Cherian 交換了補丁，以支援兩階段交易的邏輯解碼。

Peter Geoghegan 提交了一個補丁，以考慮在 vacuumlazy.c 的第一次掃描期間觸發 failsafe。

Amit Langote 提交了一個補丁，以修復 pgoutput tupeconv map 洩漏。

Kyotaro HORIGUCHI 提交了一個補丁，以將有關大括號的錯誤與它們的名稱相匹配。

Vigneshwaran C 提交了三個版本的補丁，以將 ALTER SUBSCRIPTION SET 選項 streaming 和 binary 的 Tab 鍵自動完成添加到 psql。

Ranier Vilela 提交了兩個版本的補丁，以修復 src/timezone/zic 中可能發生的記憶體損壞。

Michaël Paquier 提交了另一個版本的補丁，以將 pg_upgrade 的測試重寫為 TAP 測試。

Nitin Jadhav 和 Justin Pryzby 交換了補丁，以從 create_list_bounds 中刪除額外的記憶體分配，將 PartitionListValue 和 create_hash_bounds PartitionHashBound 分配為單個區塊，批量分配 datum 陣列以避免 palloc 開銷，並在 create_range_bounds 中 pfree() 中間結果。

Tom Lane 提交了兩個版本的補丁，旨在修復一個錯誤，該錯誤表現為 prion 失敗，並顯示錯誤：pg_toast_2619 中 toast 值 14334 缺少區塊號碼 0。

Tatsuo Ishii 提交了兩個版本的補丁，以修復 README.barrier 中的錯字。

Nitin Jadhav 提交了一個補丁，以支援 to_char() 中的 tzh_tzm 模式。