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

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

發布於 2021-08-10，作者 PWN
PWN

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

PGConf NYC 將於 2021 年 12 月 3-4 日舉行。CfP 徵稿正在開放，贊助機會亦同。

PostgreSQL 產品新聞

Pgpool-II 4.2.4、4.1.8、4.0.15、3.7.20 和 3.6.27，PostgreSQL 的連線池和語句複製系統，已發布

pgmoneta 0.4.0，PostgreSQL 的備份和還原系統，已發布

Buildfarm 13.1 軟體，PostgreSQL 專案的持續整合系統，已發布

dbForge Schema Compare 1.2 for PostgreSQL 已發布

pg_timetable 4.0.0，PostgreSQL 的工作排程器，已發布。https://github.com/cybertec-postgresql/pg_timetable/releases

本週人物

八月份的 PostgreSQL 工作機會

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

PostgreSQL 新聞

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

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

請在星期日下午 3:00 (PST8PDT) 之前將新聞和公告提交至 david@fetter.org。

已套用的 Patch

Amit Kapila 推送

Etsuro Fujita 推送

  • 修復 commit 1ec7fca8592178281cd5cdada0f27a340fb813fc 中的疏忽。我未能考慮到當 ExecAppendAsyncEventWait() 使用 postgres_fdw 通知多個具備非同步功能的節點時，前面的節點可能會調用 process_pending_request() 來處理後續節點提出的待處理非同步請求。在這種情況下，當收到通知時，後續節點應產生一個元組，以從 process_pending_request() 擷取的元組返回給父 Append 節點。修復。每個 buildfarm 透過 Michael Paquier。像之前的 commit 一樣，向後移植到 v14。感謝 Tom Lane 進行測試。討論：https://postgr.es/m/YQP0UPT8KmPiHTMs%40paquier.xyz https://git.postgresql.org/pg/commitdiff/a8ed9bd59d48c13da50ed2358911721b2baf1de3

  • postgres_fdw：修復外部資料表中產生欄位的問題。 postgres_fdw 從遠端資料表匯入產生的欄位作為普通欄位，並且在插入到外部資料表時，會導致諸如「ERROR: cannot insert a non-DEFAULT value into column "foo"」之類的故障，因為它嘗試將值插入到產生的欄位中。為了修復，我們在假設 postgres_fdw 外部資料表中的產生欄位的定義使其代表底層遠端資料表中的產生欄位的基礎上，執行以下操作： * 在插入或更新時，將 DEFAULT 發送到外部伺服器的產生欄位，而不是在本地伺服器上計算的產生欄位值。

  • 向 postgresImportForeignSchema() 新增一個選項 "import_generated"，以包含從外部伺服器匯入的外部資料表定義中的欄位產生表達式。預設情況下，該選項為 true。 該假設似乎是合理的，因為這樣會使對 postgres_fdw 外部資料表的查詢為產生欄位傳回與產生表達式一致的值。 在這裡，修復 postgresImportForeignSchema() 中的另一個問題：當啟用 import_default 選項時，它嘗試將欄位產生表達式作為外部資料表定義中的欄位預設表達式包含進來。每個 Daniel Cherniy 的錯誤 #16631。向後移植到新增產生欄位的 v12。討論：https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org https://git.postgresql.org/pg/commitdiff/aa769f80ed80b7adfbdea9a6bc267ba4aeb80fd7

Andres Freund 推送

Thomas Munro 推送

