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

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

張貼於 2021-08-23 由 PWN
PWN

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

本週人物

PostgreSQL 產品新聞

orafce_mail，一個類似於 Oracle 的 DBMS_MAIL 的工具，已發布。

八月份的 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 推送

  • 在 recovery_min_apply_delay 重新載入時，刷新應用程式延遲。 此提交確保在重播由 recovery_min_apply_delay 定義的時間量時，重播延遲迴圈中的等待間隔在重新載入時得到正確處理，如果此 GUC 值已更新，則根據正在重播的提交記錄的時間戳重新計算延遲。 之前的行為對於例如即使延遲已減少或取消，重播仍在等待的情況下會出現問題。 如果應用程式延遲增加到更大的值，則等待將僅尊重舊值，並提前完成。 作者：Soumyadeep Chakraborty、Ashwin Agrawal 審閱者：Kyotaro Horiguchi、Michael Paquier 討論：https://postgr.es/m/CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com 回溯修補：9.6 https://git.postgresql.org/pg/commitdiff/e4ba1005c0f7a95e3252f38aee02426117b8e12b

  • 將十六進制程式碼的重構還原到 src/common/。 這是以下提交的組合還原： - c3826f8，一個重構部分，將十六進制解碼程式碼移動到 src/common/。 此程式碼已由 aef8948 清理，因為它最初未包含與 SCRAM 使用的 src/common/ 中的 base64 例程相同方式的溢位檢查，這使其對於其目的而言是不安全的。 - aef8948，對十六進制編碼/解碼程式碼進行更高級的重構到 src/common/，這增加了對十六進制解碼和編碼的結果緩衝區的健全性檢查。 根據 Hans Buschmann 的報告，這些溢位檢查非常昂貴，並且可以看到 bytea 或 LO 的解碼/編碼的效能下降，它們越長。 處理大型 bytea 值的簡單 SQL 在效能分析中顯示出明顯的差異。 - ccf4e27，由 aef8948 實現的清理。 所有這些提交的回復都將十六進制解碼和編碼的效能恢復到 ~13 中的狀態。 現在和 beta3 之後，這是最簡單的選擇。 報告者：Hans Buschmann 討論：https://postgr.es/m/1629039545467.80333@nidsa.net 回溯修補：14 https://git.postgresql.org/pg/commitdiff/2576dcfb76aa71e4222bac5a3a43f71875bfa9e8

  • 提高 btree_gist 中浮點溢位檢查的效能。 目前的程式碼可能會對 isinf() 進行不必要的呼叫（對於參數值始終為兩個，而在某些情況下一個就足夠了）。 zero_is_valid 從未使用過，但仍檢查結果值在檢查的第一個位置是否為 0。 這與 607f8ce 類似。 btree_gist 只是從後端 float4/8 程式碼複製-貼上程式碼，即巨集 CHECKFLOATVAL()，以完成工作。 作者：Haiying Tang 討論：https://postgr.es/m/OS0PR01MB611358E3A7BC3C2F874AC36BFBF39@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/32cf7f7acce3891cbc3de53327704372bdd36d38

Daniel Gustafsson 推送

John Naylor 推送

