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

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 本週為您帶來

請在太平洋標準時間下午 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) 之間拍攝的任何快照都會是空的，導致任何依賴於此時快照的交易可能會損壞資料，因為可能仍然有一些 2PC 交易需要追蹤，並且 RecentXmin 在同一個交易中連續呼叫 GetSnapshotData() 時會向後移動。由於 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 的最後一個檔案名和當前為業務開啟的 fd）。除了這些點之外，該程式碼在錯誤處理方面以及檔案是否應該建立或僅繼續方面是相同的。此變更使程式碼整體上更簡單，並且將有助於引入更多基於檔案的日誌目標。此重構類似於 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 服務案例。在某些情況下，例如 syslogger 尚未可用時，send_message_to_server_log() 會強制將日誌條目重新導向到 stderr 以用於 csvlog。如果發生這種情況，csvlog 將回退到 stderr 以記錄一些資訊，而不是什麼都不記錄。程式碼的組織方式是 stderr 在 csvlog 之前完成，csvlog 檢查 stderr 尚未以反轉條件發生。透過這種程式碼組織方式，如果在 WIN32 上將 Postgres 作為服務運行，則可能會遺失一些訊息，因為沒有可用的 stderr，並且由於該原因，用於儲存 stderr 訊息的 StringInfoData 的處理相當令人困惑。此提交將 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 到 1，因此其對數可能小至 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 推送