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

PostgreSQL 每週新聞 - 2021 年 8 月 29 日

發布於 2021-08-30 作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 8 月 29 日

PostgreSQL 產品新聞

pg_dbms_job 1.0.1，一個用於建立、管理和使用 Oracle 風格 DBMS_JOB 排程任務的擴充功能，已發布。

dbMigration .NET v14.4，一個資料庫遷移和同步工具，已發布。

WAL-G 1.1，一個用 Go 編寫的 PostgreSQL 和其他資料庫的備份管理系統，已發布。

pglogical 2.4.0，一個基於邏輯 WAL 的 PostgreSQL 複製系統，已發布。

Crunchy PostgreSQL Operator 5.0.0，一個用於在 Kubernetes 上部署和管理開源 PostgreSQL 叢集的系統，已發布。

set_user 2.0.1，一個允許權限提升並增強日誌記錄和控制的擴充功能，已發布。

AGE 0.5.0，一個提供圖形資料庫功能的 PostgreSQL 擴充功能，已發布。

pg_msvc_generator 1.0.0 beta，一個用於製作擴充功能 Windows 版本的工具，已發布。

PostgreSQL 八月份的工作

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

PostgreSQL 新聞

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

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

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

已套用的修補程式

Michaël Paquier 推送了

Bruce Momjian 推送了

Álvaro Herrera 推送了

Tom Lane 推送了

  • 防止 regexp 反向引用在不該匹配時有時卻匹配到的問題。 cdissect() 中的遞迴在拒絕部分匹配後，沒有仔細清除捕獲括號的匹配數據。這可能導致後續的反向引用在按理說因為缺少定義的指涉對象而應該失敗時，反而成功。為了修正此問題，需要更嚴謹地思考 cdissect 不同層級遞迴之間的契約應該是什麼。有了正確的規範，我們可以使用更少的重置匹配數據來修正這個問題，關鍵的決定是失敗的子匹配現在明確負責清除它可能設置的任何匹配。程式碼中存在足夠多的交叉檢查和最佳化，因此不容易展示這個問題；通常，匹配會如預期般失敗。此外，即使是可能容易受到攻擊的 regexp 也最可能是使用者錯誤，因為編寫一個並非始終具有指涉對象的反向引用沒有太大意義。這些事實或許解釋了為什麼這個問題一直沒有被檢測到，即使它幾乎可以肯定已經存在幾十年了。討論：https://postgr.es/m/151435.1629733387@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9bbf6f7341f2b5a8ce41d838154380faa7346101

  • 修正 regexp 在 "{0}" 內使用捕獲括號時的錯誤行為。 像 "(.){0}...\1" 這樣的 regexp 會產生 "invalid backreference number" 的錯誤。 從表面上看，這並非不合理，因為如果捕獲組迭代零次，則永遠不會匹配。 但是，其他引擎（例如 Perl）不會對此提出抱怨，我們也不會對相關情況（例如 "(.)|\1"）拋出錯誤，即使該反向引用也永遠無法成功。 此外，如果零迭代的情況發生在執行時期而不是編譯時期，例如，當找不到任何 "x" 時的 "(x)*...\1" --- 這不是錯誤，我們只是認為反向引用不匹配。 更令人難以辯解的是，對於嵌套的情況（例如 "((.)){0}...\2"）沒有拋出任何錯誤；更糟糕的是，這些情況可能會導致斷言失敗。 （似乎在非斷言建置版本中沒有發生特別糟糕的事情。） 我們只需修正它，以便不拋出任何錯誤，而是認為反向引用永遠不會匹配，以便編譯時期的零迭代檢測與執行時期的檢測行為相同。 根據 Mark Dilger 的報告。 這似乎是 Spencer 程式庫中的一個原始錯誤，因此回溯修補到所有支援的版本。 在 v14 之前，事實證明還有必要回溯修補 commit cb76fbd7e/00116dee5 的一個方面，即創建具有其子表達式的 begin/end 狀態的捕獲節點 subRE，而不是外部 parseqatom 調用的當前 lp/rp。 否則 delsub 會抱怨我們試圖將一個狀態與自身斷開連接。 這有點可怕，但程式碼檢查表明它是安全的：在 v14 之前的程式碼中，如果我們想圍繞子表達式進行迭代，我們要做的第一件事就是用新狀態覆蓋 atom 的 begin/end 欄位。 因此，虛假值沒有存活足夠長的時間來用於任何目的，除非不需要迭代，在這種情況下，它並不重要。 討論：https://postgr.es/m/A099E4A8-4377-4C64-A98C-3DEDDC075502@enterprisedb.com https://git.postgresql.org/pg/commitdiff/65dc30ced64cd17f3800ff1b73ab1d358e92efd8

  • 移除多餘的測試。 條件 "context_start < context_end" 嚴格弱於 "context_end - context_start >= 50"，因此我們不需要兩者。 ffd3944ab commit 中的疏忽，由 tanghy.fnst 指出。 順便一提，將附近的測試換行，使其更易於閱讀。 討論：https://postgr.es/m/OS0PR01MB61137C4054774F44E3A9DC89FBC69@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/373e08a9f771e724efd3bd29f78c39515792dcf3

  • 更誠實地處理 regexp 的 makesearch 和 MATCHALL 的交互作用。 關於 commit 824bf7190 的重新思考：在確定 NFA 是否為 MATCHALL 模式後，我們將 makesearch() 應用於 NFA。 前置 ".*" 不會使其成為非 MATCHALL，但它確實改變了最大可能的匹配長度，並且 makesearch() 未能更新它。 考慮到搜尋 NFA 的典型用法，這沒有不良影響，但保持數據結構一致似乎更好。 特別是，修正此問題允許更誠實地處理 matchuntil() 中的 MATCHALL 檢查：我們現在可以斷言 maxmatchall 是無限的，而不是僅僅假設它應該以這種方式運作。 順便一提，改進 dump[c]nfa 中的程式碼，以便將無限的 maxmatchall 列印為 "inf" 而不是一個幻數。 https://git.postgresql.org/pg/commitdiff/8f72becd6b9484fbb429651d8859faa36532a35a

  • 在 pg_stat 統計資訊中計算 SP-GiST 索引掃描。 不知何故，spgist 忽略了調用 pgstat_count_index_scan() 的需求。 因此，pg_stat_all_indexes.idx_scan 和等效的欄位對於 SP-GiST 索引永遠不會變為非零，儘管相關的 per-tuple 計數器運作正常。 這個修復程式的運作方式與其他索引 AM 有點不同，因為計數器增量發生在 spgrescan 而不是 spggettuple/spggetbitmap 中。 看起來這不會使使用者可見的語義產生明顯的差異，所以我不會費力引入一個 is-this- the-first-call 標誌，只是為了使計數器增量發生在相同的位置。 根據 Christian Quest 提供的 bug #17163。 回溯修補到所有支援的版本。 討論：https://postgr.es/m/17163-b8c5cc88322a5e92@postgresql.org https://git.postgresql.org/pg/commitdiff/3778bcb39a94a3b6a821fd60fcd9919a95725e78

  • Doc: 在 src/backend/regex/README 中新增一些關於 LACON 執行的內容。 我在考慮可能的最佳化時寫了這個，但無論最佳化是否發生，它都是對現有程式碼的一個有用的描述。 所以單獨推送它。 https://git.postgresql.org/pg/commitdiff/10d58228bb1c824c5124ecd1b6c5e46a3c157a39

