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

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

由 PWN 發表於 2021-09-20
PWN

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

Pgpool-II 4.2.5，適用於 PostgreSQL 的連線池和語句複製系統，已發布

Database Lab 2.5，用於快速複製大型 PostgreSQL 數據庫以構建非生產環境的工具，已發布。

pgexporter 0.1.0，適用於 PostgreSQL 的 Prometheus exporter，已發布

PostgreSQL 產品新聞

9 月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已套用的修補程式

Michaël Paquier 推送了

  • 重構 syslogger 管道協議，以使用位元遮罩來表示其選項。先前的協議需要一組匹配的字元來檢查發送的訊息是否為最後一條，這取決於所需的目的地而改變：- 't' 和 'f' 追蹤發送到 stderr 的日誌的最後一條訊息。- 'T' 和 'F' 追蹤發送到 csvlog 的日誌的最後一條訊息。引入新目的地時，可以擴充更多字元，但使用位元遮罩更優雅。此提交變更了協議，以便在發送到 syslogger 的日誌區塊訊息的標頭中使用位元遮罩，目前可用的選項如下：- log_destination 為 stderr。- log_destination 為 csvlog。- 訊息是否為訊息的最後一個區塊。Sehrope 在引入 JSON 作為 log_destination 選項的修補程式集中發現了這個問題，但他的修補程式增大了協議標頭的大小。此提交保持與原始版本相同的大小，並根據需要調整協議。感謝 Andrew Dunstan 和 Greg Stark 的討論。作者：Michael Paquier、Sehrope Sarkuni 討論：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2d77d835403a20b51e17e59f0343ddc17f431eec

  • 為帶有日誌收集器的 csvlog 新增迴歸測試。這些已新增到現有的 pg_ctl 日誌輪換測試中，該測試已測試 stderr。新增了與 csvlog 相同的涵蓋範圍：- 檢查 pg_current_logfile()。- 使用預期檔案名稱的日誌輪換。- 產生的日誌內容。此測試經過重構，以最大限度地減少為新增日誌格式的測試所需的工作量，從而簡化了一些即將到來的工作。作者：Michael Paquier、Sehrope Sarkuni 討論：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/72b76f76161c78dd1be42592c4e5b980beef5f26

  • 修復 ECPG 連線邏輯中執行緒在 OOM 上的錯誤處理。當分配結構以儲存連線參數關鍵字和值時，發生記憶體不足的失敗會弄亂已儲存的連線集，因為在失敗時，pthread 互斥鎖仍然會持有，並且新的連線物件已列出但已 free()'d。不要僅僅解鎖互斥鎖，這會使連線的靜態列表處於不一致的狀態，而是在開始測試操作之前移動連線參數結構的分配。這可確保連線列表和連線互斥鎖在此程式碼路徑中始終保持一致。這種錯誤不太可能發生，但可能會以令人驚訝的方式嚴重破壞 ECPG 客戶端，因此一直向下回溯。報告者：ryancaicse 討論：https://postgr.es/m/17186-b4cfd8f0eb4d1dee@postgresql.org 回溯：9.6 https://git.postgresql.org/pg/commitdiff/fa703b317e9d261ffd34bbf5651ea29aff3ff0f0

  • 刪除使用複製槽的權限檢查的程式碼重複。兩個名為 check_permissions() 的函式使用相同的檢查來驗證使用者是否具有使用複製槽所需的權限。此提交刪除了重複，並將執行檢查的函式移動到 slot.c 以進行集中化。作者：Bharath Rupireddy 審閱者：Nathan Bossart、Euler Taveira 討論：https://postgr.es/m/CALj2ACUPpVw1u7sQocFVWrSs0n10pt_G_4NPZKSxXK6cW1dErw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/026ed8efd6b1d774924937baf3209b676df4531f

  • 更新資源擁有者的 README 關於支援的資源類型。所有支援的類型都直接列在 README 中，但它已非常過時。此提交不是在 README 中列出所有支援的類型，而是新增了一個參考，以查看 resowner.c 中的 ResourceOwnerData 以獲取此資訊。段落的順序經過稍微修改以提高清晰度。作者：Amit Langote 討論：https://postgr.es/m/CA+HiwqHtfT9z=4H5+F7DOy0OyNHAaVwuRcakt9b2t2uADOaiag@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cae6fc2bc27cdb072693076249ce688f048ca7b7

  • 支援使用執行階段計算的 GUC 參數的 "postgres -C"。到目前為止，postgres 的 -C 選項是在初始化一小部分在執行階段計算的 GUC 參數之前處理的，這會導致不正確的結果，因為 GUC 機制會回退到這些參數的預設值。例如，由於尚未載入控制檔案，data_checksums 可能會報告叢集的 "off"。或者，即使 initdb --wal-segsize 使用了其他值，wal_segment_size 也會顯示 16MB 的區段大小。更糟糕的是，該命令無法正確報告最近引入的 shared_memory，它需要載入 shared_preload_libraries，因為這些庫可能會要求使用一部分共享記憶體。對執行階段 GUC 參數的支援受到限制，因為現在允許在運作中的伺服器上進行操作。其中一個值得注意的原因是可載入庫的 _PG_init() 函式是在初始化所有執行階段計算的 GUC 參數之前呼叫的，並且不能保證在運作中的伺服器上執行此操作是安全的。對於 shared_memory_size，我們想要在不分配的情況下知道將使用多少記憶體，這種限制是可以接受的。另一個會有幫助的案例是 huge page，引入了不同的 GUC 參數來評估啟動伺服器之前伺服器所需的 huge page 數量，而無需分配大量的記憶體。此功能由新的 GUC 標誌控制，並且截至此變更，有四個參數被分類為執行階段計算：- data_checksums- shared_memory_size- data_directory_mode- wal_segment_size新增了一些 TAP 測試以在此處提供一些涵蓋範圍，在 pg_checksums 的測試中使用 data_checksums。經過與 Andres Freund、Justin Pryzby、Magnus Hagander 等人的討論。作者：Nathan Bossart 討論：https://postgr.es/m/F2772387-CE0F-46BF-B5F1-CC55516EB885@amazon.com https://git.postgresql.org/pg/commitdiff/0c39c292077ef3ba987ced0dc6ea1c8f4f1e1f4b

  • 停用 Msys 上 postgres -C 的測試。由於 IPC::Run 使用原生 Perl 處理輸出（會將 \r\n 轉換為 \n）與 Msys Perl（\r\n 會保持不變）的方式不同，導致 Msys 上產生的輸出不正確，造成此測試失敗。目前，暫時停用此測試，以使建置農場恢復正常狀態。我認為長期的正確解決方案是調整 PostgresNode.pm 中的所有 command_checks_* 常式，使其像 psql 在使用 Msys 時一樣處理此輸出，在比較之前自動丟棄 \r。根據 jacana 和 fairywren 的報告。感謝 Tom Lane 的提醒。討論：https://postgr.es/m/1252480.1631829409@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5adb06732d7fac8171609392ea83f18bc8f285f4

  • 澄清在關閉 WAL 段時 pg_receivewal 中的一些錯誤。在 pg_receivewal 的 WAL 流傳輸期間關閉的 WAL 段會根據上下文產生不正確的錯誤訊息，因為在引用 WAL 段時使用的檔案名稱忽略了部分檔案或使用的壓縮方法。在這種情況下，產生的錯誤訊息（關閉、搜尋或重新命名時失敗）將與實際的檔案名稱不符。pg_basebackup 也使用相同的程式碼路徑，但它不使用部分檔案的後綴，因此不受影響。7fbe0c8 在 walmethods.c 中引入了一個回呼，用於取得給定上下文使用的確切物理檔案名稱，此提交使用它來改進這些錯誤訊息。如果需要，未來可以將其擴展到 pg_basebackup/ 的更多程式碼路徑。摘自同一作者的較大修補程式。作者：Georgios Kokolatos 討論：https://postgr.es/m/ZCm1J5vfyQ2E6dYvXz8si39HQ2gwxSZ3IpYaVgYa3lUwY88SLapx9EEnOf5uEwrddhx2twG7zYKjVeuP5MwZXCNPybtsGouDsAD1o2L_I5E=@pm.me https://git.postgresql.org/pg/commitdiff/cddcf7842c31b4d07ca75439f6b4ddacaadbbd0d

  • 改進 pg_receivewal 中的一些檢查邏輯。以下方面已得到改進：

  • 在任何 WAL 流傳輸迴圈之前，從來源伺服器提取系統識別碼。這會觸發額外的檢查，以確保 pg_receivewal 仍然連接到具有相同系統 ID 且具有正確時間線的伺服器。- 將 umask()（用於檔案建立模式遮罩）和 RetrieveWalSegSize()（用於提取 WAL 段的大小）稍微延後到初始流傳輸嘗試之前。如果使用資料庫進行連線，pg_receivewal 將會失敗，但這些指令仍然會執行，這是一種浪費。現在，在檢索段大小之前完成 slot 的建立和刪除。作者：Bharath Rupireddy 審閱人：Ronan Dunklau, Michael Paquier 討論：https://postgr.es/m/CALj2ACX00YYeyBfoi55Cy=NrP-FcfMgiYYx1qRUEib3yjCVoaA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/499c9b1266395c5e4c22bd7b2cbdb7f5a64ea4fa

