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

PostgreSQL 每週新聞 - 2021 年 3 月 28 日

發布於 2021-03-29，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 3 月 28 日

本週人物：https://postgresql.life/post/julien_riou/

PostgreSQL 產品新聞

pspg 4.5.0 已發布，這是一個專為 PostgreSQL 設計的分頁器。https://github.com/okbob/pspg/releases/tag/4.5.0

pgAdmin4 5.1 已發布，這是一個適用於 PostgreSQL 的 Web 和原生 GUI 控制中心。https://www.pgadmin.org/docs/pgadmin4/5.1/release_notes_5_1.html

三月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

本週的 PostgreSQL 每週新聞由 David Fetter 帶給您

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

已套用的修補程式

Andrew Dunstan 推送了

Tom Lane 推送了

  • 使 compression.sql 回歸測試獨立於預設值。 如果安裝的 default_toast_compression 設定不是 'pglz'，則此測試將在 "make installcheck" 中失敗。 使其能夠適應這種情況。 Dilip Kumar 討論：https://postgr.es/m/CAFiTN-t0w+Rc2U3S+y=7KWcLuOYNB5MfWeGdNa7+pg0UovVdcQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/fd1ac9a548966786cf7978e590be816c55936a50

  • 使 configure 對 LZ4 的支持達到標準。 僅僅將 pkg_config 結果直接塞入我們的構建標誌是不可以的，原因有幾個

  • 這未能保持 CPPFLAGS 和 CFLAGS 之間以及 LDFLAGS 和 LIBS 之間的分隔。 （我相信 CPPFLAGS 角度是使用 MacPorts 的 liblz4 構建時報告警告訊息的原因。） * 如果 pkg_config 發出除 -I/-D/-L/-l 開關之外的任何內容，我們極不可能吸收這些內容。 這更有可能破壞構建而不是做任何有用的事情。 （即使是 -D 情況也值得懷疑；但我們正在為 libxml2 執行此操作，因此我保留了它。） 此外，跳過執行 AC_CHECK_LIB 探測是不可以的，topminnow 最近的構建失敗證明了這一點； 應該在配置時捕獲它。 以 configure 的 libxml2 支持為模型修復此問題。 似乎有人忽略了 autoheader 運行。 討論：https://postgr.es/m/20210119190720.GL8560@telsasoft.com https://git.postgresql.org/pg/commitdiff/4d399a6fbeb720b34d33441330910b7d853f703d

  • 修復 ATExecSetCompression() 中的各種愚蠢之處。 直接在 syscache 條目上塗寫是不可以的。 釋放條目後繼續訪問它也是不可以的。 此外，擺脫未使用的局部變量。 根據 valgrind 測試。 https://git.postgresql.org/pg/commitdiff/ac897c483485d3858ada23ca49650a0f2742a50f

  • 刪除 <lz4/lz4.h> 的無用配置探測。 這似乎只是從其他標頭檢查中複製粘貼而來的。 但是我們的 C 代碼完全沒有準備好支持這樣的標頭名稱，因此尋找它只會浪費週期。 如果我們確實需要支持它，則需要一些 #ifdef。 （在 codesearch.debian.net 上快速瀏覽一下會發現一些引用 lz4/lz4.h 的套件；但它們僅使用該拼寫，並且似乎打算引用它們自己的副本，而不是系統級安裝的 liblz4。 沒有證據表明需要此拼寫的獨立安裝。） 討論：https://postgr.es/m/457962.1616362509@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2c75f8a612b207c7d36e5dc73317dc9ab6fb29d4

  • 對 TOAST 相關的宏進行主要外觀上的調整。 bbe0a81db 的作者沒有完全理解像 SOMETHING_4B_C 這樣的命名宏僅用於 postgres.h 中的內部 endianness 相關細節。 為打算在其他地方使用的宏選擇更清晰的名稱。 稍微重新排列 postgres.h，以闡明這些內部宏和打算更廣泛使用的宏之間的分隔。 此外，避免使用術語 "rawsize" 表示真正的解壓縮大小； 我們使用 "extsize" 表示它，因為 "rawsize" 通常表示包括標頭在內的總 Datum 大小。 在比較這些含義之一與另一個含義的測試中，此選擇似乎特別不幸。 此修補程式包括幾個非純粹外觀上的更改：確保對齊壓縮方法的偏移是不帶正負號的（今天並不關鍵，但當存在壓縮方法 2 時將會如此），並修復 VARATT_EXTERNAL_GET_COMPRESSION（現在為 VARATT_EXTERNAL_GET_COMPRESS_METHOD）的錯誤定義，其調用者僅是意外地起作用。 討論：https://postgr.es/m/574197.1616428079@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/aeb1631ed207cef2d80e20f79eb52c72f03bca7d

  • 對大於物件大小的切片請求進行短路。 substring()，以及其他調用者，不小心傳遞的切片長度不超過 datum 的實際大小。 由於 toast_decompress_datum_slice 的子項將 palloc 請求的切片長度，因此這可能會浪費記憶體。 此外，仔細研究 liblz4 文檔表明，它依賴於調用者不要求超過正確數量的解壓縮數據； 這與 liblz4 1.8.3 的觀察到的錯誤行為相符。 如果切片請求 >= datum 的解壓縮大小，則通過切換到正常的完整解壓縮代碼路徑來避免這些問題。 Tom Lane 和 Dilip Kumar 討論：https://postgr.es/m/507597.1616370729@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/063dd37ebc7644e8db6419565b50dca019e69e86

  • 避免在完成堆重寫時可能發生的崩潰。 `end_heap_rewrite` 在執行最終的 `smgrimmedsync` 之前，沒有仔細確保目標關係在 smgr 層級已開啟。在一般情況下，這不成問題，因為它會在重寫過程中較早開啟。然而，透過使用啟用 `CLOBBER_CACHE_ALWAYS` 的方式重新叢集一個空的資料表，可以重現崩潰。儘管這種精確的場景在 v13 中不會崩潰，但我認為這是不相關的規劃器變更的一個偶然結果，並且該問題很可能仍然可以透過其他測試案例觸發。造成此故障的真正直接原因是 commit c6b92041d，它將對 `heap_sync` 的呼叫（它謹慎地開啟 smgr）替換為直接呼叫 `smgrimmedsync`。因此，將修補程式回溯至 v13。 Amul Sul，根據 Neha Sharma 的報告；我進行了外觀上的變更和測試案例。 討論： https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9d523119fd38fd205cb9c8ea8e7cceeb54355818

  • 再次修正 psql 的 \connect 命令。 Jasen Betts 報告了 commit 85c54287a 的另一個意外的副作用：使用 "\c service=whatever" 重新連線沒有產生預期的結果。原因是從 PQconndefaults() 的輸出開始，實際上允許環境變數（例如 PGPORT）覆蓋服務檔案中的條目，而正常的優先順序是相反的。完全不使用 PQconndefaults 將需要在 do_connect 的參數設定中建立第三個主要程式碼路徑，所以我真的不想以這種方式來修正它。但是我們可以讓邏輯有效地忽略所有預設值，只需要再幾行程式碼。此修補程式不會變更 "\c -reuse-previous=on service=whatever" 的行為。這與 85c54287a 之前的情況有很大的不同，因為會重新使用更多參數，因此服務條目無法替換它們。但我認為這（主要）是故意的。無論如何，由於 libpq 不會報告它從何處取得參數值，因此很難採取不同的做法。根據 Jasen Betts 提出的錯誤 #16936。與之前的修補程式一樣，將修補程式回溯至所有支援的分支。（不幸的是，9.5 現在已停止支援，因此此問題不會在那裡得到修正。）討論： https://postgr.es/m/16936-3f524322a53a29f0@postgresql.org https://git.postgresql.org/pg/commitdiff/ea80138545043c0cfcff8405b15626796f2695fe

