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

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

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

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

PostgreSQL 產品新聞

JDBC 42.3.0 已釋出。

pgmetrics 1.12，一個用於 PostgreSQL 指標的命令列工具，已釋出。

StackGres 1.0.0，一個在 Kubernetes 上執行 PostgreSQL 的平臺，已釋出。https://stackgres.io/

pgexporter 0.2.0，一個 PostgreSQL 的 Prometheus exporter，已釋出

pgAdmin4 6.1，一個用於 PostgreSQL 的 Web 和原生 GUI 控制中心，已釋出。

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 提交

  • 修復 psql 新 TAP 測試的可移植性問題。c0280bc 和 d9ddc50 在 001_basic.pl 中新增的測試引入了直接呼叫 psql 的命令，使其對環境敏感。一個問題是這些命令忘記了 -X 來不使用本地 .psqlrc，導致所有這些測試失敗，如果 psql 無法正確解析該檔案。TAP 測試應設計成獨立執行，不依賴於執行它們的環境。由於 PostgresNode::psql 已經提供了這些新測試所需的所有設施，因此切換到它而不是直接呼叫 psql 命令（當需要與後端互動時）。稍微重構了測試，以便能夠檢查 stdout 和 stderr 的預期模式，保持與之前相同的覆蓋範圍。報告人：Peter Geoghegan 討論：https://postgr.es/m/CAH2-Wzn8ftvcDPwomn+y04JJzbT=TG7TN=QsmSEATUOW-ZuvQQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/384f1abdb9b0f669279fcd57ba2173eb31724740

  • 在事務中止期間正確重置快照匯出狀態。在建立複製槽的過程中，同一事務中生成的 ERROR（與建立待匯出快照的事務相同）會導致後端處於不一致狀態，因為關聯的靜態匯出快照狀態在事務中止時未被重置，而僅在 WAL 傳送器收到的後續命令中被重置（該命令是在複製槽建立時建立此快照的）。如果該會話嘗試再次匯出快照（例如在建立複製槽時），這將觸發不一致失敗。請注意，快照匯出不能在事務塊中發生，因此無需擔心重置子事務中止的狀態。此外，這種不一致狀態非常不可能暴露給使用者。例如，一種可能發生的情況是在構建初始待匯出快照時出現記憶體不足的錯誤。Dilip 在研究另一個補丁時發現了這個問題，該補丁導致此程式碼路徑因與 HEAD 無關的原因而發生錯誤。作者：Dilip Kumar 審閱者：Michael Paquier, Zhihong Yu 討論：https://postgr.es/m/CAFiTN-s0zA1Kj0ozGHwkYkHwa5U0zUE94RSc_g81WrpcETB5=w@mail.gmail.com 向後移植到：9.6 https://git.postgresql.org/pg/commitdiff/409f9ca4471331be0f77b665ff3a1836a41de5b3

  • 阻止對 ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (options) 進行操作。在具有列名的索引上執行此命令的語法在解析器中一直被授權，並且從未被文件化。自 911e702 以來，可以在 CREATE INDEX 時定義操作類引數，這實際上破壞了舊的 ALTER INDEX/TABLE 情況，其中 n_distinct 和 n_distinct_inherited 等關係級引數可以為索引定義（參見 76a47c0 及其討論，該點仍然未被使用）。在 v13~ 中嘗試這樣做會導致索引變得不可用，因為有一個新的專用程式碼路徑來載入操作類引數，而不是之前可用的關係級引數。請注意，可以透過手動目錄更新來修復問題，以使關係恢復聯機。此提交暫時停用此命令，因為使用列名進行索引操作無論如何都沒有意義，尤其是在索引表示式中名稱是自動計算的情況下。未來正確支援此情況的一種方法是使用列號，就像 ALTER INDEX .. ALTER COLUMN .. SET STATISTICS 一樣。分割槽索引已被阻止，但普通索引未被阻止。為兩種情況添加了一些測試。ANALYZE 中有一些程式碼用於強制使用 n_distinct 用於索引表示式（如果定義了該引數），但目前將其刪除，直到/如果支援此功能（請注意，索引級引數之前在 pg_dump 中也從未得到支援），因此這只是死程式碼。報告人：Matthijs van der Vleuten 作者：Nathan Bossart, Michael Paquier 審閱者：Vik Fearing, Dilip Kumar 討論：https://postgr.es/m/17220-15d684c6c2171a83@postgresql.org 向後移植到：13 https://git.postgresql.org/pg/commitdiff/fdd88571454e2b00dbe446e8609c6e4294ca89ae

  • 修復 MSVC 與 OpenSSL 3.0.0 的構建。Visual Studio 的構建指令碼將因檢查第二個數字失敗而無法正確檢測到 3.0.0 的構建。這已根據需要進行了調整，允許構建完成。請注意，文件中提到的 OpenSSL 的 MSI 對於 Win32 和 Win64 庫名稱沒有改變，因此此更改很簡單。報告人：htalaco (透過 github) 審閱者：Daniel Gustafsson 討論：https://postgr.es/m/YW5XKYkq6k7OtrFq@paquier.xyz 向後移植到：9.6 https://git.postgresql.org/pg/commitdiff/41f30ecc29c89285d3eecd435906c4e9cb048be4

  • 修復從模板資料庫複製依賴項時 pg_shdepend 損壞。為新資料庫使用帶有需要複製的共享依賴項的模板資料庫會導致 pg_shdepend 損壞，因為用於插入具有槽的值的索引號的計算存在一個偏移錯誤。此問題由 e3931d0 引入。監控程式碼的其他部分，沒有類似的錯誤。報告人：Sven Klemm 作者：Aleksander Alekseev 審閱者：Daniel Gustafsson, Michael Paquier 討論：https://postgr.es/m/CAJ7c6TP0AowkUgNL6zcAK-s5HYsVHVBRWfu69FRubPpfwZGM9A@mail.gmail.com 向後移植到：14 https://git.postgresql.org/pg/commitdiff/98ec35b0bbf6003e89fc06aa140e12fd90bbad47

  • 文件：描述 pg_receivewal 的流式傳輸開始的計算方法。文件關於 WAL 流式傳輸的起始 LSN 的說明不夠精確，如果本地歸檔目錄（使用 pg_receivewal 命令定義）中找不到任何內容，則在此問題上更詳細地說明。摘錄自同一作者的一大塊補丁。作者：Ronan Dunklau, Michael Paquier 討論：https://postgr.es/m/18708360.4lzOvYHigE@aivenronan 向後移植到：10 https://git.postgresql.org/pg/commitdiff/1e9475694b0ae2cf1204d01d2ef6ad86f3c7cac8

