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

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

一月份的 PostgreSQL 工作崗位

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

PostgreSQL 本地活動

Nordic PGDay 2022 將於 2022 年 3 月 22 日在芬蘭赫爾辛基的希爾頓赫爾辛基斯特蘭德酒店舉行。此處

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

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

Citus Con，一個全球虛擬開發者大會，將於 2022 年 4 月 12 日至 13 日舉行。徵稿現已開放。

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()` 中的先前程式碼。由 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

  • 刪除迴歸測試指令碼的動態翻譯，第一步。`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

  • 刪除迴歸測試指令碼的動態翻譯，第二步。“git mv”所有 `input/*.source` 和 `output/*.source` 檔案到相應的 `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

  • 為自定義 GUC 新增 `EmitWarningsOnPlaceholders()` 呼叫。定義任何自定義 GUC 的擴充套件在這樣做之後應該呼叫 `EmitWarningsOnPlaceholders()`，以幫助捕獲拼寫錯誤。然而，我們的許多 contrib 模組都沒有遵循這一點。還將此類呼叫新增到 `src/test/modules` 擴充套件中，這些擴充套件有 GUC。雖然這些並非真正面向用戶，但它們應該說明良好實踐而不是錯誤的實踐。作者：Shinya Kato 討論：https://postgr.es/m/524fa2c0a34f34b68fbfa90d0760d515@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/1fada5d81e6769ded832a4ca62ee9371bac3fb9f

  • 為 psql 的 `\getenv` 新增幫助和製表符補全支援。我在 33d3eeadb 中忘記了這些細節 :-（。由 Christoph Berg 提出。討論：https://postgr.es/m/YcI8i/mduMi91uXY@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/0f2abd05441f524a67bc58ef5f0cc32054f7fb66

  • 重新考慮處理帶有擴充套件保留字首的設定。提交 `75d22069e` 在嘗試設定一個未識別的引數（位於之前由擴充套件保留的名稱空間內）時，會列印一個警告。然而，出於同樣的原因，我們不允許你設定未識別的未限定引數名稱，因此讓它成為一個明確的錯誤似乎更好。無論如何，之前的實現效率低下且有錯誤。在一個更合適的位置執行檢查，並更仔細地處理字首匹配的情況。討論：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` 分配的結構中，這樣我們就不會在每個非歸檔程序中浪費幾 KB 的靜態資料。新增一個 `binaryheap_reset()` 呼叫，以明確表示我們使用空的堆開始目錄掃描。我不認為那裡有活動的 bug，但它看起來很脆弱，而這是一種廉價的保險。提交 `beb4e9ba1` 的清理工作，無需回溯補丁。討論：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`。這只是一個潛在的 bug，因為 `pg_backup_archiver.c` 稍後會過濾掉 `ArchiveEntry`；但它們在僅資料轉儲中浪費了計算週期，並且這種遺漏有一天可能會成為一個活動的 bug。無論如何，讓一些 `dumpFoo` 函式執行此操作而另一些不執行是不好的。基於相同的理由，使 `dumpPublicationNamespace` 遵循所有其他 `dumpFoo` 函式檢查 `DUMP_COMPONENT_DEFINITION` 標誌的模式。（自 `5209c0ba0` 以來，如果未設定該標誌，我們甚至不會進入此處，因此目前檢查它只是形式上的。但將來可能並非如此。）由於這只是美化或未來相容性，因此無需回溯補丁。https://git.postgresql.org/pg/commitdiff/5e65df64d631257ce60016bec0aca43f042b1d33

  • pg_dump：透過消除子查詢來小的效能改進。移除“username_subquery”機制，轉而進行本地查詢角色名 OID。PG 後端對於 SELECT 輸出列表中的標量 SubLinks 並不十分智慧，因此這提供了一個小的效能改進，至少在擁有兩個以上使用者的安裝中是如此。無論如何，舊方法並沒有使 SQL 程式碼更易讀。同時，我移除了關於查詢物件所有者失敗的各種自定義警告訊息，轉而直接在本地查詢函式中將其視為致命錯誤。據我所知，現在沒有任何理由將其視為除了目錄損壞之外的任何情況，當然也沒有理由讓翻譯人員處理十幾種不同的訊息，而一種就足夠了。（如果事實證明 `fatal()` 確實是個壞主意，我們可以退回到發出 `pg_log_warning()` 並返回一個空字串，從而產生與之前相同的行為，只是更一致。）還刪除了一個完全不必要的子查詢來檢查序列關係的 `pg_depend` 狀態：我們已經在 FROM 子句中有一個 LEFT JOIN 來獲取感興趣的行。討論：https://postgr.es/m/2460369.1640903318@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d5e8930f50e31d836d84b353b9dadedd5007bb70

  • pg_dump：在 `getPolicies()` 中避免不安全的函式呼叫。`getPolicies()` 患有與提交 `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 的表示式，那麼返回該表示式的查詢可能會導致僅索引掃描計劃，該計劃會嘗試讀取不可返回的列，而不是按預期從可返回的列重新計算表示式。為了修復，將 `IndexOnlyScan` 計劃節點的“indextlist”列表重新定義為用 `Const` 的 `null` 值代替任何不可返回的列。透過阻止 `setrefs.c` 錯誤地匹配這些條目來解決此問題。執行程式樂於接受，因為它只關心條目的公開型別，並且 `ruleutils.c` 也不關心，因為正確的計劃不會引用這些條目。我還考慮了其他幾種方法來阻止 `setrefs.c` 產生錯誤行為，但這種方法似乎很好，因為（a）它允許非常區域性化的修復，（b）它在許多情況下使 `indextlist` 結構更緊湊，並且（c） `indextlist` 現在更忠實地表示索引 AM 實際會產生什麼，即對任何不可返回的列返回 `null`。自從我們引入了包含列以來，這一點更容易受到影響，但也可以在不使用包含列的情況下構造失敗的示例，如新增的迴歸測試所示。因此，回溯補丁到所有支援的分支。根據 bug #17350，來自 Louis Jachiet。討論：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 已推送