Tom Lane 推送

  • 文件：對邏輯複製協定文件的細微改進。在適當的地方，使用後端程式碼中資料類型的名稱來註釋訊息欄位資料類型，例如 XLogRecPtr 或 TimestampTz。以前我們只說“Int64”，這沒有提供那麼多的資訊。此外，闡明對物件 OID 的引用，並利用現有的約定來表示必須具有固定值的欄位的值。Vignesh C，由 Peter Smith 和 Euler Taveira 審閱。討論：https://postgr.es/m/CALDaNm0+fatx57KFcBopUZWQpH_tz3WKKfm-_eiTwcXui5BnhQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a5cb4f9829fbfd68655543d2d371a18a8eb43b84

  • 新增各式各樣的 regexp_xxx SQL 函數。這個修補程式新增了 regexp_count()、regexp_instr()、regexp_like() 和 regexp_substr() 這些函數，並擴展了 regexp_replace()，新增了一些可選參數。所有這些函數都遵循 Oracle 中使用的定義，儘管由於使用我們自己的 regexp 引擎，regexp 語言存在細微差異 —— 最值得注意的是，預設的換行符匹配行為有所不同。類似的函數也出現在 DB2 和其他地方。除了簡化移植性之外，對於某些任務，這些函數比我們現有的 regexp_match[es] 函數更容易使用。Gilles Darold，經我大幅修改。討論：https://postgr.es/m/fc160ee0-c843-b024-29bb-97b5da61971f@darold.net https://git.postgresql.org/pg/commitdiff/6424337073589476303b10f6d7cc74f501b8d9d7

  • 不要省略轉換為 typmod -1。將一個已經具有特定 typmod 的類型的值轉換為未指定的 typmod，就運行時行為而言，不會做任何事情。但是，它確實應該更改表示式的公開類型以匹配。到目前為止，coerce_type_typmod 並沒有處理這個問題，這在諸如遞迴聯集 (recursive unions) 之類的上下文中產生了陷阱。例如，如果聯集的一側是 numeric(18,3)，但它需要是 plain numeric 才能匹配另一側，則沒有直接的方法來表達這一點。通過插入一個 RelabelType 來更新表示式的公開類型，這很容易修復。但是，更改此行為有點令人不安，因為它已經存在很長時間了。（我強烈懷疑部分原因是該邏輯早於 7.0 中 RelabelType 的引入。57b30e8e2 的提交日誌訊息在這裡很有趣。）作為一個折衷方案，我們將偷偷地將此更改放入 14beta3 中，如果未來三個月內沒有出現投訴，則考慮向後移植到穩定分支。討論：https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5c056b0c2519e602c2e98bace5b16d2ecde6454b

  • 確實修復了 REFRESH MATERIALIZED VIEW CONCURRENTLY 中的歧義。與其嘗試選擇不會與任何可能的用戶定義的實體化視圖列名衝突的表別名，不如調整查詢的語法，以便別名僅在不會被誤認為是列名的地方使用。主要是寫成 "alias.*" 而不是僅僅 "alias"，這也為人類和機器增加了清晰度。我們確實存在 "SELECT alias.*" 的行為與 "SELECT alias" 不同的問題，但我們可以使用 ruleutils.c 用於 SELECT 列表中的整行變數的相同技巧：寫成 "alias.*::compositetype"。在完成此操作後，我們不妨恢復到原始別名；它們更容易閱讀。與 75d66d10e 一樣，向後移植到所有受支援的分支。討論：https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9179a82d7af38112cd0f6e84ab62d0b3592a6e0e

  • 使 regexp 引擎的 backref 相關編譯狀態更具防禦性。到目前為止，我們透過儲存指向相關 subRE 節點的指標來記住捕獲括號子表達式的定義。在之前這沒問題，因為在解析 regexp 的其餘部分時，不會再修改該 subRE。但是，在 commit ea1268f63 之後，情況不再如此：parseqatom() 的外部調用可以自由地塗寫該 subRE。儘管如此，這似乎仍然有效，因為我們在「準備通用狀態骨架」段落中塞入子 atom 的狀態在語義上與子 atom 的原始端點沒有真正的不同。但這很容易被破壞，而且絕對不是以前的工作方式。考慮到這一點以及先前提交中修復的問題，最好完全消除對 subRE 節點的這種依賴。我們不需要整個子 subRE 用於將來的 backref，只需要它的開始和結束 NFA 狀態；所以讓我們只儲存指向這些狀態的指標。此外，在我們建立一個額外的 subRE 來處理立即巢狀的捕獲括號的邊角情況下，似乎最好讓額外的 subRE 具有與原始子 subRE 相同的 begin/end 狀態 (s/s2 not lp/rp)。我認為從 lp 連結到 rp 實際上在語義上可能是錯誤的，但由於 Spencer 的原始程式碼是這樣做的，所以我不能完全確定。無論如何，使用 s/s2 肯定沒有錯。根據 Mark Dilger 的報告。向後移植到引入問題修補程式的 v14。討論：https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com https://git.postgresql.org/pg/commitdiff/cb76fbd7ec87e44b3c53165d68dc2747f7e26a9a

  • 修復 regexp 引擎中的 use-after-free 問題。Commit cebc1d34e 教導 parseqatom() 透過擺脫多餘的 subRE 節點來優化分支僅包含一個「雜亂」atom 的情況。我們真正應該做的是保留為「雜亂」子 atom 建構的 subRE；但是為了避免更改 parseqatom 的名義 API，我使其在將其欄位複製到 parsebranch() 建立的外部 subRE 之後刪除該節點。似乎當時這實際上是有效的；但在 ea1268f63 之後變得危險，因為後面的提交允許 parse() 的較低調用返回一個 subRE，該 subRE 也被某些 v->subs[] 條目指向。這意味著我們可能會在 v->subs[] 中得到一個懸空指標，從而導致後來的 backref 行為不正常，但前提是該 subRE struct 在這期間被重複使用。因此，損壞似乎僅限於 '((...))...(...\2' 之類的情況。為了修復這個問題，做我之前應該做的事情，並修改 parseqatom 的 API，使其可以刪除呼叫者的 subRE 而不是被呼叫者的 subRE。這更安全，因為我們知道 subRE 尚未完成，因此沒有其他地方會有指向它的指標。根據 Mark Dilger 的報告。向後移植到引入問題修補程式的 v14。討論：https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com https://git.postgresql.org/pg/commitdiff/cc1868799c8311ed1cc3674df2c5e1374c914deb

  • 重新思考 regexp 引擎的反向參照相關編譯狀態。在推送 cb76fbd7e 後幾乎立刻感到後悔，因為我發現從資料結構中移除捕獲子表達式的 subREs 會破壞我提議的 REG_NOSUB 優化補丁。恢復該資料結構的變更。取而代之，解決關於不變更捕獲子表達式端點的問題，方法是不變更端點。我們不需要變更，因為該位的重點只是確保原子具有與我們在分支之間串聯的外部狀態對不同的端點。我們已經在括號子表達式的情況下建立了合適的狀態，因此額外的狀態只是無用的開銷。這似乎比 Spencer 最初的編碼更容易理解，並且通過節省一些狀態建立和弧線變更，它應該也會稍微快一點。（我實際上在 Jacobson 的網路語料庫上看到了幾個百分點的改進，雖然這幾乎超出了雜訊基底，所以我不會對此結果抱有太大的期望。）此外，修復 ea1268f63 添加的邏輯，以確保 v->subs[subno] 中記錄的 subRE 正是 capno == subno 的那個。Spencer 最初的編碼記錄了捕獲節點的子 subRE，就擁有正確的端點狀態而言，這還可以，但從 cb76fbd7e 開始，捕獲 subRE 本身也總是具有這些端點。我認為這種不一致會讓 REG_NOSUB 優化感到困惑。和以前一樣，向後移植到 v14。討論：https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com https://git.postgresql.org/pg/commitdiff/00116dee5ad4c1964777c91e687bb98b1d9f7ea0

  • 文件：移除虛假的 <indexterm> 項目。顯然是 665c5855e 中的複製貼上錯誤。9.6 文件工具鏈抱怨重複的索引條目，雖然我們現代的工具鏈沒有。無論如何，這些 GUC 肯定不是關於這些值的預設設定。https://git.postgresql.org/pg/commitdiff/cf5ce5aa70d33fc3048ab63c50585b8cc0f11dfd

