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

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

由 PWN 於 2021-08-15 發布
PWN

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

安全性版本 13.4、12.8、11.13、10.18、9.6.23 和 14 Beta 3 已發布 請儘快升級。 9.6 系列將於 2021 年 11 月 11 日停止接收修復。現在規劃主要版本升級。

行為準則委員會正在尋找新成員，任期為 1-3 年。

PostgreSQL 產品新聞

pgbouncer 1.16.0，一個用於 PostgreSQL 的連線池和其他功能 已發布

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

已套用的修補程式

Bruce Momjian 推送

David Rowley 推送

  • 為 MSVC x86_64 建置新增 POPCNT 支援。 02a6a54ec 新增了程式碼，以便在許多常見平台上使用 POPCNT 指令（如果可用）。在這裡，我們對 MSVC for x86_64 機器執行相同的操作。 MSVC 的 popcnt 內部函數似乎與 GCC 的不同，它們總是發出 popcnt 指令。在 GCC 中，此行為取決於原始程式檔是否使用 -mpopcnt 編譯。因此，MSVC 內部函數已歸入 pg_popcount*_asm 函數中，但是這樣做會使該函數的名稱無效，因此讓我們將其重新命名為 pg_popcount*_fast()。 作者：David Rowley 審閱者：John Naylor 討論：https://postgr.es/m/CAApHDvqL3cbbK%3DGzNcwzsNR9Gi%2BaUvTudKkC4XgnQfXirJ_oRQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/2e281249af6c702fd057f34150fd9ac6cb8c7a8b

  • 在 EXPLAIN 中針對 queryid 使用 ExplainPropertyInteger。這可以節省幾行程式碼。此外，新增一條註解以提及為什麼我們使用 ExplainPropertyInteger 而不是 ExplainPropertyUInteger，因為 queryid 是一個 uint64 類型。作者：David Rowley 審閱者：Julien Rouhaud 討論：https://postgr.es/m/CAApHDvqhSLYpSU_EqUdN39w9Uvb8ogmHV7_3YhJ0S3aScGBjsg@mail.gmail.com 向後移植：14，此程式碼最初是在此處新增的 https://git.postgresql.org/pg/commitdiff/4a3d806f38f99fecf8f2a2bf7990a7ebea9b6c63

  • Doc：修正有關 VACUUM 記憶體限制的誤導性陳述。在 ec34040af 中，我提到將 maintenance_work_limit 設定為高於 1GB 對於 vacuum 沒有任何意義，但這是錯誤的，因為 ginInsertCleanup() 也會查看在 VACUUM 期間 maintenance_work_mem 設定為何，並且這不受限於 1GB。在這裡，我嘗試更清楚地表明該限制僅圍繞我們可以在 VACUUM 期間收集的無效元組識別碼數量。我還在 autovacuum_work_mem 中新增了一條註解來提及此限制。我沒有在 ec34040af 中這樣做，因為我對將該 GUC 的最大值限制為 1GB 有一些錯誤的想法。作者：David Rowley 討論：https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com 向後移植：9.6，與 ec34040af 相同 https://git.postgresql.org/pg/commitdiff/deb6ffd4fdeb589de7a13ac1791380a7138cf59f

  • 從 MSVC 建置腳本中移除一些特殊情況。在這裡，我們新增了對 Makefiles 的額外解析，以確定何時新增對 libpgport 和 libpgcommon 的引用。我們還通過新增非常基本的邏輯來實現 Makefile 規則，從而消除了新增當前 contrib_extrasource 的需求，這些規則在 Makefile 中針對給定的 .o 檔案存在時新增 .l 和 .y 檔案。這只是一些對 Makefiles 的非常基本的額外解析，旨在盡量保持使用 make 建置和 MSVC 建置之間的一致性。這恰好適用於我們目前 Makefiles 的佈局方式，但如果有人選擇在 Makefile 中執行我們不支援解析的操作，則將來很容易被破壞。當我們遇到它時，我們將跨過那座橋。作者：David Rowley 討論：https://postgr.es/m/CAApHDvoPULi5JW3933NxgwxOmu9Ncvpcyt87UhEHAUX16QqmpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/76ad24400d73fa10d527844d50bedf7dacb1e87b

  • 修正 simplehash.h 中不正確的雜湊表調整大小程式碼。此修正解決了 simplehash.h 中的一個錯誤，該錯誤導致雜湊表增長到 SH_MAX_SIZE (2^32) 時，使用了不正確的大小遮罩。當雜湊表達到最大可能的 bucket 數量時，程式碼錯誤地將大小遮罩設定為 0。這將導致始終嘗試使用第 0 個 bucket，從而導致由於衝突太多而嘗試不斷增長雜湊表的無限迴圈。 顯然，simplehash 表增長到這麼大並不常見，因為這個錯誤可以追溯到 v10，而且似乎沒有人注意到它。但是，人們最有可能注意到它的地方可能是執行一個大型的記憶體內雜湊聚合，其中包含至少接近 2^31 個群組。在此修復之後，程式碼現在可以正確處理高達 2^32 群組的 98% 並且在嘗試將更多項目插入雜湊表時將出現以下錯誤而失敗：ERROR: hash table size exceeded (錯誤：雜湊表大小超出) 但是，work_mem（或較新版本中的 hash_mem_multiplier）設定通常會導致雜湊聚合在達到那麼多群組之前就溢位到磁碟。我做的最小測試案例使用了超過 192GB 的 work_mem 設定才能觸發這個錯誤。 simplehash 雜湊表也用於一些其他地方，例如位圖索引掃描，但是，雜湊表在那裡可以達到的大小也受到 work_mem 的限制，並且需要大約 16TB (2^31) 頁的關係和非常大的 work_mem 設定才能觸發它。使用較小的 work_mem 值，該表會變得有損，並且永遠不會增長到足以觸發問題。 作者：Yura Sokolov 審閱者：David Rowley, Ranier Vilela 討論：https://postgr.es/m/b1f7f32737c3438136f64b26f4852b96@postgrespro.ru 向後移植到：10，其中新增了 simplehash.h https://git.postgresql.org/pg/commitdiff/37450f2ca9ad430d78673cc26816fc2085e65904

