2024年11月21日: PostgreSQL 17.2, 16.6, 15.10, 14.15, 13.18, 和 12.22 版本已發佈！

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

發布於 2021-04-05 由 PWN
PWN

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

本週人物: https://postgresql.life/post/jan_karremans/

PostgreSQL 產品新聞

Ora2Pg 21.1 發布，這是一個將 Oracle 資料庫遷移到 PostgreSQL 的工具。 https://github.com/darold/ora2pg/blob/master/changelog

pgtt 2.3 發布，這是一個實現全域臨時表的擴展。 https://github.com/darold/pgtt/releases/tag/v2.3

SB Data Generator 發布，這是一個用於產生和填充測試資料的 GUI 工具。 SB Data Generator

四月份 PostgreSQL 職缺

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

PostgreSQL 新聞

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

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

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

已套用的修補程式

David Rowley 推送了

  • 如果 PathTarget 和 RestrictInfos 包含 volatile 函數，則進行緩存。 這裡的目的是減少 contain_volatile_functions() 的重複工作，方法是在第一次為 PathTargets 和 RestrictInfos 調用 contain_volatile_functions() 時，緩存它們是否包含任何 volatile 函數。 以後對這些節點的任何調用都只使用緩存的值，而無需再次麻煩地遞迴檢查子節點。 感謝 Tom Lane 的想法。 代碼中任何對 PathTarget 或 RestrictInfo 進行更改的位置，如果這些更改可能改變 volatility 檢查的結果，則必須將緩存的值改回 VOLATILITY_UNKNOWN。 contain_volatile_functions() 是唯一負責將緩存值設置為 VOLATILITY_VOLATILE 或 VOLATILITY_NOVOLATILE 的代碼。 一些現有代碼確實受益於這種額外的緩存，但是，此更改主要針對即將發布的修補程式，該修補程式必須在連接搜尋期間檢查 volatility。 在連接搜尋包含多個關係時，在這種情況下重複進行 volatility 檢查可能會變得非常昂貴。 作者：David Rowley 討論：https://postgr.es/m/3795226.1614059027@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/f58b230ed0dba2a3d396794a2ec84541e321d92d

  • 調整每個 worker 並行循序掃描資料結構的設計。 允許在並行循序掃描期間儲存每個 worker 記憶體的資料結構的設計並不理想。 56788d215 中的工作需要額外的資料結構，以允許 worker 記住在並行循序掃描期間已分配給它們進行處理的頁面範圍。 該 commit 向 TableScanDescData 添加了一個 void 指標欄位，以允許 heapam 儲存每個 worker 的分配資訊。 但是，將欄位放在那裡沒有多大意義，因為我們有 AM 特定的結構體來實現該目的，例如 HeapScanDescData。 在這裡，我們從 TableScanDescData 中刪除 void 指標欄位，並為此目的向 HeapScanDescData 添加一個專用欄位。 以前，我們還為所有掃描分配了此並行 worker 資料的記憶體，無論它是否是並行掃描。 對於非並行掃描來說，這只是一種浪費的分配，因此在這裡我們使分配取決於掃描是否為並行。 此外，還添加了先前缺少的 pfree() 以釋放 heap_endscan() 中的每個 worker 資料。 回報者：Andres Freund 審閱者：Andres Freund 討論：https://postgr.es/m/20210317023101.anvejcfotwka6gaa@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/af527705edc3fd0b335264d17e0521c05edc5cca

  • 允許 simplehash.h 的使用者執行直接刪除。 以前，simplehash.h 僅公開了一種使用雜湊表鍵執行雜湊表刪除的方法。 這意味著刪除函數必須執行雜湊查找才能找到要刪除的條目。 在這裡，我們添加了一個新函數，以便 simplehash.h 的使用者可以使用條目指標直接執行雜湊刪除，從而節省雜湊查找。 即將發布的使用 simplehash.h 的修補程式已經執行了雜湊查找，因此已經具有條目指標。 此更改將允許該修補程式中的代碼執行雜湊刪除，而無需 simplehash.h 中的代碼執行額外的雜湊查找。 作者：David Rowley 審閱者：Andres Freund 討論：https://postgr.es/m/CAApHDvqFLXXge153WmPsjke5VGOSt7Ez0yD0c7eBXLfmWxs3Kw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ff53d7b159b93ce9fc884897f9d96b97744781e2

  • 修復 unistr 函數中的編譯器警告。 一些編譯器沒有意識到 elog/ereport ERROR 不會返回。 https://git.postgresql.org/pg/commitdiff/efd9d92bb39c74c2aded64fc08e2d601ce20c39d

  • 允許 estimate_num_groups() 傳回關於估計的更多細節。 在這裡，我們向 estimate_num_groups() 添加了一個新的輸出參數，以允許它將有關估計的其他可能有用資訊通知呼叫者。 新的輸出參數是一個結構體，目前只包含一個帶有一組標誌的欄位。 這樣做是為了避免將標誌作為輸出參數，以便在我們想要傳回不適合儲存在標誌欄位中的更多資訊時，無需在以後更改函數的簽名。 看起來很合理的是，有一天規劃器想要了解有關估計的更多資訊。 例如，估計是從多少個單獨的統計資料集產生的？ 如果我們想在產生計劃時同時考慮風險和成本，則規劃器可能想要考慮這一點。 目前，我們只在標誌欄位中設置 1 個標誌。 這表示估計是否回退到在估計的任何部分中使用硬編碼的常量。 如果設置了此選項，呼叫者可能希望更改其行為，這使他們能夠這樣做。 如果呼叫者對獲取有關估計的任何其他資訊沒有興趣，則可以將標誌指標作為 NULL 傳遞。 我們在這裡沒有添加這些標誌的任何實際用法。 一些後續 commit 將使用此功能。 此外，我們也沒有進行任何更改來添加對 clauselist_selectivity() 和 clauselist_selectivity_ext() 的支援。 但是，如果將來需要此功能，那麼添加在此處的相同結構體應該可以用作這些函數的新輸出參數。 作者：David Rowley 討論：https://postgr.es/m/CAApHDvqQqpk=1W-G_ds7A9CsXX3BggWj_7okinzkLVhDubQzjA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ed934d4fa30f0f94e6f7125ad2154e6a58d1c7f7

  • 新增結果快取執行器節點。這裡我們新增一個名為「結果快取」（Result Cache）的新執行器節點類型。規劃器可以在計畫中包含此節點類型，讓執行器快取參數化巢狀迴圈聯結內部（inner side）的結果。 這樣一來，就能為特定參數集合快取元組，以便在節點再次看到相同的參數值時，直接返回快取的元組，而無需重新掃描聯結的內部。 在內部，結果快取使用雜湊表，以便快速找到先前已快取的元組。 對於某些資料集，這可以顯著提高聯結的效能。 使用此新節點類型的最佳情況是聯結問題中，來自聯結內部的很大一部分元組在聯結外部（outer side）沒有聯結夥伴。 在這種情況下，雜湊聯結將不得不雜湊永遠不會被查詢的值，從而使雜湊表膨脹，並可能導致多批次處理。 合併聯結將不得不跳過所有不匹配的列。 如果我們使用帶有結果快取的巢狀迴圈聯結，那麼我們只會快取在聯結外部至少有一個聯結夥伴的元組。 當被查詢的相異值較少，且每個值的查詢次數較多時，使用帶有結果快取的參數化巢狀迴圈的優勢會增加。 此外，雜湊探測來查詢快取的速度可能比雜湊聯結中的雜湊探測快得多，因為結果快取的雜湊表通常比雜湊聯結的雜湊表小得多，這是因為結果快取只快取有用的元組，而不是來自聯結內部的所有元組。 當雜湊聯結的雜湊表不再適合 CPU 的 L3 快取，但結果快取的雜湊表可以時，這種雜湊探測效能的差異會更為顯著。 每次雜湊探測對雜湊桶的表面「隨機」存取，可能會導致大型雜湊表的 L3 快取命中率很差。 較小的雜湊表通常效能更好。 用於快取的雜湊表會限制自身大小，不超過 work_mem * hash_mem_multiplier。 我們為此快取維護一個金鑰的 dlist，當我們新增新的元組並意識到我們已經超過了記憶體預算時，我們會從最近最少使用的快取條目開始逐出，直到我們有足夠的記憶體將新的元組新增到快取為止。 對於參數化巢狀迴圈聯結，我們現在考慮在巢狀迴圈節點及其內部節點之間使用這些結果快取節點之一。 我們根據成本來判斷這是否可能有用，成本主要取決於預期的快取命中率。 估計快取命中率取決於對巢狀迴圈參數有良好的相異值估計。 目前，規劃器只會考慮對參數化巢狀迴圈聯結使用結果快取。 這適用於正常的聯結，也適用於 LATERAL 類型的子查詢聯結。 未來可以使用這個新節點進行其他用途。 例如，快取來自相關子查詢的結果。 但是，由於在外部計畫上取得相異值估計以計算估計的快取命中率存在一些困難，因此這裡沒有這樣做。 目前，我們在規劃外部計畫之前規劃內部計畫，因此沒有好的方法知道結果快取是否有用，因為在生成外部計畫之前，我們無法估計子計畫將被呼叫的次數。 這裡新增的功能是在聯結搜尋期間，新引入對 estimate_num_groups() 傳回值的依賴。 以前，在聯結搜尋期間，我們只需要執行選擇性估計。 透過這次提交，我們需要使用 estimate_num_groups() 來估計結果快取的命中率。 簡單來說，如果我們預期有 10 個相異值，並且我們預期有 1000 個外部列，那麼我們將估計命中率為 99%。 由於與掃描巢狀迴圈聯結內部底層節點相比，快取命中非常便宜，因此這將顯著降低規劃器聯結的成本。 然而，很容易在這裡看到，當 estimate_num_groups() 錯誤地傳回一個遠低於實際相異值數量的數值時，事情會變得糟糕。 如果發生這種情況，可能會導致我們使用帶有結果快取的巢狀迴圈聯結，而不是其他聯結類型，例如合併或雜湊聯結。 我們對相異值的估計過去一直是問題的來源，因此這裡對它們的額外依賴可能會導致規劃器選擇比具有此功能之前更慢的計畫。 當已經聯結了多個表，或者當 WHERE 子句過濾掉一組與我們正在估計相異值數量的表達式相關的值時，相異值的估計也很難準確估計。 目前，我們在查詢規劃期間對結果快取執行的成本計算，確實對相異值估計的準確性寄予了相當多的信任。 當這些估計準確時，我們通常會看到包含結果快取的計畫執行時間更快。 然而，在現實世界中，我們可能會發現我們需要更改成本計算，以減少對相異值估計準確性的信任，或者甚至預設停用此功能。 當我們教導查詢規劃器新的技巧時，總會存在一定的風險，它可能會在錯誤的時間決定使用該新技巧，並導致回歸。 使用者可以透過使用 enable_resultcache GUC 關閉該功能來獲得舊的行為。 目前，預設情況下啟用此功能。 我們是否會為發布維護該設定還有待觀察。 此外，「結果快取」是我在開始編寫修補程式時能想到的這個新節點的最佳名稱。 沒有人似乎強烈不喜歡這個名稱。 有幾個人確實提出了其他名稱，但在關於名稱的簡短討論中，沒有其他名稱似乎佔據主導地位。 讓我們允許 Beta 測試階段看看目前的名稱是否能讓足夠的人滿意。 如果對更好的名稱達成共識，我們可以在發布之前更改它。 請參閱下面的第二個討論連結，以了解關於「結果快取」名稱的討論。 作者：David Rowley 審閱人：Andy Fan、Justin Pryzby、Zhihong Yu 測試人：Konstantin Knizhnik 討論：https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com 討論：https://postgr.es/m/CAApHDvq=yQXr5kqhRviT2RhNKwToaWr9JAN5t+5_PzhuRJ3wvg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b6002a796dc0bfe721db5eaa54ba9d24fd9fd416

  • 還原 b6002a796。這會移除「新增結果快取執行器節點」。 許多 Buildfarm 動物強調，快取命中和未命中的追蹤似乎出現了一些奇怪的問題。 目前尚不清楚問題是什麼，因為計畫的其他部分表明快取確實正常工作，只是命中和未命中的報告為 0。 現在 Buildfarm 如此崩潰尤其糟糕，因此在更多動物變紅之前還原。 討論：https://postgr.es/m/CAApHDvq_hydhfovm4=izgWs+C5HqEeRScjMbOgbpC-jRAeK3Yw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/28b3e3905c982c42fb10ee800e6f881e9742c89d

  • 新增結果快取執行器節點（版本 2）。 這裡我們新增一個名為「Result Cache」（結果快取）的新執行器節點類型。 規劃器可以在計畫中包含此節點類型，讓執行器快取參數化巢狀迴圈聯結內側的結果。 這樣可以快取參數集合的元組，以便在節點再次看到相同的參數值時，可以直接傳回快取的元組，而無需重新掃描聯結的內側。 在內部，結果快取使用雜湊表，以便快速找到先前已快取的元組。 對於某些資料集，這可以顯著提高聯結的效能。 使用這種新節點類型最好的情況是，聯結問題中聯結內側的大部分元組在聯結外側沒有聯結夥伴。 在這種情況下，雜湊聯結必須雜湊從未被查詢的值，從而使雜湊表膨脹，並可能導致多批次處理。 合併聯結必須跳過所有不匹配的行。 如果我們使用帶有結果快取的巢狀迴圈聯結，那麼我們只會快取在聯結外側至少有一個聯結夥伴的元組。 當查詢的相異值較少，且每個值的查詢次數較多時，使用帶有結果快取的參數化巢狀迴圈的好處就會增加。 此外，雜湊探測查詢快取的速度可能比雜湊聯結中的雜湊探測快得多，因為結果快取的雜湊表通常比雜湊聯結的雜湊表小得多，因為結果快取只快取有用的元組，而不是聯結內側的所有元組。 當雜湊聯結的雜湊表不再適合 CPU 的 L3 快取，但結果快取的雜湊表適合時，雜湊探測效能的這種差異會更明顯。 每次雜湊探測對雜湊桶的明顯「隨機」存取都可能導致大型雜湊表的 L3 快取命中率降低。 較小的雜湊表通常表現更好。 用於快取的雜湊表將自身限制為不超過 work_mem * hash_mem_multiplier 的大小。 我們維護此快取的金鑰 dlist，當我們新增新的元組並意識到我們已超過記憶體預算時，我們將從最近最少使用的快取條目開始逐出快取條目，直到我們有足夠的記憶體將新元組新增到快取中。 對於參數化巢狀迴圈聯結，我們現在考慮在巢狀迴圈節點及其內部節點之間使用其中一個結果快取節點。 我們根據成本來確定何時可能有用，這主要是由預期的快取命中率驅動的。 估計快取命中率取決於對巢狀迴圈參數的良好相異值估計。 目前，規劃器只會考慮對參數化巢狀迴圈聯結使用結果快取。 這適用於普通聯結，也適用於 LATERAL 類型的子查詢聯結。 將來可以使用這種新節點進行其他用途。 例如，快取相關子查詢的結果。 但是，由於在外部計畫上獲得相異值估計以計算估計的快取命中率存在一些困難，因此這裡沒有這樣做。 目前，我們在規劃外部計畫之前先規劃內部計畫，因此沒有好的方法知道結果快取是否有用，因為在生成外部計畫之前，我們無法估計子計畫將被呼叫的次數。 這裡新增的功能是在聯結搜尋期間新引入對 estimate_num_groups() 傳回值的依賴性。 以前，在聯結搜尋期間，我們只需要執行選擇性估計。 透過此提交，我們需要使用 estimate_num_groups() 來估計結果快取的命中率。 簡單來說，如果我們預期有 10 個相異值，並且我們預期有 1000 個外部行，那麼我們將估計命中率為 99%。 由於快取命中與掃描巢狀迴圈聯結內側的基礎節點相比非常便宜，因此這將顯著降低規劃器聯結的成本。 但是，很容易在這裡看到，當 estimate_num_groups() 錯誤地傳回一個遠低於實際相異值數量的數值時，事情會變得糟糕。 如果發生這種情況，可能會導致我們使用帶有結果快取的巢狀迴圈聯結，而不是其他聯結類型，例如合併或雜湊聯結。 眾所周知，我們的相異值估計過去一直是問題的根源，因此在此對它們的額外依賴可能會導致規劃器選擇比具有此功能之前更慢的計畫。 當已經聯結了多個表或 WHERE 子句過濾掉一組與我們正在估計相異值數量的表達式相關的值時，相異值估計也相當難以準確估計。 目前，我們在查詢規劃期間對結果快取執行的成本計算確實對相異值估計的準確性寄予了相當多的信任。 當這些準確時，我們通常應該看到包含結果快取的計畫的執行時間更快。 但是，在現實世界中，我們可能會發現我們需要更改成本計算以減少對相異值估計準確性的信任，或者甚至預設停用此功能。 當我們教查詢規劃器執行新技巧時，總是存在一定的風險，它會在錯誤的時間決定使用該新技巧並導致迴歸。 使用者可以透過使用 enable_resultcache GUC 關閉該功能來獲得舊的行為。 目前，預設情況下已啟用此功能。 我們是否會為該版本保持該設定還有待觀察。 此外，「Result Cache」這個名稱是我在開始編寫修補程式時能想到的這個新節點的最佳名稱。 看起來沒有人強烈不喜歡這個名稱。 有些人確實提出了其他名稱，但在關於名稱的簡短討論中，沒有其他名稱似乎佔據主導地位。 讓我們允許 beta 測試期看看目前的名稱是否讓足夠多的人滿意。 如果對更好的名稱達成共識，我們可以在發布之前更改它。 請參閱下面的第二個討論連結，以了解有關「Result Cache」名稱的討論。 作者：David Rowley 審閱人：Andy Fan、Justin Pryzby、Zhihong Yu、Hou Zhijie 測試人：Konstantin Knizhnik 討論：https://postgr.es/m/CAApHDvrPcQyQdWERGYWx8J%2B2DLUNgXu%2BfOSbQ1UscxrunyXyrQ%40mail.gmail.com 討論：https://postgr.es/m/CAApHDvq=yQXr5kqhRviT2RhNKwToaWr9JAN5t+5_PzhuRJ3wvg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9eacee2e62d89cab7b004f97c206c4fba4f1d745

  • 嘗試修復不穩定的結果快取迴歸測試。 force_parallel_mode = regress 導致的問題比我想像的還要多。 似乎領導者和單個工作者都可以參與執行。 我錯誤地認為只有工作者進程才會做任何工作。 由於不確定這兩個進程中的哪一個有機會處理計畫，因此禁用這些測試的 force_parallel_mode 似乎更好。 至少這樣做似乎比僅更改為 EXPLAIN 而不是 EXPLAIN ANALYZE 更好。 此外，我忽略了一個事實，即結果快取下子計畫的執行次數會根據快取逐出而執行不同的次數。 32 位機器將使用更少的記憶體，並從快取中逐出更少的元組。 這導致子節點在 32 位機器上執行的次數更少。 讓我們將每個節點中的迴圈數都清空。 https://git.postgresql.org/pg/commitdiff/a4fac4ffe8f8d543a10ac7debf1157e34963ece3

  • 移除 Result Cache 程式碼中無用的 Asserts。測試一個無符號變數是否 >= 0 毫無意義。在啟用 Assert 的版本中，remove_cache_entry() 中可能有足夠的程式碼來驗證快取記憶體記帳是否正確。即使這些 Asserts 檢查的是有符號變數上的 >= 0，它們也沒有增加多少額外的覆蓋率。Reported-by: Andres Freund Discussion: https://postgr.es/m/20210402204734.6mo3nfacnljlicgn@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/1267d9862fc6a4f8cdc0ca38d1988b61f39da585

