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

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

發布於 2021-11-29，作者：PWN
PWN

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

本週人物

11 月的 PostgreSQL 工作

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

PostgreSQL 本地社群

Nordic PGDay 2022 將於 2022 年 3 月 22 日在芬蘭赫爾辛基的 Hilton Helsinki Strand Hotel 舉行。徵稿截止日期為 2021 年 12 月 31 日，詳情請見此處

PostgreSQL 新聞

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

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

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

已應用修補程式

Peter Geoghegan 推送了

  • 移除 lazy_scan_heap 並行 VACUUM 註解區塊。 這不屬於 lazy_scan_heap 執行的任務之非常高層級的討論。 在 vacuumlazy.c 的頂部已經有一個類似的、更長的註解區塊，直接提到 lazy_scan_heap。 https://git.postgresql.org/pg/commitdiff/97f5aef609ce51422934b7dbdba599a7de4dbafd

  • 回到考慮標記為 full 的頁面上的 HOT。 Commit 2fd8685e7f 簡化了 heap_update() 內發生的已修改屬性的檢查。 這包括一個微優化，影響標記為 PD_PAGE_FULL 的頁面：甚至不要嘗試使用 HOT 來節省一些週期來確定 HOT 安全性。 假設是這次不會成功，因為上次沒有成功。 刪除微優化。 它只能節省 heap_update() 的絕大多數呼叫所消耗的週期，這似乎不值得增加複雜性。 同時，在短期內，儘管平均可以節省一些週期，但隨著時間的推移，透過重複應用微優化，某些工作負載可能會變得更糟。 作者：Peter Geoghegan pg@bowt.ie 審閱者：Álvaro Herrera alvherre@alvh.no-ip.org 討論：https://postgr.es/m/CAH2-WznU1L3+DMPr1F7o2eJBT7=3bAJoY6ZkWABAxNt+-afyTA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1a6f5a0e876306293fda697e7820b404d5b93693

  • 更新高層級 vacuumlazy.c 註解。 更新 vacuumlazy.c 檔案標頭註解（以及 lazy_scan_heap 函數上方的註解），這些註解主要是在引入 HOT 優化之前編寫的，當時 lazy_scan_heap 做的事情少得多，並且實際上並沒有在初始堆疊掃描期間進行修剪。 由於 lazy_scan_heap 現在將更多工作外包給較低層級的函數，因此最好透過談論高層級不變量來引入該函數，該不變量決定了每個階段發生的順序。 同時，淡化我們記憶體不足以處理 TID 的情況，因為延遲該討論可以更容易地討論核心重要性問題。 最後，從標頭註解中刪除並行 VACUUM 的討論。 這些並沒有增加太多，而且位置不正確。 https://git.postgresql.org/pg/commitdiff/12b5ade9023f3ecaddcbc423a22dc284c91c79f6

  • vacuumlazy.c：首選術語「清理鎖」。術語「超級獨佔鎖」是「清理鎖」的可接受同義詞。即便如此，在同一個檔案中從一個術語切換到另一個術語也會令人困惑。在 vacuumlazy.c 中標準化為「清理鎖」。根據 Andres Freund 的投訴。 https://git.postgresql.org/pg/commitdiff/276db875d4f9be2911582f367596d444d6986c77

Fujii Masao 推送了

Peter Eisentraut 推送了

Álvaro Herrera 推送了

