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

PostgreSQL 每週新聞 - 2021 年 9 月 5 日

發布於 2021-09-06，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 9 月 5 日

PostgreSQL 產品新聞

pg_dbms_job 1.1.0，一個用於建立、管理和使用 Oracle 風格 DBMS_JOB 排程任務的擴充套件，已發布。

dbForge Data Compare for PostgreSQL v3.4 已發布

pgmoneta 0.5.0，一個用於 PostgreSQL 的備份和還原系統，已發布

pgspider_ext，一個基於 PostgreSQL 外部資料包裝器建立分散式資料叢集引擎的擴充套件，已發布。

psycopg2 3.0.0 beta 1，一個用於 PostgreSQL 的 Python 連接器，已發布。

postgresql-wheel，一個 Python 套件，包含一個完整的已編譯 PostgreSQL 伺服器在一個單一的 pip 可安裝檔案中，已發布

九月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

PostgreSQL 每週新聞由 David Fetter 本週為您帶來

請在太平洋標準時間下午 3:00 前（週日）提交新聞和公告至 david@fetter.org。

已套用的修補程式

Michaël Paquier 推送

Amit Kapila 推送

Fujii Masao 推送

Álvaro Herrera 推送

Daniel Gustafsson 推送

Tom Lane 推送

  • 修正內聯新式 SQL 函數時遺漏的鎖定取得。當開始使用從目錄載入的查詢剖析樹時，我們必須首先應用 AcquireRewriteLocks()，以取得與剖析器在以互動方式輸入查詢時將取得的相同的關係鎖定，並執行一些其他清除工作，例如處理稍後刪除的欄位。新式 SQL 函數與其他儲存的剖析樹一樣受此規則約束；但是，在處理這些函數的地方中，只有 init_sql_fcache 記住了這一點。特別是，如果我們成功內聯了包含任何關係引用的新式集合傳回 SQL 函數，我們會得到一個斷言失敗，或者嘗試在沒有鎖定的情況下使用這些關係。我也將 AcquireRewriteLocks 呼叫新增到 fmgr_sql_validator 和 print_function_sqlbody。隨意的實驗並未顯示任何失敗，但我懷疑我只是不夠努力。當然，我們不希望附近的程式碼路徑在沒有鎖定的情況下運行。根據其邏輯，它應該具有與舊程式碼相同的效果，也在 fmgr_sql_validator 中呼叫 pg_rewrite_query()。有可能兩個程式碼路徑都不需要費心重寫，但執行分析以證明這一點超出了我今天的目標。根據 Alexander Lakhin 提供的錯誤 #17161。討論：https://postgr.es/m/17161-048a1cdff8422800@postgresql.org https://git.postgresql.org/pg/commitdiff/589be6f6c732a20e2bcaa02560de464ebbd48af2

  • 在 pg_dump 中快取 format_type() 查詢的結果。長期以來，pg_dump 的 getFormattedTypeName 函數上一直有一個 "TODO: 快取結果可能有一些價值" 的註解；但我們一直沒有去檢查重複查詢類型名稱會花費我們多少成本。結果發現，在傾印當前的迴歸測試資料庫時，發出的總查詢次數中約有 10% 是重複的 format_type() 查詢。然而，Hubert Depesz Lubaczewski 回報了一個不常見的案例，其中這些查詢佔 pg_dump 發出的查詢次數的一半以上。單獨來看，這些查詢並不昂貴，但當網路延遲是一個因素時，它們會累積成一個問題。我們可以非常容易地添加一些快取到 getFormattedTypeName 來解決這個問題。由於這是一個如此簡單的修復，並且可以帶來明顯的性能提升，因此回溯修補到所有支援的分支。 討論：https://postgr.es/m/20210826084430.GA26282@depesz.com https://git.postgresql.org/pg/commitdiff/6c450a861f1a928f44c9ae80814ed9a91927c25a

  • 在 pg_dump 中，避免對每個表進行 RLS 策略的查詢。getPolicies() 沒有特別好的理由，為每個表單獨查詢 pg_policy。我們可以改為在單個查詢中收集所有策略，並使用 findTableByOid() 查找將它們附加到正確的 TableInfo 物件。在迴歸測試資料庫上，這大大減少了查詢的數量，即使在本地伺服器上運行也能提供明顯的節省。根據 Hubert Depesz Lubaczewski 的抱怨。由於這是一個如此簡單的修復，並且可以帶來明顯的性能提升，因此回溯修補到所有支援的分支。 討論：https://postgr.es/m/20210826084430.GA26282@depesz.com https://git.postgresql.org/pg/commitdiff/bd3611db5a6f3726094872f59feab426374d2c46

  • 重構 postgresImportForeignSchema 以避免程式碼重複。 避免重複我們正在構建的查詢片段，與 pg_dump 中最近的清理工作類似。我對此感到惱火，因為 aa769f80e 破壞了我正在申請的補丁，該補丁用於更改 postgres_fdw 的排序規則處理，因為我們每個人都不完全地完成了相同的重構。讓我們完成這項工作，以期擁有一個更穩定的基礎。 https://git.postgresql.org/pg/commitdiff/2dc53fe2a77d8d5f22c656fdf6590198e358a996

  • 文件：闡明觸發器如何與交易相關。 Laurenz Albe，根據 Nathan Long 的抱怨。 討論：https://postgr.es/m/161953360822.695.15805897835151971142@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/469150a240dd79acbe7d86cb5df869d95f4d6d2d

  • 修復 float4/float8 雜湊函數以產生 NaN 的一致結果。 IEEE 754 標準允許 NaN 的多種位元模式，其中至少兩種（"NaN" 和 "-NaN"）很容易從大多數機器上的 SQL 產生。這是有問題的，因為我們的 btree 比較函數認為所有 NaN 都相等，但我們的 float 雜湊函數對 NaN 一無所知，並且會很樂意為它們產生不同的雜湊碼。這會導致查詢包含不同 NaN 值的欄位時產生意外的結果。當在浮點欄位上使用雜湊索引時，也可能產生意外的查找失敗，即 "WHERE x = 'NaN'" 將不會找到它應該找到的所有列。為了修復，在浮點雜湊函數中特殊處理 NaN，與現有的特殊情況（強制零和負零雜湊相同）沒有太大的不同。我安排了最普通的 NaN 類型（來自 C99 NAN 常數）仍然具有與以前相同的雜湊碼，以減少對現有雜湊索引的風險。我猶豫是否要將此修補程式回溯修補到穩定分支，但最終決定這樣做。對於內部進行雜湊的查詢來說，這是一個明顯的改進。如果有人在雜湊索引中使用 -NaN，他們最好在應用此修補程式後重新索引 ... 但是如果他們不這樣做，其錯誤行為不會比他們之前遇到的錯誤行為更糟。根據 Ma Liangzhu 提出的錯誤 #17172。 討論：https://postgr.es/m/17172-7505bea9e04e230f@postgresql.org https://git.postgresql.org/pg/commitdiff/ce773f230d9b5bb2e0dd23fec4e5462fd99487fe

  • 在 count_usable_fds() 中，複製 stderr 而不是 stdin。我們收到一個投訴，如果調用程式關閉 stdin，則 postmaster 無法啟動。發生這種情況是因為 count_usable_fds 期望能夠 dup(0)，如果它不能，我們得出結論沒有可用的 FD，並且會崩潰。就我所知，伺服器中沒有其他地方會觸摸 stdin，並且期望守護進程不使用該文件是合理的。作為一個簡單的改進，讓我們改為 dup FD 2 (stderr)。與 stdin 不同，期望我們打開 stderr 是*合理的*；即使我們配置為不觸摸它，常見的庫（例如 libc）也可能會嘗試在那裡寫入錯誤訊息。根據 Mario Emmenlauer 的抱怨。 考慮到之前沒有投訴，我對將此推送到穩定分支感到不興奮，但似乎可以將其塞進 v14。 討論：https://postgr.es/m/48bafc63-c30f-3962-2ded-f2e985d93e86@emmenlauer.de https://git.postgresql.org/pg/commitdiff/c95ede41b8d47b21d58702fbc519e720f41fdaf1

  • 修復來自提交 ce773f230 的測試中的可移植性問題。 現代 POSIX 似乎要求 strtod() 接受 "-NaN"，但在 SUSv2 中沒有關於 NaN 的任何內容，並且我們的一些最舊的構建農場成員不喜歡它。 讓我們嘗試將其寫為 -'NaN' 代替； 至少在 Intel 硬體上，這似乎產生了相同的結果。 每個構建農場。 https://git.postgresql.org/pg/commitdiff/fd549145d5d9fba3367cbf7e3d4fc7cb3562feb0

  • 如果資料庫編碼不支援，則不允許建立 ICU 排序規則。 以前這是允許的，但是由於 lookup_collation() 的工作方式，排序規則實際上消失在乙太中：您無法使用排序規則，甚至無法刪除它。 似乎最好先給出一個錯誤，而不是讓使用者想知道為什麼它不起作用。 （由於此測試在 DefineCollation 而不是 CreateCollation 中，因此無論最初選擇的編碼如何，它都不會阻止 pg_import_system_collations 建立 ICU 排序規則。） 根據 Andrew Bille 提出的錯誤 #17170。 回溯修補到新增 ICU 支援的 v10。 討論：https://postgr.es/m/17170-95845cf3f0a9c36d@postgresql.org https://git.postgresql.org/pg/commitdiff/db2760a84191c329c0cdfaa1dae048c32b0c1752

  • 刪除 pg_ctl 中命令長度的任意 MAXPGPATH 限制。 將固定長度的命令緩衝區替換為 psprintf() 調用。 編寫此程式碼時，我們沒有像 psprintf() 這樣方便的東西，但是現在我們有了，沒有理由讓這個限制存在。 刪除它可以消除一些邊緣情況，例如，啟動帶有很多選項的 postmaster 會失敗。 pg_ctl 處理的大多數個別檔案名稱仍然限制為 MAXPGPATH，但是只要它僅應用於一個檔案名，我們就很少收到關於該限制的投訴。 回溯修補到所有支援的分支。 Phil Krylov 討論：https://postgr.es/m/567e199c6b97ee19deee600311515b86@krylov.eu https://git.postgresql.org/pg/commitdiff/87ad491472d6f8620d83ec9db4f515ce303052ac

  • psql 幫助輸出的次要改進。 修復 "\?" 輸出的字母順序，並改進一個描述。 在需要時更新 PageOutput 計數，修復先前修補程式的損壞。 Haiying Tang （PageOutput 修復由我完成） 討論：https://postgr.es/m/OS0PR01MB61136018064660F095CB57A8FB129@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/ac5ea660996ecbbfbe78b881a581132a95d93d26

  • 針對 float4/float8 雜湊函數進行進一步的可移植性調整。為了使 hashfloat4() 看起來盡可能像 hashfloat8()，我原本以為可以在擴展到 float8 之前，先用 get_float4_nan() 替換 NaN 值。然而，來自 protosciurus 和 topminnow 的結果顯示，在某些平台上，這樣做會產生與 get_float8_nan() 不同的位元模式，從而破壞了 ce773f230 的意圖。重新安排程式碼，以便我們在所有 NaN 情況下都使用 get_float8_nan() 的結果。和之前一樣，進行回溯修補。https://git.postgresql.org/pg/commitdiff/b30cc0fd6d5d96c63037824c286cec561e092b6f