Peter Geoghegan 推送了

Peter Eisentraut 推送了

Andrew Dunstan 推送了

Álvaro Herrera 推送了

Etsuro Fujita 推送

Amit Kapila 推送

Tom Lane 推送

  • 進一步調整 pg_dump 對 default_toast_compression 的處理方式。如 bbe0a81db 中所提交的，來自 pre-v14 伺服器的 pg_dump 實際上表現得好像您說了 --no-toast-compression。我認為正確的做法是讓它表現得好像 default_toast_compression 設定為 "pglz"，以便保留資料表的 toast 壓縮行為。如果您想要其他行為，可以隨時使用該開關。討論：https://postgr.es/m/1112852.1616609702@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/54bb91c30e3964fd81059e6b02e377cc9dd2d64c

  • 移除 ExecARDeleteTriggers/ExecARUpdateTriggers 中的小效率低下。在研究 nodeModifyTable.c 時，我偶然注意到，雖然它對 ExecBRTriggers 和 ExecIRTriggers 的呼叫受到測試保護，以查看是否有任何相關的觸發程序要觸發，但它對 ExecARTriggers 的呼叫沒有受到保護；後面的函式會自行執行等效的測試。考慮到涉及的更複雜的條件，這似乎是合理的，但不合理的是，ExecAR 函式在沒有工作要做時並不謹慎地不做任何工作。ExecARInsertTriggers 做對了，但其他兩個函式都會強制建立一個查詢可能不需要的插槽。ExecARUpdateTriggers 還在該插槽上執行了通常無用的 ExecClearTuple()。這在實際工作負載中可能非常微小，但節省的週期就是賺到的週期。https://git.postgresql.org/pg/commitdiff/65158f497a7d7523ad438b2034d01a560fafe6bd

  • 重新設計並執行 UPDATE 和 DELETE。此修補程式進行了兩組密切相關的變更： 1. 對於 UPDATE，ModifyTable 節點的子計畫現在僅傳遞已變更欄位的新值（即查詢的 SET 子句中計算的表達式）以及列識別資訊，例如 CTID。ModifyTable 必須重新提取原始元組，以合併任何未變更欄位的舊值。這樣做的核心優點是，變更的欄位在繼承或分割的目標關係的所有表中都是一致的，而其他欄位可能不是。次要優點是，當 UPDATE 涉及聯結時，需要通過計畫樹傳遞的資料更少。當然，缺點是需要額外提取每個要更新的元組。但是，在上下文中，這似乎幾乎是免費的；即使是最壞情況的測試也表明它對總查詢成本的增加不超過幾個百分點。在某個時候，將重新提取與 ModifyTable 必須執行的元組存取結合起來以標記舊元組為已死亡可能很有趣；但這需要大量的重構，而且似乎不會帶來太多的好處，因此此修補程式沒有嘗試這樣做。 2. 對於繼承的 UPDATE/DELETE，我們現在不是為每個目標關係產生一個單獨的子計畫，而是產生一個與 SELECT 計畫完全相同的單個子計畫，然後將 ModifyTable 放在其之上。為了讓 ModifyTable 知道給定的輸入列指的是哪個目標關係，一個 tableoid 垃圾欄位被添加到列識別資訊中。這消除了 inheritance_planner() 中可怕的 hack，從而消除了在有許多無法修剪的目標關係的情況下 O(N^2) 的計畫成本和記憶體消耗。第 2 點當然需要第 1 點，以便子計畫返回的非垃圾欄位具有統一的定義。但是，如果我們想保持在分割層次結構中同時擁有普通表和外部表的能力，我們就不能堅持要求列識別垃圾欄位具有統一的定義。由於讓每個子表都有自己的列識別欄位無法很好地擴展，因此此修補程式包含將相似的列識別欄位合併到子計畫結果的一個欄位中的規定。特別是，我們可以通過假裝它們是 RECORD 類型，將通常用作 FDW 列識別的整列 Vars 合併到一個欄位中。（即使實際的複合 Datums 用表的 rowtype OID 標記，也沒關係。） 可以做更多的工作來減少此修補程式中的殘餘效率低下，但現在看來是可以提交的。 FDW 作者應注意以下幾個 API 變更： * AddForeignUpdateTargets() 的參數列表已更改，並且它必須用於將垃圾欄位添加到查詢的方法也已更改。呼叫 add_row_identity_var() 而不是直接操作分析樹。您可能還想重新考慮您正在添加的內容。 * PlanDirectModify() 現在必須更加努力地找到 ForeignScan 計畫節點；如果外部表是分割層次結構的一部分，則 ForeignScan 可能不是 ModifyTable 的直接子節點。有關範例程式碼，請參閱 postgres_fdw。 * 要檢查關係是否為目標關係，僅將其 relid 與 root->parse->resultRelation 進行比較已不再足夠。相反，請根據 all_result_relids 或 leaf_result_relids 進行檢查（視情況而定）。 Amit Langote 和 Tom Lane 討論： https://postgr.es/m/CA+HiwqHpHdqdDn48yCEhynnniahH78rwcrv1rEX65-fsZGBOLQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/86dc90056dfdbd9d1b891718d2e5614e3e432f35

  • 改善一些與複製相關的錯誤訊息的樣式。將遠端端的錯誤訊息放入主要錯誤字串中，而不是將其降級到 errdetail()。雖然如果遠端傳送給我們一個非常長的錯誤訊息，這最終可能會很尷尬，但它似乎更符合我們的訊息樣式指南，並且在 errdetail 可能被刪除的情況下更有幫助。 Peter Smith 討論： https://postgr.es/m/CAHut+Ps-Qv2yQceCwobQDP0aJOkfDzRFrOaR6+2Op2K=WHGeWg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/6197db5340b8154adce1c6d07f6d3325547429c1

  • 抑制 libpq_pipeline.c 中的編譯器警告。某些編譯器似乎擔心 recv_step 可能不是任何已定義的枚舉值。以不同於我在 9fb9691a8 中的方式來消除有關未初始化的 cmdtag 的警告。 https://git.postgresql.org/pg/commitdiff/522d1a89f8d7ed45681988c60bd0a687332a4023

  • 不要過早地將值塞入 short int 中。自 a4d75c86b 以來，某些建置場成員一直在警告說，如果 attnum 是 AttrNumber，則 Assert(attnum <= MaxAttrNumber) 是無用的。我不確定從點陣圖中出來的值實際上可能超過 MaxAttrNumber 有多大可能性，但我們似乎早在 7300a6995 就認為這是可能的。將中間變數恢復為 int，以便我們具有與以前相同的溢位保護。 https://git.postgresql.org/pg/commitdiff/c545e9524dcfcfce25c370f584b31562e8d7a4b7

  • 在非 assert 建置中消除編譯器警告。根據建置場。 https://git.postgresql.org/pg/commitdiff/8998e3cafa23632790787b8cc726998e84067259

  • 修正 pqTraceFormatTimestamp 中的可移植性和安全性問題。消除 time_t 和 pg_time_t 之間的混淆；gettimeofday() 和 localtime() 都不處理後者。libpq 實際上根本不應該使用 <pgtime.h>。使用 snprintf 而不是 sprintf，以確保我們不會溢出提供的緩衝區。（不太可能，但讓我們保持安全。）根據建置場。 https://git.postgresql.org/pg/commitdiff/f1be740a991406d7885047beb971e1ff5dbe8b71

  • 修正 isprint() 的不可移植使用。我們必須將 <ctype.h> 函式的參數轉換為 unsigned char，以避免 char 為有符號數時出現問題。說到這一點，考慮到這是一個 <ctype.h> 函式，我們沒有看到更多關於未包含該標頭的抱怨是相當令人驚訝的。根據建置場。 https://git.postgresql.org/pg/commitdiff/9e20406dd847d0f8c1cbd803786c6d0ad33bcbdd

  • 修正 pg_restore 程式碼中錯誤設計的封存檔案格式偵測。儘管明確的註解指出 ReadHead() 和 _discoverArchiveFormat() 中重複的程式碼片段需要同步，但它們並不同步：後者沒有費心套用前者的任何健全性檢查。我們沒有注意到這一點，部分原因是這些檢查在我們通常測試的場景中都不會失敗，部分原因是如果兩個片段都執行，則會掩蓋該疏忽，但在需要自動偵測不可搜尋 stdin 來源的格式的情況下除外。然而，在滿足所有這些要求的情況下（例如，嘗試從不可搜尋的 stdin 讀取比支援的版本更新的封存格式），pg_restore 會遺漏套用版本檢查，並可能導致核心傾印或以其他方式錯誤執行。無論如何，整件事都很愚蠢，因為除了驗證檔案是否以 "PGDMP" 開頭的一行程式碼之外，似乎沒有太多理由複製邏輯。似乎有一個未記錄的假設，即多個主要格式（主要到需要單獨的讀取器模組）仍然會共享自訂格式標頭的前六個欄位。這似乎不太可能，因此讓我們透過直接刪除 _discoverArchiveFormat() 中的重複邏輯來修正它。此外，擺脫成功自動偵測後嘗試尋找回到檔案開頭的無意義嘗試。這會浪費週期，並且意味著我們有四種行為要驗證，而不是兩種。根據 Sergey Koposov 提出的錯誤 #16951。這個問題已經存在幾十年了，所以回溯修補到所有支援的版本。討論：https://postgr.es/m/16951-a4dd68cf0de23048@postgresql.org https://git.postgresql.org/pg/commitdiff/ec03f2df17a8ba5b431b34dd924e020a0be729f6

  • 重新思考 SP-GiST 中傳值葉節點資料的處理方式。SP-GiST 中現有的慣例是，任何傳值資料類型都以 Datum 表示法儲存，也就是說，即使 typlen 小於 sizeof(Datum)，其寬度也是 sizeof(Datum)。對於內部（上層）tuple 中的前綴資料和節點標籤資料來說，這還可以，或者至少現在更改它已經太晚了。但對於葉節點資料來說，這是有問題的，因為我們更希望這些資料以 Postgres 的標準 on-disk 表示法儲存，以便我們可以輕鬆地擴展葉節點 tuple 以攜帶額外的「included」欄位。但是，我相信我們可以直接更改它。這將是一個不可接受的 on-disk 格式中斷，但有兩個很大的緩解因素：1. 似乎不太可能有任何 SP-GiST opclass 使用傳值葉節點資料類型。當然，核心中的任何一個都沒有，codesearch.debian.net 也沒有聽說過任何一個。鑑於 SP-GiST 的用途，很難想像葉節點層級的值既小又固定寬度的用例。（舉例來說，如果您想使用只有一個位元組的葉節點層級來索引文字值，那麼每個文字字串都必須用每個前一個位元組的一層內部 tuple 來表示，這將在空間上極度浪費且存取速度慢。您總是希望使用盡可能少的內部 tuple 層級，將盡可能多的內容留在葉節點值中。）2. 即使您有這樣的索引，此變更也只會在大端機器上破壞事物。在小端機器上，Datum 格式的高位位元組現在只會顯示為對齊填充空間。因此，變更程式碼以通常的 on-disk 格式儲存傳值葉節點資料。內部 tuple 資料不受影響。這是從一個較大的 patch 中提取的，該 patch 旨在新增對「included」欄位的支援。我將其單獨提交，以便在我們的 commit 記錄中具有可見性。Pavel Borisov 和 Tom Lane，由 Andrey Borodin 審閱 討論：https://postgr.es/m/CALT9ZEFi-vMp4faht9f9Junb1nO3NOSjhpxTmbm1UGLMsLqiEQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1ebdec8c03294e55a9fdb6e676a9e8de680231cc

  • 在 Windows 上，也去除錯誤訊息中報告的檔案名稱。Commit dd136052b 建立了一項策略，即錯誤訊息 FILE 項目應僅包含報告來源檔案的基本名稱，以實現統一和簡潔。我們現在觀察到一些 Windows 編譯器在 FILE 字串中使用反斜線，因此也應在反斜線處截斷。預計這將修復新 libpq_pipeline 測試模組結果中的一些平台差異。討論：https://postgr.es/m/3650140.1617372290@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/53aafdb9ff6a561c7dea0f428a7c168f2b7e0f16

  • 改善 psql 在編輯器退出且未儲存時的行為。編輯先前的查詢緩衝區時，如果編輯器退出且未修改臨時檔案，則清除查詢緩衝區，而不是重新載入（並可能重新執行）先前的查詢緩衝區。這降低了意外重新執行您不想執行的內容的可能性。同樣，在 "\e file" 中，如果檔案實際上沒有被修改，則不要將其載入到查詢緩衝區中。並且在 "\ef" 和 "\ev" 中，如果沒有進行任何變更，則清除查詢緩衝區，而不是將函數或檢視定義載入到其中。我們未能調用編輯器或編輯器傳回非零狀態的情況，將被視為檔案未修改的情況。Laurenz Albe，由 Jacob Champion 審閱 討論：https://postgr.es/m/0ba3f2a658bac6546d9934ab6ba63a805d46a49b.camel@cybertec.at https://git.postgresql.org/pg/commitdiff/55873a00e3c3349664e7215077dca74ccea08b4d

  • 修正 SP-GiST 中屬性類型和葉節點儲存類型之間的混淆。根據文件，傳遞給 opclass config 函數的 attType（以及核心程式碼所依賴的）是正在建立索引的堆積資料行或表達式的類型。但實際上傳遞的是索引資料行儲存的類型。對於使用者定義的 SP-GiST opclass 來說，這沒有任何區別，因為我們不允許使用 CREATE OPCLASS 的 STORAGE 子句，因此這兩種類型將是相同的。但是不允許這樣做是很愚蠢的，因為內建的 poly_ops opclass 的 opckeytype 與 opcintype 的值不同，而且如果您想進行有損儲存，那麼這些類型必須確實不同。（因此，進行有損儲存的使用者定義的 opclass 必須謊報索引中的類型。）因此，刪除此限制，並確保在相關的地方使用輸入資料行的類型，而不是 opckeytype。由於與現有使用者定義的 opclass 的回溯相容性，我們不能完全堅持指定的 leafType 與 STORAGE 子句匹配；而是添加一個 amvalidate() 警告，如果它們不匹配。同時修復了一些錯誤，這些錯誤只會在 attType 與 attLeafType 不同時嘗試傳回索引條目時才會顯現。這些錯誤沒有被報告並不令人驚訝，因為這種差異的唯一常見原因是將葉節點值進行有損儲存，導致僅索引掃描變得不可能。添加一個 src/test/modules 模組來練習 attType 與 attLeafType 不同但支援僅索引掃描的情況。討論：https://postgr.es/m/3728741.1617381471@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ac9099fc1dd460bffaafec19272159dd7bc86f5b