Peter Geoghegan 推送了

  • 回收在同一次 VACUUM 期間刪除的 nbtree 頁面。維護一個簡單的陣列，其中包含有關在 nbtree VACUUM 目前的 btvacuumscan() 呼叫期間刪除的頁面的元資料。在 btvacuumscan() 結束時使用此元資料，嘗試將新刪除的頁面放入 FSM 中，而無需進一步延遲。屆時可能還不能安全地將任何頁面放入 FSM 中（它們可能不被認為是可回收的），但我們嘗試一下並沒有什麼損失，而且有很多好處。實際上，在清理較大的索引時，這很有可能奏效，因為掃描索引自然需要很長時間。此 commit 不會變更頁面回收不變量；它僅在現有設計的範圍內提高了頁面回收的效率。回收安全是 nbtree 對 Lanin & Shasha 稱為「drain technique」的實作的一部分。該設計恰好使用交易 ID（它們儲存在已刪除的頁面中），但這本身並不能將回收安全性的截止點與 VACUUM 使用的任何基於 XID 的截止點對齊（例如，OldestXmin）。所有重要的是其他後端是否可能觀察到樹狀結構中的各種不一致之處（他們無法僅透過向右移動來偵測和恢復）。回收安全純粹是維護物理資料結構的一致性（或表面上的一致性）的問題。請注意，執行一個涉及大範圍 DELETE 然後是 VACUUM VERBOSE 的簡單序列測試案例可能會顯示任何新刪除的 nbtree 頁面尚未可重用/可回收。這是在沒有任何並行 XID 指派的情況下所預期的。這是一個舊的實作限制。實際上，這不太可能使回收仍然不安全，至少對於較大的索引來說，在同一個 VACUUM 期間回收新刪除的頁面實際上很重要。此 commit 的一個重要高層目標（以及相關的最近 commit e5d8a999 和 9f3665fb）是使索引 AM 中的昂貴的延遲清理操作在一般情況下變得罕見。如果索引清理經常依賴於下一個 VACUUM 操作來完成目前操作開始的工作，那麼索引清理的總體行為就難以預測。這與正在進行的工作相關，該工作新增了一個 vacuumlazy.c 機制，以便在某些情況下跳過索引清理。任何使索引清理的實際行為更簡單和更線性的東西，也將使 vacuumlazy.c 中的自上而下的建模更加穩健。作者：Peter Geoghegan pg@bowt.ie 審閱人：Masahiko Sawada sawada.mshk@gmail.com 討論： https://postgr.es/m/CAH2-Wzk76_P=67iUscb1UN44-gyZL-KgpsXbSxq_bdcMa7Q+wQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9dd963ae2534e9614f0abeccaafbd39f1b93ff8a

  • nbtree VACUUM：應對有錯誤的 opclass。教導 nbtree VACUUM 在頁面刪除嘗試失敗，「重新找到」其子/目標頁面的下行連結的情況下，繼續進行清理。沒有充分的理由將其視為不可恢復的錯誤。但是有一個很好的理由不這樣做：在這一點上繼續進行可消除 VACUUM 僅由於使用者定義的運算子類別程式碼的錯誤行為而沒有取得進展的任何疑問。 討論： https://postgr.es/m/CAH2-Wzma5G9CTtMjbrXTwOym+U=aWg-R7=-htySuztgoJLvZXg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5b861baa550a369e04bf67fbe83f3a5a8c742fb4