Amit Kapila 推送

Tom Lane 推送

  • 修正 plpgsql 中最外層區塊的 EXIT。通常，以這種方式使用 EXIT 會產生「控制在沒有 RETURN 的情況下到達函數結尾」的錯誤。但是，如果該函數是不需要明確 RETURN 的函數（例如 DO 區塊），則不應發生這種情況。但事實上確實發生了，因為 add_dummy_return() 忽略了這種情況。根據 Herwig Goemans 的報告。向後移植到所有支援的分支。討論：https://postgr.es/m/868ae948-e3ca-c7ec-95a6-83cfc08ef750@gmail.com https://git.postgresql.org/pg/commitdiff/1bf2518dd67be58b207979a66db7bb7c94b93a62

  • 文件：改進 CREATE/ALTER SUBSCRIPTION 的文件。改進一些選項的描述。修正粗糙的語法和標記。Peter Smith 和 Tom Lane 討論：https://postgr.es/m/CAHut+PtPJDSOxtuMGpO2yDrRPKxcYGL4n7HqJP9HernZE=Cj+g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1882d6cca161dcf9fa05ecab5abeb1a027a5cfd2

  • 在成功完成 PQconnectdb() 時清除 conn->errorMessage。提交 ffa2e4670 和 52a10224e 導致 libpq 的連線建立函數通常會在連線的 errorMessage 緩衝區中留下一個非空字串，即使在成功連線後也是如此。雖然這是我有意為之，但更清醒的反思表明這不是一個好主意：該字串會讓人感到困惑。此外，這至少破壞了一個應用程式，該應用程式透過檢查 errorMessage 而不是使用文件中記載的 PQstatus() 來檢查連線是否成功。讓我們在成功退出時清除緩衝區，恢復到 v14 之前的行為。討論：https://postgr.es/m/4170264.1620321747@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/138531f1bbc333745bd8422371c07e7e108d5528

  • 修正規劃器（planner）中多個 AlternativeSubPlan 副本造成的錯誤。我們有可能將 AlternativeSubPlan 表達式節點複製到多個位置，例如多個分割區子節點的掃描條件（scan quals）。這樣一來，我們有可能在每個位置選擇不同的替代方案作為最佳方案。Commit 41efb8340 未能考慮到這種情況，因此其嘗試移除「未使用」子計畫的做法，可能會移除在其他地方仍在使用的子計畫。修正方法是延遲移除邏輯，直到我們檢查完給定查詢層級中的所有 AlternativeSubPlan 為止。（這裡假設 AlternativeSubPlan 不會被複製到其他查詢層級，但在可預見的未來，這沒有問題；參見 qual_is_pushdown_safe。）根據 Rajkumar Raghuwanshi 的報告。回溯修補到 v14，因為錯誤的邏輯是從該版本引入的。討論：https://postgr.es/m/CAKcux6==O3NNZC3bZ2prRYv3cjm3_Zw1GfzmOjEVqYN4jub2+Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e8638d78a2cb94efba11a5dfbf3e7cd746d0af3e

  • 在 CommitTransaction 期間發送 NOTIFY 訊號。以前，我們在 ProcessCompletedNotifies 中發送傳出的 NOTIFY 訊息的訊號，該函式也負責將相關的訊息轉發給連線的客戶端。因此，它必須在主迴圈處理期間執行，該處理發生在閒置之前。這種安排有兩個很大的缺點：* 現在程序允許指令內的 COMMIT，在 COMMIT 時立即將 NOTIFY 發送給其他 Session 會很有用（但是，由於線路協定的穩定性原因，我們仍然不應該在指令結束之前將它們轉發給我們的客戶端）。* 諸如複製工作者之類的背景程序根本不會發送 NOTIFY，因為它們從不執行客戶端通訊迴圈。我們已經收到允許在複製工作者中執行的觸發器發送 NOTIFY 的請求，這是一個問題。為了解決這些問題，請將傳出 NOTIFY 訊號的傳輸移至 AtCommit_Notify，它將在 CommitTransaction 期間發生。同時將 asyncQueueAdvanceTail 的可能調用移到那裡，以確保如果背景工作者發送了許多 NOTIFY 而沒有人收聽，我們不會使 async SLRU 膨脹。我們還可以刪除 asyncQueueReadAllNotifications 的調用，從而完全消除 ProcessCompletedNotifies。那是因為 commit 790026972 在 PostgresMain 的 ProcessCompletedNotifies 調用旁邊添加了 ProcessNotifyInterrupt 的調用，並且它自己調用了 asyncQueueReadAllNotifications，這意味著每當入站通知訊號與出站通知重合時，我們都會無用地執行兩個這樣的調用（在兩個單獨的事務中）。我們只需要設定 notifyInterruptPending 以確保 ProcessNotifyInterrupt 運行，就完成了。現有文檔建議自定義背景工作者如果想發送 NOTIFY 訊息，應該調用 ProcessCompletedNotifies。為了避免在後端分支中出現 ABI 中斷，請將其簡化為空例程，而不是完全刪除它。刪除將在 v15 中發生。儘管上述問題已經存在了一段時間，但我不太願意將其回溯修補到 v13 之外。在 12 和 13 之間的相鄰代碼中發生了相當多的變動。至少我們還必須回溯修補 51004c717，並且還需要進行大量其他調整，因此收益與風險的比率看起來並不吸引人。根據 Michael Powers 的錯誤 #15293（以及其他人的類似抱怨）。Artur Zakirov 和 Tom Lane 討論：https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/2e4eae87d02fef51c42c2028b65d85b9e051f9eb

  • 改進 pg_import_system_collations() 的日誌訊息。 pg_import_system_collations() 在報告它沒有為其建立 pg_collation 條目的 locale（"locale -a" 輸出的名稱）時，有點不一致。我認為，我們應該為我們拒絕的每個 locale 列印一些合適的訊息，除非它與預先存在的 pg_collation 條目匹配。（所有這些都在 DEBUG1 日誌級別，因此不會在 initdb 期間產生噪音。）為先前未記錄的兩種情況（即無法識別的編碼和僅客戶端編碼）新增訊息。重新措辭現有訊息以使其具有一致的樣式。 Anton Voloshin 和 Tom Lane 討論：https://postgr.es/m/429d64ee-188d-3ce1-106a-53a8b45c4fce@postgrespro.ru https://git.postgresql.org/pg/commitdiff/69e31d05b0a33f55aa5d9540917540f5fccb93a7

  • 不允許在背景工作者中使用 LISTEN。可以在某些背景處理程序中執行使用者定義的 SQL；例如，邏輯複製工作者可以觸發觸發器。這開啟了某人嘗試在此上下文中執行 LISTEN 的可能性。但是，由於只有常規後端才會調用 ProcessNotifyInterrupt，因此實際上不會收到任何訊息，因此註冊的監聽器只會阻止訊息佇列被清除。最終 NOTIFY 將停止工作，這很糟糕。也許有一天，有人會發明基礎結構來使背景工作者中的監聽真正有用。在此期間，禁止它。回溯修補到 v13，這是我們引入 MyBackendType 變數的地方。如果沒有它，將很難實現檢查，並且似乎不值得麻煩。討論：https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/1316be28664f1834ac091113217537101331bdf3

  • 移除 rangetable 大小的任意 64K 左右的限制。到目前為止，查詢的 rangetable 的大小受到 INNER_VAR 等常數的限制，這些常數不得等於任何實際的 rangetable 索引。 65000 毫無疑問似乎對任何人來說都足夠了，並且它仍然比我們可以實際處理的聯結數量大幾個數量級。但是，我們需要為查詢處理的每個子分割區（或可能處理的）建立 rangetable 條目。具有數千個分割區的查詢越來越真實，因此該限制成為問題的日子指日可待，即使它尚未到來。因此，讓我們提高限制。此修補程式沒有僅增加 INNER_VAR 等的值，而是採用了使它們成為小的負值的策略，因此 rangetable 理論上可以達到 INT_MAX 的長度。該修補程式的大部分內容都與將 Var.varno 和一些相關變數從 "Index"（無符號整數）更改為普通的 "int" 有關。這基本上是裝飾性的，除了有助於除錯器很好地列印其值之外，幾乎沒有實際效果。因此，我只費心更改了實際可以看到 INNER_VAR 等的地方，解析器和大多數規劃器沒有。我們確實必須小心地在對 varno 執行小於/大於比較的場合，但是除了 IS_SPECIAL_VARNO 巨集本身之外，這種場合很少。此修補程式的一個顯著副作用是，雖然以前可以將 INNER_VAR 等添加到 Bitmapset 中，但現在將引發錯誤。我不認為將這些虛假的 varno 包含在真實 varno 的位元圖集中不會是一個錯誤，因此我認為這一切都很好。儘管這觸及了 outfuncs/readfuncs，但我認為不需要 catversion 增加，因為儲存的規則永遠不會包含具有這些虛假 varno 的 Vars。 Andrey Lepikhov 和 Tom Lane，根據 Peter Eisentraut 的建議 討論：https://postgr.es/m/43c7f2f5-1e27-27aa-8c65-c91859d15190@postgrespro.ru https://git.postgresql.org/pg/commitdiff/e3ec3c00d85bd2844ffddee83df2bd67c4f8297f

  • 修正 EXPLAIN 以處理 SEARCH BREADTH FIRST 查詢。SEARCH BREADTH FIRST 的重寫器轉換會在 RECORD 類型的 Var 上產生 FieldSelect，其中 Var 引用遞迴聯集的 worktable 輸出。EXPLAIN VERBOSE 無法處理這種情況，因為它只預期此類 Var 出現在 CteScan 而不是 WorkTableScan 中。修正該問題，並新增一些測試案例，以測試 SEARCH 和 CYCLE 查詢上的 EXPLAIN。原則上，這個疏忽是一個舊錯誤，但似乎在沒有 SEARCH BREADTH FIRST 的情況下無法觸及該案例，因為當嘗試手動建立此類參考時，剖析器會失敗。因此，今天我將只修補 HEAD/v14。未來我們可能會發現此修補程式的程式碼部分需要進一步的回溯修補。根據 Atsushi Torikoshi 的報告。討論：https://postgr.es/m/5bafa66ad529e11860339565c9e7c166@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/3f50b82639637c9908afa2087de7588450aa866b

  • 修正 pull_varnos 以處理已轉換的 PlaceHolderVars。Commit 55dc86eca 更改了 pull_varnos 以（如果可能）使用與 PlaceHolderVar 相關聯的 ph_eval_at。但我忽略了一個細節：我們可能正在查看子 appendrel 的 quals 或 tlist 中的 PHV，在這種情況下，我們需要計算一個已轉換的 ph_eval_at 值，其轉換方式與 PHV 本身相同（參見 adjust_appendrel_attrs）。幸運的是，PlaceHolderInfo 中有足夠的資訊可以進行此類轉換，而無需額外的外部資料，因此我們不需要再次醜化 planner API。這有點複雜，但由於這是一個難以命中的角落案例，因此我不太擔心在這裡增加週期。根據 Jaime Casanova 的報告。回溯修補到 v12，與之前的 commit 相同。討論：https://postgr.es/m/20210915230959.GB17635@ahch-to https://git.postgresql.org/pg/commitdiff/a21049fd3f64518c8a7227cf07c56f2543241db2

  • 文件：修正拼寫錯誤。"PGcon" 應為 "PGconn"。D. Frey 注意到。討論：https://postgr.es/m/163191739352.4680.16994248583642672629@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/d5eeb51bc053d75f647136026de522d6ee3bf725

Andres Freund 推送

Peter Eisentraut 推送

Daniel Gustafsson 推送

Fujii Masao 推送

Peter Geoghegan 推送

  • pageinspect: 減少頁面刪除 elog 的冗長程度。commit e5d8a999 新增了一個 elog，用於報告儲存在已刪除的 nbtree 頁面上的交易 ID 的值，該 commit 教導頁面刪除儲存完整的 64 位元 XID。進一步反思，它似乎非常冗長，因此將其 elevel 從 NOTICE 降低到 DEBUG2。作者：Peter Geoghegan pg@bowt.ie 回溯：14-，就像 nbtree XID 增強功能一樣。 https://git.postgresql.org/pg/commitdiff/d7897abf9e0071946e9e4e8efd2d4463607c04de