Heikki Linnakangas 提交

Álvaro Herrera 提交

Daniel Gustafsson 提交

  • 修復 pg_basebackup 和 pg_dump 中的 sscanf 限制。確保字串解析受到目標緩衝區大小的限制。在 pg_basebackup 中，伺服器傳送的可用值限制為兩個字元，因此沒有溢位風險。在 pg_dump 中，緩衝區由 MAXPGPATH 限制，因此必須透過預處理器展開插入限制，並將緩衝區增加一個以容納終止符。這裡沒有溢位風險，因為在這種情況下，掃描的緩衝區比目標緩衝區小。將 pg_basebackup 的修復回溯到引入它的 11 版本，並將 pg_dump 的修復回溯到 9.6。審閱者：Tom Lane 討論：https://postgr.es/m/B14D3D7B-F98C-4E20-9459-C122C67647FB@yesql.se 向後移植到：11 和 9.6 https://git.postgresql.org/pg/commitdiff/1d7641d51a51aa00dff685022fab6c03be8f8af8

  • 修復 TOC 檔案錯誤訊息列印中的錯誤。如果 blob TOC 檔案無法解析，錯誤訊息將無法列印檔名，因為儲存它的變數被解析的目標緩衝區所覆蓋。當檔名解析失敗時，錯誤將列印一個空字串：“./pg_restore -d foo -F d dump pg_restore: error: invalid line in large object TOC file ""：..”，而不是預期的錯誤訊息：“./pg_restore -d foo -F d dump pg_restore: error: invalid line in large object TOC file "dump/blobs.toc"：..”。透過重新命名兩個變數來修復，因為共享名稱太通用，無法同時儲存兩者並傳達變數的內容。回溯到 9.6。審閱者：Tom Lane 討論：https://postgr.es/m/A2B151F5-B32B-4F2C-BA4A-6870856D9BDE@yesql.se 向後移植到：9.6 https://git.postgresql.org/pg/commitdiff/998d060f3db79c6918cb4a547695be150833f9a4

  • 重構 sslfiles Makefile 目標以方便使用。Makefile 處理 TLS 測試使用的證書和金鑰對變得相當難以處理。新增新證書而無需重新生成所有內容過於複雜。此補丁重構了 sslfiles make 目標，使得新增新證書只需要新增一個 .config 檔案，將其新增到 Makefile 的頂部，然後執行 make sslfiles。改進：- 檔案依賴關係應已修復，CRL 目錄除外。- 新證書的序列號基於當前時間，減少了衝突的可能性。- CA 索引狀態按需建立，並在 Make 執行結束時自動清理。- `*.config` 檔案現在是自包含的；一個證書需要一個配置檔案而不是兩個。- 重複程式碼減少，並隨之減少了一些不必要的程式碼（和可能的複製貼上錯誤）。- 所有配置檔案都放在 conf/ 目錄下。該目標已移動到其自己的 makefile 中，以避免與全域性 make 設定衝突。作者：Jacob Champion pchampion@vmware.com 審閱者：Michael Paquier michael@paquier.xyz 討論：https://postgr.es/m/d15a9838344ba090e09fd866abf913584ea19fb7.camel@vmware.com https://git.postgresql.org/pg/commitdiff/b4c4a00eada3c512e819e9163114a5ad1606bc7e

  • 修復 32 位 Perl 上的 SSL 測試。證書序列號生成在 b4c4a00ea 中更改為使用當前時間戳。因此，testharness 必須使用 "openssl x509" 來查詢證書的序列號，該命令以十六進位制格式發出序列號。將序列號轉換為整數格式以匹配 pg_stat_ssl 中使用的格式需要一個 64 位相容的 Perl。這在 32 位 Perl 測試時增加了回退到檢查整數的選項。根據 buildfarm 成員 prairiedog 的故障。討論：https://postgr.es/m/0D295F43-806D-4B3F-AB98-F941A19E0271@yesql.se https://git.postgresql.org/pg/commitdiff/0c04342b1d3dd5b24f795f94874163be8e21710e