Michaël Paquier 推送了

  • 修正在具有 2PC 交易的檢查點中的時間軸指派。任何由檢查點發現仍然處於準備狀態的交易，其狀態資料都是從 PREPARE TRANSACTION 產生的 WAL 記錄中讀取的，然後再移動到 pg_twophase/ 中的新位置。在讀取這些記錄時，WAL 讀取器使用回呼函數 read_local_xlog_page() 來讀取頁面，該頁面在系統的各個部分之間共享。自 1148e22a 以來，此回呼函數在恢復期間讀取記錄時引入了 ThisTimeLineID 的更新，這可能對串聯 WAL 發送者有所幫助。如果當從其記錄中讀取一些 2PC 資料時發生升級，則 ThisTimeLineID 的此更新會與檢查點發生不良互動，因為透過變更 ThisTimeLineID，任何後續 WAL 記錄都將寫入比升級的時間軸更舊的時間軸。這會導致一致性問題。例如，後續的伺服器重新啟動將導致在尋找有效的檢查點記錄時發生故障，從而導致 PANIC 等。此 commit 變更了讀取 2PC 資料的程式碼，以便在讀取 2PC 記錄後重設時間軸，以防止干擾檢查點的靜態狀態。直接在 read_local_xlog_page() 中執行相同的操作可能很誘人。但是，基於導致 1148e22a 的討論，使用者可能依賴於在恢復中讀取 WAL 記錄頁面時 ThisTimeLineID 的更新，因此變更此回呼可能會破壞一些目前正在工作的案例。新增了一個重現該問題的 TAP 測試，該測試依賴於 PITR 來精確地觸發具有仍然被追蹤的已準備交易的升級。根據與 Heikki Linnakangas、Kyotaro Horiguchi、Fujii Masao 和我本人的討論。作者：Soumyadeep Chakraborty, Jimmy Yih, Kevin Yeap 討論： https://postgr.es/m/CAE-ML+_EjH_fzfq1F3RJ1=XaaNG=-Jz-i3JqkNhXiLAsM3z-Ew@mail.gmail.com Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/595b9cba2ab0cdd057e02d3c23f34a8bcfd90a2d

  • 簡化使用預期日誌檔案內容的 Kerberos TAP 測試。 Kerberos 的 TAP 測試依賴後端產生的日誌來檢查各種連線情境。為了確保給定的測試不會與先前測試產生的日誌內容重疊，測試套件依賴於具有日誌收集器和日誌檔案輪換的邏輯，以確保產生的日誌的唯一性，並帶有一個等待階段。 PostgresNode::issues_sql_like() 以更簡單的方式解決了針對預期模式解析日誌內容的問題，其中日誌檔案在檢查產生的內容之前被截斷，後端將其輸出發送到 pg_ctl 給定的日誌檔案中。 此提交將 Kerberos 測試套件切換為使用此方法，刪除任何等待階段並簡化整個邏輯，從而減少了程式碼。 如果測試中發生故障，由於 like() 的作用，日誌的內容仍然會在故障發生時顯示給使用者，因此這對除錯能力沒有影響。 我在審查一個不同的修補程式集時遇到了這個問題，該修補程式集旨在擴展 Kerberos 測試套件以檢查多個日誌模式，而不是現在的一個。 作者：Michael Paquier 審閱者：Stephen Frost, Bharath Rupireddy 討論：https://postgr.es/m/YFXcq2vBTDGQVBNC@paquier.xyz https://git.postgresql.org/pg/commitdiff/11e1577a576fec6307aa0bfcde7333e63f907fa7

  • 修復 Windows 上 2PC 交易和 PITR 的新 TAP 測試。 595b9cb 增加的測試忘記了在 Windows 上，需要使用特定條目設定 pg_hba.conf（參見 PostgresNode::set_replication_conf），否則基本備份會失敗。 任何需要支援複寫的節點只需在初始化時傳遞 allows_streaming。 這會更新測試以執行此操作。 在此過程中稍微簡化了一些事情。 每個 buildfarm 成員 fairywren。 任何執行此測試的 Windows 主機都會失敗，我也重現了該問題。 向後移植：10 https://git.postgresql.org/pg/commitdiff/992d353a190c551db39bcab2dec0ecf14fbc7a40

  • 修復 Windows 上 WAL 區段回收的並發問題。 此提交主要回復 aaa3aed，它將執行回收 WAL 區段的內部重新命名的常式切換為在 Windows 上使用 CreateHardLinkA() 加上 unlink()，而不是 rename()。 根據 Postgres 13 的多位使用者回報，這在使用 WAL 區段時會導致並發問題，主要表現為以下錯誤： LOG: could not rename file "pg_wal/000000XX000000YY000000ZZ": Permission denied（無法重新命名檔案 "pg_wal/000000XX000000YY000000ZZ"： 權限不足） 這會退回到使用單個 rename() (實際上是 Windows 上的 pgrename()) 的邏輯。 事實證明，當我測試時，這個問題很難命中，只有在 archive_command 無法完成其工作時才會遇到一次，因此它對環境敏感。 在我們切換回單個 rename() 之後，此問題的回報者已經能夠確認情況有所改善。 為了檢查事情，我向回報者提供了一個基於 13.2 的已修補組建（其中 aaa3aed 已還原），以測試錯誤是否消失，以及一個未修補的 13.2 組建，以測試錯誤是否仍然出現（只是為了確保我沒有搞砸我的組建過程）。 特別感謝 Fujii Masao 指出看起來像是罪魁禍首的提交，並感謝所有回報者花時間測試我發送給他們的東西。 回報者：Andrus, Guy Burgess, Yaroslav Pashinsky, Thomas Trenz 審閱者：Tom Lane, Andres Freund 討論：https://postgr.es/m/3861ff1e-0923-7838-e826-094cc9bef737@hot.ee 討論：https://postgr.es/m/16874-c3eecd319e36a2bf@postgresql.org 討論：https://postgr.es/m/095ccf8d-7f58-d928-427c-b17ace23cae6@burgess.co.nz 討論：https://postgr.es/m/16927-67c570d968c99567%40postgresql.org 討論：https://postgr.es/m/YFBcRbnBiPdGZvfW@paquier.xyz 向後移植：13 https://git.postgresql.org/pg/commitdiff/909b449e00fc2f71e1a38569bbddbb6457d28485

  • 在自動清理的詳細日誌中增加每個索引的統計資訊。 一旦關係的自動清理完成，如果達到 log_autovacuum_min_duration（或其關係選項）的閾值，則日誌會包含有關此關係狀態的更多資訊，例如關係的 VACUUM 操作、WAL 和系統使用的統計資訊內容。 此提交增加了有關關係索引統計資訊的更多資訊，每個索引產生一行日誌。 索引統計資訊已經計算出來了，但尚未在自動清理的上下文中列印出來。 在此過程中，進行了一些重構，以直接在 LVRelStats 中追蹤索引統計資訊，從而簡化了一些與並行 VACUUM 相關的常式。 作者：Masahiko Sawada 審閱者：Michael Paquier, Euler Taveira 討論：https://postgr.es/m/CAD21AoAy6SxHiTivh5yAPJSUE4S=QRPpSZUdafOSz0R+fRcM6Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5aed6a1fc214913de9ac69c1717dc64a2483e16d

  • 稍微修改自動清理中為索引統計資訊產生的日誌的措辭。 使用 "remain" 會造成混淆，因為這意味著索引檔案可以縮小。 而是使用 "in total"。 根據與 Peter Geoghegan 的討論。 討論：https://postgr.es/m/CAH2-WzkYgHZzpGOwR14CScJsjaQpvJrEkEfkh_=wGhzLb=yVdQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/99dd75fb99baa9188971cf47779ed8d7a5e6eb29

  • 清理程式碼註解中的術語 "combo CID"。 在程式碼註解中，Combo CID 使用了不同的術語，因此將使用的術語與某些 README 中目前使用的術語統一起來。 作者："Hou, Zhijie" 討論：https://postgr.es/m/1d42865c91404f46af4562532fdbea31@G08CNEXMBPEKD05.g08.fujitsu.local https://git.postgresql.org/pg/commitdiff/a1999a01bb56c5f5451116abe61b892b2eec5e49

