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

PostgreSQL 每週新聞 - 2021 年 11 月 7 日

釋出於 2021-11-08，作者 PWN
PWN

PostgreSQL 每週新聞 - 2021 年 11 月 7 日

PG Build 2021 將於 2021 年 11 月 30 日和 12 月 1 日 GMT 時間 09:00-17:00 線上舉行。 詳情。

PostgreSQL 產品新聞

PostgresDAC 3.11 釋出，這是一個用於 PostgreSQL 的直接訪問元件套件。 http://microolap.com/products/connectivity/postgresdac/download/

JDBC 42.3.1 已釋出。

ODB C++ ORM 版本 2.5.0-b.21 已釋出。

DynamoDB FDW 1.0.0 已釋出。

Babelfish，一個用於 PostgreSQL 的 MS SQL Server 相容層，已釋出。

11月 PostgreSQL 工作機會

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

PostgreSQL 相關新聞

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

本週 PostgreSQL 週報由 David Fetter 提供。

請在太平洋標準時間（PST8PDT）週日晚上3:00之前將新聞和公告發送至 david@fetter.org。

已應用補丁

Tom Lane 提交

Michaël Paquier 提交

  • 在 REINDEX CONCURRENTLY 期間保留運算子類引數。舊索引的運算子類引數 Datums 的獲取方式與謂詞和表示式相同，直接從系統目錄中獲取。然後將它們複製到將用於建立新副本的新的 IndexInfo 中。這導致新索引以預設引數重建，而不是使用者預定義的引數。獲得具有正確運算子類引數的新索引的唯一方法是重新從頭開始建立新索引。此問題由 911e702 引入。作者：Michael Paquier 審閱者：Zhihong Yu 討論：https://postgr.es/m/YX0CG/QpLXcPr8HJ@paquier.xyz 回溯到：13 https://git.postgresql.org/pg/commitdiff/add5cf28d48149459466b9aff374d78aebf17482

  • 為 pg_receivewal 新增時間線切換的 TAP 測試。pg_receivewal 能夠跟蹤時間線切換，但這並未經過測試。此測試使用空的歸檔位置，並從槽進行重啟，使其實現比重用現有歸檔目錄稍簡單一些。作者：Ronan Dunklau 審閱者：Kyotaro Horiguchi, Michael Paquier 討論：https://postgr.es/m/18708360.4lzOvYHigE@aivenronan https://git.postgresql.org/pg/commitdiff/0f9b9938a0367313fcf6a32fcb7fb5be9e281198

  • 重構 pg_receivewal 的壓縮選項。自 cada1af 起，pg_receivewal 包含了 --compress 選項，允許使用 gzip 壓縮 WAL 段，值為 0（預設）表示不壓縮。此提交引入了一個新選項 --compression-method，其值可以為“none”（預設）和“gzip”，以使事情更具擴充套件性。--compress=0 的情況與此選項層變得模糊，因此我們選擇使 pg_receivewal 在使用“none”且壓縮級別非零時返回錯誤，這意味著 --compress 的授權值現在是 [1,9] 而不是 [0,9]。未指定 --compress 和“gzip”作為壓縮方法，pg_receivewal 會使用 zlib 的預設值（Z_DEFAULT_COMPRESSION）。負責在掃描現有歸檔時查詢流式啟動 LSN 的程式碼被重構並使其更具擴充套件性。同時，在 walmethods.c 中將“compression”重新命名為“compression_level”，以減少與引入壓縮方法混淆，即使 pg_basebackup 使用的 tar 方法不依賴於壓縮方法（至少目前還不是），而僅僅依賴於壓縮級別（實際上，這個區域可以進一步改進）。這是為即將釋出的新增 LZ4 支援到 pg_receivewal 的補丁做準備。作者：Georgios Kokolatos 審閱者：Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar 討論：https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/d62bcc8b07f921bad105c7a826702c117ea7be58

  • 修復 pg_receivewal --compression-method 的一些錯誤。選項名稱在一個錯誤訊息中不正確，並且程式碼中使用了短選項 'I'，但我們不打算這樣。同時，修復文件以引用“方法”，而不是“級別”。提交 d62bcc8 中的疏忽，我在進一步審查 pg_receivewal 的 LZ4 補丁後檢測到。 https://git.postgresql.org/pg/commitdiff/9588622945754305836555273a6a3be814db315c

  • 為 pg_receivewal 新增 LZ4 壓縮支援。pg_receivewal 獲得了一個新選項 --compression-method=lz4，當代碼使用 --with-lz4 編譯時可用。與 gzip 類似，這提供了使用 LZ4 壓縮歸檔 WAL 段的可能性。此選項與 --compress 不相容。實現使用 LZ4 幀，併兼容簡單的 lz4 命令。與 gzip 類似，使用 --synchronous 可以確保任何資料在當前 .partial 段內重新整理到磁碟，從而儘可能多地檢索 WAL 資料，即使是從未完成的段（這需要將部分檔案填充零直到後端解壓後支援的 WAL 段大小，但這與 gzip 相同）。計算流式啟動 LSN 的程式碼能夠透明地查詢和檢查 LZ4 壓縮的段。與 gzip 不同，gzip 直接將未壓縮的大小儲存在讀取的物件中，LZ4 塊協議預設不儲存未壓縮的資料。there is contentSize，它可以透過 LZ4 幀使用，但這無助於使用包含預設壓縮的“lz4”命令壓縮的段的歸檔，其中此資訊未儲存。因此，此提交採取了最可擴充套件的方法，透過以 64kB 的塊（沒有注意到 8kB、16kB 或 32kB 的實際效能差異，並且操作本身實際上很快）為空輸出緩衝區來解壓縮已歸檔的段以檢查其未壓縮大小。已新增測試以驗證生成的 LZ4 檔案的建立和正確性。後者透過使用環境變數中的“lz4”命令來實現。walmethods.c 中的 tar-based WAL 方法（目前僅由 pg_basebackup 使用）尚不瞭解 LZ4。其程式碼可以擴充套件用於此目的。作者：Georgios Kokolatos 審閱者：Michael Paquier, Jian Guo, Magnus Hagander, Dilip Kumar 討論：https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/babbbb595d2322da095a1e6703171b3f1f2815cb

  • 改進 psql 的 tab 補全功能 for COMMENT。為更多物件型別添加了補全，例如 domain constraints、text search 相關物件或 policies。此外，該區域進行了重組，將 COMMENT 支援的物件列表的順序更改為與文件一致，以便於將來的新增。作者：Ken Kato 審閱者：Fujii Masao, Shinya Kato, Suraj Khamkar, Michael Paquier 討論：https://postgr.es/m/6e0c2f3f657b229bea32d098d118f307@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/a5b336b8b9e04a93e7c8526302504d2e5201eb80

