2025年9月25日: PostgreSQL 18 釋出！

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

釋出於 2021-10-11，作者：PWN
PWN

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

PostgreSQL 產品新聞

pgCluu 3.2，一個用於審計 PostgreSQL 效能的 Perl 程式，已釋出。

PGroonga 2.3.2，一個支援所有語言的全文搜尋平臺，已釋出。

10 月份的 PostgreSQL 工作崗位

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

PostgreSQL 相關新聞

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

本週 PostgreSQL 週報由 David Fetter 提供。

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

已應用補丁

Michaël Paquier 提交

  • 修復了在 2PC 過程中熱備節點提升時快照構建的問題。在涉及 2PC 事務的恢復結束時會執行一些特定邏輯：1) 呼叫 RecoverPreparedTransactions()，將 2PC 事務的狀態恢復到記憶體中（重新獲取鎖等）。2) 呼叫 ShutdownRecoveryTransactionEnvironment()，恢復到正常操作，主要是清理恢復鎖和 KnownAssignedXids（包括先前跟蹤的任何 2PC 事務）。3) 將 XLogCtl->SharedRecoveryState 切換到 RECOVERY_STATE_DONE，這是任何呼叫 RecoveryInProgress() 的程序檢查叢集是否仍在恢復中的臨界點。在步驟 2) 和 3) 之間拍攝的任何快照都將是空的，這可能導致依賴於此時快照的任何事務損壞資料，因為在同一次事務中連續呼叫 GetSnapshotData() 時，RecentXmin 可能會向後移動。由於 SharedRecoveryState 是判斷是否可以安全丟棄 KnownAssignedXids 的關鍵點，因此此提交將步驟 2) 移到了步驟 3) 之後，這樣我們就不會出現空快照的情況。這個問題自熱備引入以來就存在，因此需要回溯所有版本。出現錯誤快照的視窗期非常短，但我透過執行 023_pitr_prepared_xact.pl 發現了它，buildfarm 成員 fairywren 也發現了。Thomas Munro 也獨立發現了這個問題。特別感謝 Andres Freund 花時間分析這個問題。報告者：Thomas Munro，Michael Paquier 分析者：Andres Freund 討論：https://postgr.es/m/20210422203603.fdnh3fu2mmfp2iov@alap3.anarazel.de 回溯至：9.6 https://git.postgresql.org/pg/commitdiff/8a4237908c0fe73dd41d4d7c7a6314f17dfd7a6f

  • 修復 pg_verifybackup 的 TAP 測試中的警告。a3fcbcd 中的疏忽。報告者：Thomas Munro 討論：https://postgr.es/m/CA+hUKGKnajZEwe91OTjro9kQLCMGGFHh2vvFn8tgHgbyn4bF9w@mail.gmail.com 回溯至：13 https://git.postgresql.org/pg/commitdiff/ec2133a447318ac6d78887e91940d69e6d92a435

  • 重構日誌收集器的每個目標檔案輪換。stderr 和 csvlog 在按大小、按年齡輪換檔案或被使用者強制請求（pg_ctl logrotate 或 SQL 函式 pg_rotate_logfile）時，使用了重複的程式碼。兩者之間的主要區別在於，stderr 需要始終開啟其檔案，以便在日誌收集器尚未準備好執行其工作時，如果啟用了其他目標，仍然可以路由。此外，如果停用了 csvlog，我們需要正確關閉其儲存在日誌收集器中的元資料（current_logfiles 的最後一個檔名以及正在使用的檔案描述符）。除了這些點之外，在錯誤處理以及是否應建立檔案或繼續使用現有檔案方面，程式碼是相同的。此更改總體上使程式碼更簡單，並將有助於引入更多基於檔案的日誌目標。此重構與 5b0b699 中的工作類似。大部分重複源自 fd801f4。pg_ctl 的一些 TAP 測試會檢查強制日誌輪換的情況，但這有些侷限，因為它沒有覆蓋 log_rotation_age 或 log_rotation_size（這些可能不值得花費額外的資源執行），也沒有覆蓋具有不同 stderr 和 csvlog 組合的 log_destination 過載。我在此重構中單獨測試了所有這些情況。作者：Michael Paquier 討論：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5c6e33f071537d9831db57471a06d39a175b535a

  • 修復 syslogger.c 中的編譯警告。5c6e33f 中的疏忽。作者：Nathan Bossart 討論：https://postgr.es/m/DD8AD4CE-63B7-44BE-A3D2-14A4E4B19C26@amazon.com https://git.postgresql.org/pg/commitdiff/05c4248ad1bf0c2721ce9445f6908da9ece36ff8

  • 重構 csvlog 的 stderr 回退，以更好地處理 WIN32 服務情況。send_message_to_server_log() 在某些情況下會強制將 csvlog 的日誌條目重定向到 stderr，例如 syslogger 尚未準備好。如果發生這種情況，csvlog 將回退到 stderr 來記錄一些資訊，而不是什麼都不記錄。程式碼的組織方式是先處理 stderr，然後處理 csvlog，csvlog 透過反向條件檢查 stderr 是否尚未發生。使用這種程式碼組織方式，在 WIN32 上將 Postgres 作為服務執行時，可能會丟失一些訊息，因為沒有可用的 stderr，並且由於這個原因，StringInfoData（儲存 stderr 訊息）的處理相當令人困惑。此提交將 csvlog 的處理移到 stderr 之前，因為我們可以追蹤是否需要將某條資訊記錄到 stderr。這將 stderr 的處理減少到單一程式碼路徑，併為 WIN32 服務添加了回退到事件日誌的功能。這還簡化了我們處理 stderr 的 StringInfoData 的方式，使得整合新的基於檔案的日誌目標更容易。我在檢查此更改時，在 Windows 上對服務和事件日誌進行了操作。審稿人：Chris Bandy 討論：https://postgr.es/m/YV0vwBovEKf1WXkl@paquier.xyz https://git.postgresql.org/pg/commitdiff/8b76f89c37973082b3d64f5a27937efcca9d65f6

Daniel Gustafsson 提交

Peter Eisentraut 提交

Tom Lane 提交

Andres Freund 提交

Bruce Momjian 已推送

Fujii Masao 提交

Amit Kapila 提交

Robert Haas 提交

Dean Rasheed 已推送

  • 修復 numeric_power() 中丟失精度的角落情況。這修復了一個精度丟失問題，當第一個輸入非常接近 1 時，其對數非常小。以前，在估計結果權重的初始低精度計算過程中，對數會以本地 rscale 計算，該 rscale 被限制在 NUMERIC_MAX_DISPLAY_SCALE (1000) 以下。然而，基數可能接近 1e-16383，因此其對數可能小至 1e-16383，所以區域性 rscale 需要允許超過 16383，否則所有精度都會丟失，導致為全精度計算選擇不佳的 rscale。透過移除初始低精度計算過程中對區域性 rscale 的上限來修復此問題，就像我們在全精度計算中已經做的那樣。這並不改變初始計算是低精度近似的事實，對數計算到大約 8 位有效數字，這非常快，尤其是當基數非常接近 1 時。補丁由我提供，Alvaro Herrera 進行了審查。討論：https://postgr.es/m/CAEZATCV-Ceu%2BHpRMf416yUe4KKFv%3DtdgXQAe5-7S9tD%3D5E-T1g%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/e54a758d24dab056bb7f50d26c57a3c8761cc44a

Etsuro Fujita 推送