Noah Misch 推送

Fujii Masao 推送

  • pgbench: 改善 \sleep 命令中的錯誤處理。本次提交改善了 pgbench 的 \sleep 命令，使其能更正確地處理以下三種情況。(1) 當 \sleep 命令中只指定一個參數且該參數不是數字時，之前 pgbench 會報告一個令人困惑的錯誤訊息，例如 "unrecognized time unit, must be us, ms or s"。本次提交修正了這個問題，改為報告更正確的錯誤訊息，例如 "invalid sleep time, must be an integer"。(2) 當 \sleep 命令中指定兩個參數且第一個參數不是數字時，之前 pgbench 會將該參數視為休眠時間 0。在這種情況下不會報告任何錯誤。本次提交修正了這個問題，使其在這種情況下會拋出錯誤。(3) 當一個變數被指定為 \sleep 命令中的第一個參數且該變數儲存了非數字值時，之前 pgbench 會將該參數視為休眠時間 0。在這種情況下不會報告任何錯誤。本次提交修正了這個問題，使其在這種情況下會拋出錯誤。作者：Kota Miyake 審閱人：Hayato Kuroda, Alvaro Herrera, Fujii Masao 討論：https://postgr.es/m/23b254daf20cec4332a2d9168505dbc9@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/8c6eda2d1c926be76baa79c28521275323bd26fd

  • pg_waldump: 修正每筆記錄統計中的錯誤。pg_waldump --stats=record 使用 RmgrId 和記錄的 xl_info 欄位的四個位元的組合來識別記錄。但 XACT 記錄使用這四個位元的第一個位元作為可選的旗標變數，而後面的三個位元用於 opcode 來識別記錄。因此，之前相同類型的 XACT 記錄可能會有不同的四個位元（三個位元相同但第一個位元不同），這可能導致 pg_waldump --stats=record 為相同的 XACT 記錄顯示兩行每筆記錄的統計資訊。這是一個錯誤。本次提交變更了 pg_waldump --stats=record，使其僅以不同的方式處理 XACT 記錄，即，僅針對 XACT 記錄，從 xl_info 中篩選出 opcode，並使用 RmgrId 和這三個位元的組合作為記錄的識別符。對於其他記錄，仍然使用 xl_info 欄位的四個位元。回溯修補到所有支援的分支。作者：Kyotaro Horiguchi 審閱人：Shinya Kato, Fujii Masao 討論：https://postgr.es/m/2020100913412132258847@highgo.ca https://git.postgresql.org/pg/commitdiff/51893c8463501fc9a38e39cc097773dbdfb9db82

  • 將 WalReceiverWaitStart 等待事件的類型從 Client 變更為 IPC。先前此等待事件的類型為 Client。但當報告此等待事件時，walreceiver 程序正在等待啟動程序設定串流複製的初始資料。它並非在等待連接到使用者應用程式或 walsender 的 Socket 上的任何活動。因此，本次提交將 WalReceiverWaitStart 等待事件的類型變更為 IPC。作者：Fujii Masao 審閱人：Kyotaro Horiguchi 討論：https://postgr.es/m/cdacc27c-37ff-f1a4-20e2-ce19933abfcc@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/1e3e8b51bda8ddd59984230f876f199c9ce3166a

  • 記錄 GetNewOidWithIndex() 無法多次找到未使用 OID 的情況。GetNewOidWithIndex() 會逐一產生新的 OID，直到找到關聯中不存在的 OID 為止。如果存在很長的連續現有 OID，GetNewOidWithIndex() 需要在迴圈中重複多次才能找到未使用的 OID。由於 TOAST 表可以有大量條目，並且可能存在這種長串的 OID，因此存在需要多次迭代才能找到 TOAST 表中不存在的新 OID 的情況。此外，如果所有（即 2^32）個 OID 都已被使用，GetNewOidWithIndex() 將進入類似忙碌迴圈的狀態，並重複迭代，直到至少一個 OID 被標記為未使用。有一些報告的問題是由 GetNewOidWithIndex() 中大量迭代引起的。例如，當將十億筆記錄插入到表中時，所有執行該插入操作的後端都在某個時間點掛起，並佔用 100% 的 CPU 使用率。之前沒有簡單的方法可以檢測到 GetNewOidWithIndex() 無法多次找到未使用的 OID。因此，例如，需要取得掛起的後端的 gdb 完整回溯，才能調查該問題。這很不方便，並且在某些生產環境中可能無法使用。為了提供簡單的方法，本次提交使 GetNewOidWithIndex() 記錄迭代次數超過 GETNEWOID_LOG_THRESHOLD 但尚未在關聯中找到未使用的 OID 的情況。此外，本次提交使其以指數級增加的時間間隔重複記錄，直到迭代次數超過 GETNEWOID_LOG_MAX_INTERVAL，並使其最終以每 GETNEWOID_LOG_MAX_INTERVAL 的間隔重複記錄，除非找到未使用的 OID。使用這些巨集變數是為了避免在伺服器日誌中填滿類似的訊息。在 pgsql-hackers 的討論中，還有另一個想法是透過等待事件報告 GetNewOidWithIndex() 中大量的迭代。但是由於 GetNewOidWithIndex() 會遍歷索引以尋找未使用的 OID，這將執行 I/O、取得鎖定等等，這將覆寫等待事件並在完成後將其重設為無。因此，這個想法效果不佳，我們沒有採用它。作者：Tomohiro Hiramitsu 審閱人：Tatsuhito Kasahara, Kyotaro Horiguchi, Tom Lane, Fujii Masao 討論：https://postgr.es/m/16722-93043fb459a41073@postgresql.org https://git.postgresql.postgresql.org/pg/commitdiff/7fbcee1b2d5f1012c67942126881bd492e95077e

  • 將等待事件 WalrcvExit 重新命名為 WalReceiverExit。Commit de829ddf23 新增了等待事件 WalrcvExit。但其名稱與其他等待事件（例如 WalReceiverMain 或 WalReceiverWaitStart 等）不一致。因此，本次提交將 WalrcvExit 重新命名為 WalReceiverExit。作者：Fujii Masao 審閱人：Thomas Munro 討論：https://postgr.es/m/cced9995-8fa2-7b22-9d91-3f22a2b8c23c@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/84007043fc1b1be68dad5d0a78269347c12094b6

  • 改善復原期間連線遭拒的錯誤訊息。先前，當啟動封存復原或備用伺服器，且達到一致的復原狀態，但 hot_standby 設定為關閉時，用戶端連線時的錯誤訊息為「資料庫系統正在啟動」，這是不必要地令人困惑，且也不是很準確。本次提交改善了復原期間連線遭拒的錯誤訊息，如下所示，以便使用者立即知道他們的伺服器已配置為拒絕這些連線。

  • 如果停用 hot_standby，當客戶端在封存復原或待機伺服器執行時嘗試連線，會輸出錯誤訊息 "the database system is not accepting connections" (資料庫系統不接受連線)，以及詳細訊息 "Hot standby mode is disabled." (已停用熱備援模式)。- 如果啟用 hot_standby，當客戶端在一致的復原狀態達成且 postmaster 開始接受唯讀連線之前嘗試連線，會輸出錯誤訊息 "the database system is not yet accepting connections" (資料庫系統尚未接受連線)，以及詳細訊息 "Consistent recovery state has not been yet reached." (尚未達成一致的復原狀態)。此提交不會變更在一般伺服器啟動和當機復原期間的連線拒絕錯誤訊息 "the database system is starting up" (資料庫系統正在啟動中)。因為它仍然適用於這些情況。作者：James Coleman 審閱者：Alvaro Herrera, Andres Freund, David Zhang, Tom Lane, Fujii Masao 討論：https://postgr.es/m/CAAaqYe8h5ES_B=F_zDT+Nj9XU7YEwNhKhHA2RE4CFhAQ93hfig@mail.gmail.com https://git.postgresql.org/pg/commitdiff/df9384492b89aac370ab9d12eb89375aeb38a1d4

  • 修正 WAL 重播 COMMIT_TS_SETTS 記錄中的錯誤。先前，COMMIT_TS_SETTS 記錄的 WAL 重播使用參數 write_xlog=true 呼叫 TransactionTreeSetCommitTsData()，這會產生並寫入新的 COMMIT_TS_SETTS 記錄。這在復原期間是不應該發生的。此提交修正了 COMMIT_TS_SETTS 記錄的 WAL 重播，使其使用 write_xlog=false 呼叫 TransactionTreeSetCommitTsData()，並且在復原期間不產生新的 WAL。向後移植到所有支援的分支。回報者：lx zou zoulx1982@163.com 作者：Fujii Masao 審閱者：Alvaro Herrera 討論：https://postgr.es/m/16931-620d0f2fdc6108f1@postgresql.org https://git.postgresql.org/pg/commitdiff/438fc4a39c3905b7af88bb848bc5aeb1308a017d