Amit Kapila 推送

  • 修正 Alter Subscription 的 Add/Drop Publication 行為。 目前的重新整理行為試圖僅重新整理新增/刪除的發布，但這會導致從訂閱中移除錯誤的表格。 我們無法僅重新整理刪除的發布，因為很可能某些表格在那時已從發布中移除，現在這些表格將保留為訂閱的一部分。 此外，屬於被刪除發布的表格也有可能屬於另一個發布，因此我們無法移除這些表格。 因此，我們決定預設情況下，add/drop 命令也將像 REFRESH PUBLICATION 一樣運作，這意味著它們將重新整理所有發布。 我們可以為 "add publication" 保留舊的行為，但最好與 "drop publication" 保持一致。 作者：Hou Zhijie 審閱者：Masahiko Sawada, Amit Kapila Backpatch-through：14，即它被引入的地方 討論：https://postgr.es/m/OS0PR01MB5716935D4C2CC85A6143073F94EF9@OS0PR01MB5716.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/1046a69b3087a6417e85cae9b6bc76caa22f913b

  • 修正邏輯解碼中的 TOAST 重寫問題。Commit 325f2ec555 引入了 pg_class.relwrite，用於跳過 DDL 期間作為堆重寫一部分建立的表格上的操作。它透過 pg_class 中的這個新欄位將這些暫時性的堆連接到原始關係 OID，但忘記處理 TOAST 表格。因此，邏輯解碼無法跳過內部建立的 TOAST 表格上的操作。這導致一個錯誤，當我們嘗試解碼下一個操作的 WAL 時，錯誤顯示應該有 TOAST 資料，但實際上並沒有。為了修正這個問題，我們也為內部建立的 TOAST 表格設定了 pg_class.relwrite，允許在邏輯解碼期間跳過對它們的操作。作者：Bertrand Drouvot 審閱者：David Zhang, Amit Kapila 回溯修補：11，即引入該問題的版本 討論：https://postgr.es/m/b5146fb1-ad9e-7d6e-f980-98ed68744a7c@amazon.com https://git.postgresql.org/pg/commitdiff/29b5905470285bf730f6fe7cc5ddb3513d0e6945

  • 將邏輯變更的詳細資訊添加到邏輯複製工作程序 errcontext。先前，在訂閱者端，我們為元組資料轉換失敗設定了錯誤上下文回呼。此 commit 使用一個更全面的回呼替換了現有的錯誤上下文回呼，以便它不僅顯示資料轉換失敗的詳細資訊，還顯示由套用工作程序或表格同步工作程序套用的邏輯變更的詳細資訊。顯示的額外資訊將是命令、交易 ID 和時間戳記。僅當套用變更時才會將錯誤上下文添加到錯誤中，而不是在執行接收資料等其他工作時。這將有助於使用者診斷邏輯複製期間發生的問題。它也可用於未來允許跳過訂閱者端特定交易的工作。作者：Masahiko Sawada 審閱者：Hou Zhijie, Greg Nancarrow, Haiying Tang, Amit Kapila 測試者：Haiying Tang 討論：https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/abc0910e2e0adfc5a17e035465ee31242e32c4fc

