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

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

發布於 2021-12-20 由 PWN
PWN

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

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

PostgreSQL 轉換指南，包含許多來之不易的智慧，並提供法文和英文版本，已發布

pgDay Paris 2022 將於 2022 年 3 月 24 日在法國巴黎舉行。 徵稿 (CfP) 開放至巴黎時間 2021 年 12 月 31 日午夜。

Citus Con，一個全球虛擬開發者活動，將於 2022 年 4 月 12-13 日舉行。 CFP 現已開放。

PostgreSQL 產品新聞

Pgpool-II 4.3.0，一個用於 PostgreSQL 的連線池和語句複製系統，已發布。

Access-to-PostgreSQL v2.3 已發布。

check_pgbackrest 2.2，一個與 Nagios 相容的 pgBackRest 監控程式，已發布。 https://github.com/dalibo/check_pgbackrest/releases

DB Comparer 5.0 for PostgreSQL 已發布。

Database .NET v33.6，一個多資料庫管理工具，現在支援 PostgreSQL，已發布。

pgAdmin4 6.3，一個用於 PostgreSQL 的 Web 和原生 GUI 控制中心，已發布。

pgFormatter 5.2，一個用於 SQL 代碼的格式化/美化工具，已發布。 https://github.com/darold/pgFormatter/blob/master/ChangeLog

MySQL-to-PostgreSQL v5.5 已發布。

PostgreSQL 12 月的職缺

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

PostgreSQL Local

Nordic PGDay 2022 將於 2022 年 3 月 22 日在芬蘭赫爾辛基的希爾頓赫爾辛基海灘酒店舉行。 CfP 開放至 2021 年 12 月 31 日 此處

PostgreSQL 新聞

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

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

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

已套用的修補程式