Robert Haas 推送

Tomáš Vondra 推送

Bruce Momjian 推送

Amit Kapila 推送

Peter Eisentraut 推送

Stephen Frost 推送

Michael Meskes 推送

Álvaro Herrera 推送

待處理的修補程式

Kyotaro HORIGUCHI 送出另一個修補程式的版本，以使異步副本等待 LSN 被重播。

Bharath Rupireddy 送出一個修補程式，以移除 BloomInitPage、GinInitPage 和 SpGistInitPage 中多餘的 memset 呼叫。

Hou Zhijie 送出另一個修補程式的版本，以避免在 INSERT INTO 參照表時，在 RI 觸發器中執行 CommandCounterIncrement。

Amul Sul 送出另一個修補程式的版本，以建立支援 ALTER SYSTEM READ {ONLY | WRITE} 的基礎架構。

Amit Langote 送出另一個修補程式的版本，以修復 UPDATE ... RETURNING 和在分割區之間移動元組之間的不一致問題。

Greg Nancarrow 送出另一個修補程式的版本，以啟用並行 INSERT 和/或 SELECT 用於 INSERT INTO。

Tang 送出另一個修補程式的版本，以支援 psql 中針對大寫字元輸入的查詢結果使用 Tab 鍵自動完成。

Tom Lane 送出另一個修補程式的版本，以允許根據 SQL 標準將別名直接附加到 JOIN ... USING。