Tomáš Vondra 推送了

John Naylor 推送了

Peter Geoghegan 推送了

Peter Eisentraut 推送了

  • 修正不正確的格式佔位符。 https://git.postgresql.org/pg/commitdiff/590ecd982304dec8599d6ca339903982d39a9a1a

  • 修正靜態連結的 pkg-config 檔案。自 ea53100d5 (PostgreSQL 12) 以來，提供的 pkg-config 檔案對於靜態連結 libpq 已經損壞，因為缺少 libpgcommon 和 libpgport。此修補程式新增了這兩個缺少的私有依賴項（以非硬編碼的方式）。報告人：Filip Gospodinov f@gospodinov.ch 討論：https://postgres.tw/message-id/flat/c7108bde-e051-11d5-a234-99beec01ce2a@gospodinov.ch https://git.postgresql.org/pg/commitdiff/4c2eab3a0dec2eae40892fb525830a5947a398c7

  • 使 pkg-config 檔案更易於交叉編譯。目前，pc 檔案針對 "includedir" 和 "libdir" 使用了硬編碼的路徑。 範例： Cflags: -I/usr/include Libs: -L/usr/lib -lpq 當在建置環境 (buildroot) 內進行交叉編譯時，這不是很理想，因為 include 檔和 lib 檔位於暫存目錄中，這會將主機路徑引入到建置過程中： checking for pkg-config... /builder/shared-workdir/build/sdk/staging_dir/host/bin/pkg-config checking for PostgreSQL libraries via pkg_config... -L/usr/lib <---- 此 commit 通過執行以下兩件事來解決這個問題： 1. 不再在 "Cflags" 和 "Libs" 中硬編碼路徑，而是使用 "${includedir}" 和 "${libdir}"。注意：這些變數可以在 pkg-config 命令列上覆寫 ("--define-variable=libdir=/some/path")。 2. 新增變數 "prefix" 和 "exec_prefix"。 如果 "includedir" 和/或 "libdir" 正在使用這些變數，則相應地建構它們。 這樣做是因為建置環境 (例如 OpenWrt) 傾向於重新命名真實的 pkg-config，並從一個設置 "prefix"、"exec_prefix" 和 "bindir" 的腳本中間接呼叫它，如下所示： pkg-config.real --define-variable=prefix=${STAGING_PREFIX} \ --define-variable=exec_prefix=${STAGING_PREFIX} \ --define-variable=bindir=${STAGING_PREFIX}/bin $@ 範例 #1：使用者使用 "--libdir=/some/lib" 和 "--includedir=/some/include" 呼叫 ./configure： prefix=/usr/local/pgsql exec_prefix=${prefix} libdir=/some/lib includedir=/some/include Name: libpq Description: PostgreSQL libpq library Url: https://postgres.tw/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm 範例 #2：使用者不帶任何參數呼叫 ./configure： prefix=/usr/local/pgsql exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libpq Description: PostgreSQL libpq library Url: https://postgres.tw/ Version: 12.1 Requires: Requires.private: Cflags: -I${includedir} Libs: -L${libdir} -lpq Libs.private: -lcrypt -lm 像這樣，當使用建置環境設定時，路徑可以被強制進入暫存目錄： checking for pkg-config... /home/sk/tmp/openwrt/staging_dir/host/bin/pkg-config checking for PostgreSQL libraries via pkg_config... -L/home/sk/tmp/openwrt/staging_dir/target-mips_24kc_musl/usr/lib 作者：Sebastian Kemper sebastian_ml@gmx.net 共同作者：Peter Eisentraut peter.eisentraut@enterprisedb.com 討論： https://postgres.tw/message-id/flat/20200305213827.GA25135%40darth.lan https://git.postgresql.org/pg/commitdiff/6588d8416e4ef84fd99fb271b63116f207c6c479

Tatsuo Ishii 推送了

  • 在 pgbench 中使用 COPY FREEZE 以加快基準測試表格的填充速度。 在填充 pgbench_accounts 表格時，無條件地使用了普通的 COPY。 通過將其更改為 COPY FREEZE，可以顯著減少 VACUUM 的時間，從而也減少了 "pgbench -i" 的總時間。 這僅在 pgbench 針對 PostgreSQL 14 或更高版本運行時發生，因為 PostgreSQL 早期版本的 COPY FREEZE 不會帶來好處。 此外，如果使用分割區，則不能使用 COPY FREEZE。 在這種情況下，也將使用普通的 COPY。 作者：Tatsuo Ishii 討論： https://postgr.es/m/20210308.143907.2014279678657453983.t-ishii@gmail.com 審閱者：Fabien COELHO, Laurenz Albe, Peter Geoghegan, Dean Rasheed https://git.postgresql.org/pg/commitdiff/06ba4a63b85e5aa47b325c3235c16c05a0b58b96