Tom Lane 推送

  • 減少未決失效訊息的記憶體消耗。inval.c 中的現有資料結構對於指令或子交易註冊少量快取失效事件的常見情況來說效率較低。雖然如果我們立即提交則沒有關係，但在包含許多 DDL 操作的事務中，它可能會累積成大量的膨脹。透過對預期的用例進行更多假設，我們可以切換到使用密集封裝陣列的表示法。雖然這消除了部分資料複製，但似乎在時間上沒有太大差異。但空間消耗顯著減少。由我撰寫的修補程式；感謝 Nathan Bossart 的審閱。討論：https://postgr.es/m/2380555.1622395376@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3aafc030a53621e91be2e7c1c72b5f3e8b103486

  • 改進 regex 編譯器的弧移動/複製邏輯。函數 moveins()、copyins()、moveouts()、copyouts() 需要保留 regex 的 NFA 中沒有重複弧的不變性。Spencer 的原始實作是 O(N^2)，因為它會分別檢查每個源弧是否匹配。在 commit 579840ca0 中，我透過新增排序/合併邏輯來改進了這一點，以便在移動/複製多個弧時使用。但是，我現在意識到錯失了一個機會。在許多呼叫站點，目標狀態是新建立的，並且不能有任何可能重複的現有入弧（分別是出弧）。因此，在檢查重複項上花費任何週期都是浪費精力；在這些情況下，我們可以盲目地移動/複製所有源弧。新增程式碼路徑來執行此操作。結果表明，對於 copyins()/copyouts()，所有呼叫站點都具有此屬性，從而使它們中的所有「改進」邏輯完全無法訪問。也許有一天我們再次需要完整的功能，所以我只是使用 #ifdef 將這些路徑排除，而不是完全刪除它們。順便一提，新增一些測試案例以改善此區域以及 regc_locale.c/regc_pg_locale.c 中的程式碼涵蓋率。討論：https://postgr.es/m/810272.1629064063@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/78a843f119ca7d4a6eb173a7ee3bed45889d48d8

  • 減少對新 regex 測試中 locale 行為的假設。我過於樂觀地認為基於 UTF8 的 locale 都會認為 U+1500 是 [[:alpha:]] 字元類別的成員。調整 commit 78a843f11 新增的測試案例，以避免此假設。我們可能需要進一步刪減它們，但這應該足以修復早期的 buildfarm 報告。https://git.postgresql.org/pg/commitdiff/b66336c4e1af0e8eae520623e4b018251807b0bb

  • 防止 ALTER TYPE/DOMAIN/OPERATOR 變更擴充功能成員資格。如果在擴充功能更新腳本期間對預先存在的獨立物件調用 recordDependencyOnCurrentExtension，則該物件將歸擴充功能所有。在我們目前的程式碼中，這在三種情況下是可能的：* 替換「shell」類型或運算子。* CREATE OR REPLACE 覆寫現有物件。* ALTER TYPE SET、ALTER DOMAIN SET 和 ALTER OPERATOR SET。第一種情況是故意的行為，如 GenerateTypeDependencies 的現有註釋所述。CREATE OR REPLACE 似乎也是合適的行為；至少，明顯的替代方案並不好。但是，它在 ALTER 期間發生的事實是嘗試在 CREATE 和 ALTER 案例之間共享程式碼（GenerateTypeDependencies 和 makeOperatorDependencies）的人工產物。由於擴充功能腳本不太可能 ALTER 不屬於擴充功能的物件，因此此行為對於直接目標物件來說並不太令人不安...但 ALTER TYPE SET 將遞迴到相依的網域，並且如果這些網域尚未歸擴充功能所有，則它們歸擴充功能所有非常不好。讓我們透過重新定義 ALTER 案例來解決此問題，使其永遠不會變更擴充功能成員資格，完全停止。我們可以透過僅在 ALTER TYPE SET 遞迴到網域時變更行為來最大程度地減少行為變更，但這會使程式碼複雜化，並且看起來不是一個更好的定義。依照 Alex Kozhemyakin 的錯誤 #17144。回溯修補至新增 ALTER TYPE SET 的 v13。（其他案例較舊，但由於它們只影響直接命名的物件，因此沒有足夠的問題來證明進一步變更行為是合理的。）討論：https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org https://git.postgresql.org/pg/commitdiff/6b71c925cb817f79cb0d389edacdd033efaa301d

  • 修正 check_agg_arguments 對聚合 FILTER 子句的檢查。FILTER 子句的遞迴實作錯誤，因此會忽略 FILTER 子句最頂端的相關 Var 或 Aggref。（當然，這必須是純布林 Var 或傳回布林的聚合。）後果將是錯誤地識別聚合的正確語義層級，這可能導致不符合規格的查詢行為。如果 FILTER 表達式是一個聚合，這也可能導致未能發出預期的「聚合函數呼叫不能巢狀」錯誤，這很可能會在稍後導致核心轉儲，因為規劃器和執行器不希望出現這種情況。根本原因是 commit b560ec1b0 盲目地複製了一些程式碼，這些程式碼假設它正在遞迴到一個 List，因此沒有檢查最上層的節點。為了阻止人們詢問為什麼此呼叫看起來與其他呼叫不同，以及將來可能出現的複製貼上錯誤，讓我們變更 check_agg_arguments 中的所有三個 check_agg_arguments_walker 呼叫，即使只有一個用於篩選子句的呼叫確實已損壞。依照 Zhiyong Wu 的錯誤 #17152。自我們實作 FILTER 以來，這一直是錯誤的，因此回溯修補到所有受支援的版本。（測試表明，由於 ExecInitAgg 中的「冗餘」檢查，v11 之前的分支設法避免在 bad-Aggref 案例中崩潰。但我不確定這種保護有多徹底，而且無論如何，錯誤行為問題仍然存在，因此也修復了 9.6 和 10。）討論：https://postgr.es/m/17152-c7f906cc1a88e61b@postgresql.org https://git.postgresql.org/pg/commitdiff/2313dda9d493d3685ac7328b49dc6f5a87c1c295

  • 避免嘗試使用 FOR UPDATE 鎖定規則中的 OLD/NEW。在處理規則的查詢時，transformLockingClause 忽略了排除 OLD/NEW 的偽 RTE。這導致了稍後的奇怪錯誤甚至崩潰。這個錯誤非常古老，但沒有人注意到它並不令人驚訝，因為在非視圖規則中使用 SELECT FOR UPDATE 的情況介於稀少和不存在之間。儘管如此，崩潰是不行的。依照 Zhiyong Wu 的錯誤 #17151。感謝 Masahiko Sawada 對問題的分析。討論：https://postgr.es/m/17151-c03a3e6e4ec9aadb@postgresql.org https://git.postgresql.org/pg/commitdiff/8d2d6ec7708b475787fd92a9f828e554805e3df6

  • 修正 regexp 的 citerdissect/creviterdissect 中的效能錯誤。在迭代節點的第 i 個子匹配中偵測到子匹配 "dissect" 失敗（即，反向參照匹配失敗）後，我們應該調整第 i 個子匹配的嘗試長度。然而，在程式碼中，這些函式會更改最後一個子匹配的嘗試長度，並且只有在窮盡該子匹配的所有可能性後，才會返回並調整倒數第二個子匹配，然後是倒數第三個，等等；所有這些都是徒勞無功的，因為只有更改第 i 個子匹配的起點或長度才有可能使其成功。這個疏忽會造成指數級的效能降低。幸運的是，在大多數情況下，這個問題被其他地方應用的最佳化或約束所掩蓋；這解釋了為什麼我們之前沒有注意到它。但是，使用相當簡單（如果人為設計）的正規表示式是有可能遇到這個問題的。這是 commit 173e29aa5 中的疏忽。那已經是很久以前的事了，所以回溯修補到所有支援的分支。討論：https://postgr.es/m/1808998.1629412269@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/facce1da918a8bf55a8f54606512f944529cba85

  • 改善關於誤用 SELECT INTO 的錯誤訊息。改善 plpgsql 中的兩個地方和 spi.c 中的一個地方，在這些地方，錯誤訊息會令人困惑地告訴您不能使用 SELECT 查詢，而您所撰寫的正是 SELECT 查詢。實際的問題是您不能在這些上下文中使用 SELECT ... INTO，但訊息未能明確說明這一點。特殊處理 SELECT INTO 以使這些錯誤更有幫助。此外，修正 plpgsql 中的相同位置，以及 exec_eval_expr() 中的幾個訊息，使其不要在主要錯誤訊息中引用整個被投訴的查詢或表達式。這種行為很容易導致違反我們關於保持主要錯誤訊息簡短和單行的訊息樣式準則。此外，由於訊息的重要部分在插入的文字之後，這可能會使真正的問題難以發現。我們可以將查詢或表達式作為 errcontext 的第一行報告。根據 Roger Mason 的投訴。回溯修補到 v14，因為 (a) 其中一些訊息是 v14 中新增的，並且 (b) v14 的可翻譯字串仍在變動中。這個問題當然比這更早，但我對於進一步更改行為感到猶豫。討論：https://postgr.es/m/1914708.1629474624@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/26ae66090398082c54ce046936fc41633dbfc41e