Tom Lane 推送

  • 在檢查 TAP 測試所需的模組時，探測 $PROVE 而不是 $PERL。通常，「prove」和「perl」來自相同的 Perl 安裝，但我們支援它們不來自相同安裝的情況（主要是因為 MSys buildfarm 動物需要這個）。在這種情況下，AX_PROG_PERL_MODULES 完全是錯誤的使用方式，因為它檢查的是「perl」擁有的東西。相反，建立一個包含所需模組的 TAP 測試腳本，並在「prove」下執行它。此變更後，我們根本不需要 ax_prog_perl_modules.m4，因此將其刪除。為了 buildfarm 的利益，回溯修補至所有支援的分支。（在 v10 中，這也回溯修補了 commit 264eb03aa 的影響。） Andrew Dunstan 和 Tom Lane，根據 Noah Misch 的觀察。討論：https://postgr.es/m/E1moZHS-0002Cu-Ei@gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/c4fe3199a6d65212537a59eb0d7e6fad22b9e903

  • 修正 pg_dump --inserts 模式，用於具有已刪除欄位的產生欄位。如果一個表包含一個由已刪除欄位先前的產生欄位，則 dumpTableData_insert 未能考慮已刪除的欄位，並且會在錯誤的欄位中發出 DEFAULT 佔位符。這導致在還原時失敗。預設的 COPY 程式碼路徑沒有這個錯誤，可能解釋了為什麼沒有早點注意到它。在我們修復此問題時，我們可以對這種情況更聰明一些：（1）避免不必要地獲取產生欄位的值，（2）如果我們使用 --column-inserts，也從輸出中省略產生欄位。雖然預計這些模式不像 COPY 路徑那樣具有高效能，但我們不妨盡可能地提高效率；它不會增加太多的複雜性。根據 Дмитрий Иванов 的報告。回溯修補至 v12，產生欄位出現在此版本中。討論：https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0b126c6a4b00972f2f3533e1718bbe297e2851c2

  • 安撫 perlcritic。根據 buildfarm。 https://git.postgresql.org/pg/commitdiff/db3a660c6327a6df81a55c4aa86e6c0837ecd505

  • 調整 pg_dump 中轉換 (cast) 的優先順序。當儲存的表達式 (stored expression) 依賴於使用者定義的轉換時，後端會將依賴性記錄為依賴於轉換的實作函數 --- 或者，如果沒有涉及轉換函數，只是 RelabelType 或 CoerceViaIO，則根本不記錄任何依賴性。這對於 pg_dump 來說是有問題的，因為它可能會以錯誤的順序傾印 (dump) 內容，導致還原失敗。鑑於先前沒有相關報告，這種風險並不是很高，但如果轉換用於某個視圖 (view) 中，而該視圖的列類型 (rowtype) 隨後被用作另一個函數的輸入或結果類型，則可以證明這一點。（這會導致視圖被提升到傾印的函數部分，位於轉換之前。）一個邏輯上萬無一失的解決方案是將轉換的 OID 包含在表達式的解析形式中，然後 dependency.c 可以提取它，並且儲存的依賴性會強制 pg_dump 執行正確的操作。這樣的變更會相當具有侵入性，而且肯定無法回溯修補 (back-patch)。此外，由於我們希望使用轉換語法的表達式與通過顯式函數調用執行相同操作的表達式 equal()，因此轉換 OID 欄位必須具有特殊的、比較時被忽略的語義，從而使事情變得混亂。因此，我們改用 pg_dump 中的一個非常簡單的技巧來解決這個問題：更改物件類型優先順序，以便在類型之後立即對轉換進行初始排序，排序在函數之前。這以相當直接的方式解決了沒有實作函數的轉換的問題。對於那些有實作函數的轉換，實作函數將通過依賴性排序步驟提升到轉換之前，以便我們仍然具有有效的傾印順序。（我不確定這是否能完全保證沒有問題；但由於多年來一直如此，沒有任何先前的報告，因此這可能足以在實踐中解決它。）根據 Дмитрий Иванов 的報告。回溯修補到所有支援的分支。討論：https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b55f2b6926556115155930c4b2d006c173f45e65

  • Doc: 改善關於 nextval()/setval() 的文件。澄清 nextval 和 setval 的結果在呼叫交易 (transaction) 提交之前，不能保證是持久性的。有些人似乎從這些函數永遠不會回滾的聲明中得出相反的結論，因此重新措辭以避免以這種方式說明。討論：https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4ac452e2285da347c75f5960ae211e183a87b57b