Stephen Frost 推送了

Bruce Momjian 推送了

Michaël Paquier 推送了

  • 在 pg_dump 中新增對 --extension 的支援。指定此選項後，只有符合給定模式的擴充功能才會包含在傾印中。與 --table 和 --schema 類似，當使用 --strict-names 時，需要完全匹配。同樣，與其他兩個選項一樣，這個新選項不保證已傾印了依賴物件，因此在乾淨的資料庫上還原可能會失敗。測試已新增到 test_pg_dump/ 中，在多組正面和負面案例之後進行檢查，無論擴充功能的內容是否已新增到產生的傾印中。Author: Guillaume Lelarge Reviewed-by: David Fetter, Tom Lane, Michael Paquier, Asif Rehman, Julien Rouhaud Discussion: https://postgr.es/m/CAECtzeXOt4cnMU5+XMZzxBPJ_wu76pNy6HZKPRBL-j7yj1E4+g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/6568cef26e0f40c25ae54b8e20aad8d1410a854b

  • 修正 parsenodes.h 中的註解。CreateStmt->inhRelations 是一個 RangeVars 列表，但註解不正確。Author: Julien Rouhaud Discussion: https://postgr.es/m/20210330123015.yzekhz5sweqbgxdr@nol https://git.postgresql.org/pg/commitdiff/7ef64e7e72a65f191fc2f7d4bbe220f53dd8d5de

  • 將一些客戶端特定的常式從 SSLServer 移至 PostgresNode。 test_connect_ok() 和 test_connect_fails() 一直都是 SSL 測試的一部分，並且檢查與後端的連線是否應該成功，以及如果連線失敗，libpq 放棄的特定錯誤模式會進行健全性檢查。這在兩個方面基本上是錯誤的。首先，SSLServer.pm 主要用於設定和變更 PostgresNode 的 SSL 設定，與客戶端實際上沒有任何關係。其次，在 b34ca595 的情況下，情況變得更糟，其中 SSL 測試會透過使用一個 psql 指令來完成，該指令可能與設定的節點來自不同的安裝。此提交將這些客戶端常式移至 PostgresNode，使 SSLServer 的重構更容易，使其更能感知 SSL 實現。這也可以被 ldap、kerberos 和身份驗證測試套件重複使用以進行連線檢查，並且後續的修補程式應該擴展這些介面以匹配後端日誌模式。作者：Michael Paquier 審閱者：Andrew Dunstan, Daniel Gustafsson, Álvaro Herrera 討論：https://postgr.es/m/YGLKNBf9zyh6+WSt@paquier.xyz https://git.postgresql.org/pg/commitdiff/0d1a33438d3a88938264e12e94c22818307d2f4d

  • 文件：闡明在各個部分中使用 ACCESS EXCLUSIVE 鎖。文件的某些部分使用“exclusive lock”來描述在給定操作期間取得 ACCESS EXCLUSIVE 鎖。這可能會讓讀者感到困惑，因為 ACCESS SHARE 在使用 EXCLUSIVE 鎖時是允許的，但這與文件中描述的那些部分的情況不同。作者：Greg Rychlewski 討論：https://postgr.es/m/CAKemG7VptD=7fNWckFMsMVZL_zzvgDO6v2yVmQ+ZiBfc_06kCQ@mail.gmail.com 回溯修補：9.6 https://git.postgresql.org/pg/commitdiff/ffd3391ea94165fbb5adc9534894c62d41138505

  • 提高 reloptions.sql 中使用 vacuum_truncate 的測試的穩定性。此測試一直使用簡單的 VACUUM 和 pg_relation_size() 來檢查關係是否被物理截斷，但忘記了某些並行活動（如檢查點緩衝區寫入）可能導致跳過某些頁面的事實。第二個啟用 vacuum_truncate 的測試可能會失敗，看到一個非空的關係。第一個測試不會失敗，但可能會完成測試與目標行為不同的行為。這兩個測試都獲得了 FREEZE 選項，以使 vacuum 更具侵略性並防止頁面跳過。這與 c2dc1a7 中修復的問題類似。作者：Arseny Sher 審閱者：Masahiko Sawada 討論：https://postgr.es/m/87tuotr2hh.fsf@ars-thinkpad 回溯修補：12 https://git.postgresql.org/pg/commitdiff/fe246d1c111d43fd60a1b0afff25ed09b7ae11eb

  • 文件：闡明如何使用非獨佔備份產生備份檔案。目前描述如何寫入 backup_label 和 tablespace_map 檔案的說明令人困惑。例如，在 Windows 上以文字模式開啟檔案並複製貼上檔案內容將導致恢復失敗，因為產生了額外的 CRLF 字元。文件沒有清楚地說明這一點，並且根據討論，這不被視為受支援的方案。此提交稍微擴展了文件，以提及可能需要在寫入其資料之前以二進位模式開啟檔案。回報者：Wang Shenhao 作者：David Steele 審閱者：Andrew Dunstan, Magnus Hagander 討論：https://postgr.es/m/8373f61426074f2cb6be92e02f838389@G08CNEXMBPEKD06.g08.fujitsu.local 回溯修補：9.6 https://git.postgresql.org/pg/commitdiff/6fb66c268df2de1112cac3cf0a6cf0a8b96ceaf0

  • 重構 HMAC 實現。與 cryptohash 實現類似，這會將現有的 HMAC 程式碼重構為一組單一的 API，這些 API 可以與 PostgreSQL 建置的任何加密函式庫（目前僅限 OpenSSL）搭配使用。如果沒有此類函式庫，則可以使用後備實現。這些新的 API 的設計與現有的 cryptohash 層類似，因此這裡沒有真正的新設計，具有圍繞緩衝區邊界檢查和記憶體處理的相同邏輯。HMAC 依賴於 cryptohashes，因此 cryptohash{_openssl}.c 支援的所有 cryptohash 類型都可以與 HMAC 一起使用。此重構主要對 SCRAM 有利，SCRAM 包括其自己的 HMAC with SHA256 實現，即使 PostgreSQL 建置時支援現有的加密函式庫，也不會依賴它們。此程式碼已在 Windows 和 Linux 上經過測試，無論有無 OpenSSL，在 HEAD 上從 1.1.1 到 1.0.1 支援的所有版本中都是如此。我還使用一些範例結果、我自己的自訂擴充以及使用客戶端和後端的 SCRAM 在不同主要版本之間進行交叉檢查，來檢查這些實現是否正常工作。作者：Michael Paquier 審閱者：Bruce Momjian 討論：https://postgr.es/m/X9m0nkEJEzIPXjeZ@paquier.xyz https://git.postgresql.org/pg/commitdiff/e6bdfd9700ebfc7df811c97c2fc46d7e94e329a2

  • 在 SSL TAP 測試中使用更詳細的錯誤匹配模式。src/test/ssl/ 的 TAP 測試一直在使用相當通用的匹配模式來檢查一些失敗場景，例如「SSL error」或僅僅是「FATAL」。這些是在 081bfc1 中引入的。這些訊息本身並沒有錯，但是當處理整合新的 SSL 函式庫時，很難知道這些錯誤是否合法，並且現有的場景可能會以不正確的方式失敗。此提交透過新增 OpenSSL 產生的資訊，使所有這些訊息更詳細。幸運的是，相同的錯誤訊息用於 HEAD 上支援的所有版本（在從 1.0.1 到 1.1.1 執行測試後檢查），因此變更非常簡單。回報者：Jacob Champion, Álvaro Herrera 討論：https://postgr.es/m/YGU3AxQh0zBMMW8m@paquier.xyz https://git.postgresql.org/pg/commitdiff/8d3a4c3eae5367fba60ab77c159814defba784fe