Amit Kapila 推送

Tom Lane 推送

  • 盡可能避免確定正則表達式子表達式匹配。 鑒於我們的正則表達式引擎的工作方式，識別帶括號的子表達式的精確匹配位置是一項相當昂貴的任務，無論是在正則表達式編譯時（我們必須為每個帶括號的子表達式創建一個優化的 NFA），還是在運行時（其中確定確切的匹配位置需要費力的搜索）。 到目前為止，我們幾乎沒有嘗試優化這種情況。 此修補程式識別了我們在編譯時知道我們不需要知道子表達式匹配位置的情況，並教導正則表達式編譯器不要為正則表達式中其他地方的反向引用未引用的括號對創建每個子表達式的正則表達式。 （為了保留語義，我們顯然仍然必須確定反向引用參考的匹配位置。） 使用者之前可以通過小心地盡可能編寫「非捕獲」括號來獲得相同的結果，但很少有人會費心這樣做。 討論：https://postgr.es/m/2219936.1628115334@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0e6aa8747d439bb7f08f95e358f0509c50396785

  • 讓 regexp_replace() 在可行時使用 REG_NOSUB。 如果替換字串不包含 \1...\9，那麼我們不需要子匹配位置，所以我們也可以在這裡使用 REG_NOSUB 優化。 已經有一個對替換字串的預掃描來尋找反斜線，所以擴展它來檢查數字，並重構以允許在我們編譯正則表達式之前發生這種情況。 同時，嘗試通過使用 memchr() 而不是手寫迴圈來加速預掃描。 與正則表達式處理相比，這很可能在噪聲中消失，但也許不會。 無論如何，這個程式碼更短。 此外，新增一些測試案例以改善 appendStringInfoRegexpSubstr() 的較差覆蓋率。 討論：https://postgr.es/m/3534632.1628536485@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/18bac60ede44359a1e577df80aef196e371c902e

  • 修復帶有 "char" 類型和 <!--<= 運算符的 btree_gin 索引掃描失敗的問題。 由於對 "char" 類型是有符號還是無符號的混淆，對 "col < 'x'" 或 "col <= 'x'" 之類的索引搜索的掃描將從索引的中間而不是左端開始，因此遺漏了許多或所有它們應該找到的條目。 幸運的是，這不是索引損壞的徵兆。 只有搜尋邏輯被破壞，我們可以修復它而沒有令人不快的副作用。 根據 Jason Kim 的報告。 自 btree_gin 開始以來，這一直是錯誤的，因此向後移植到所有受支援的分支。 討論：https://postgr.es/m/20210810001649.htnltbh7c63re42p@jasonk.me https://git.postgresql.org/pg/commitdiff/a6bd28beb0639d4cf424e961862a65c466ca65bf

  • 在 s_lock.h 中新增 RISC-V spinlock 支援。 就像 ARM 的情況一樣，只需使用 gcc 的 __sync_lock_test_and_set();，它將編譯成 AMOSWAP.W.AQ，這就是我們需要的。 在某個時候，可能值得對 RISC-V 的原子操作做一些工作，但這應該足以進行可靠的移植。 向後移植到所有受支援的分支，以防有人想在 RISC-V 上嘗試它們。 Marek Szuba 討論：https://postgr.es/m/dea97b6d-f55f-1f6d-9109-504aa7dfa421@gentoo.org https://git.postgresql.org/pg/commitdiff/c32fcac56a212b4e6bb5ba63596f60a25a18109a

  • 取消對 s_lock_test 的破壞。 Commit 80abbeba2 顯然沒有費心檢查此程式碼。 此外，在 .gitignore 中列出產生的可執行檔（所以已經很久沒有人嘗試這個了）。 在嘗試 RISC-V spinlock 修補程式時注意到。 鑑於這已經被破壞了 5 年，而且沒有人注意到，因此可能不值得向後移植。 https://git.postgresql.org/pg/commitdiff/0a208ed63ffe50a8d9d7c0b33996ec01cc4fdef6