Michaël Paquier 推送了

  • 新增 SQL 函數來監控複寫槽 (replication slot) 的目錄內容。此提交新增了一組能夠查看與複寫槽相關的各種路徑內容的函數：- pg_ls_logicalsnapdir，適用於 pg_logical/snapshots/ - pg_ls_logicalmapdir，適用於 pg_logical/mappings/ - pg_ls_replslotdir，適用於 pg_replslot/<slot_name>/ 這些函數旨在供監控工具使用。與 pg_ls_dir() 不同，可以將執行權限授予非超級使用者。pg_monitor 角色的成員有權存取這些函數。提高目錄版本。作者：Bharath Rupireddy 審閱者：Nathan Bossart, Justin Pryzby 討論：https://postgr.es/m/CALj2ACWsfizZjMN6bzzdxOk1ADQQeSw8HhEjhmVXn_Pu+7VzLw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1922d7c6e1a74178bd2f1d5aa5a6ab921b3fcd34

  • 在建置腳本中新增對 Visual Studio 2022 的支援。更新文件和任何與 VS 相關的程式碼路徑，以保持整體一致性。與 2017 和 2019 類似，我們用於確定使用哪個程式碼路徑進行建置的 VS 版本和 nmake 版本仍然以它們自己的方式不一致。回溯修補到 10，以便 buildfarm 成員能夠在所有支援的穩定分支上使用這個新版本的 Visual Studio。作者：Hans Buschmann 討論：https://postgr.es/m/1633101364685.39218@nidsa.net Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/b2265d305d81b0c1a2cec6c5b66a190a9e69e853

  • 移除寫入檔案標頭時，發生錯誤時無用的 LZ4 系統呼叫。如果在寫入 LZ4 檔案標頭時發生錯誤，則會在 write() 的錯誤程式碼路徑中呼叫 LZ4F_compressEnd()，然後呼叫 LZ4F_freeCompressionContext() 以完成清理。現有的程式碼沒有損壞，但 LZ4F_compressEnd() 被證明是不必要的，因為在此階段沒有要刷新的內容，因此將其刪除。根據 Jeevan Ladhe 和 Robert Haas 的抱怨。討論：https://postgr.es/m/CAOgcT0PE33wbD7giAT1OSkNJt=p-vu8huq++qh=ny9O=SCP5aA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f79962d8264b8d205ce45a8aa11d1b37f9592a81

  • 修正 Windows 上標準流 (stream) 的 fstat() 模擬。win32stat.c 中的 fstat() 模擬導致現有核心內呼叫者出現兩個問題，當使用流作為參數時會失敗並顯示 EINVAL：- psql 的 \copy 在使用流時會崩潰。- pg_recvlogical 會因為 -f - 而失敗。主測試套件中的 copyselect.sql 中的測試涵蓋了第一種情況，並且第二種情況有一個 TAP 測試。但是，在這兩種情況下，由於標準流總是重新導向，因此自動化測試沒有注意到這些問題，需要 Windows 上的終端才能重現。這個問題是在 bed9075 中引入的，問題的根源在於 GetFileInformationByHandle() 無法直接在流上工作，因此這個提交新增了一個額外的程式碼路徑來模擬並傳回一組最符合現實的統計資料。請注意，重新導向的流依賴於可以使用 GetFileInformationByHandle() 查詢的句柄，但我們可以依靠 GetFinalPathNameByHandleA() 來檢測這種情況。作者：Dmitry Koval, Juan José Santamaría Flecha 討論：https://postgr.es/m/17288-6b58a91025a8a8a3@postgresql.org Backpatch-through: 14 https://git.postgresql.org/pg/commitdiff/10260c794b211117a56ee2eb2deacf609bcca25f

  • 阻止 ALTER TABLE .. DROP NOT NULL 用於副本身份索引中的欄位。直接依賴於索引的副本身份依賴於一組屬性，其中之一是此索引中定義的所有欄位都必須標記為 NOT NULL。ALTER TABLE DROP NOT NULL 的邏輯中存在一個漏洞，可以移除用作副本身份的索引部分的欄位的 NOT NULL 屬性，因此阻止它以避免將來的邏輯解碼出現問題。對於主鍵的一部分的欄位，已經進行了相同的檢查，因此修復很簡單。作者：Haiying Tang, Hou Zhijie 審閱者：Dilip Kumar, Michael Paquier 討論：https://postgr.es/m/OS0PR01MB6113338C102BEE8B2FFC5BD9FB619@OS0PR01MB6113.jpnprd01.prod.outlook.com Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/f0d43947a1b0c30f0bf2c117cd78bf95a3161268

David Rowley 推送了

  • 允許 Memoize 以二進位比較模式運作。Memoize 原本總是使用雜湊相等運算子來比較快取鍵類型，以判斷目前的參數集合是否與先前快取的集合相同。某些類型，例如浮點數，其中 -0.0 和 +0.0 在二進位表示法中不同，但被雜湊相等運算子歸類為相等，可能會導致問題，因為除非 join 使用相同的運算子，否則 join 運算子可能能夠區分這兩個值。在這種情況下，我們可能會意外地從快取中傳回不正確的列。為了修正這個問題，我們在這裡為 Memoize 添加了一種二進位模式，允許它透過逐位比較而不是使用雜湊相等運算子的邏輯方式來比較目前參數集合與先前快取的值。這種二進位模式總是用於 LATERAL joins，並且當任何 join 運算子不可雜湊時，它也用於正常的 joins。報告者：Tom Lane 作者：David Rowley 討論：https://postgr.es/m/3004308.1632952496@sss.pgh.pa.us 回溯修補：14，即 Memoize 加入的版本 https://git.postgresql.org/pg/commitdiff/e502150f7d0be41e3c8784be007fa871a32d8a7f

  • 當非鍵參數變更時，清除 Memoize 快取。Memoize 節點下的子計畫可能包含來自 Memoize 節點上方的參數。如果此參數變更，則由於新的參數值，快取項目可能會過時。先前 Memoize 錯誤地沒有意識到這一點。我們在這裡透過在每次非快取鍵的一部分的參數變更時清除快取來修正這個問題。錯誤：#17213 報告者：Elvis Pranskevichus 作者：David Rowley 討論：https://postgr.es/m/17213-988ed34b225a2862@postgresql.org 回溯修補：14，即 Memoize 加入的版本 https://git.postgresql.org/pg/commitdiff/1050048a315790a505465bfcceb26eaf8dbc7e2e

  • 還原「當非鍵參數變更時，清除 Memoize 快取」。這會還原 commit 1050048a315790a505465bfcceb26eaf8dbc7e2e。https://git.postgresql.org/pg/commitdiff/dad20ad4709f602b4827a1ab2b0e715f36c548c3

  • 當非鍵參數變更時，清除 Memoize 快取，第二次嘗試。Memoize 節點下的子計畫可能包含來自 Memoize 節點上方的參數。如果此參數變更，則由於新的參數值，快取項目可能會過時。先前 Memoize 錯誤地沒有意識到這一點。我們在這裡透過在每次非快取鍵的一部分的參數變更時清除快取來修正這個問題。錯誤：#17213 報告者：Elvis Pranskevichus 作者：David Rowley 討論：https://postgr.es/m/17213-988ed34b225a2862@postgresql.org 回溯修補：14，即 Memoize 加入的版本 https://git.postgresql.org/pg/commitdiff/411137a429210e432f923264a8e313a9872910ca

