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

PostgreSQL 每週新聞 - 2022 年 1 月 2 日

發布於 2022-01-05，作者 PWN
PWN

PostgreSQL 每週新聞 - 2022 年 1 月 2 日

PostgreSQL 產品新聞

Pgpool-II 4.2.7、4.1.10、4.0.17 和 3.7.22，PostgreSQL 的連線池和語句複製系統，已重新 發 布 。

parquet_s3_fdw 0.2.1，用於 S3 上 parquet 檔案的外部資料包裝器，已發布。

Database Lab 3.0，用於快速克隆大型 PostgreSQL 資料庫以構建非生產環境的工具，已發布。

sqlite_fdw 2.1.1 已發布。

DynamoDB FDW 1.1.0 已發布。

pg_query_rewrite 0.0.3，用於特定類型 PostgreSQL 語句的重寫器，已發布。

InfluxDB fdw 1.1.1 已發布 https://github.com/pgspider/influxdb_fdw

pgspider v2.0，基於 PostgreSQL 外部資料包裝器的分散式資料叢集引擎，已發布。

pg_builder 2.0.0，PostgreSQL 的 PHP 查詢構建器，已發布。

JDBC FDW 0.1.0 已發布

griddb_fdw 2.1.1 已發布。https://github.com/pgspider/griddb_fdw

1 月份的 PostgreSQL 工作

https://archives.postgresql.org/pgsql-jobs/2022-01/

PostgreSQL 本地活動

Nordic PGDay 2022 將於 2022 年 3 月 22 日在芬蘭赫爾辛基的 Hilton Helsinki Strand Hotel 舉行。這裡

pgDay Paris 2022 將於 2022 年 3 月 24 日在法國巴黎舉行。

FOSDEM PGDay 2022 將於 2022 年 2 月 5-6 日線上舉行。https://fosdem.org/2022/

Citus Con 是一項虛擬全球開發者活動，將於 2022 年 4 月 12-13 日舉行。徵稿啟事 (CFP) 現已開放。

PostgreSQL 新聞

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

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

請在太平洋標準時間 (PST8PDT) 星期日下午 3:00 之前將新聞和公告提交至 david@fetter.org。

已套用的修補程式

Peter Eisentraut 推送了

John Naylor 推送了

  • 為驗證 UTF-8 文字添加快速路徑。我們之前的驗證器使用傳統的演算法，一次執行一個位元組的比較和分支。 它很有用，因為我們總是確切地知道我們已經驗證了多少個位元組，但是這種精確性是有代價的。 輸入驗證可能會在 COPY FROM 的概況中突出顯示，並且 COPY FROM 的未來改進（例如並行性或更快的行解析）將對輸入驗證施加更大的壓力。 因此，為 ASCII 和多位元組 UTF-8 添加快速路徑：使用按位運算一次檢查 16 個位元組的 ASCII 碼。 如果失敗，請在這些位元組上使用「基於移位」的 DFA 來處理一般情況，包括多位元組。 這些路徑相對沒有分支，因此可以抵抗各種位元組模式。 使用這些演算法，UTF-8 驗證速度提高了幾倍，具體取決於平台和輸入位元組分佈。 pg_utf8_verifystr() 中的先前編碼被保留用於短字串以及快速路徑傳回錯誤時。 Review、效能測試和額外入侵由：Heikki Linakangas、Vladimir Sitnikov、Amit Khandekar、Thomas Munro 和 Greg Stark 討論：https://postgres.tw/message-id/CAFBsxsEV_SzH%2BOLyCiyon%3DiwggSyMh_eF6A3LU2tiWf3Cy2ZQg%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/911588a3f816d875261d8f7d89e2517978831cd5