Michaël Paquier 推送了

  • 改進 psql 的 tab 鍵自動完成，適用於檢視表、FDW、序列和轉換。 進行了以下改進： - 為 ALTER SEQUENCE AS 新增類型完成。 - 忽略轉換的 ALTER，因為該命令不受支援。 - 為 ALTER FOREIGN DATA WRAPPER 新增更多完成。 - 在 ALTER VIEW 中新增與列相關的選項。 這是 0cd6d3b 中所做工作的延續。 作者：Ken Kato 討論： https://postgr.es/m/9497ae9ca1b31eb9b1e97aded1c2ab07@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/f44ceb46ec2d8da48f6e145bf462d5620c25e079

  • 集中控制檔案更新時的時間戳計算。 此提交將控制檔案的時間戳計算移動到 src/common/ 的例程中，負責更新後端的控制檔案，該例程由多個前端工具（pg_rewind、pg_checksums 和 pg_resetwal）和後端本身共用。 此變更的直接影響是在 pg_rewind 和 pg_checksums 中寫入控制檔案時更新控制檔案的時間戳，這有助於追蹤這些操作的控制檔案更新，後端也會在其日誌中的啟動時追蹤。 這一部分可以說是錯誤，因為 ControlFileData->time 每次寫入新版本的控制檔案時都應該更新，但這是一個行為變更，因此不進行回溯修補。 作者：Amul Sul 審閱者：Nathan Bossart、Michael Paquier、Bharath Rupireddy 討論： https://postgr.es/m/CAAJ_b97nd_ghRpyFV9Djf9RLXkoTbOUqnocq11WGq9TisX09Fw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/6fb7c5d67cdd55454fe6317f939a191f85e96473

  • 修正 win32stat.c 中標準流上的 fstat() 的相容性錯誤。 GetFinalPathNameByHandleA() 無法在 _WIN32_WINNT < 0x0600 的編譯環境中使用，這表示 Postgres 仍然需要支援 MinGW 下的一些 buildfarm 成員使用的至少 Windows XP。 buildfarm 回報這是一個編譯警告，但這實際上比報告更糟，因為代碼將無法工作。 相反，這切換到 GetFileInformationByHandle()，它能夠在標準流上失敗，並在重新導向的流上成功，這正是我們在代碼中模擬 fstat() 時所尋找的。 我們也知道，由於 win32stat.c 的現有邏輯，它能夠在所有仍然支援的環境中工作。 由 10260c7 引入的問題，因此回溯修補到 14。 報告者：Justin Pryzby，透過 buildfarm 成員 jacana 作者：Michael Paquier 審閱者：Juan José Santamaría Flecha 討論： https://postgr.es/m/20211129050122.GK17618@telsasoft.com 回溯修補透過：14 https://git.postgresql.org/pg/commitdiff/58651d8dd6a56af306a361e2c386db798164c0f1

  • 修正錯字。 作者：Lingjie Qiang 討論： https://postgr.es/m/OSAPR01MB71654E773F62AC88DC1FC8CC80669@OSAPR01MB7165.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/98105e53e0ab472b7721a3e8d7b9f1750a635120

  • 修正某些 GUC 的標誌並改進一些描述。 此提交修正了 GUC 的一些問題： - enable_incremental_sort 沒有標記為 GUC_EXPLAIN，導致在使用與預設值不同的值時，它不會列在 EXPLAIN (SETTINGS) 的輸出中，這與其他規劃器級別的 GUC 相反。 - trace_recovery_messages 遺漏了 GUC_NOT_IN_SAMPLE，就像其他開發者選項一樣。 - ssl_renegotiation_limit 應標記為 COMPAT_OPTIONS_PREVIOUS。 在此同時，這修正了一個與 autovacuum_freeze_max_age 相關的不正確註解，並改進了最近引入的其他 GUC 的描述。 從同一作者的較大修補程式集中提取。 作者：Justin Pryzby 描述： https://postgr.es/m/20211129030833.GJ17618@telsasoft.com https://git.postgresql.org/pg/commitdiff/be5455124b0f073ba3924ae2ba302a27b1686230

  • 改進 psql 的 tab 鍵自動完成，適用於各種 DROP 命令。 進行了以下改進： - 處理 DROP OWNED、matviews 和策略的 RESTRICT/CASCADE。 - 處理 DROP TRANSFORM 這是 0cd6d3b 和 f44ceb4 中所做工作的延續。 作者：Ken Kato 審閱者：Asif Rehman 討論： https://postgr.es/m/0fafb73f3a0c6bcec817a25ca9d5a853@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/9270778f467dad0d78d3b9e435a89a6039322b2f

  • 修正 slotfuncs.c 中的註解語法。作者：Bharath Rupireddy 討論：https://postgr.es/m/CALj2ACUkrNR2xTak+QaqxoTjPKGn8zXWripv7SR27t+Q5qF1Wg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/7799d4e3bdd14c90989d829a9b24e73d4ff4d4ad

  • 將 pg_upgrade 測試中使用的所有 SQL 查詢移至獨立檔案。現有的 pg_upgrade/test.sh 和 buildfarm 代碼在執行跨版本升級測試時，一直持有相同的 SQL 查詢集，以便調整升級前由迴歸測試建立的物件（主要是，需要從來源捨棄不相容或不存在的物件，或者重新建立）。此變更將所有這些 SQL 查詢移動到一個新的、獨立的檔案中，並使用一組 \if 子句來處理根據要升級的舊叢集版本的版本檢查。長期計畫是讓 buildfarm 代碼重新使用這個新的 SQL 檔案，以便提交者能夠修正 pg_upgrade 測試中的任何相容性問題，而無需修改 buildfarm 客戶端。請注意，這僅適用於主要的迴歸測試套件，並且尚未對 contrib 模組執行任何操作（這些模組有更多問題，例如它們的資料庫名稱）。回溯修補至 10 版，調整版本檢查，因為此腳本只需要向後相容，以便盡可能清理 buildfarm 客戶端中的最大量代碼。作者：Justin Pryzby, Michael Paquier 討論：https://postgr.es/m/20201206180248.GI24052@telsasoft.com 回溯修補：10 https://git.postgresql.org/pg/commitdiff/0df9641d39057f431655b92b8a490b89c508a0b3

  • pg_waldump：當被 SIGINT 中斷時，發出統計摘要。 以前，如果 pg_waldump 被 SIGINT 中斷（或說簡單的 Ctrl+C），它不會顯示其統計摘要。 此提交新增了一個 SIGINT 的信號處理程序，捕獲該信號以便在最早的方便時退出，從而在退出前允許顯示統計摘要。 這使得報告更具互動性，類似於 strace -c。 這個新行為使得選項 --stats 和 --follow 的組合更有用，以便使用者在這種情況下獲得任何 pg_waldump 呼叫的報告。 關於計算的統計資料的 LSN 範圍的資訊作為標頭新增到顯示的報告中。 此實作來自 Álvaro Herrera 和我自己的建議，此前此修補程式的作者抱怨 --stats 和 --follow 最初一起使用沒有用。 如文檔所述，Windows 不支援此功能，但可以透過捕獲與 Ctrl+C 相關聯的終端事件來實現其支援，例如（這可能需要更集中的實作，因為其他工具可以從通用 API 中受益）。 作者：Bharath Rupireddy 討論：https://postgr.es/m/CALj2ACUUx3PcK2z9h0_m7vehreZAUbcmOky9WSEpe8TofhV=PQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f2c52eeba919a1b191f60445001371bd7c53aaa9

  • 改進各種 GUC 的描述。 此提交修復了一些 GUC 描述中的一些不一致之處，同時使其措辭在它們所依賴的單位方面更通用。 對於它們中的大多數，這消除了使用諸如「N 秒」或「N 位元組」之類的術語，這些術語可能不容易應用於翻譯的這些字串的所有語言（根據我自己的經驗，這在法語和英語中有效，在日語中較少）。 根據下面列出的作者之間的辯論。 作者：Justin Pryzby, Michael Paquier 討論：https://postgr.es/m/20211129030833.GJ17618@telsasoft.com https://git.postgresql.org/pg/commitdiff/03774f9bb304d49fae3379806115aaa5d1fafea2

  • 修復使用 REINDEX CONCURRENTLY 時 toast 索引的損壞。 在 toast 索引或 toast 關係上執行的 REINDEX CONCURRENTLY 可能會損壞重建的目標索引，因為並行運行的後端在完成其本地操作時會直接釋放 toast 關係上的鎖，而不是在處理 toast 值的交易提交後釋放鎖。 這裡的修復很簡單：我們現在在保存或刪除 toast 值時，在處理它們的交易提交之前，在 toast 關係上持有 ROW EXCLUSIVE 鎖，以便並行發生的併發索引重建能夠等待任何活動並查看任何新插入（或刪除）的行。 新增了一個隔離測試來檢查這裡修復的情況之後，由於它依賴 allow_system_table_mods 將 toast 表及其索引重新命名為固定名稱，因此設計上有些花哨。 這樣，就可以直接重新索引它們，而無需依賴底層關係的 OID。 請注意，這也不能使用 DO 塊，因為 REINDEX CONCURRENTLY 無法在交易塊中運行。 該測試已回溯修補至 13，在那裡可以透過 c4a7a39 在測試套件中使用 allow_system_table_mods。 報告人：Alexey Ermakov 分析人：Andres Freund, Noah Misch 作者：Michael Paquier 審閱人：Nathan Bossart 討論：https://postgr.es/m/17268-d2fb426e0895abd4@postgresql.org 回溯修補：12 https://git.postgresql.org/pg/commitdiff/f99870dd867331f576a84e37438da86a866559c4

  • 改進 CREATE/ALTER SUBSCRIPTION 選項的解析。 這簡化了程式碼，因此 parse_subscription_options() 的呼叫者不再需要將 SubOpts 清零，而是保留提供的選項的位元圖以及預設/已解析的選項值。 這也簡化了與命令支援的選項相關的一些檢查，在檢查不相容性時。 同時，重新排序了為「slot_name = NONE」的不支援組合產生的錯誤。 與以前的主要版本相比，這可能會產生不同的錯誤，但使用者必須瀏覽所有這些錯誤才能在這種情況下獲得正確的命令，當使用選項「enabled」和「create\slot」的錯誤值時，因此最終產生的命令將保持不變。 作者：Peter Smith 審閱人：Nathan Bossart 討論：https://postgr.es/m/CAHut+PtXHfLgLHDDJ8ZN5f5Be_37mJoxpEsRg8LNmm4XCr06Rw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/00029deaf65aad47044d9290fe80f2f68601f7ac

  • 修復一些 {a,an} 的拼字錯誤。 其中一項變更會影響文檔，因此進行回溯修補。 作者：Peter Smith 討論：https://postgr.es/m/CAHut+Pu6+c+r3mY24VT7u+H+E_s6vMr5OdRiZ8NT3EOa-E5Lmw@mail.gmail.com 回溯修補：14 https://git.postgresql.org/pg/commitdiff/5d08137076fd39694188ec4625013756aab889e1

  • 改進某些具有交易命令的 WAL 記錄的描述。 此提交改進了 Transaction RMGR 的某些 WAL 記錄的描述： - 追蹤交易提交的 remote_apply。 此 GUC 是使用者可設定的，因此此資訊可用於除錯。 - 為 PREPARE TRANSACTION 新增複寫來源資訊，包括來源 ID、LSN 和時間戳記 - 與上面相同，適用於 ROLLBACK PREPARED。 這會影響 pg_waldump 或任何使用這些描述例程的內容的格式，因此不會進行回溯修補。 作者：Masahiko Sawada, Michael Paquier 討論：https://postgr.es/m/CAD21AoD2dJfgsdxk4_KciAZMZQoUiCvmV9sDpp8ZuKLtKCNXaA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c8b733c4c4b0c5b7aa93553aa5b7f2c1d0bf00bf

  • 移除 PREPARE TRANSACTION 中關於複製來源的斷言。當使用複製來源時，可以選擇性地使用 pg_replication_origin_xact_setup() 來設定 LSN 和時間戳記以標記來源，這些資訊會額外添加到 WAL 中，用於事務提交或中止（包括 2PC 事務）。PREPARE TRANSACTION 的程式碼路徑中的一個斷言假設此資料應始終被設定，因此在使用複製來源但未設定來源 LSN 時會觸發。添加了一些測試來涵蓋更多此類情境。這是 commit 1eb6d65 中的疏忽。根據與 Amit Kapila 和 Masahiko Sawada 的討論。討論：https://postgr.es/m/YbbBfNSvMm5nIINV@paquier.xyz Backpatch-through: 11 https://git.postgresql.org/pg/commitdiff/ece8c76192fee0b78509688325631ceabca44ff5

  • 調整 MSVC 的 TAP 測試中某些環境設定的行為。edc2332 在 vcregress.pl 中引入了一些對環境變數 LZ4、TAR 和 GZIP_PROGRAM 的控制，以允許任何 TAP 測試都能使用這些指令。這使得設定與 src/Makefile.global.in 更加一致，因為 Make 和 MSVC 建置使用相同的預設值。每個參數都可以在 buildenv.pl 中更改，但由於在載入 buldenv.pl 後會分配一個預設值，因此無法取消任何這些參數，並且使用空值也無法使用 "||="。由於某些環境的 PATH 中可能沒有相容的指令（例如來自 MinGW 的 tar 就是一個問題），這可能會導致測試失敗，且沒有退出路徑來繞過任何失敗的測試。此 commit 更改了此問題，以便在載入 buildenv.pl 之前，而不是之後，分配 LZ4、TAR 和 GZIP_PROGRAM 的預設值。這樣，我們就能保持與具有相同預設值的 GNU 建置相同數量的相容性，並且可以取消任何這些值。同時，這會在專門用於 MSVC 的 TAP 測試的部分中添加一些關於這三個變數的說明文件。根據與 Andrew Dunstan 的討論。討論：https://postgr.es/m/YbGYe483803il3X7@paquier.xyz Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/7acd01015c4a5edb253ea9468ccb71ef99cabd1a

  • 為 pg_upgrade 添加 -N/--no-sync 選項。這是一個與 src/bin/ 的其他工具（pg_checksums、pg_dump、pg_rewind 和 pg_basebackup）提供一致的選項，可用於在測試時減少 I/O 負擔。這不應在生產環境中使用。pg_upgrade 的所有迴歸測試都已更新為使用此新選項。這可以在 I/O 受限的環境中最多減少幾秒鐘的時間，方法是避免刷新升級後的新叢集的資料夾。作者：Michael Paquier 審閱者：Peter Eisentraut 討論：https://postgr.es/m/YbrhzuBmBxS/DkfX@paquier.xyz https://git.postgresql.org/pg/commitdiff/3d5ffccb6df323f528cf870c26d0d0517ffe3eaa

  • 修正 pg_receivewal 的 TAP 測試中的一個錯字。在 d62bcc8 中引入，在該區域進行 hack 時發現。https://git.postgresql.org/pg/commitdiff/22592e10b41a95f841642fa16127521989177bbc