Amit Kapila 推送

Robert Haas 推送

  • 修正在檢測到不正確的時間軸切換時的邊緣情況故障。rescanLatestTimeLine() 包含一個防護措施，以防止切換到在當前恢復點之前從當前時間軸分叉出來的時間軸，但如果時間軸切換發生在讀取第一個 WAL 記錄（必須是檢查點記錄）之前，則該防護措施不起作用。如果沒有此修補程式，在這種情況下，可能會發生不正確的時間軸切換。發生這種情況的原因是 rescanLatestTimeLine() 依賴於全域變數 EndRecPtr 來了解 WAL 重播的目前位置。但是，此時程式碼中的 EndRecPtr 包含上次重播記錄的端點，而不是現在重播記錄的起點或端點。因此，在重播任何記錄之前，它為零，這會導致健全性檢查始終通過。為了修復，請明確傳遞正確的時間軸。我們想要的 EndRecPtr 值來自 xlogreader，它將是我們將要嘗試讀取的記錄的起始位置，而不是全域變數，它是我們成功讀取的最後一條記錄的結束位置。它們通常相同，但在這裡描述的邊緣情況下則不然。沒有回溯修補，因為在 v14 及更早版本中，我們在這裡使用的 TLI 也是錯誤的，LSN 也是錯誤的。在 master 中，這已由 commit 4a92a1c3d1c361ffb031ed05bf65b801241d7cdd 修復，但它及其先決條件修補程式對於如此小問題而言，侵入性太強而無法進行回溯修補。我提供的修補程式，Amul Sul 審閱。討論：http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e7ea2fa342b008ae97e794b0fa2ee538ddcee3b7

  • xlog.c：移除全域變數 ReadRecPtr 和 EndRecPtr。在大多數情況下，變數必須儲存與我們在 WAL 重播期間使用的 XLogReaderState 的同名成員相同的值，因為 ReadRecord() 在 XLogReadRecord() 傳回後立即將這些值從結構成員指派給全域變數。但是，XLogBeginRead() 會調整結構成員，但不會調整全域變數，因此在 XLogBeginRead() 之後和 XLogReadRecord() 完成之前，這些值可能會有所不同。否則，它們必須相同。根據我的分析，唯一在可能與結構成員的值不相同的位置引用任一變數的地方是 XLogPageRead 內的 EndRecPtr 引用。因此，在我們使用全域變數的每個其他位置，我們可以改為切換到使用結構成員，並移除全域變數。但是，我們可以並且實際上應該在 XLogPageRead() 中也執行此操作，因為在程式碼中的該點，全域變數實際上將儲存我們要讀取的記錄的開始位置 - 要么是因為它是最後一個 WAL 記錄結束的位置，要么是因為自上次讀取記錄以來，已使用 XLogBeginRead 變更了讀取位置。另一方面，結構成員已經更新為指向我們剛讀取的記錄的結尾。在其他地方，後者是我們用作 emode_for_corrupt_record() 的參數，所以我們應該在這裡也這樣做。此修補程式的這部分可能是一個錯誤修復，但我認為它沒有任何重要的後果，因此沒有回溯修補。這裡的重點只是繼續減少 xlog.c 中完全過度使用全域變數的情況。討論：http://postgr.es/m/CA+Tgmoao96EuNeSPd+hspRKcsCddu=b1h-QNRuKfY8VmfNQdfg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d2ddfa681db27a138acb63c8defa8cc6fa588922

Heikki Linnakangas 推送

Andres Freund 推送

Daniel Gustafsson 推送