Noah Misch 推送

Joe Conway 推送

  • 修正 has_column_privilege 函式的邊角案例。根據註解，當將無效或已刪除的欄位 oid 傳遞給 has_column_privilege() 時，意圖一直是傳回 NULL。但是，當呼叫者具有表層級權限時，由於首先檢查了表權限，因此從未發現無效/遺失的欄位。透過引入 pg_attribute_acl(check|mask) 和 pg_class_acl(check|mask) 的擴充版本來修正此問題，這些版本採用一個新引數 is_missing。當 is_missing 為 NULL 時，保留舊行為。但是，當 is_missing 由呼叫者傳遞時，不會針對已刪除或遺失的欄位/關係拋出 ERROR，並且 is_missing 會翻轉為 true。反過來，這允許 has_column_privilege 首先檢查欄位權限，從而提供所需的語意。由於這是一個使用者可見的行為變更，且之前沒有投訴，而且修復有點侵入性，因此沒有回溯修補。作者：Joe Conway 審閱者：Tom Lane 回報者：Ian Barwick 討論：https://postgr.es/m/flat/9b5f4311-157b-4164-7fe7-077b4fe8ed84%40joeconway.com https://git.postgresql.org/pg/commitdiff/b12bd4869b5e64b742a69ca07915e2f77f85a9ae

  • 釐清 RESET ROLE 的文件說明。命令列選項或先前的 "ALTER (ROLE|DATABASE) ... SET ROLE ..." 命令可能會更改工作階段的預設角色值。如果存在其中一種情況，RESET ROLE 會將目前使用者識別符號變更為預設角色，而不是工作階段使用者識別符號。修正文件以反映此事實。回溯修補到所有支援的版本。作者：Nathan Bossart 審閱者：Laurenz Albe, David G. Johnston, Joe Conway 報告者：Nathan Bossart 討論：https://postgr.es/m/flat/925134DB-8212-4F60-8AB1-B1231D750CB4%40amazon.com Backpatch-through: 9.6 https://git.postgresql.org/pg/commitdiff/174edbe9f9c1538ab3347474e96d176223591cd1