David Rowley 推送了

  • 在 RelOptInfo 中追蹤未修剪分區的 Bitmapset。對於具有大量分區的分割資料表，且查詢能夠修剪除極少數分區之外的所有分區，規劃器在 RelOptInfo.part_rels 上循環檢查非 NULL RelOptInfos 所花費的時間可能佔據整體規劃時間的很大一部分。在這裡，我們添加一個 Bitmapset 來記錄未修剪的分區。這允許我們通過循環遍歷 Bitmapset 來更有效地跳過修剪的分區。這會在無法修剪或修剪不多分區的情況下導致非常輕微的減速，但是，這些情況已經很難規劃，並且與其他任務（例如為大量分區建立路徑）相比，循環遍歷 Bitmapset 的開銷將是無法衡量的。Reviewed-by: Amit Langote, Zhihong Yu 討論：https://postgr.es/m/CAApHDvqnPx6JnUuPwaf5ao38zczrAb9mxt9gj4U1EKFfd4AqLA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/475dbd0b718de8ac44da144f934651b959e3b705

  • 允許在更多情況下進行有序分區掃描。959d00e9d 添加了使用 Append 節點而不是 MergeAppend 的功能，當我們想要執行分割資料表的掃描，並且所需的排序順序與分割鍵相同，並且分割資料表的定義方式保證較早的分區僅包含低於較晚分區的值時。但是，以前，當存在允許使用多個 Datums 的分區時，我們不允許對 LIST 分割資料表進行這些有序分區掃描。這是一個非常簡單的檢查，如果我們檢查是否存在交錯分區，我們可能會做得更好，但當時我們無法知道哪些分區已被修剪，因此我們仍然可能不允許所有交錯分區都被修剪的情況。自 475dbd0b7 以來，我們現在了解已修剪的分區，我們可以在 partitions_are_ordered() 內部做得更好。在這裡，我們將從分區修剪中倖存的分區傳遞到 partitions_are_ordered()，並且對於 LIST 分區，讓它檢查是否存在任何位於 PartitionBoundInfo 中定義的新 "interleaved_parts" 欄位中的活動分區。對於 RANGE 分區，我們可以放鬆代碼，該代碼在存在 DEFAULT 分區時導致分區無序。由於我們現在知道哪些分區已被修剪，因此當 DEFAULT 分區已被修剪時，partitions_are_ordered() 現在返回 true。Reviewed-by: Amit Langote, Zhihong Yu 討論：https://postgr.es/m/CAApHDvrdoN_sXU52i=QDXe2k3WAo=EVry29r2+Tq2WYcn2xhEA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/db632fbca392389807ffb9d9b2207157e8e9b3e8

  • 移除未使用的函數宣告。似乎宣告了 check_track_commit_timestamp，但從未在我們的程式碼庫中定義。這很可能是原始補丁的開發版本中添加 commit timestamps 後留下的殘餘物。讓我們移除無用的宣告。包含 guc.h 似乎也是多餘的。Author: Andrey Lepikhov 討論：https://postgr.es/m/f49aefb5-edbb-633a-af07-3e777023a94d@postgrespro.ru https://git.postgresql.org/pg/commitdiff/75a2d132eaef7d951db894cf3201f85e9a524774