David Oksman 送出一個修補程式，以實現 ALTER TABLE ... RENAME COLUMN IF EXISTS。

Andrei Zubkov 送出兩個修補程式版本，以將語句輸入時間戳記新增到 pg_stat_statements。

Thomas Munro 送出另一個修補程式的版本，以新增 psql \watch 指令的 PSQL_WATCH_PAGER。

Thomas Munro 送出四個修補程式的版本，以檢測執行查詢時連接已斷線的情況。

Fujii Masao 送出一個修補程式，旨在修復一個在待命伺服器關閉時發生的斷言失敗錯誤，方法是在啟動程序退出時呼叫 ShutdownRecoveryTransactionEnvironment()。

Peter Eisentraut 送出另一個修補程式的版本，以新增 result_format_auto_binary_types 設定。

Jan Wieck 送出三個修補程式的版本，以修復 pg_upgrade 以保留 datdba。

Bertrand Drouvot 送出四個修補程式的版本，以在待命伺服器上實現最小的邏輯解碼。

Pavel Stěhule 送出兩個修補程式的版本，以實現 schema 變數。

Marcus Wanner 送出兩個修補程式的版本，以將 xid 參數新增到輸出外掛程式的 filter_prepare 回呼函數。

Amul Sul 送出兩個修補程式的版本，以新增 RelationGetSmgr() 內聯函數。