Álvaro Herrera 推送

  • 還原對分割表 (partitioned tables) 的 analyze 支援。 這會還原以下 commit： 1b5617eb844cd2470a334c1d2eec66cf9b39c41a Describe (auto-)analyze behavior for partitioned tables 0e69f705cc1a3df273b38c9883fb5765991e04fe Set pg_class.reltuples for partitioned tables 41badeaba8beee7648ebe7923a41c04f1f3cb302 Document ANALYZE storage parameters for partitioned tables 0827e8af70f4653ba17ed773f123a60eadd9f9c9 autovacuum: handle analyze for partitioned tables 在處理具有大量分割區的資料庫時，此程式碼存在效率問題，而且似乎沒有簡單的方法可以處理這些問題。還有一些其他問題。現在週期已經太晚，無法進行重要的修正，因此我們必須讓 Postgres 14 使用者繼續手動處理其分割表的 ANALYZE，並且希望我們能夠修正 Postgres 15 的問題。我保留了 [大部分] be280cdad298 ("Don't reset relhasindex for partitioned tables on ANALYZE")，因為雖然我們由於 0827e8af70f4 新增了它，但它本身就是一個很好的錯誤修正，因為它影響手動 analyze 以及 autovacuum 引起的 analyze，並且沒有理由還原它。我保留了將 relkind 'p' 新增到 pg_stat_user_tables 包含的表中，因為還原它需要 catversion bump。此外，在 pg14 中，我保留了新增到 PgStat_TabStatEntry 的 struct 成員，以避免與現有的 stat 檔案不相容。回溯修補到 14。討論：https://postgr.es/m/20210722205458.f2bug3z6qzxzpx2s@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/6f8127b7390119c21479f5ce495b7d2168930e82

Heikki Linnakangas 推送

Michael Meskes 推送

Amit Kapila 推送

Andres Freund 推送

  • 取消設定 MyBEEntry，使 elog.c 對 pgstat_get_my_query_id() 的呼叫更安全。 之前，在關機後期發生的日誌訊息可能會使用另一個後端的 PgBackendStatus (多使用者) 或產生 segfault (單一使用者)，因為 pgstat_get_my_query_id() 對 !MyBEEntry 的檢查沒有過濾掉 pgstat_beshutdown_hook() 之後的使用。 這在 4f0b0966c86 中成為一個錯誤，但之前有點可疑。 但鑑於在 14 之前沒有已知的問題案例，因此似乎不值得進一步回溯修補。 此外，修正了在 e1025044 中引入的註解中的錯誤檔案名稱。 Reported-By: Andres Freund andres@anarazel.de Reviewed-By: Julien Rouhaud rjuju123@gmail.com 討論：https://postgr.es/m/Julien Rouhaud rjuju123@gmail.com Backpatch: 14- https://git.postgresql.org/pg/commitdiff/bed5eac2d50eb86a254861dcdea7b064d10c72cf

Peter Eisentraut 推送

David Rowley 推送