Tom Lane 推送

Peter Geoghegan 推送了

  • vacuumlazy.c：將 dead_tuples 重命名為 dead_items。 Commit 8523492d 簡化了對於 VACUUM 來說，一個 item 被認為是 "dead" 的含義：記憶體中收集的 TID（為了索引 vacuuming 做準備）必須始終來自 heap page 中的 LP_DEAD stub line pointer，在 pruning 之後找到。這正式確立了索引 vacuuming（和 heap vacuuming）是可選過程的觀點。與 pruning 不同，它們可以無限期地延遲，而不會有違反基本不變量的任何風險。例如，留下 LP_DEAD item 顯然不會增加事務 ID 環繞的風險。沒有事務 ID，就不可能發生事務 ID 環繞。重命名任何引用 DEAD tuples（具有儲存的 tuples）的事物，可以強化所有這些。vacuumlazy.c 之外的程式碼繼續混淆 dead/deleted tuples 和 LP_DEAD item 之間的區別。這是必要的，因為 autovacuum 調度仍然主要由 "dead item/tuple" 統計資料驅動。未來，我們可能會發現將此模型替換為更複雜的模型很有用，作為教導 autovacuum 執行更頻繁的 vacuuming 的一步，以針對那些碰巧更容易因版本更迭而膨脹的個別索引。順便一提，簡化一些處理 VACUUM 的 dead_items 陣列的函數簽名。作者：Peter Geoghegan pg@bowt.ie 審閱人：Masahiko Sawada sawada.mshk@gmail.com 討論：https://postgr.es/m/CAH2-WzktGBg4si6DEdmq3q6SoXSDqNi6MtmB8CmmTmvhsxDTLA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4f8d9d1217956798e761491d236af576b27f5e12

  • vacuumlazy.c：修正剩餘的 "dead tuple" 引用。 commit 4f8d9d12 的疏忽。報告人：Masahiko Sawada sawada.mshk@gmail.com 討論：https://postgr.es/m/CAD21AoDm38Em0bvRqeQKr4HPvOj65Y8cUgCP4idMk39iaLrxyw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4bdfe6855901a4104dbdac2be53d465b626e244d

  • 標準化 cleanup lock 術語。術語 "super-exclusive lock" 是 "buffer cleanup lock" 的同義詞，它首先出現在多年前的 nbtree 中。透過一致使用術語 cleanup lock 來標準化。這完成了 commit 276db875 開始的工作。沒有充分的理由使用兩個術語。但是，只有一個術語才有充分的理由：避免對 VACUUM 在 ambulkdelete 呼叫期間，為什麼在索引 AM 中獲取完整的 cleanup lock（而不僅僅是普通的 exclusive lock）感到困惑。這與保護物理索引資料結構本身無關。需要它來實作鎖定協定，以確保指向 heap/table 結構的 TID 在安全之前不會被 VACUUM 標記為回收（這有點類似於 VACUUM 如何在其第一次 heap pass 期間使用 cleanup lock）。請注意，索引 AM 並非絕對需要實作此鎖定協定——一些索引 AM 使用 MVCC 快照作為其唯一的互鎖來防止不安全的 TID 回收。順便一提，更新 nbtree README。將前面提到的索引 vacuuming 鎖定協定的討論與 commit 2ed5b87f 添加的 "drop leaf page pin" 最佳化的討論清楚地分開。我們現在透過描述個別索引掃描如何安全地選擇不應用標準鎖定協定（因此可以避免阻礙 VACUUM 的進度）來構建對後者的討論。此外，記錄為什麼在 nbtree 僅索引掃描期間應用該最佳化是不安全的。作者：Peter Geoghegan pg@bowt.ie 討論：https://postgr.es/m/CAH2-WzngHgQa92tz6NQihf4nxJwRzCV36yMJO_i8dS+2mgEVKw@mail.gmail.com 討論：https://postgr.es/m/CAH2-WzkHPgsBBvGWjz=8PjNhDefy7XRkDKiT5NxMs-n5ZCf2dA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/bcf60585e6e0e95f0b9e5d64c7a6edca99ec6e86