Fujii Masao 推送

Etsuro Fujita 推送

Peter Eisentraut 推送

Robert Haas 推送

  • 修正並行工作程序中損壞的快照處理。Pengchengliu 報告了一個並行工作程序在使用溢出的快照執行並行掃描時出現的斷言失敗。最直接的原因是 TransactionXmin 被設定為不正確的值。根本原因是 parallel.c 中不正確的快照處理。特別是，InitializeParallelDSM() 無條件地呼叫 GetTransactionSnapshot()，因為我 (rhaas) 錯誤地認為這總是檢索現有的快照，而實際上，在低於 REPEATABLE READ 的隔離等級下，它實際上正在取得一個新的快照。因此，相反，僅在較高的隔離等級下執行此操作，在這些等級下，整個交易實際上只有一個快照。就其本身而言，這不是一個充分的修正，因為我們仍然需要保證 TransactionXmin 在工作程序中得到正確設定。最簡單的方法似乎是將領導者的活動快照安裝為交易快照，如果領導者沒有序列化交易快照。這不會影響未來 GetTrasnactionSnapshot() 呼叫的結果，因為無論如何都需要取得一個新的快照；我們關心的是設定 TransactionXmin 的副作用。報告者：Pengchengliu。補丁作者：Greg Nancarrow，除了我提供的一些註釋文本。討論：https://postgr.es/m/002f01d748ac$eaa781a0$bff684e0$@tju.edu.cn https://git.postgresql.org/pg/commitdiff/a780b2fcce6cf45462946fffcd84021a4d1429c8

John Naylor 推送

Peter Geoghegan 推送了

Daniel Gustafsson 推送了

Stephen Frost 推送了

Noah Misch 推送了

  • 修正在 `wal_level=minimal` 時，`CREATE TABLESPACE` 指令在崩潰後回復可能造成資料遺失的問題。如果系統在 `CREATE TABLESPACE` 指令執行後，且下一次檢查點 (checkpoint) 執行前崩潰，可能會導致 tablespace 中某些檔案意外地不包含任何資料列。受影響的檔案會是那些系統沒有寫入 WAL 的檔案，請參閱 `wal_skip_threshold` 文件。在 v13 之前，寫入 WAL 的條件由另一組條件決定；請參閱 v12 的 <sect2 id="populate-pitr">。（v12 的條件在某些方面更廣泛，在另一些方面更狹窄。）使用者可能需要審查非預設的 tablespace，以檢查是否有意外的短檔案。此錯誤可能已截斷索引，而未影響相關的資料表，重新建立索引將修復該特定問題。此修復透過使 `create_tablespace_directories()` 更像 `TablespaceCreateDbspace()` 來解決此錯誤。`create_tablespace_directories()` 過去會遞迴地移除 tablespace 的內容，理由是 WAL 重做會重新建立以這種方式移除的所有內容。此假設適用於其他 `wal_level` 值。在 `wal_level=minimal` 下，舊方法可能會刪除不存在其他副本的檔案。向後移植到 9.6（所有受支援的版本）。由 Robert Haas 和 Prabhat Sahu 審閱。由 Robert Haas 報告。討論：https://postgr.es/m/CA+TgmoaLO9ncuwvr2nN-J4VEP5XyAcy=zKiHxQzBbFRxxGxm0w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/97ddda8a82ac470ae581d0eb485b6577707678bc