Heikki Linnakangas 已推送

  • 新增 'noError' 參數到編碼轉換函式。使用 'noError' 參數，您可以嘗試轉換緩衝區，而無需事先知道字元邊界。現在函式需要傳回成功轉換的輸入位元組數。如果您使用 CREATE CONVERSION 建立了自訂編碼轉換，這是一個不相容的回溯變更。這會對 pg_upgrade 新增檢查，如果存在任何使用者定義的編碼轉換，則拒絕升級。自訂轉換非常罕見，據我所知，沒有常用的擴充功能使用該功能。沒有其他物件可以依賴轉換，因此如果您確實有一個，您可以在升級之前相當容易地將其刪除，並在升級後使用更新的版本重新建立它。為內建編碼轉換新增迴歸測試。這沒有涵蓋所有轉換，但它涵蓋了 conv.c 中用於實作轉換的所有內部函式。審閱者：John Naylor 討論：https://postgres.tw/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi https://git.postgresql.org/pg/commitdiff/ea1b99a6619cd9dcfd46b82ac0d926b0b80e0ae9

  • 以較大的區塊執行 COPY FROM 編碼轉換/驗證。這透過減少對轉換/驗證函式的呼叫次數，並讓它處理更大的輸入，從而提供較小的效能提升。此外，重新組織輸入管道使得更容易平行化輸入解析：在輸入已轉換為資料庫編碼後，尋找換行符號的下一個階段可以平行完成，因為在我們支援作為伺服器編碼的編碼中，多位元組字元中不能有任何「嵌入」的換行符號。這在一個邊角案例中變更了行為：如果用戶端和伺服器編碼是相同的單一位元組編碼（例如 latin1），則先前不會檢查輸入中是否存在零位元組（'\0'）。包含零位元組的任何欄位都將在零處截斷。但是如果需要編碼轉換，轉換常式會在零上拋出錯誤。在此提交之後，始終會檢查輸入中是否存在零。審閱者：John Naylor 討論：https://postgres.tw/message-id/e7861509-3960-538a-9025-b75a61188e01%40iki.fi https://git.postgresql.org/pg/commitdiff/f82de5c46bdf8cd65812a7b04c9509c218e1545d