Amit Kapila 推送了

Daniel Gustafsson 推送

Álvaro Herrera 推送

Tomáš Vondra 推送

Peter Eisentraut 推送

Robert Haas 推送

  • 記錄 tar 封存檔現在已正確終止。Commit 5a1007a5088cd6ddf892f7422ea8dbaef362372f 變更了伺服器行為，但我沒有注意到現有行為已記錄在案，因此沒有更新文件。此 commit 執行此操作。我選擇提及行為已變更，而不是僅刪除對標準偏差的引用。這似乎對工具作者有所幫助。Discussion: http://postgr.es/m/CA+TgmoaYZbz0=Yk797aOJwkGJC-LK3iXn+wzzMx7KdwNpZhS5g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/81fca310b38e7808dff9c01a26564e8f2db10893

  • 預設為 log_checkpoints=on, log_autovacuum_min_duration=10m。這裡的想法是，當已知在特定時間點發生效能問題時，如果可以從日誌中獲得一些資訊來幫助弄清楚該時間點前後可能發生的情況，那將是一件好事。此變更引起了高於平均水準的異議，因為這意味著即使沒有發生任何問題，具有預設設定的伺服器也會產生一些日誌輸出。但是，根據我的計算，郵件列表討論中贊成該變更的人數大約是反對者的兩倍。相信額外的日誌輸出在實踐中不是問題的原因是： (1) 在正確設定的系統上，此設定可以產生的訊息速率限制為每隔幾分鐘一次，以及 (2) 生產系統往往由於失敗的連線嘗試、應用程式活動產生的 ERROR 訊息等原因而在日誌中包含更多垃圾。Bharath Rupireddy，經 Fujii Masao 和我審閱。許多其他人對此執行緒發表了評論，但據我所知，那是對變更優點的討論，而不是對修補程式的審閱。Discussion: https://postgr.es/m/CALj2ACX-rW_OeDcp4gqrFUAkf1f50Fnh138dmkd0JkvCNQRKGA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/64da07c41a8c0a680460cdafc79093736332b6cf

  • 移除 InitXLOGAccess()。RecoveryInProgress() 呼叫 InitXLOGAccess() 並不好，因為狀態查詢函式通常不應具有執行初始化的副作用。我們可以透過從其他地方呼叫 InitXLOGAccess() 來修正此問題，但讓我們改為完全移除它。InitXLogAccess() 所做的一件事是初始化 wal_segment_size，但它不需要這樣做。在 postmaster 中，PostmasterMain() 呼叫 LocalProcessControlFile()，所有子進程都將繼承該值 -- 除了在 EXEC_BACKEND bulds 中，但每個後端都會執行 SubPostmasterMain()，它也會呼叫 LocalProcessControlFile()。InitXLOGAccess() 所做的另一件事是更新 RedoRecPtr 和 doPageWrites，但這並不重要，因為所有使用它們的程式碼都會在發現它們已變更時重試。唯一的區別是大多數程式碼現在將看到一個絕對無效的初始值，而不是一個可能已經過時的初始值，但這只會在每個後端生命週期中發生一次，因此不應該是一個大問題。由我修補，並由 Nathan Bossart、Michael Paquier、Andres Freund、Heikki Linnakangas 和 Álvaro Herrera 審閱。Discussion: http://postgr.es/m/CA+TgmoY7b65qRjzHN_tWUk8B4sJqk1vj1d31uepVzmgPnZKeLg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/fa0e03c15a9f67671f0a6e0ec66d5e2ac7119c8a