Álvaro Herrera 提交

Daniel Gustafsson 提交

Amit Kapila 提交

Fujii Masao 提交

Peter Geoghegan 提交

Peter Eisentraut 提交

Heikki Linnakangas 提交

Robert Haas 提交

  • amcheck：新增額外的 TOAST 指標檢查。擴充套件對 TOAST 屬性的檢查，以在原始大小過大時發出警告。對於壓縮屬性，如果壓縮似乎擴大了屬性或壓縮方法無效，也應發出警告。Mark Dilger，審閱者 Justin Pryzby, Alexander Alekseev, Heikki Linnakangas, Greg Stark 和我。討論：http://postgr.es/m/8E42250D-586A-4A27-B317-8B062C3816A8@enterprisedb.com https://git.postgresql.org/pg/commitdiff/bd807be6935929bdefe74d1258ca08048f0aafa3

  • 引入 'bbsink' 抽象以模組化基礎備份程式碼。基礎備份程式碼多年來積累了大量新功能，但由於沒有真正分離關注點，維護和進一步增強這些程式碼變得越來越困難。例如，瞭解如何使用 libpq 協議將資料傳送到客戶端的程式碼分散在 basebackup.c 的各個部分，而不是集中在一個地方。為了試圖改善這種情況，引入了一個新的 'bbsink' 物件，它充當基礎備份過程中生成的歸檔的接收者，也充當備份清單的接收者。此提交引入了三種類型的 bbsink：'copytblspc' bbsink 透過每個表空間一次 COPY OUT 操作將備份轉發到客戶端，以及一個用於清單的；'progress' bbsink 執行命令進度報告；'throttle' bbsink 執行速率限制。'progress' 和 'throttle' bbsink 型別還將資料轉發到後繼的 bbsink；目前，鏈中的最後一個 bbsink 始終是 'copytblspc' 型別。計劃在未來的提交中新增更多型別的 'bbsink'。此抽象在進度報告的情況下有點洩漏，但仍然比我們以前的更好。補丁由我編寫，由 Andres Freund, Sumanta Mukherjee, Dilip Kumar, Suraj Kharage, Dipesh Pandit, Tushar Ahuja, Mark Dilger 和 Jeevan Ladhe 審閱和測試。討論：https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com 討論：https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/bef47ff85df18bf4a3a9b13bd2a54820e27f3614

  • 引入 'bbstreamer' 抽象以模組化 pg_basebackup。pg_basebackup 知道如何處理從伺服器獲取的備份的許多事情，例如直接寫出檔案，或先壓縮它們，甚至解析 tar 格式並將修改後的 postgresql.auto.conf 檔案注入伺服器生成的歸檔中。不幸的是，這使得 pg_basebackup.c 成為一個非常大的原始檔，並且也難以進行增強，因為例如，關於伺服器正在向我們傳送“tar”檔案而不是其他型別歸檔的知識分佈在各個地方，而不是集中在一個地方。為了改善這種情況，此提交發明瞭一個新的“bbstreamer”抽象。從伺服器接收的每個歸檔都饋送給一個 bbstreamer，該 bbstreamer 可以選擇處理它或將其傳遞給另一個 bbstreamer。資料塊也可以根據它們是歸檔檔案中檔案的資料負載部分還是歸檔元資料部分被“標記”。因此，例如，如果我們想獲取一個 tar 檔案，修改其中包含的 postgresql.auto.conf 檔案，然後將其 gzip 並寫出，我們可以使用 bbstreamer_tar_parser 來解析從伺服器接收到的 tar 檔案，bbstreamer_recovery_injector 來修改 postgresql.auto.conf 的內容，bbstreamer_tar_archiver 來用新構建的、對於已修改檔案正確的 tar 頭替換前一步修改檔案的 tar 頭，以及 bbstreamer_gzip_writer 來 gzip 並寫出結果資料。只有名稱中包含“tar”的物件才知道 tar 歸檔格式，並且理論上如果我們想使用除“tar”以外的其他格式進行重新歸檔，我們可以這樣做。這些更改確實增加了大量程式碼，但我認為結果更易於維護和擴充套件。pg_basebackup.c 本身縮小了大約三分之一，其中許多以前包含的複雜性都轉移到了新新增的檔案中。補丁由我編寫。作為此部分的大型補丁系列，已由 Andres Freund, Sumanta Mukherjee, Dilip Kumar, Suraj Kharage, Dipesh Pandit, Tushar Ahuja, Mark Dilger, Sergei Kornilov 和 Jeevan Ladhe 在不同時間進行過審閱和測試。討論：https://postgr.es/m/CA+TgmoZGwR=ZVWFeecncubEyPdwghnvfkkdBe9BLccLSiqdf9Q@mail.gmail.com 討論：https://postgr.es/m/CA+TgmoZvqk7UuzxsX1xjJRmMGkqoUGYTZLDCH8SmU1xTPr1Xig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/23a1c6578c87fca0e361c4f5f9a07df5ae1f9858

  • 在不需要時不要設定 ThisTimeLineID。在 slotfuncs.c 中，pg_replication_slot_advance() 需要確定槽應推進到的 LSN，但這不需要更新 ThisTimeLineID，因為從這裡呼叫的任何程式碼都不依賴於它。如果複製槽是邏輯的，pg_logical_replication_slot_advance 將呼叫 read_local_xlog_page，它確實會使用 ThisTimeLineID，但也會確保其是最新的。如果是物理複製槽，時間線根本不會被使用。在 logicalfuncs.c 中，pg_logical_slot_get_changes_guts() 存在同樣的問題：我們唯一要執行的程式碼是 read_local_xlog_page 或其下游程式碼，後者已經確保設定了正確的值。因此，不要在這裡執行。補丁由我編寫，由 Michael Paquier, Amul Sul 和 Álvaro Herrera 審閱和測試。討論：https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/caf1f675b88d1aa67ea3fb642e8f38b470cc911e

  • 移除 xlog.c 之外對 ThisTimeLineID 全域性變數的所有使用。所有此類程式碼都以三種方式之一處理此全域性變數。有時，同一函式在同一時間以多種方式使用它。首先，有時它是 xlog.c 或其他地方呼叫的一個或多個函式的隱式引數，並且必須在呼叫這些函式之前設定為適當的值，以免它們出錯。在那些情況下，現在將它顯式傳遞作為引數。其次，有時在恢復結束後用於獲取當前時間線，即正在寫入和重新整理 WAL 的時間線。此類程式碼現在呼叫 GetWALInsertionTimeLine() 或依賴於新增到 GetFlushRecPtr() 的新的輸出引數。第三，有時在恢復期間用於儲存當前重放時間線。這可能會發生變化，因此此類程式碼通常必須在每次使用之前更新該值。它們仍然可以這樣做，但現在必須使用區域性變數。這些更改的淨效應是直接訪問此全域性變數的程式碼量大幅減少。這是好事，因為歷史表明，我們並不總是清楚在任何給定時間點它應該包含哪個時間線 ID，甚至在程式碼的任何給定點是否已經或需要初始化它。補丁由我編寫，由 Michael Paquier, Amul Sul 和 Álvaro Herrera 審閱和測試。討論：https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e997a0c642860a96df0151cbeccfecbdf0450d08

  • 將 ThisTimeLineID 從全域性變數更改為區域性變數。StartupXLOG() 仍然將 ThisTimeLineID 作為區域性變數，但 xlog.c 中剩餘的程式碼現在需要透過其他方式獲取相關 TimeLineID。大多數情況下，這意味著現在將它作為函式引數傳遞給許多以前沒有的函式。然而，少數情況需要特殊處理：- 在可能被外部呼叫者呼叫而不知道要指定哪個時間線的函式中，我們從共享記憶體中獲取時間線 ID。在大多數情況下可以使用 XLogCtl->ThisTimeLineID，因為可以假定在呼叫這些函式之前恢復已經完成。在 xlog_redo() 中，我們可以使用 XLogCtl->replayEndTLI。- XLogFileClose() 需要知道開啟的日誌檔案的 TLI。透過一個新的全域性變數 openLogTLI 來實現。雖然有人可能認為這只是用另一個全域性變數替換了一個全域性變數，但新的變數的用途要窄得多，並且只在少數幾個地方被引用。- read_backup_label() 現在返回透過解析 backup_label 檔案獲得的 TLI。以前，可以呼叫 ReadRecord() 來解析檢查點記錄，而 ThisTimeLineID 尚未初始化。現在，時間線會傳遞下去，而我不想傳遞未初始化的變數；這個更改可以避免這種情況。舊程式碼似乎沒有任何實際後果需要我們擔心，但這樣更清晰。- 在 BootstrapXLOG() 中，它只是一個常量。補丁由我編寫，由 Michael Paquier, Amul Sul 和 Álvaro Herrera 審閱和測試。討論：https://postgr.es/m/CA+TgmobfAAqhfWa1kaFBBFvX+5CjM=7TE=n4r4Q1o2bjbGYBpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4a92a1c3d1c361ffb031ed05bf65b801241d7cdd

  • 刪除由 bd807be6935929bdefe74d1258ca08048f0aafa3 新增的測試。Buildfarm 對此不滿意。不清楚它為什麼不喜歡這些測試，但讓我們在弄清楚之前刪除它們。討論：http://postgr.es/m/462618.1636171009@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ccf289745d3e50360653181dce6a277a1fc79730

Tomáš Vondra 提交了

Alexander Korotkov 提交了

Andres Freund 提交