Andres Freund 推送

Michaël Paquier 推送

Daniel Gustafsson 已推送

Heikki Linnakangas 已推送

  • 修正使用本地和外部分割區混合的 EvalPlanQual 期間發生的分段錯誤。在 EvalPlanQual 期間重新評估 direct-modify Foreign Update 或 Delete 是沒有意義的。但是，如果表格混合了本地和外部分割區，仍然可以呼叫 ExecInitForeignScan()。EvalPlanQualStart() 在子 EPQ EState 中將 es_result_relations 陣列保持未初始化狀態，但 ExecInitForeignScan() 仍然期望找到它。這導致了分段錯誤。透過在 EvalPlanQual 處理期間跳過 es_result_relations 查找來修正。為了使事情更健壯，也跳過 BeginDirectModify 呼叫，並新增一個執行時期檢查，確保在 EvalPlanQual 處理期間不會對 direct-modify foreign scans 呼叫 ExecForeignScan()。這是 v14 中的新增功能，commit 1375422c782。在此之前，EvalPlanQualStart() 將整個 ResultRelInfo 陣列複製到 EPQ EState。後向移植到 v14。Report and diagnosis by Andrey Lepikhov. Discussion: https://postgres.tw/message-id/cb2b808d-cbaa-4772-76ee-c8809bafcf3d%40postgrespro.ru https://git.postgresql.org/pg/commitdiff/c3928b467a4f0ed2b0ef21a33848e9fcdade37b4

John Naylor 已推送

Tomáš Vondra 已推送

Thomas Munro 推送了提交

Michael Meskes 推送了提交

Peter Eisentraut 推送了提交