Tom Lane 提交

Andres Freund 提交

Amit Kapila 提交

Andrew Dunstan 推送

Noah Misch 推送

  • 避免 RelationBuildDesc() 中影響 CREATE INDEX CONCURRENTLY 的競態條件。CIC 和 REINDEX CONCURRENTLY 假定後端看到的目錄更改不晚於每個後端下一次事務開始。當後端在執行 CIC 索引的 RelationBuildDesc() 過程中吸收了相關的無效化時，這種情況會失敗。使用由此產生的索引的查詢可能會悄悄地找不到行。透過使 RelationBuildDesc() 迴圈直到它完成而無需接受相關無效化來修復未來的索引構建。可能需要重新索引才能從過去的事件中恢復；REINDEX CONCURRENTLY 即可。回溯到 9.6（所有支援的版本）。Noah Misch 和 Andrey Borodin，由 Andres Freund 審閱（在早期版本中）。討論：https://postgr.es/m/20210730022548.GA1940096@gust.leadboat.com https://git.postgresql.org/pg/commitdiff/fdd965d074d46765c295223b119ca437dbcac973

  • 修復針對最新準備事務的 CREATE INDEX CONCURRENTLY。提交 8a54e12a38d1545d249f1402f66c8cde2837d97c 的目的是修復此問題，並且在 PREPARE TRANSACTION 在 CIC 查詢鎖衝突之前完成時就足夠了。否則，事情仍然會出錯。與以前一樣，在已啟用準備事務的情況下使用 CIC 的叢集中，使用由此產生的索引的查詢可能會悄悄地找不到行。可能需要重新索引才能從過去的事件中恢復；REINDEX CONCURRENTLY 即可。透過使 CIC 等待任意近期的準備事務以及可能尚未 PREPARE TRANSACTION 的普通事務來修復未來的索引構建。作為其中的一部分，讓 PREPARE TRANSACTION 在呼叫 ProcArrayClearTransaction() 之前將鎖轉移到其虛擬 PGPROC。回溯到 9.6（所有支援的版本）。Andrey Borodin，由 Andres Freund 審閱（在早期版本中）。討論：https://postgr.es/m/01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru https://git.postgresql.org/pg/commitdiff/3cd9c3b921977272e6650a5efbeade4203c4bca2