Robert Haas 已推送

Fujii Masao 已推送

Thomas Munro 已推送

Andres Freund 推送

  • 將與 wait event 相關的程式碼從 pgstat.[ch] 分割到 wait_event.[ch]。與 wait event 相關的程式碼與 pgstat.[ch] 程式碼的其餘部分無關，具有相當大的規模，並且會定期變更。將其放入自己的檔案集中。由於似乎沒有一個很好的現有目錄用於此類程式碼，因此新增 src/backend/utils/activity。審閱者：Robert Haas robertmhaas@gmail.com 討論：https://postgr.es/m/20210316195440.twxmlov24rr2nxrg@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/a333476b925134f6185037eaff3424c07a9f466f

  • 不要依賴 pgstat.h 間接包含 storage/ 標頭檔。 即將到來的修補程式可能會移除 (現在間接的) proc.h 包含 (進而包含其他標頭檔)，而且讓修改後的檔案直接包含其相依性會更乾淨... 討論：https://postgr.es/m/20210402194458.2vu324hkk2djq6ce@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/1d9c5d0ce2dcac05850401cf266a9df10a68de49

  • 將後端狀態和進度相關的功能從 pgstat.c 中分離出來。 後端狀態 (支援 pg_stat_activity) 和命令進度 (支援 pg_stat_progress*) 相關的程式碼在很大程度上獨立於 pgstat.[ch] 的其餘部分 (支援像 pg_stat_all_tables 這樣會隨著時間累積資料的檢視)。 另請參閱 a333476b925。 此 commit 沒有重新命名函式名稱，以區分與 pgstat 的其餘部分的區別 - 這將更具侵入性，並且沒有明顯的好處。 如果我們決定在某個時候執行這樣的重新命名，最好與移動程式碼分開執行。 Robert 的審閱是針對早期版本。審閱者：Robert Haas robertmhaas@gmail.com 討論：https://postgr.es/m/20210316195440.twxmlov24rr2nxrg@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/e1025044cd4e7f33f7304aed54d5778b8a82cd5d

  • 提高 wait event 報告的效率，移除 proc.h 依賴性。 到目前為止，pgstat_report_wait_start() 和 pgstat_report_wait_end() 需要兩個條件分支。 一個用於檢查 MyProc 是否為 NULL，另一個用於檢查是否設定了 pgstat_track_activities。 由於 wait event 在相對輕量級的操作周圍使用，並且是內聯的（降低分支預測器的有效性），因此這不是很好。 對於 MyProc 的依賴性還有第二個缺點：低階子系統（例如 storage/file/fd.c）報告 wait event，但在架構上，最好讓它們不依賴於像 proc.h（定義 PGPROC）這樣的進程間子系統。 在此變更之後，包含 pgstat.h（或顯然它的子元件，如 backend_status.h、wait_event.h 等）不再引入與 IPC 相關的標頭檔。 這些目標（效率和抽象）是透過讓 pgstat_report_wait_start/end() 不與 MyProc 互動，而是與新的 my_wait_event_info 變數互動來實現的。 在後端啟動時，它指向一個本機變數，從而無需檢查 MyProc 是否為 NULL。 在進程初始化期間，my_wait_event_info 會重新導向到 MyProc->wait_event_info。 在關閉時，此操作會反轉。 因為 wait event 報告現在不需要知道 wait event 的儲存位置，所以它不再需要知道 PGPROC。 現在提交此工作的主要動機是，從 pgstat.h 中移除 (間接) pgproc.h 包含，簡化了將統計資訊報告移動到共用記憶體的修補程式（仍然有機會進入 14）。作者：Andres Freund andres@anarazel.de 討論：https://postgr.es/m/20210402194458.2vu324hkk2djq6ce@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/225a22b19ed2960acc8e9c0b7ae53e0e5b0eac87