Tom Lane 推送了

  • 向 psql 添加一個 \getenv 指令。\getenv 將環境變數的值提取到 psql 變數中。 這與十多年前添加的 \setenv 指令相反。 我們當時沒有看到 \getenv 的令人信服的用例，但即將進行的迴歸測試重構提供了現在添加它的充分理由。討論：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/33d3eeadb21d2268104840cfef6bc2226ddfc680

  • 移除迴歸測試腳本的動態轉換，步驟 1。pg_regress 長期以來都具有將路徑名稱動態替換到迴歸測試腳本和結果檔案中的功能，但使用該功能一直非常麻煩，主要是因為更新結果檔案需要繁瑣的手動編輯。讓我們擺脫這種情況，改為在環境變數中傳遞路徑。除了更容易維護之外，這種方式還能夠處理需要在運行時進行跳脫的路徑名稱，例如包含單引號的路徑。（在實際建立看起來像那樣的路徑方面，還有其他的絆腳石，但移除這個障礙似乎是一件好事。）使這種改變成為可能的關鍵編碼規則是使用 psql 的 \set 命令串連動態變數字串的各個部分，然後使用 :'variable' 標記來引用並跳脫字串，以供下一層的解釋。為了使這種更改對 "git blame" 更加透明，我將其分為兩個步驟。此提交增加了必要的 pg_regress.c 支援，並就地更改了所有 *.source 檔案，使其不再需要任何動態轉換。下一個提交只會將它們 "git mv" 到常規的 sql/ 和 expected/ 目錄中。討論：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d1029bb5a26cb84b116b0dee4dde312291359f2a

  • 移除迴歸測試腳本的動態轉換，步驟 2。將所有 input/.source 和 output/.source 檔案 "git mv" 到相應的 sql/ 和 expected/ 目錄中。然後移除與動態轉換相關的 pg_regress 和 Makefile 基礎結構。討論：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/dc9c3b0ff21465fa89d71eecf5e6cc956d647eca

  • 將 dblink 的路徑測試腳本合併到其主要測試中。不再需要啟動單獨的 psql 運行來建立這些函數。（主要迴歸測試中的一些重構也是必要的，但這需要更多的思考。）討論：https://postgr.es/m/1655733.1639871614@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/0e6e7f0806b2080cb31f33ff992ec2e4e35fa6f1

  • 新增遺漏的 EmitWarningsOnPlaceholders() 呼叫。定義任何自訂 GUC 的擴充功能，在執行此操作後應呼叫 EmitWarningsOnPlaceholders，以協助捕獲拼寫錯誤。我們的許多 contrib 模組尚未收到相關通知。此外，將此類呼叫新增到具有 GUC 的 src/test/modules 擴充功能中。雖然這些並非真正面向使用者，但它們應該說明良好的實踐，而不是錯誤的實踐。Shinya Kato 討論：https://postgr.es/m/524fa2c0a34f34b68fbfa90d0760d515@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/1fada5d81e6769ded832a4ca62ee9371bac3fb9f

  • 為 psql 的 \getenv 新增說明文件和 Tab 鍵自動完成支援。我在 33d3eeadb :-( 中忘記了這些細節。由 Christoph Berg 指出。討論：https://postgr.es/m/YcI8i/mduMi91uXY@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/0f2abd05441f524a67bc58ef5f0cc32054f7fb66

  • 重新思考如何處理擴充功能保留的具有字首的設定。如果您嘗試在先前由擴充功能保留的命名空間中設定無法辨識的參數，提交 75d22069e 會使 SET 印出警告。由於我們不允許您設定無法辨識的非限定參數名稱，因此這樣做直接產生錯誤似乎更好。無論如何，先前的實作效率低下且有錯誤。在更合適的位置執行檢查，並更加小心字首匹配的情況。討論：https://postgr.es/m/116024.1640111629@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2ed8a8cc5b634d33ea07d681c6b02213da07f792

  • 將 EmitWarningsOnPlaceholders() 重新命名為 MarkGUCPrefixReserved()。對於它現在的功能，這似乎是一個更清晰的名稱。提供一個相容性巨集，以便擴充功能不必立即轉換為新名稱。討論：https://postgr.es/m/116024.1640111629@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5609cc01c69b80f8788771dc6f5696a459469119

  • 回復關於預留位置的警告/錯誤的變更。回復提交 5609cc01c、2ed8a8cc5 和 75d22069e，直到我們對此應如何在平行工作程序中運作有一個不那麼破碎的想法為止。根據 buildfarm。討論：https://postgr.es/m/1640909.1640638123@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/cab5b9ab2c066ba904f13de2681872dcda31e207

  • 修復 pgarch 新目錄掃描邏輯中的問題。arch_filenames[] 陣列元素小了一個位元組，因此如果之後製作了另一個條目，則最大長度的檔名會損壞。（由 Thomas Munro 指出，Nathan Bossart 修復。）將這些陣列移動到 palloc'd struct 中，這樣我們就不會在每個非歸檔程序中浪費幾千位元組的靜態資料。新增 binaryheap_reset() 呼叫，以清楚表明我們從空堆積開始目錄掃描。我不認為有任何此類即時錯誤，但這似乎很脆弱，而且這是一個非常便宜的保險。清理提交 beb4e9ba1，因此不需要 back-patch。討論：https://postgr.es/m/CA+hUKGLHAjHuKuwtzsW7uMJF4BVPcQRL-UMZG_HM-g0y7yLkUg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1fb17b1903414676bd371068739549cd2966fe87

  • pg_dump 中的次要清理/最佳化。在提交 05649b88c 和 5209c0ba0 之後，findComments() 和 findSecLabels() 不再使用其 "Archive *fout" 參數，因此請刪除它們。在執行此操作的同時，我注意到沒有很好的理由讓 dumpCompositeTypeColComments() 執行自己的查詢來獲取複合類型的欄位名稱，而呼叫函數剛剛獲取了相同的資料。調整它以使用該查詢結果。這可能不會為大多數人節省很多，因為自 5209c0ba0 以來，除非複合類型至少有一個註解，否則我們根本不會進入此程式碼。儘管如此，這還是一個浪費的查詢。https://git.postgresql.org/pg/commitdiff/c7cf73eb7b9e7911748ebe117a7219f21e504121

  • pg_dump：使 dumpPublication 等函數更像同級函數。dumpPublication、dumpPublicationNamespace、dumpPublicationTable 和 dumpSubscription 未能檢查 dataOnly。這只是一個潛在的錯誤，因為 pg_backup_archiver.c 會在稍後過濾掉 ArchiveEntry；但它們在僅資料傾印中浪費週期，並且此疏忽將來可能會成為一個即時錯誤。無論如何，讓一些 dumpFoo 函數執行此操作，而另一些則不執行，這是不好的。基於相同的推理，使 dumpPublicationNamespace 遵循與每個其他 dumpFoo 函數相同的模式來檢查 DUMP_COMPONENT_DEFINITION 標誌。（自 5209c0ba0 以來，如果未設定該標誌，我們甚至不會到達此處，因此現在檢查它只是形式上的。但它可能不會永遠如此。）由於這只是表面上的和/或未來的證明，因此無需 back-patch。https://git.postgresql.org/pg/commitdiff/5e65df64d631257ce60016bec0aca43f042b1d33

  • pg_dump: 透過消除子查詢來改善效能。移除 "username_subquery" 機制，改為從角色 OID 進行角色名稱的本地查找。PG 後端對於 SELECT 輸出列表中的純量 SubLink 並不是很聰明，因此這提供了一些效能上的改善，至少在擁有超過幾個使用者的環境中是如此。無論如何，舊方法產生的 SQL 程式碼並不好讀。同時，我移除了關於無法找到物件擁有者的各種自訂警告訊息，改為直接在本地查找函式中觸發 fatal()。據我所知，沒有理由再將其視為目錄損壞的情況，當然也沒有理由讓翻譯人員處理十幾個不同的訊息，而一個訊息就可以解決問題。（如果 fatal() 確實是一個壞主意，我們可以退回到發出 pg_log_warning() 並返回一個空字串，產生與之前相同的行為，只是更加一致。）此外，也移除了一個完全不必要的子查詢，用於檢查序列關係的 pg_depend 狀態：我們已經有一個 LEFT JOIN 來在 FROM 子句中取得感興趣的列。討論：https://postgr.es/m/2460369.1640903318@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d5e8930f50e31d836d84b353b9dadedd5007bb70

  • pg_dump: 避免在 getPolicies() 中呼叫不安全的函式。getPolicies() 存在與我在 commit e3fcbbd62 中修復的其他地方相同的問題，也就是說，它正在為我們不一定擁有鎖的表格呼叫 pg_get_expr()。為了修復，限制查詢僅收集感興趣的列，而不是在客戶端進行過濾。與之前的補丁一樣，目前僅應用於 HEAD。討論：https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us 討論：https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc https://git.postgresql.org/pg/commitdiff/3e6e86abca0138abd7265306beb6346dc2d9e221

  • 修正當並非所有索引欄位都可以返回時，僅索引掃描計畫的問題。如果索引同時具有可返回和不可返回的欄位，並且其中一個不可返回的欄位是使用 Var 的表達式，而該 Var 位於可返回的欄位中，則返回該表達式的查詢可能會導致嘗試讀取不可返回欄位的僅索引掃描計畫，而不是像預期的那樣從可返回的欄位重新計算表達式。為了修復，將 IndexOnlyScan 計畫節點的 "indextlist" 列表重新定義為包含空 Consts，以代替任何不可返回的欄位。這透過防止 setrefs.c 錯誤地匹配到這些條目來解決問題。執行器很樂意，因為它只關心條目的公開類型，而 ruleutils.c 則不在乎，因為正確的計畫不會引用這些條目。我考慮過其他一些方法來防止 setrefs.c 做錯誤的事情，但這種方式似乎很好，因為 (a) 它允許非常局部的修復，(b) 它使 indextlist 結構在許多情況下更加緊湊，並且 (c) indextlist 現在更忠實地表示索引 AM 實際將產生什麼，即任何不可返回欄位的 null。自從我們引入包含欄位以來，這更容易命中，但是可以構建失敗的示例而無需它，如添加的回歸測試所示。因此，回溯修補到所有支援的分支。根據 Louis Jachiet 提供的錯誤 #17350。討論：https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org https://git.postgresql.org/pg/commitdiff/4ace456776524839ef3279ab0bad8a2c9f6cc2a7

Amit Kapila 推出了

Michaël Paquier 推出了

Bruce Momjian 推送

Fujii Masao 推送

Thomas Munro 推送

Daniel Gustafsson 推送

Álvaro Herrera 推送

Andres Freund 推送

Magnus Hagander 推送