Peter Smith 和 Amit Kapila 交換修補程式，以新增兩階段交易的邏輯解碼。

Euler Taveira de Oliveira 和 Peter Eisentraut 交換修補程式，以新增邏輯複製的列過濾。

Kyotaro HORIGUCHI 送出另一個修補程式的版本，以將統計收集器的暫時儲存從檔案變更為共享記憶體。

Masahiro Ikeda 和 Fujii Masao 交換修補程式，以使 WAL 接收器報告 WAL 統計資訊。

Bruce Momjian 和 Julien Rouhaud 交換修補程式，以在 pg_stat_activity、log_line_prefix 和 verbose explain 中公開 queryid。

Atsushi Torikoshi 送出四個修補程式的版本，以新增一個函數 pg_get_backend_memory_contexts()，其功能如其名稱所示。

Daniel Gustafsson 送出兩個修補程式的版本，以支援 NSS 作為 libpq TLS 後端。

Michaël Paquier 和 Jeevan Chalke 交換修補程式，以記錄來自所有 auth 後端的已驗證身份。

Stephen Frost 送出另一個修補程式的版本，以使用 WaitLatch 進行 vacuum/autovacuum 休眠。

Stephen Frost 送出三個修補程式的版本，為現在已過時的 recovery.conf 新增文件存根。

Justin Pryzby 送出另一個修補程式的版本，以新增一個可選的 ACCESS METHOD 到 CREATE TABLE ... LIKE。

Takayuki Tsunakawa 送出兩個修補程式的版本，以加速遠端分割區的 COPY FROM 運作。

Amit Langote 送出另一個修補程式的版本，以在分割資料表中建立外部索引鍵觸發程序，並使用它在跨分割區更新期間正確強制執行外部索引鍵。

David Rowley 送出兩個修補程式的版本，以新增 Result Cache 執行器節點。

Li Japin 送出另一個修補程式的版本，以實現 ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION。

Tomáš Vondra 送出一個修補程式，以修復 opclass 儲存類型。

Fujii Masao 送出另一個修補程式的版本，以將 WalrcvExit wait_event 重新命名為 WalReceiverExit。