Tomáš Vondra 推送

待處理的 Patches

James Hilliard 送出另一個 patch 修訂版，以修正對 OSX 的 preadv/pwritev 支援的偵測。

Mark Rofail 送出另一個 patch 修訂版，以實作外鍵陣列。

Tomáš Vondra 送出一個 patch，使用新的子命令 ANALYZE (MERGE) 合併來自子關係的統計資訊。

Zeng Wenjing 送出另一個 patch 修訂版，以實作全域臨時表。

Marcus Wanner 送出另外四個 patch 修訂版，以將 xid 引數新增到輸出外掛程式的 filter_prepare 回呼函數。

Euler Taveira de Oliveira 送出另一個 patch 修訂版，以新增由邏輯複製的 WHERE 子句指定的列篩選。

Peter Smith 送出另一個 patch 修訂版，以將對預備交易的支援新增到內建邏輯複製。

Arne Roland 送出另外兩個 patch 修訂版，以使 ALTER TRIGGER ... RENAME TO 在分割表上工作。

Tang 送出一個 patch，以更新 nbtsearch.c 的著作權年份。

Paul Guo 送出另一個 patch 修訂版，以支援從具有表空間的備份進行節點初始化、修正待命節點上建立資料庫記錄的重播，以及修正資料庫建立/刪除 wal 描述。

