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

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

發表於 2021-11-08 由 PWN
PWN

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

PG Build 2021 將於 2021 年 11 月 30 日和 12 月 1 日格林威治標準時間 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 帶給您

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

已應用補丁

Tom Lane 推送

Michaël Paquier 推送

  • 在 REINDEX CONCURRENTLY 中保留 opclass 參數。舊索引的 opclass 參數 Datums 是以與 predicates 和 expressions 相同的方式從系統目錄直接抓取來取得的。 然後將它們複製到將用於建立新副本的 IndexInfo 中。 這導致使用預設參數而不是使用者預定義的參數來重建新索引。 取得具有正確 opclass 參數的新索引的唯一方法是從頭開始重新建立一個新索引。 此問題是由 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]。如果將壓縮方法設定為 "gzip" 但未指定 `--compress`，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' 在程式碼中使用，但我們並非有意這樣做。同時，修正文件以引用 "method"，而不是 "level"。commit 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 區塊協定預設情況下不儲存解壓縮資料。可以使用 contentSize 與 LZ4 框架一起使用，但如果使用包含使用 "lz4" 命令預設值壓縮的區段的封存檔，則這將沒有幫助，因為這未儲存。因此，本次提交採用了最具擴充性的方法，通過在 64kB 的區塊中使用空白輸出緩衝區來解壓縮已封存的區段以檢查其解壓縮大小 (沒有注意到與 8kB、16kB 或 32kB 的實際效能差異，並且該操作本身實際上很快)。已添加測試以驗證產生的 LZ4 檔案的建立和正確性。後者是通過使用命令 "lz4" (如果在環境中找到) 來實現的。walmethods.c 中基於 tar 的 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 對於 COMMENT 的 Tab 自動完成功能。為更多物件類型 (例如域約束、文字搜尋相關物件或策略) 添加了自動完成功能。此外，該區域進行了重新組織，更改了 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 指標檢查。 擴充對 toasted 屬性的檢查，如果 rawsize 過大，則發出警告。 對於壓縮的屬性，如果壓縮似乎擴展了屬性，或壓縮方法無效，也發出警告。 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。區塊也可以根據它們是封存檔中檔案的 payload 資料的一部分還是封存檔元資料的一部分進行 "標記"。因此，例如，如果我們想取得一個 tar 檔案，修改它包含的 postgresql.auto.conf 檔案，然後 gzip 結果並寫出，我們可以使用 bbstreamer_tar_parser 來解析從伺服器收到的 tar 檔案，使用 bbstreamer_recovery_injector 來修改 postgresql.auto.conf 的內容，使用 bbstreamer_tar_archiver 來將前一步修改的檔案的 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() 需要確定應將 slot 進展到的 LSN，但這不需要我們更新 ThisTimeLineID，因為從這裡呼叫的任何程式碼都不依賴它。如果 replication slot 是 logical，pg_logical_replication_slot_advance 將呼叫 read_local_xlog_page，它會使用 ThisTimeLineID，但也會注意確保它是最新的。如果 replication slot 是 physical，則時間軸根本不會用於任何事情。在 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 推送了