Fujii Masao 推送

  • postgres_fdw：修正意外回報空訊息的問題。postgres_fdw 中的 pgfdw_report_error() 函式會從 PGresult 或 PGconn 取得訊息，以回報從遠端伺服器收到的錯誤。先前，如果它無法從兩者取得訊息，則會意外地回報空訊息。此問題的原因是 pgfdw_report_error() 沒有正確處理無法取得訊息且其區域變數 message_primary 設定為 '\0' 的情況。此提交改進了 pgfdw_report_error()，以便在沒有收到訊息且 message_primary 設定為 '\0' 時，回報訊息「could not obtain ...」。這與 message_primary 為 NULL 時的行為相同。dblink 中的 dblink_res_error() 函式也有相同的問題，因此此提交也以相同方式對其進行改進。向所有受支援的分支進行回溯修補。作者：Fujii Masao，審閱者：Bharath Rupireddy。討論：https://postgr.es/m/477c16c8-7ea4-20fc-38d5-ed3a77ed616c@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/557c39bba925d553c6bb12b5e80d1964d355583b

  • postgres_fdw：在取得查詢結果時，如果逾時，則回報警告。當中止遠端交易或向遠端伺服器發送取消請求時，postgres_fdw 會呼叫 pgfdw_get_cleanup_result() 以等待交易中止查詢或取消請求的結果到達。如果逾時或發生連線問題，則無法取得結果。先前，即使在 pgfdw_get_cleanup_result() 中逾時或發生連線問題，postgres_fdw 也不會回報任何警告訊息。這可能會使在發生此類事件時的疑難排解更加困難。此提交使 pgfdw_get_cleanup_result() 在失敗時告知其呼叫者發生了什麼問題（逾時或連線錯誤），並使其呼叫者根據該資訊回報適當的警告訊息。作者：Fujii Masao，審閱者：Bharath Rupireddy。討論：https://postgr.es/m/15aa988c-722e-ad3e-c936-4420c5b2bfea@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/815d61fcd485e8c60dba22988bf5a90fc12df32d

  • doc：新增關於 postgres_fdw.application_name 的注意事項。postgres_fdw.application_name 可以是任何長度的任何字串，甚至包含非 ASCII 字元。但是，當它傳遞到外來伺服器並用作 application_name 時，它會被截斷為小於 NAMEDATALEN 個字元，並且其中的任何非可列印 ASCII 字元都將被替換為問號。此提交將這些注意事項新增到文件中。作者：Hayato Kuroda，審閱者：Kyotaro Horiguchi、Fujii Masao。討論：https://postgr.es/m/TYCPR01MB5870D1E8B949DAF6D3B84E02F5F29@TYCPR01MB5870.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/58e2e6eb67fec14c793c74207407e172d7e0291d

Andrew Dunstan 推送了

Thomas Munro 推送了

Alexander Korotkov 推送了

Andres Freund 推送了