2025年9月25日: PostgreSQL 18 发布！

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 版本的工具，已發佈。

2021 年 8 月 PostgreSQL 工作岗位

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

PostgreSQL 相关新闻

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

本周 PostgreSQL 周报由 David Fetter 提供。

请在太平洋标准时间（PST8PDT）周日晚上3:00之前将新闻和公告发送至 david@fetter.org。

已应用补丁

Michaël Paquier 提交

Bruce Momjian 已推送

Álvaro Herrera 提交

Tom Lane 提交

  • 防止 regex 反向引用有時在不應該匹配時進行匹配。cdissect() 中的遞歸在拒絕部分匹配後，對清除捕獲括號的匹配數據時不夠謹慎。這可能導致後續的反向引用成功，儘管它實際上應該因為沒有定義的引用而失敗。為了解決這個問題，需要更嚴格地考慮 cdissect 遞歸的各個級別之間的合同。有了正確的規範，我們可以通過更少的重置匹配數據來修復這個問題；關鍵決定是，一個失敗的子匹配現在應負責清除它可能設置的任何匹配。代碼中有足夠多的交叉檢查和優化，使得展示這個問題並不那麼容易；通常，匹配會按預期失敗。此外，即使可能容易受到攻擊的正規表達式，大多數情況下也是用戶錯誤，因為編寫一個沒有始終有引用的反向引用的正規表達式沒有多大意義。這些事實可能解釋了為什麼這個問題沒有被發現，儘管它幾乎肯定是幾十年前就存在的。討論：https://postgr.es/m/151435.1629733387@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9bbf6f7341f2b5a8ce41d838154380faa7346101

  • 修復正規表達式中包含 "{0}" 的捕獲括號的誤行為。類似 "(.){0}...\1" 的正規表達式會出現 "無效的反向引用號"。從表面上看，這並不奇怪，因為如果捕獲組被迭代零次，它將永遠不會被匹配。然而，像 Perl 的引擎等其他引擎不會對此抱怨，我們也不會為相關情況（如 "(.)|\1"，儘管該反向引用永遠不會成功）拋出錯誤。此外，如果零次迭代的情況發生在運行時而不是編譯時——例如，當找不到 "x" 時為 "(x)*...\1"——這也不是錯誤，我們只會認為反向引用不匹配。更糟糕的是，對於嵌套情況，如 "((.)){0}...\2"，沒有拋出錯誤；而且，更糟糕的是，這些情況可能導致斷言失敗。（儘管在非斷言構建中似乎沒有發生特別糟糕的事情。）讓我們修復它，使其不再拋出錯誤，而是認為反向引用永遠不匹配，以便零次迭代的編譯時檢測與運行時檢測相同。根據 Mark Dilger 的報告。這似乎是 Spencer 庫中的一個原始錯誤，因此向後移植到所有支持的版本。在 v14 之前，我們還需要向後移植 commit cb76fbd7e/00116dee5 的一個方面，即創建捕獲節點 subRE，使其具有子表達式的 begin/end 狀態，而不是外部 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"，所以我們不需要兩者。Commit ffd3944ab 中的疏忽，由 tanghy.fnst 發現。順便，換行附近的一個測試使其更具可讀性。討論：https://postgr.es/m/OS0PR01MB61137C4054774F44E3A9DC89FBC69@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/373e08a9f771e724efd3bd29f78c39515792dcf3

  • 更誠實地處理正規表達式 makesearch 和 MATCHALL 的交互。對 commit 824bf7190 的二次思考：我們在確定一個 NFA 是否為 MATCHALL 模式後，對其應用 makesearch()。在前面加上 ".*" 並不會使其變為非 MATCHALL，但它確實改變了最大可能匹配長度，而 makesearch() 並未更新該值。考慮到 search NFAs 的風格化用法，這沒有產生任何不良影響，但保持數據結構的一致性似乎更好。特別是，修復此問題使得 matchuntil() 中對 MATCHALL 的檢查能更誠實地處理：我們現在可以斷言 maxmatchall 是無窮大，而不是愚蠢地假設它應該這樣工作。順便，改進 dump[c]nfa 中的代碼，以便將無限的 maxmatchall 打印為 "inf" 而不是一個魔術數字。 https://git.postgresql.org/pg/commitdiff/8f72becd6b9484fbb429651d8859faa36532a35a

  • 在 pg_stat 統計信息中計算 SP-GiST 索引掃描。不知何故，spgist 忽略了調用 pgstat_count_index_scan() 的需要。因此，對於 SP-GiST 索引，pg_stat_all_indexes.idx_scan 和等價列從未變成非零，儘管相關的每元組計數器工作正常。此修復與其他索引 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

  • 文檔：在 src/backend/regex/README 中添加有關 LACON 執行的簡要說明。我在考慮一個可能的優化時寫了這個，但無論優化是否發生，它都是對現有代碼的有用的描述。因此，單獨推送。 https://git.postgresql.org/pg/commitdiff/10d58228bb1c824c5124ecd1b6c5e46a3c157a39

Amit Kapila 提交

  • 修復 Alter Subscription 的 Add/Drop Publication 行為。當前的刷新行為試圖只刷新添加/刪除的 publication，但這會導致從 subscription 中刪除錯誤的表。我們不能只刷新刪除的 publication，因為它很有可能一些表已經在那時被從 publication 中移除了，現在這些表將作為 subscription 的一部分保留。此外，被刪除的 publication 的表也可能屬於另一個 publication，所以我們不能刪除它們。因此，我們決定默認情況下，add/drop 命令也將像 REFRESH PUBLICATION 一樣工作，這意味著它們將刷新所有 publication。我們可以為 "add publication" 保留舊行為，但與 "drop publication" 保持一致更好。作者：Hou Zhijie 審閱者：Masahiko Sawada, Amit Kapila 向後移植至：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 數據。為了解決這個問題，我們也為內部創建的 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 添加邏輯更改詳細信息。先前，在訂閱者端，我們為元組數據轉換失敗設置了錯誤上下文回調。此提交用一個全面的回調替換了現有的錯誤上下文回調，以便它不僅顯示數據轉換失敗的詳細信息，還顯示 apply worker 或 table sync worker 正在應用的邏輯更改的詳細信息。額外顯示的信息將是命令、事務 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 在工作進程中被正確設置。最簡單的方法似乎是將 leader 的活動快照安裝為事務快照，如果 leader 沒有序列化事務快照。這不會影響未來 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 推送

  • 修復 CREATE TABLESPACE 的 wal_level=minimal 崩潰恢復中的數據丟失。如果在 CREATE TABLESPACE 和下一個 checkpoint 之間系統崩潰，結果可能是某些表空間的文件意外地不包含任何行。受影響的文件將是系統未寫入 WAL 的文件；請參見 wal_skip_threshold 文檔。在 v13 之前，不同的條件決定了 WAL 的寫入；請參見 v12 的 <sect2 id="populate-pitr">。（v12 的條件在某些方面更寬泛，在另一些方面更狹窄。）用戶可能希望審查非默認表空間是否有意外的短文件。該錯誤可能截斷了索引而不影響相關表，重新索引該索引將解決該特定問題。此修復通過使 create_tablespace_directories() 更像 TablespaceCreateDbspace() 來解決此錯誤。create_tablespace_directories() 遞歸地刪除表空間內容，理由是 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