Andrey V. Lepikhov 送出另一個修補程式的版本，以實現全域快照。

Atsushi Torikoshi 送出兩個修補程式的版本，以將 plan type 新增到 pg_stat_statements。

Denis Hirn 送出一個修補程式，以允許在 WITH RECURSIVE 中有多個遞迴自參考。

Masahiro Ikeda 和 Fujii Masao 交換修補程式，以使 pgstat 避免在 SIGQUIT 上寫入。

Kyotaro HORIGUCHI 送出另一個修補程式的版本，以保護 syscache 免於因負快取條目而膨脹。

Hou Zhijie 送出另一個修補程式的版本，以新增 eval_const_expressions 的 nullif 案例。

Mark Dilger 和 Robert Haas 交換修補程式，以新增 pg_amcheck contrib 應用程式。

Daniel Gustafsson 送出另一個修補程式的版本，以重構 SSL 測試工具，以允許使用多個程式庫。

Pavel Stěhule 送出兩個修補程式的版本，以新增例程標籤。

Thomas Munro 送出四個修補程式的版本，以使所有 SLRU 緩衝區大小可配置。

Peter Geoghegan 和 Masahiko Sawada 交換修補程式，以集中每個 VACUUM 的狀態，將 lazy_scan_heap() 分解為多個函數，從 vacuumlazy.c 中移除 tupgone 特殊案例，並在某些情況下跳過索引 vacuuming。

Kyotaro HORIGUCHI 送出另一個修補程式的版本，以實現就地資料表持久性變更，並新增一個新指令 ALTER TABLE ALL IN TABLESPACE SET LOGGED/UNLOGGED 來搭配使用。

Ashutosh Bapat 送出另一個修補程式的版本，以修復使用 TOAST 解碼投機性插入時的記憶體洩漏。

Ekaterina Sokolova 送出另一個修補程式的版本，以新增用於 Nested Loop 的 explain 的額外統計資訊。

Pavel Borisov 送出兩個修補程式的版本，以實現覆蓋 SP-GiST 索引，即支援 INCLUDE 欄位。

Marcus Wanner 為輸出外掛程式新增 concurrent_abort 回呼函數。

Joel Jacobson 送出另一個修補程式的版本，以新增視圖 pg_permissions 和 pg_ownerships。

Bharath Rupireddy 送出另一個修補程式的版本，使在將資料表新增至發佈時的錯誤訊息更具資訊性和一致性。

Kyotaro HORIGUCHI 送出另一個修補程式的版本，旨在修復一個 Walsender 可能無法將 wal 送到結尾的錯誤。

Jim Finnerty 送出另一個修補程式的版本，以新增具有 64 位元 GUC 的功能、使用 XID_FMT 格式化 xid，以及使用 ClogPageNumber 代替 int 以確保類型安全。

Sven Klemm 送出一個修補程式，以允許 CustomScan 節點發出訊號表示它們是否支援投影。

Andrew Dunstan 和 Nikita Glukhov 交換修補程式，以實現 SQL/JSON 的 JSON_TABLE 部分。

Andrew Dunstan 和 Nikita Glukhov 交換修補程式，以實現 SQL/JSON 的函數部分。

Amit Langote 和 Tom Lane 交換修補程式，透過修改更新計算新元組的方式，以及修改繼承更新/刪除的處理方式，使繼承樹中的更新可以更好地擴展。

David Steele 送出兩個修補程式的版本，以記錄備份標籤可能需要在 Windows 上以二進位模式開啟的事實。

Cai Mengjuan 送出一個修補程式，以在每次請求 xlog 串流傳輸時更新 walrcv->flushedUpto。

Andrew Dunstan 送出另一個修補程式的版本，以允許比對來自用戶端憑證的整個 DN。

Masahiro Ikeda 送出一個修補程式，以改善報告 wal 統計資訊的效能。

Tomáš Vondra 送出一個修補程式，以在 explain 中顯示已套用的擴展統計資訊。

Noah Misch 送出另一個修補程式的版本，以新增公用 schema 預設 ACL。

Lætitia Avrot 送出兩個修補程式的版本，以使使用 pg_dump 僅傾印函數成為可能。

Noah Misch 送出另一個修補程式的版本，以接受元組略大於 fillfactor 的略微填滿的頁面。

Álvaro Herrera 送出兩個修補程式的版本，以將追蹤功能新增到 libpq。

Kazutaka Onishi 送出另一個修補程式的版本，以使 TRUNCATE 在外部資料表上運作。

Andrew Dunstan 送出另一個修補程式版本，以實作全域暫存表格。

Yoan SULTAN 送出一個修補程式，使 pg_stat_statements 可以追蹤最新的陳述式。

David Rowley 送出另一個修補程式版本，以從 valgrind 洩漏追蹤中獲得更好的結果。