Bruce Momjian 推送了

Peter Geoghegan 推送了

Dean Rasheed 推送了

  • 修正 to_char() 中 'EEEE' 格式的除以零錯誤。修正了使用 to_char() 格式化科學記號表示法的數值時的一個長期存在的錯誤 -- 如果該值的指數小於 -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001)，則會產生除以零的錯誤。此錯誤的原因是 get_str_from_var_sci() 將其輸入除以 10^exp，這是使用 power_var_int() 產生的。但是，power_var_int() 中的下溢測試會使其在結果比例太小時返回零。對於 power_var_int() 的另一個唯一呼叫者 power_var() 來說，這不是問題，因為該呼叫者將 rscale 限制為 1000，但在 get_str_from_var_sci() 中，指數可以小得多，需要更大的 rscale。通過引入一個新函數來直接計算 10^exp，而沒有 rscale 限制來解決此問題。這也使得 10^exp 可以更有效地計算，而無需任何數值乘法、除法或四捨五入。討論：https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/226ec49ffd78c0f246da8fceb3094991dd2302ff

  • 調整 numeric 程式碼中的整數溢位測試。以前，numeric 程式碼通過將較大型別的整數值轉換為較小型別，然後測試反向轉換是否產生原始值來測試該整數值是否適合較小型別。除了它在 buildfarm 動物 castoroides 上導致測試失敗（很可能是由於編譯器錯誤）之外，這完全沒問題。取而代之的是，通過與 PG_INT16/32_MIN/MAX 進行比較來進行這些測試。這與其他地方（例如 int84()）的現有程式碼相符，經過更廣泛的測試，因此不太可能出錯。同時，添加涵蓋 numeric-to-int8/4/2 轉換的回歸測試，並將最近添加的測試調整為 434ddfb79a（在 v11 分支上）的風格，以使故障更容易診斷。每個 buildfarm 通過 Tom Lane，由 Tom Lane 審閱。討論：https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2642df9fac09540c761441edd9bdd0a72c62f39c

Fujii Masao 推送了

Peter Eisentraut 推送了