Masahiro Ikeda 送出另外兩個 patch 修訂版，以加速 WAL 統計資訊的報告。

Daniil Zakhlystov 送出另外兩個 patch 修訂版，以新增 zlib 和 zstd 串流壓縮，並實作 libpq 壓縮。

Atsushi Torikoshi 和 Fujii Masao 交換了 patch 以取得任意後端進程的記憶體環境。

John Naylor 送出兩個 patch 修訂版，以記錄最近新增的 date_bin() 函式。

Dean Rasheed 和 Fabien COELHO 交換了 patch 以將虛擬隨機排列函式新增到 pgbench。

Isaac Moreland 送出一個 patch，以新增 abs(interval) 函式和相關的 @ 運算符。

Kyotaro HORIGUCHI 送出一個 patch，以使 box 類型的描述更清晰。

Vigneshwaran C 送出另一個 patch 修訂版，如果預備交易鎖定了系統表/使用者目錄表，則使其失敗。

Douglas Hirn 送出另一個 patch 修訂版，以允許在 WITH RECURSIVE 中使用多個線性遞迴自我引用。

Sait Talha Nisanci 送出一個 patch，旨在修正一個表現為 record_type_typmod_compare 崩潰的錯誤。

Tomáš Vondra 送出一個 patch，使用擴展統計資訊來改進聯結估計。

Stephen Frost 送出另一個 patch 修訂版，將預設角色重新命名為預定義角色。

Vigneshwaran C 送出三個 patch 修訂版，以處理覆寫複寫槽統計資訊的問題，並將總交易次數和總交易位元組數新增到複寫統計資訊。

Peter Geoghegan 送出另外兩個 patch 修訂版，以簡化 VACUUM 管理的狀態、重構 lazy_scan_heap()、從 vacuumlazy.c 中刪除 tupgone 特殊情況、在 VACUUM 期間截斷行指標陣列，並在某些情況下繞過索引清理。

Peter Geoghegan 和 Matthias van de Meent 交換了 patch，以在頁面具有尾隨未使用的 ItemIds 時截斷頁面的行指標陣列，並在 PageRepairFragmentation 中覆蓋可用頁面空間。

Tang 送出另一個 patch 修訂版，以支援 psql 中大寫字元輸入的查詢結果的 tab 補全。

Fujii Masao 送出另一個 patch 修訂版，以修正 walreciever 中的斷言失敗。

John Naylor 送出另一個 patch 修訂版，以使用兩個更快的實作取代 pg_utf8_verifystr()：一個用於使用 SSE-4.1 指令集的 Intel-ish 處理器，另一個使用客製化的後備函式，而不是依賴 pg_utf8_verifychar() 和 pg_utf8_isvalid() 的函式。

Peter Eisentraut 送出另一個 patch 修訂版，以將 EXTRACT 的回傳類型更改為 numeric。

Stephen Frost 送出一個 patch，以新增 pg_read_all_data 和 pg_write_all_data 角色。

Thomas Munro 送出一個 patch，以在 OpenBSD 上使用 POSIX_NAMED_SEMAPHORES。

Fujii Masao 和 Bharath Rupireddy 交換了 patch 以新增 postgres_fdw 伺服器級別選項 keep_connections，以不快取連線。

Heikki Linnakangas 送出一個 patch，透過強制前瞻來簡化 COPY FROM 剖析。

Daniel Gustafsson 送出另外兩個 patch 修訂版，以支援 NSS 作為 libpq TLS 後端。

Yuzuko Hosoya 和 Álvaro Herrera 交換了 patch 以修正在分割表上的自動清理。

Bharath Rupireddy 送出一個 patch，當分割表的持久性變更時發出警告。

Amit Langote 送出另一個 patch 修訂版，以也在分割表中建立外鍵觸發器，並使用相同的觸發器在跨分割區更新期間正確強制執行外鍵。

Euler Taveira de Oliveira 送出另一個 patch 修訂版，以重構 parse_output_parameters 函式，以使用封裝所有 pgoutput 選項的 struct PGOutputData，而不是使用多個參數，並使用相同的程式碼將邏輯解碼訊息支援新增到 pgoutput。

Peter Eisentraut 送出另一個 patch 修訂版，以實作 SQL 標準函式主體。

Justin Pryzby 送出另一個 patch 修訂版，以實作分割表的 CLUSTER。

Amit Langote 送出另外兩個 patch 修訂版，以匯出 get_partition_for_tuple()，並使用相同的程式碼來避免將 SPI 用於某些 RI 檢查。

Julien Rouhaud 送出另外三個 patch 修訂版，將 pg_stat_statements 查詢混亂移至核心，並使用相同的程式碼在 pg_stat_activity、log_line_prefix 和 verbose explain 中公開 queryid。

Joel Jacobson 送出一個 patch 以新增 MotD 函式。

Bharath Rupireddy 送出另一個 patch 修訂版，以實作 ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION ...

Erik Rijkers 送出另一個 patch 修訂版，以修正一個舊的令人困惑的 JSON 範例。

Kazutaka Onishi 送出另外六個 patch 修訂版，以實作外部表的 TRUNCATE。

Thomas Munro 送出另一個 patch 修訂版，以新增用於 SLRUs 的緩衝區對應表，並使所有 SLRU 緩衝區大小可配置。

Takamichi Osumi 送出另外兩個 patch 修訂版，以保護封存復原不會遺漏資料。這會停用伺服器，使其在封存復原期間偵測到使用 wal_level=minimal 產生的 WAL 時啟動。無論 EnableHotStandby 的值如何，都應該這樣做，因為我們不認為會發生經歷 wal_level=minimal 期間的情況。此 patch 的動機是保護使用者最終獲得可能在待命模式下遺漏資料的複本，並使伺服器在復原模式下遺漏資料。

Amit Langote 送出另一個 patch 修訂版，以延遲設定 ForeignScanState.resultRelInfo，並延遲初始化結果關係資訊。

Justin Pryzby 送出一個 patch，以使 track_activity_query_size 成為 STATS_COLLECTOR 類別、確保 log_autovacuum_min_duration 是 LOGGING_WHAT、使 track_commit_timestamp 成為 REPLICATION_SENDING，並將 force_parallel_mode 更改為 DEVELOPER GUC，並將其從範例配置中移除。

Pavel Stěhule 提交了 schema 變數實作的另一個修訂版本。

Anton Voloshin 提交了一個修正 collationcmds.c 中錯字的 patch。

Zhihong Yu 提交了一個從 AttrDefaultFetch 中移除未使用的變數的 patch。

Amit Langote 提交了允許在跨分割區更新期間批次處理插入的另一個修訂版本。

Anton Voloshin 提交了一個在 icu_convert_case() 中使用 repalloc() 而非 palloc() 的 patch，因為有問題的結構可能已經被 palloc() 分配過。

Tom Lane 提交了一個修正一些 adbin 不一致性的 patch。