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

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

由 PWN 於 2021-10-24 發布
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 導出器，已發布

pgAdmin4 6.1，適用於 PostgreSQL 的 Web 和原生 GUI 控制中心，已發布。

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

  • 修正 psql 新 TAP 測試中的可移植性問題。 001_basic.pl 中由 c0280bc 和 d9ddc50 添加的測試直接調用 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

  • 在事務中止期間正確重置快照導出狀態。 在複製槽創建期間，與創建要導出的快照的同一個事務中產生的錯誤會使後端處於不一致狀態，因為關聯的靜態導出快照狀態未在事務中止時重置，而僅在 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 的 opclass 參數，這實際上破壞了 ALTER INDEX/TABLE 的舊情況，其中可以為索引定義關係級別的參數 n_distinct 和 n_distinct_inherited（請參閱 76a47c0 及其已觸及此點的線程，但仍然未使用）。 在 v13~ 中嘗試這樣做會導致索引變得無法使用，因為有一個新的專用代碼路徑來加載 opclass 參數，而不是以前可用的關係級別參數。 請注意，可以使用手動目錄更新來修復，以使關係重新聯機。 此提交現在禁用此命令，因為索引使用列名無論如何都沒有意義，尤其是在索引表達式中自動計算名稱時。 將來正確支持這種情況的一種方法是在涉及索引時使用列號，就像 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

  • 修正使用 OpenSSL 3.0.0 的 MSVC 的構建。 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 限制，因此必須透過前置處理器擴充插入限制，並且緩衝區增加 1 以考慮終止符。這裡沒有溢位風險，因為在這種情況下，掃描的緩衝區小於目標緩衝區。將 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 目標以方便使用。用於 TLS 測試的憑證和金鑰對的 Makefile 處理變得非常難以使用。無需重新產生所有內容即可新增憑證太過複雜。此補丁重構 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 中變更為使用目前的時間戳記。因此，測試工具必須使用 "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 推送

  • 移除 transformExpressionList() 中錯誤的斷言。我認為當我新增這個斷言（在 commit 8f889b108 中）時，我只考慮了 transformExpressionList 在 INSERT 和 VALUES 的頂層的使用。但它也被 transformRowExpr() 呼叫，而 transformRowExpr() 肯定會出現在 UPDATE targetlist 中，所以假設 p_multiassign_exprs 必須為空是不恰當的。此外，由於輸入預期不包含 ResTargets，因此也沒有理由包含 MultiAssignRefs。因此，此程式碼無需關心 p_multiassign_exprs 的狀態，我們應該直接刪除該斷言。根據來自 ocean_li_996 的錯誤 #17236。這個錯誤已經存在多年，所以 back-patch 到所有受支援的分支。討論： https://postgr.es/m/17236-3210de9bcba1d7ca@postgresql.org https://git.postgresql.org/pg/commitdiff/697dd1925f418c9f54ee1fd1cefbc613d6504b1f

  • 修正複合型別的網域陣列賦值。如果陣列元素是網域而不是普通複合型別，則類似於 "UPDATE ... SET fld[n].subfld = whatever" 的更新會失敗。這是因為 isAssignmentIndirectionExpr() 無法處理這種情況下出現在表達式樹中的 CoerceToDomain 節點。結果通常是崩潰，即使我們意外地沒有崩潰，我們也無法正確地保留相同陣列元素的其他欄位。根據 Onder Kalaci 的報告。Back-patch 到 v11，該版本引入了網域陣列。討論： https://postgr.es/m/PH0PR21MB132823A46AA36F0685B7A29AD8BD9@PH0PR21MB1328.namprd21.prod.outlook.com https://git.postgresql.org/pg/commitdiff/3e310d837a9b3de8ad977c0a3e2a769bcdf61cc9

  • pg_dump：重新組織 getTables()。與 047329624、ed2c7f65b 和 daa9fe8a5 類似，減少程式碼重複，方法是只保留一份在所有伺服器版本中都相同的查詢部分；並使條件式控制盡可能少的程式碼。這也消除了之前我們在這裡實現相同結果的各種令人困惑的方法。同時，確保函數的所有三個相關部分都以相同的順序列出欄位。這當然只是整潔主義。討論： https://postgr.es/m/1240992.1634419055@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/4438eb4a495c977d8ac485dd6e544c2b6e077deb

  • 改進 pg_regress.c 中用於發出 psql 命令的基礎架構。支援向單個 psql 調用發出多個 "-c command" 參數。這允許將一些以前需要兩個或多個後端啟動的操作合併到一個會話中。特別是，我們可以將 DROP DATABASE 作為其中一個 -c 命令發出，而不會收到 "DROP DATABASE cannot run inside a transaction block" 的錯誤訊息。除了減少所需的會話數量外，此修補程式還抑制了 pg_regress 在 DROP DATABASE（或 ROLE）IF NOT EXISTS 呼叫期間產生的 "NOTICE: database "foo" does not exist, skipping" 訊息。這使我們更接近於在成功建構/測試期間不看到任何訊息的理想狀態。此修補程式還消除了對發出命令長度的一些硬編碼限制。我不認為我們接近達到這些限制，但消除限制令人欣慰。由我修補，但感謝 Nathan Bossart 發起討論。討論： https://postgr.es/m/DCBAE0E4-BD56-482F-8A70-7FD0DC0860BE@amazon.com https://git.postgresql.org/pg/commitdiff/f45dc59a38cab1d2af6baaedb79559fe2e9b3781

  • 文件：闡明 simplehash.h 的一個關鍵且未記載的方面。我剛剛因為嘗試使用 pg_malloc 而不是 pg_malloc0 而被困擾。透過不留下這個 API 細節未記載，為下一個駭客節省一些時間。 https://git.postgresql.org/pg/commitdiff/b1ce6c284366ce1dae120f5d10dd59e8804322ee

  • pg_dump：修正錯誤轉儲非全域預設權限的問題。非全域預設權限項目應該按原樣轉儲，而不是相對於其物件類型的預設 ACL 進行轉儲。如果人們在全域項目中撤銷了一些預設權限，然後想要在非全域項目中再次授予它們，這通常才會有關係。根據 Boris Korzun 的報告。這是一個舊錯誤，因此 back-patch 到所有受支援的分支。Neil Chen，Masahiko Sawada 的測試案例 討論： https://postgr.es/m/111621616618184@mail.yandex.ru 討論： https://postgr.es/m/CAA3qoJnr2+1dVJObNtfec=qW4Z0nz=A9+r5bZKoTSy5RDjskMw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2acc84c6fd299125702c8a8af13820abcc0d4891

  • 修正 simplehash.h 中前端版本的 sh_error()。程式碼不希望 sh_error() 返回，但使此標頭可在前端使用的修補程式沒有注意到這一點。在這裡，將 unlikely() 貼在決定是否調用 sh_error() 的測試上，並新增我們的標準著作權聲明。Andres Freund 註意到。Back-patch 到 v13，該版本引入了此前端支援。討論： https://postgr.es/m/0D54435C-1199-4361-9D74-2FBDCF8EA164@anarazel.de https://git.postgresql.org/pg/commitdiff/974aedcea46dfd0119eea2fbb2eeacd232596f05

  • 在 pg_dump 中，使用 simplehash.h 按 OID 查找可轉儲物件。建立一個雜湊表，該雜湊表按 CatalogId（即，目錄 OID + 物件 OID）索引可轉儲物件。使用此雜湊表來取代之前的 catalogIdMap 陣列，以及各種其他單個目錄索引陣列，以及擴充套件成員資格圖。原則上，對於具有許多物件的資料庫，這應該更快，因為現在查找是 O(1) 而不是 O(log N)。但是，似乎這些查找在上下文中幾乎可以忽略不計，因此無法測量到總體效能的變化。但是，只有一個查找資料結構需要維護使程式碼更簡單、更靈活，所以讓我們這樣做吧。討論： https://postgr.es/m/2595220.1634855245@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/92316a4582a5714d4e494aaf90360860e7fec37a

  • 修正 pg_dump 中一些微小的記憶體洩漏。我透過在 "valgrind --leak-check=full" 下執行 pg_dump 發現了這些問題。 flagInhIndexes() 和 getIndexes() 中的變更，將原本分配一個陣列但只使用其中一部分元素的方式，改為個別分配實際需要的物件。之前的寫法浪費了一些記憶體，但更重要的是，它混淆了 valgrind 的洩漏追蹤。collectComments() 和 collectSecLabels() 仍然是 valgrind 報告中的主要污點，因為它們沒有使用 PQclear 清除查詢結果，以避免大量的 strdup 操作。這是一個有問題的權衡，但我將在此處保持原樣；即將到來的修補程式將修改這些函數，足以證明更改此權衡的合理性。https://git.postgresql.org/pg/commitdiff/70bef494000e4dbbeca0f0a40347ca1747aea701

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。commit 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