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

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

發表於 2021-04-12，作者：PWN
PWN

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

PostgreSQL 14 的功能凍結期已到。任何可能在 PostgreSQL 14 中的新功能都已進入 git 儲存庫。

PostgreSQL 產品新聞

AGE 0.4.0，一個提供圖形資料庫功能的 PostgreSQL 擴充功能已發布。https://github.com/apache/incubator-age/releases/tag/0.4.0

四月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已套用的修補程式

Tom Lane 推送了

Michaël Paquier 推送

  • 重構所有執行連線檢查的 TAP 測試套件。此提交重構了更多的 TAP 測試，以適應 PostgresNode 中最近引入的 connect_ok() 和 connect_fails()，由 0d1a3343 引入。這會更改以下測試套件以使用相同的程式碼路徑進行連線檢查： - Kerberos - LDAP - SSL - Authentication 這些常式經過擴充，能夠處理根據每個套件的需求設定的可選參數，如下所示： - 自定義 SQL 查詢。 - 預期的 stderr 匹配模式。 - 預期的 stdout 匹配模式。 新的設計可以通過更多參數進行擴充，並且未來有一些針對這些常式的計劃，包括基於後端日誌內容的檢查。作者：Jacob Champion, Michael Paquier 討論：https://postgr.es/m/d17b919e27474abfa55d97786cb9cfadfe2b59e9.camel@vmware.com https://git.postgresql.org/pg/commitdiff/c50624cdd248c13b4ba199f95e24c88d2cc8a097

  • 修復 collationcmds.c 中的錯字。由 51e225d 引入。作者：Anton Voloshin 討論：https://postgr.es/m/05477da0-703c-7de7-998c-5879738e8f39@postgrespro.ru https://git.postgresql.org/pg/commitdiff/9f6f1f9b8e61f9ce47e1936fc68c21a4a8d6722c

  • 變更 PostgresNode::connect_fails() 使其永遠不發送查詢。此類型的故障與 c757a3da 中已修復的問題相似，其中身份驗證失敗與 psql 將命令推送到其通訊管道中會導致測試失敗。此常式設計為失敗，因此發送查詢無論如何都沒有意義。根據 buildfarm 成員 gaur 和 hoverfly 的說法，基於 Tom Lane 的分析和修復。討論：https://postgr.es/m/513200.1617634642@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6d41dd045ada28ee14182112fc4cf50fb3879d28

  • 修復 SSL 和 Kerberos 測試中的一些問題。c50624c 中最近的重構意外地破壞了查詢後檢查的 kerberos 測試的一部分，因此將其功能添加回來。一些非活動的 SSL 測試的參數順序不正確，如果它們要運行，將導致它們失敗。作者：Jacob Champion 討論：https://postgr.es/m/4f5b0b3dc0b6fe9ae6a34886b4d4000f61eb567e.camel@vmware.com https://git.postgresql.org/pg/commitdiff/5a71964a832febfee23cedc3bb354049d6ca78a7

  • 透過 log_connections 添加有關已驗證身分的一些資訊。「已驗證身分」是身份驗證方法用來識別特定使用者的字串。在許多常見情況下，這與 PostgreSQL 使用者名稱相同，但對於某些第三方身份驗證方法，使用中的識別碼可能會在伺服器儲存之前被縮短或以其他方式翻譯（例如，透過 pg_ident 使用者映射）。為了幫助管理員查看誰實際與系統互動，此提交增加了在後端的 Port 內成功進行身份驗證時儲存原始身分的功能，並在啟用 log_connections 時產生日誌條目。產生的日誌條目看起來像這樣（其中名為「foouser」的本地使用者正在以名為「admin」的資料庫使用者身份連接到資料庫）：LOG: connection received: host=[local] LOG: connection authenticated: identity="foouser" method=peer (/data/pg_hba.conf:88) LOG: connection authorized: user=admin database=postgres application_name=psql Port->authn_id 根據身份驗證方法設定：bsd：PostgreSQL 使用者名稱（又名本地使用者名稱）cert：客戶端的 Subject DN gss：使用者主體 ident：遠端使用者名稱 ldap：最終綁定 DN pam：PostgreSQL 使用者名稱（又名 PAM 使用者名稱）password（以及所有 pw-challenge 方法）：PostgreSQL 使用者名稱 peer：對等方的 pw_name radius：PostgreSQL 使用者名稱（又名 RADIUS 使用者名稱）sspi：降級（與 SAM 相容）的登入名稱（如果 compat_realm=1），或使用者主體名稱（如果 compat_realm=0）trust 身份驗證方法未設定已驗證身分。clientcert=verify-full 也不設定。Port->authn_id 可以用於其他目的，例如 pg_stat_activity 中的僅超級使用者額外欄位，但這將留作未來工作。PostgresNode::connect_{ok,fails}() 已修改為允許測試使用新的 log_like 和 log_unlike 參數檢查後端日誌檔中所需的或禁止的模式。這使用了一種基於截斷現有伺服器日誌檔的方法，如 issues_sql_like()。測試已添加到 ldap、kerberos、身份驗證和 SSL 測試套件中。作者：Jacob Champion 審閱人：Stephen Frost, Magnus Hagander, Tom Lane, Michael Paquier 討論：https://postgr.es/m/c55788dd1773c521c862e8e0dddb367df51222be.camel@vmware.com https://git.postgresql.org/pg/commitdiff/9afffcb833d3c5e59a328a2af674fac7e7334fc1

  • 刪除一些索引 AM 的頁面初始化中多餘的 memset(0) 呼叫。Bloom、GIN、GiST 和 SP-GiST 依靠 PageInit() 來初始化頁面的內容，並且此常式會以零填充整個頁面，大小為 BLCKSZ，包括特殊空間。這些索引 AM 一直使用額外的 memset() 呼叫來以零填充特殊頁面空間，甚至整個頁面，這是不必要的，因為 PageInit() 已經完成了這項工作，因此讓我們刪除它們。GiST 沒有執行這個額外的呼叫，但自 6236991 以來已經註釋掉了一個執行此操作的系統呼叫。在此過程中，刪除 SP-GiST 的一個 MAXALIGN()，因為 PageInit() 會處理它。這使得所有索引 AM 的整個頁面初始化邏輯更加一致。作者：Bharath Rupireddy 審閱人：Vignesh C, Mahendra Singh Thalor 討論：https://postgr.es/m/CALj2ACViOo2qyaPT7krWm4LRyRTw9kOXt+g6PfNmYuGA=YHj9A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4c0239cb7a7775e3183cb575e62703d71bf3302d

  • 修復 Windows 主機上連線測試中的一些失敗。日誌檔的截斷（這組測試依賴於它來確保連線嘗試與其預期的後端日誌模式相符）失敗，正如 buildfarm 成員 fairywren 所報告的那樣。不要截斷，而是輪換日誌檔並重新啟動節點。這將確保每次測試的連線嘗試資料都是唯一的。討論：https://postgr.es/m/YG05nCI8x8B+Ad3G@paquier.xyz https://git.postgresql.org/pg/commitdiff/c7578fa64019f27edc31261ea49066a4b2569a6c

  • 修復文件和程式碼註解中的錯字和文法。註解修復應用於 HEAD，文件改進應用於需要的回溯分支。作者：Justin Pryzby 討論：https://postgr.es/m/20210408164008.GJ6592@telsasoft.com Backpatch-through：9.6 https://git.postgresql.org/pg/commitdiff/609b0652af00374b89411ea2613fd5bb92bca92c

Peter Eisentraut 推送了

Álvaro Herrera 推送了程式碼

Fujii Masao 推送了程式碼

  • 在啟動程序退出時關閉交易追蹤。Maxim Orlov 報告說，備用伺服器的關閉可能導致以下斷言失敗。此問題的原因是，當關閉導致啟動程序退出時，即使恢復時間交易追蹤已經初始化，也沒有關閉它，並且被追蹤的交易持有的一些鎖定無法釋放。在這種情況下，如果調用了其他程序，並且啟動程序使用的 PGPROC 條目被分配給它，則它會在初始化期間找到這些未釋放的鎖定並導致斷言失敗。TRAP: FailedAssertion("SHMQueueEmpty(&(MyProc->myProcLocks[i]))" 這個提交透過使啟動程序在退出時關閉交易追蹤並釋放所有鎖定來修復此問題。反向移植到所有支援的分支。回報者：Maxim Orlov 作者：Fujii Masao 審閱者：Maxim Orlov 討論：https://postgr.es/m/ad4ce692cc1d89a093b471ab1d969b0b@postgrespro.ru https://git.postgresql.org/pg/commitdiff/ad8b674922eb70dc5cd02951dd82fe2c4c37c80a

  • 新增函式以記錄指定後端程序的記憶體上下文。Commit 3e98c0bafb 新增了 pg_backend_memory_contexts 檢視表，以顯示後端程序的記憶體上下文。然而，其目標程序僅限於存取該檢視表的後端程序。因此，當調查其他後端程序的本地記憶體膨脹時，這並不是很方便。為了改善這種情況，此 commit 新增了 pg_log_backend_memory_contexts() 函式，該函式請求記錄指定後端程序的記憶體上下文。這些資訊也可以透過偵錯工具呼叫 MemoryContextStats(TopMemoryContext) 來收集。但這種技術在某些環境中無法使用，因為這些環境中沒有可用的偵錯工具。因此，pg_log_backend_memory_contexts() 讓我們可以更輕鬆地查看指定後端的記憶體上下文。只有超級使用者才被允許請求記錄記憶體上下文，因為允許任何使用者以無限制的速度發出此請求將會導致大量的日誌訊息，這可能會導致阻斷服務攻擊。收到請求後，在下一個 CHECK_FOR_INTERRUPTS() 時，目標後端會以 LOG_SERVER_ONLY 級別記錄其記憶體上下文，以便這些記憶體上下文會出現在伺服器日誌中，但不會發送到用戶端。它會針對每個記憶體上下文記錄一則訊息。因為如果它將所有記憶體上下文緩衝到 StringInfo 中，並將它們記錄為一則訊息，這可能會需要非常大地擴展緩衝區，並導致 OOM 錯誤，因為後端中可能存在大量的記憶體上下文。當後端程序消耗大量記憶體時，記錄其所有記憶體上下文可能會超出可用的磁碟空間。為了防止這種情況，此修補程式現在限制每個父上下文要記錄的子上下文數量為 100 個。與 MemoryContextStats() 類似，它假設日誌變長的實際情況通常是同一個父上下文下有大量的同級上下文；而查看超過 100 個的個別同級上下文的詳細資訊所帶來的額外偵錯價值並不大。在討論中，還有另一個建議的修補程式，用於新增函式以傳回指定後端的記憶體上下文作為結果集，而不是記錄它們。然而，該修補程式並未包含在此 commit 中，因為它有一些問題需要解決。感謝 Tatsuhito Kasahara、Andres Freund、Tom Lane、Tomas Vondra、Michael Paquier、Kyotaro Horiguchi 和 Zhihong Yu 的討論。Bump catalog version. 作者：Atsushi Torikoshi 審閱者：Kyotaro Horiguchi、Zhihong Yu、Fujii Masao 討論：https://postgr.es/m/0271f440ac77f2a4180e0e56ebd944d1@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/43620e328617c1f41a2a54c8cee01723064e3ffa

  • 修正 pgstat.c 中的錯字。由 9868167500 引入。作者：Vignesh C 討論：https://postgr.es/m/CALDaNm1DqgaLBAJrtGznKk1sR1mH-augmp7LfGvxWwTUhah+rg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f5d94e405e17a49487672316610630be2f9d0bb7

  • 如果找到以 wal_level=minimal 產生的 WAL，則停止封存復原。先前，如果啟用了熱備份，則當找到以 wal_level=minimal 產生的 WAL 時，封存復原會以錯誤退出。但如果禁用了熱備份，則它只會報告警告並在該情況下繼續。這可能會導致正常操作期間的資料遺失或錯誤。發出了一個警告，但使用者很容易錯過它，並且直到遇到實際錯誤時才注意到這種嚴重情況。為了改善這種情況，此 commit 變更了封存復原，以便當找到以 wal_level=minimal 產生的 WAL 時，無論熱備份的設定為何，它都會以 FATAL 錯誤退出。這使使用者可以很快注意到嚴重情況。如果封存復原是從在 wal_level 變更為 minimal 之前取得的基礎備份開始，則會擲回 FATAL 錯誤。當封存復原以錯誤退出時，如果使用者擁有在將 wal_level 設定為高於 minimal 之後取得的基礎備份，則他們可以透過從較新的備份開始封存復原來復原資料庫。但請注意，如果不存在這樣的備份，則沒有簡單的方法可以完成封存復原，這可能會使資料庫伺服器無法啟動，並且使用者可能會遺失整個資料庫。此 commit 將有關此風險的註解新增到文件中。即使在無法啟動資料庫伺服器的情況下，先前只要停用熱備份，使用者就可以避免封存復原期間的錯誤，強制啟動伺服器並從中搶救資料。但請注意，此 commit 使此程序完全不可用。作者：Takamichi Osumi 審閱者：Laurenz Albe、Kyotaro Horiguchi、David Steele、Fujii Masao 討論：https://postgr.es/m/OSBPR01MB4888CBE1DA08818FD2D90ED8EDF90@OSBPR01MB4888.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/9de9294b0c4dac77edb80f029648afca79d14653

  • postgres_fdw：允許匯入 LIMIT TO 中指定的分區。Commit f49bcd4ef3 不允許 postgres_fdw 匯入資料表分區。因為所有資料都可以透過作為分區階層根目錄的分區資料表存取，因此僅匯入分區資料表應允許存取所有資料，而無需建立額外的物件。當匯入整個綱要時，這是一個合理的預設值。但可能存在使用者想要明確匯入分區資料表的分區之一的情況。對於該用例，此 commit 允許 postgres_fdw 僅當在 LIMIT TO 子句中明確指定時，匯入作為其他資料表分區的資料表或外部資料表。它不會更改未在 IMPORT FOREIGN SCHEMA 命令的 LIMIT TO 中指定的任何分區會自動排除的行為。作者：Matthias van de Meent 審閱者：Bernd Helmle、Amit Langote、Michael Paquier、Fujii Masao 討論：https://postgr.es/m/CAEze2Whwg4i=mzApMe+PXxCEfgoZmHGqdqQFW7J4bmj_5p6t1A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a3740c48eb2f91663c7c06c948dfcfb6493d2588

  • 修復 commit 9de9294b0c 新增的測試。建置伺服器成員 "drongo" 和 "fairywren" 報告說，commit 9de9294b0c 新增的回歸測試 (024_archive_recovery.pl) 失敗。此失敗的原因是測試呼叫了 $node->init() 而沒有 "allows_streaming => 1"，並且沒有為來自 pg_basebackup 的 TCP/IP 連線新增 pg_hba.conf 條目。此 commit 透過在呼叫 $node->init() 時指定 "allows_streaming => 1" 來修正此問題。作者：Fujii Masao 討論：https://postgr.es/m/3cc3909d-f779-7a74-c201-f1f7f62c7497@oss.nttdata.com https://git.postgresql.org/pg/commitdiff/8ee9b662daa6d51b54d21ec274f22a218462ad2d

  • 允許 TRUNCATE 命令截斷外部資料表。此 commit 為 TRUNCATE 引入了新的外部資料包裝函式 API。它擴展了 TRUNCATE 命令，使其接受外部資料表作為要截斷的目標，並調用該 API。它還擴展了 postgres_fdw，使其可以向外部伺服器發出 TRUNCATE 命令，方法是為該 TRUNCATE API 新增例程。TRUNCATE 命令中指定的選項的相關資訊（例如 ONLY、CASCADE 等）會透過 API 傳遞到 FDW。要截斷的外部資料表清單也會傳遞到 FDW。FDW 會根據這些資訊截斷傳遞的外部資料表指定的外部資料來源。例如，postgres_fdw 會使用它們建構 TRUNCATE 命令，並將其發送到外部伺服器。為了提高效能，TRUNCATE 命令會針對要截斷的外部資料表所屬的每個外部伺服器，調用一次 TRUNCATE 的 FDW 例程。作者：Kazutaka Onishi、Kohei KaiGai，由 Fujii Masao 略作修改 審閱者：Bharath Rupireddy、Michael Paquier、Zhihong Yu、Alvaro Herrera、Stephen Frost、Ashutosh Bapat、Amit Langote、Daniel Gustafsson、Ibrar Ahmed、Fujii Masao 討論：https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com 討論：https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8ff1c94649f5c9184ac5f07981d8aea9dfd7ac19

  • 移除 COMMIT_TS_SETTS 記錄。提交 438fc4a39c 防止 WAL 重播寫入 COMMIT_TS_SETTS 記錄。由於此變更，PostgreSQL 核心中不再有產生 COMMIT_TS_SETTS 記錄的程式碼。此外，我們可以認為沒有擴充功能使用此記錄，因為我們目前尚未收到任何關於提交 438fc4a39c 修復的問題的投訴。因此，此提交移除了 COMMIT_TS_SETTS 記錄及其相關程式碼。即使沒有此記錄，提交時間戳記功能所需的時間戳記也可以從 COMMIT 記錄中取得。增加 WAL 頁面魔術數字。報告者：lx zou zoulx1982@163.com 作者：Fujii Masao 審閱者：Alvaro Herrera 討論：https://postgr.es/m/16931-620d0f2fdc6108f1@postgresql.org https://git.postgresql.org/pg/commitdiff/08aa89b326261b669648df97d4f2a6edba22d26a

  • 避免 TRUNCATE 指令中不必要的 table open/close。ExecuteTruncate() 會過濾 TRUNCATE 指令中重複指定的資料表，例如執行 "TRUNCATE foo, foo" 的情況。顯然，此類重複的資料表不需要開啟和關閉，因為它們會被跳過。但先前它總是在檢查它們是否是重複的資料表之前開啟這些資料表，然後在它們是重複的資料表時關閉它們。也就是說，重複的資料表被不必要地開啟和關閉。此提交變更了 ExecuteTruncate()，使其在確認資料表不是重複的資料表後才開啟該資料表，從而避免不必要的資料表開啟/關閉。不要回溯修補，因為這種不必要的資料表開啟/關閉雖然存在於舊版本中，但不是錯誤。作者：Bharath Rupireddy 審閱者：Amul Sul, Fujii Masao 討論：https://postgr.es/m/CALj2ACUdBO_sXJTa08OZ0YT0qk7F_gAmRa9hT4dxRcgPS4nsZA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/81a23dd87999ec9fb62554328c69c5b678612d56

Stephen Frost 推送

  • 新增 pg_read_all_data 和 pg_write_all_data 角色。一個常見的需求是擁有一個可以執行不受限制的 pg_dump 的角色，而無需明確授予該使用者存取所有資料表、結構描述等的權限，而該角色又不是超級使用者。這透過新增一個 "pg_read_all_data" 角色來解決此問題，該角色隱式地授予此角色的任何成員對所有資料表、檢視表和序列的 SELECT 權限，以及對所有結構描述的 USAGE 權限。由於在某些情況下，擁有一個具有寫入所有物件權限的角色也很有用，因此也引入了 pg_write_all_data，並授予使用者對所有資料表、檢視表和序列的隱式 INSERT、UPDATE 和 DELETE 權限。這些角色無法直接登入，而應 GRANT 給能夠登入的角色。如文件中所述，如果正在使用 RLS，則管理員可能（或可能不）希望在授予這些預定義角色的登入角色上設定 BYPASSRLS。審閱者：Georgios Kokolatos 討論：https://postgr.es/m/20200828003023.GU29590@tamriel.snowman.net https://git.postgresql.org/pg/commitdiff/6c3ffd697e2242f5497ea4b40fffc8f6f922ff60

Peter Geoghegan 推送

  • 簡化 VACUUM 管理的狀態。重新組織 VACUUM 使用的狀態結構 - 將相關項目組合在一起，以便更容易理解。此外，停止依賴 lazy_scan_heap() 內的堆疊變數 - 改為將這些變數移至狀態結構中。這樣做簡化了大量相關函數，這些函數的函數簽名具有許多不必要的冗餘。切換為使用 int64 作為用於計算透過 log_autovacuum 和 VACUUM VERBOSE 輸出報告給使用者的項目的結構欄位。我們之前使用的是 double，但似乎沒有任何優勢。使用 int64 使得可以新增斷言，以驗證堆積上的第一次傳遞（修剪）遇到的 LP_DEAD 項目數量與稍後在堆積上的第二次傳遞中從索引中刪除的項目數量完全相同。這些斷言將在稍後的提交中新增。最後，在 IndexBulkDeleteResult 指標參數與單一索引或所有索引相關存在歧義的情況下，調整具有 IndexBulkDeleteResult 指標參數的函數的簽名。函數現在使用 ambulkdelete() 和 amvacuumcleanup() 一直使用的慣用語（在適用的情況下）：接受可變的 IndexBulkDeleteResult 指標參數，並將結果 IndexBulkDeleteResult 指標傳回呼叫者。作者：Peter Geoghegan pg@bowt.ie 審閱者：Masahiko Sawada sawada.mshk@gmail.com 審閱者：Robert Haas robertmhaas@gmail.com 討論：https://postgr.es/m/CAH2-WzkeOSYwC6KNckbhk2b1aNnWum6Yyn0NKP9D-Hq1LGTDPw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b4af70cb210393c9c8f41643acf6b213e21178e7

  • 傳播並行 VACUUM 的緩衝區存取策略。並行 VACUUM 依賴於從 leader 流程傳播到 fork() 上的 worker 的全域變數狀態。提交 b4af70cb 移除了 vacuumlazy.c 內部大多數全域變數的使用，但沒有考慮緩衝區存取策略狀態。為了修復此問題，改為透過共享記憶體傳播狀態。根據 elver、curculio 和 morepork 上的建置場失敗情況。非常感謝 Thomas Munro 在清單外提供的協助。 https://git.postgresql.org/pg/commitdiff/49f49defe7c0a330cca084de5da14ccdfdafc6a3

  • 在並行 VACUUM worker 中分配存取策略。提交 49f49def 採取了完全錯誤的方法來修復此問題。只需在每個 worker 中分配一個本地緩衝區存取策略，而不是嘗試傳播狀態。此狀態從未首先由並行 VACUUM 傳播。看起來在提交 40d964ec 之後，這起作用的唯一原因是它涉及靜態全域變數，這些變數根據 C 標準初始化為 0。即使在 HEAD 上，也可能需要更全面的修復。此修復至少應再次使建置場變綠。再次感謝 Thomas Munro 在清單外提供的持續協助。 https://git.postgresql.org/pg/commitdiff/f6b8f19a084ce949522fcbc940dc116c034cfc47

  • 重構 lazy_scan_heap() 迴圈。新增一個 lazy_scan_heap() 的輔助函式，用來處理堆疊修剪和元組凍結：lazy_scan_prune()。這樣程式碼會更乾淨。現在 lazy_scan_heap() 的每個區塊迴圈中剩下的程式碼可以被認為是 lazy_scan_prune() 呼叫之前或之後的程式碼，lazy_scan_prune() 現在是明顯的焦點。這種劃分是透過我們現在管理狀態的方式來強制執行的。lazy_scan_prune() 輸出狀態（使用它自己的結構），描述在修剪和凍結後如何處理頁面（例如，可見性映射維護，在 FSM 中記錄可用空間）。它不會從前言程式碼傳遞任何特殊的指示狀態。此外，乾淨地分離使用 INDEX_CLEANUP=off 的 VACUUM 所使用的邏輯，與單一堆疊掃描 VACUUM 所使用的邏輯。前一種情況現在被組織為雙次掃描 VACUUM 略過索引和堆疊的 vacuuming。後一種情況則恢復為僅在表格恰好沒有索引時使用（就像 commit a96c41fe 之前一樣）。這種結構更自然，因為 INDEX_CLEANUP=off 的重點是跳過原本會發生的索引和堆疊 vacuuming。單一堆疊掃描的情況並沒有跳過任何有用的工作，它只是在表格恰好沒有索引時，一起進行堆疊修剪和堆疊 vacuuming。這兩個變更都是為即將到來的 patch 做準備，該 patch 將概括 INDEX_CLEANUP=off 使用的機制。後續的 patch 將允許 VACUUM 動態放棄索引和堆疊 vacuuming，因為問題出現（例如，發生迴繞），以便受影響的 VACUUM 操作可以盡快完成。此外，修復了單次掃描 VACUUM VERBOSE 輸出中的一個非常古老的錯誤。我們將透過修剪刪除的元組數量，直接替代為報告在處理堆疊第二次掃描的函式中移除的 LP_DEAD 項目數量。但這根本行不通，因為它們是兩回事。為了修復這個問題，開始追蹤修剪期間遇到的 LP_DEAD 項目總數，並在報告中使用它。單次掃描 VACUUM 將始終在修剪後立即 vacuum 掉堆疊頁面擁有的任何 LP_DEAD 項目，因此修剪期間遇到的 LP_DEAD 項目總數等於 vacuum 掉的總數。（在 INDEX_CLEANUP=off 的情況下，它們不相等，但沒關係，因為跳過索引 vacuuming 現在是一個與單次掃描 VACUUM 完全正交的概念。）此外，停止在 VACUUM VERBOSE 輸出中報告 LP_UNUSED 項目的計數。這使 VACUUM VERBOSE 的輸出與 log_autovacuum 的輸出更加一致（因為它從未顯示有關 LP_UNUSED 項目的資訊）。VACUUM VERBOSE 報告了上次 VACUUM 留下的 LP_UNUSED 項目，以及在當前 VACUUM 期間透過修剪 HOT 鏈創建的 LP_UNUSED 項目（它從未包括當前 VACUUM 對堆疊的第二次掃描留下的 LP_UNUSED 項目）。這使其無法作為行指標膨脹的指標，這一定是最初的意圖。（與第一個 VACUUM VERBOSE 問題一樣，這個問題可以說是 commit 282d2a03 中的一個疏忽，該 commit 新增了僅堆疊元組優化。）最後，停止在 VACUUM VERBOSE 輸出中報告 empty_pages，並開始報告 pages_removed。這也使 VACUUM VERBOSE 的輸出與 log_autovacuum 的輸出更加一致（它不顯示 empty_pages，但顯示 pages_removed）。一個空頁面與幾乎為空的頁面，或除了少量剩餘的 LP_UNUSED 項目之外為空的頁面，沒有有意義的差異。作者：Peter Geoghegan pg@bowt.ie 審閱人：Robert Haas robertmhaas@gmail.com 審閱人：Masahiko Sawada sawada.mshk@gmail.com 討論：https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/7ab96cf6b312cfcd79cdc1a69c6bdb75de0ed30f

  • 從 vacuumlazy.c 中移除 tupgone 特例。在極少數情況下重試對 heap_prune_page() 的呼叫，在這些情況下，heap_prune_page() 呼叫與緊隨其後的 HeapTupleSatisfiesVacuum() 呼叫之間存在差異。當並發中止的事務在每個步驟之間的小窗口中使元組變為 DEAD 時，可能會出現差異。這是 VACUUM 認為 DEAD 的元組在修剪後仍然具有儲存空間的唯一情況。VACUUM 對死元組的定義現在非常簡單且明確：每個頁面中的死元組始終是在我們執行修剪之後（以及在我們考慮凍結具有元組儲存空間的剩餘項目之前）遇到的 LP_DEAD 行指標。消除 tupgone=true 特例，可以基於靈活的動態標準跳過 INDEX_CLEANUP=off 樣式的索引 vacuuming。INDEX_CLEANUP=off 的情況必須事先知道跳過索引，這是由於與特例的細微互動（請參閱 commit dd695979）-- 這本身就是一個特例。現在沒有特例了。因此，現在無論我們何時或如何決定跳過索引 vacuuming，都無關緊要：它不會影響修剪的行為方式，也不會受到修剪或凍結的任何實作細節的影響。此外，移除 XLOG_HEAP2_CLEANUP_INFO 記錄。由於我們現在完全依賴堆疊修剪來處理恢復衝突，因此這些不再是必需的。對於修剪剛錯過的 DEAD 元組，不再需要產生恢復衝突。這也意味著堆疊 vacuuming 現在使用與索引 vacuuming 始終使用的策略完全相同的恢復衝突策略：REDO 例程永遠不需要處理來自 WAL 記錄的 latestRemovedXid，因為在所有情況下，更早的修剪 WAL 記錄的 REDO 都是足夠的。通用的 XLOG_HEAP2_CLEAN 記錄類型現在分為兩個新的記錄類型，以反映這種新的劃分（這些稱為 XLOG_HEAP2_PRUNE 和 XLOG_HEAP2_VACUUM）。此外，當堆疊頁面在 VACUUM 的第二次堆疊掃描期間被 vacuum 時，停止獲取堆疊頁面的超級獨佔鎖。常規的獨佔鎖就足夠了。這是正確的，因為堆疊頁面 vacuuming 現在嚴格來說是將 LP_DEAD 行指標設定為 LP_UNUSED。沒有其他後端可以擁有指向位於釘選緩衝區中的元組的指標，該指標可能會被並發堆疊頁面 vacuum 操作無效化。現在可以將堆疊 vacuuming 視為概念上與索引 vacuuming 相似，而與堆疊修剪概念上不同。堆疊修剪現在對涉及資料庫邏輯內容的任何事情負有全部責任（例如，管理事務狀態資訊、恢復衝突、考慮如何處理 HOT 鏈）。索引 vacuuming 和堆疊 vacuuming 現在只關心從支援邏輯資料庫的物理資料結構中回收垃圾項目。由於修剪和堆疊頁面 vacuum WAL 記錄的變更，提高 XLOG_PAGE_MAGIC。避免 tupgone 情況重試修剪頁面的想法歸功於 Andres Freund。作者：Peter Geoghegan pg@bowt.ie 審閱人：Andres Freund andres@anarazel.de 審閱人：Masahiko Sawada sawada.mshk@gmail.com 討論：https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8523492d4e349c4714aa2ab0291be175a88cb4fc

  • 在 VACUUM 期間截斷行指標陣列。使 VACUUM 能夠截斷每個堆積頁面的行指標陣列，當連續的 LP_UNUSED 行指標群組出現在陣列的末尾時 -- 這些未使用且未被引用的項目將被排除。此過程發生在 VACUUM 對堆積的第二次遍歷期間，緊接在頁面上的 LP_DEAD 行指標（在第一次遍歷期間遇到/修剪的指標）被標記為 LP_UNUSED 之後。截斷避免了某些工作負載導致的行指標膨脹，特別是那些涉及針對同一表持續的範圍 DELETE 和批量 INSERT。此外，強化 heapam 代碼，以檢查我們尚未進行檢查的地方是否存在超出範圍的頁面偏移量編號。作者：Matthias van de Meent boekewurm+postgres@gmail.com 作者：Peter Geoghegan pg@bowt.ie 審閱者：Masahiko Sawada sawada.mshk@gmail.com 審閱者：Peter Geoghegan pg@bowt.ie 討論：https://postgr.es/m/CAEze2WjgaQc55Y5f5CQd3L=eS5CZcff2Obxp=O6pto8-f0hC4w@mail.gmail.com 討論：https://postgr.es/m/CAH2-Wzn6a64PJM1Ggzm=uvx2otsopJMhFQj_g1rAj4GWr3ZSzw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3c3b8a4b26891892bccf3d220580a7f413c0b9ca

  • 為 VACUUM 添加環繞失效保護。添加一個失效保護機制，當 VACUUM 注意到表的 relfrozenxid 和/或 relminmxid 非常接近過去時觸發。VACUUM 以有規律的間隔動態檢查表的年齡。當失效保護觸發時，VACUUM 會採取非常措施以盡快完成，以便可以推進 relfrozenxid 和/或 relminmxid。VACUUM 將停止應用任何可能生效的基於成本的延遲。VACUUM 還將繞過任何進一步的索引清理和堆積清理 -- 它只完成所需的任何剩餘的修剪和凍結。繞過索引/堆積清理由 commit 8523492d 啟用，這使得可以動態觸發 VACUUM 內部已使用的機制，當它以 INDEX_CLEANUP 關閉運行時。預計失效保護幾乎總是在自動清理中觸發，以防止環繞，遠在自動清理開始之後。但是，失效保護機制可以在任何 VACUUM 操作中觸發。即使在非積極的 VACUUM 中，我們可能不會推進 relfrozenxid，但完成剩餘的修剪和凍結仍然是一個好主意。隨後將立即啟動積極/反環繞 VACUUM。請注意，隨後的反環繞 VACUUM 本身會觸發失效保護，通常甚至在其開始第一次（也是唯一一次）堆積遍歷之前。失效保護由兩個新的 GUC 控制：vacuum_failsafe_age 和 vacuum_multixact_failsafe_age。沒有等效的 reloption，因為預計它不會有用。GUC 具有相當高的默認值（兩者都默認為 16 億），並且預計通常僅用於使失效保護更早/更頻繁地觸發。作者：Masahiko Sawada sawada.mshk@gmail.com 作者：Peter Geoghegan pg@bowt.ie 討論：https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com 討論：https://postgr.es/m/CAH2-WzmgH3ySGYeC-m-eOBsa2=sDwa292-CFghV4rESYo39FsQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1e55e7d1755cefbb44982fbacc7da461fa8684e6

  • 使 VACUUM 能夠繞過不必要的索引清理。在結束對堆積的第一次遍歷（也是在這種情況下對堆積的唯一一次遍歷）時，如果其 dead_tuples 陣列中恰好有零個 TIDs，則 VACUUM 從不需要為每個索引調用 ambulkdelete()。當發生這種情況時，根本不需要索引清理。索引清理仍然會繼續進行，但實際上，當沒有之前的 ambulkdelete() 調用時，大多數對 amvacuumcleanup() 的調用通常都是空操作。簡而言之，當顯然沒有要從索引中刪除的索引元組時，VACUUM 通常設法避免索引掃描。但是，要刪除的索引元組接近於零的情況是另一回事 -- 進行了一輪 ambulkdelete() 調用（每個索引一個），每個調用都執行了完整的索引掃描。現在，VACUUM 的行為就像要刪除的索引元組為零的情況一樣，實際上是“幾乎為零”的情況。也就是說，它現在可以繞過索引清理和堆積清理作為一種優化（儘管不能繞過索引清理）。VACUUM 是否繞過索引是動態確定的，基於剛剛觀察到的表中具有一個或多個 LP_DEAD 項目的堆積頁面的數量（在最壞的情況下，堆積頁面中的 LP_DEAD 項目與仍然需要從每個索引中刪除的索引元組具有 1:1 的對應關係）。我們僅在表中 2% 或更少的頁面具有一個或多個 LP_DEAD 項目時跳過索引清理 -- 作為一種優化，繞過索引清理不得顯著阻礙在可見性地圖中設置位。作為進一步的條件，在堆積上的第一次遍歷完成時，dead_tuples 陣列（即 VACUUM 的 LP_DEAD 項目 TIDs 陣列）不得超過 32MB，這也是做出繞過決策的時間。（VACUUM 還必須能夠將所有 TIDs 放入其 maintenance_work_mem 綁定的 dead_tuples 空間中，儘管使用默認的 maintenance_work_mem 設置，這無關緊要。）這避免了在連續 VACUUM 操作始終具有幾乎零個無效索引元組的工作負載中，例行清理的持續時間和開銷出現令人驚訝的跳躍。LP_DEAD 項目的數量很可能會在多次 VACUUM 操作中累積，然後最終超過閾值，並且 VACUUM 執行常規索引清理。即便如此，該優化也將避免大量基本上不必要的索引清理。將來，我們可能會教導 VACUUM 在每個索引的基礎上跳過索引清理，使用一種更加複雜的方法。目前，我們僅考慮極端情況，在這些情況下，我們可以非常確信，使用簡單的啟發式方法，索引清理是不值得的。此外，當啟用自動清理日誌記錄時，記錄有關有多少堆積頁面具有一個或多個 LP_DEAD 項目的信息。作者：Masahiko Sawada sawada.mshk@gmail.com 作者：Peter Geoghegan pg@bowt.ie 討論：https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com 討論：https://postgr.es/m/CAH2-WzmkebqPd4MVGuPTOS9bMFvp9MDs5cRTCOsv1rQJ3jCbXw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5100010ee4d5c8ef46619dbd1d17090c627e6d0a

  • 消除另一個 _bt_check_unique 編譯器警告。根據 Tom Lane 的投訴。討論：https://postgr.es/m/1922884.1617909599@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/796092fb84c08162ae803e83a13aa8bd6d9b23d0

Amit Kapila 推送

David Rowley 提交

  • 修正 MSVC 中 fe-trace.c 的編譯器警告。似乎在 MSVC 中，timeval 的 tv_sec 欄位類型為 long。 localtime() 接受一個 time_t 指標。由於 long 即使在 MSVC 的 64 位版本中也是 32 位的，因此傳遞一個 long 指標而不是正確的 time_t 指標會產生編譯器警告。修正此問題。審閱者：Tom Lane 討論：https://postgr.es/m/CAApHDvoRG25X_=ZCGSPb4KN_j2iu=G2uXsRSg8NBZeuhkOSETg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9bc9b4609a246ded5caf3f3d4c0013a002ba2323

  • 修正 libpq_pipeline.c 中 MSVC 的編譯器警告。DEBUG 已經被 MSVC 工具鏈為 "Debug" 建置定義。在這些系統上，無條件的 #define DEBUG 會導致 'DEBUG': 巨集重新定義警告。在這裡，我們將 DEBUG 重新命名為 DEBUG_OUPUT，並且也刪除定義此常數的 #define。這似乎是錯誤地留在程式碼中的。討論：https://postgr.es/m/CAApHDvqTTgDm38s4HRj03nhzhzQ1oMOj-RXFUB1pE6Bj07jyuQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3b82d990ab784881153c0f127e4c1211e9b6065c

  • 清理分割區修剪步驟的產生。gen_prune_steps_from_opexps 中有一些程式碼不必要地檢查一個列表是否為空，而該列表顯然必須至少包含一個項目。這促使 partprune.c 中進行了進一步的清理操作。此外，先前的程式碼最終可能會添加額外的不必要的 INTERSECT 步驟。但是，這些步驟似乎不會導致任何錯誤行為。 gen_prune_steps_from_opexps 現在不再負責產生組合修剪步驟。相反，已經進行一些組合步驟建立的 gen_partprune_steps_internal 已被賦予產生所有組合步驟的唯一責任。這意味著當我們遞迴呼叫 gen_partprune_steps_internal 時，由於它現在總是在產生多個步驟時添加一個組合步驟，因此我們只需關注返回的最終步驟。順便說一下，對註釋進行大量工作，以更清楚地解釋 gen_partprune_steps_internal 和 gen_prune_steps_from_opexps 的作用。這是相當複雜的程式碼，因此額外努力為任何新讀者提供有關事物如何運作的概述似乎是一個好主意。作者：Amit Langote 報告者：Andy Fan 審閱者：Kyotaro Horiguchi, Andy Fan, Ryan Lambert, David Rowley 討論：https://postgr.es/m/CAKU4AWqWoVii+bRTeBQmeVW+PznkdO8DfbwqNsu9Gj4ubt9A6w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5ac9c4307337313bedeafc21dbbab93ba809241c

  • 加速 ScalarArrayOpExpr 的評估。具有 "useOr=true" 和一組 Consts 在右側的 ScalarArrayOpExprs 傳統上一直使用對陣列進行線性搜尋的方式進行評估。當這些陣列包含大量元素時，這種線性搜尋可能會成為執行時間的重要組成部分。在這裡，我們添加了一種新的評估 ScalarArrayOpExpr 運算式的方法，允許透過首先建立一個包含每個元素的雜湊表來對它們進行評估，然後在後續評估中，我們只需探測該雜湊表以確定是否存在匹配項。規劃器負責確定何時可以進行此最佳化，並且它透過在 ScalarArrayOpExpr 中設定 hashfuncid 來啟用它。僅當設定了 hashfuncid 時，執行器才會執行雜湊表評估。這意味著並非所有情況都經過最佳化。例如，包含 IN 子句的 CHECK 約束不會透過規劃器，因此不會設定 hashfuncid。我們可能會在稍後的日期對此做些什麼。我們現在不這樣做的原因是擔心我們可能會減慢運算式僅評估一次的情況。這些情況可能很常見，例如，對包含 IN 子句的 CHECK 約束的表進行單行 INSERT。在規劃器中，當 ScalarArrayOpExpr 的運算符有合適的雜湊函數，並且陣列中至少有 MIN_ARRAY_SIZE_FOR_HASHED_SAOP 個元素時，我們會啟用它。目前閾值設定為 9。作者：James Coleman, David Rowley 審閱者：David Rowley, Tomas Vondra, Heikki Linnakangas 討論：https://postgr.es/m/CAAaqYe8x62+=wn0zvNKCj55tPpg-JBHzhZFFc6ANovdqFw7-dA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/50e17ad281b8d1c1b410c9833955bc80fbad4078

  • 稍微改善 nodeFuncs.c 中容易產生誤導的註釋。nodeFuncs.c 中有一些註釋，根據您對 "result" 一詞的理解，可能會讓您認為這些註釋是從其他地方複製貼上的。如果您將 "result" 視為註釋所寫入函數的返回值，那麼您會被誤導。但是，如果您正確地將 "result" 解釋為給定節點類型的結果類型，那麼您不會看到任何問題。在這裡，我們做一個小的清理，以防止未來出現任何誤解。根據 Tom Lane 的措辭建議。審閱者：Tom Lane 討論：https://postgr.es/m/CAApHDvp+Bw=2Qiu5=uXMKfC7gd0+B=4JvexVgGJU=am2g9a1CA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/152d33bccec7176f50be225bdbedf2e6de214e54

Etsuro Fujita 提交

Dean Rasheed 提交

  • pgbench: 產生隨機排列的函式。此新增了一個新函式 permute()，可產生任意大小的虛擬隨機排列。可用於隨機打亂一組值，以消除不必要的關聯性。例如，排列來自非均勻隨機分佈的輸出，以便所有最常見的值不會集中在一起，從而可以執行更真實的測試。以前，建議使用 hash() 來達到此目的，但它存在可能改變分佈的衝突問題，因此建議改用 permute()。由 Fabien Coelho 和 Hironobu Suzuki 完成，我進行了額外的修改。經 Thomas Munro、Alvaro Herrera 和 Muhammad Usama 審閱。討論：https://postgr.es/m/alpine.DEB.2.21.1807280944370.5142@lancre https://git.postgresql.org/pg/commitdiff/6b258e3d688db14aadb58dde2a72939362310684

Heikki Linnakangas 推送

Tomáš Vondra 推送

  • 修正處理與擴充統計資料不相容的子句。在套用擴充統計資料時，對不相容子句的處理有點混亂 - 在處理相容和不相容子句的組合時，有時會錯誤地將不相容子句視為相容，從而導致崩潰。透過重新設計套用所選統計物件的程式碼來使其更容易理解，並新增適當的相容性檢查來修正此問題。由 David Rowley 回報。討論：https://postgr.es/m/CAApHDvpYT10-nkSp8xXe-nbO3jmoaRyRFHbzh-RWMfAJynqgpQ%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/518442c7f334f3b05ea28b7ef50f1b551cfcc23e

  • 不要將不存在的頁面從 BRIN 新增到點陣圖。bringetbitmap() 中的程式碼只是將整個匹配的頁面範圍新增到 TID 點陣圖，如 pages_per_range 所確定，即使某些頁面超出堆積的末尾。然後，查詢可能會因類似這樣的錯誤而失敗：ERROR: could not open file "base/20176/20228.2" (target block 262144): previous segment is only 131021 blocks 在這種情況下，關係有 262093 個頁面（131072 和 131021 個頁面），但我們試圖存取區塊 262144，即第 3 個區段的第一個區塊。在那個時候，_mdfd_getseg() 注意到前面的區段不完整，並且失敗。實際上遇到這種情況的可能性很小，因為

  • 大多數索引使用二次方範圍，因此區段和頁面範圍完美對齊（區段結束也是頁面範圍結束）。* 表格大小必須恰到好處，最後一個區段幾乎已滿 - 距離完整區段少於一個頁面範圍，因此最後一個頁面範圍實際上跨越了區段邊界。* 必須啟用預先提取。常規頁面存取會檢查頁面是否超出堆積末尾，但預先提取不會。在較舊的版本（12 之前）中，執行會在遇到第一個不存在的頁面後停止，因此預先提取距離必須足以到達下一個區段中的第一個頁面以觸發問題。自 12 以來，只需啟用預先提取就足夠了，預先提取距離無關緊要。透過不將不存在的頁面新增到 TID 點陣圖來修正此問題。全部向後移植到 9.6（BRIN 索引是在 9.5 中引入的，但該版本已終止）。向後移植：9.6 https://git.postgresql.org/pg/commitdiff/23607a8156d595522c232ff3933d77041d3adaa1

Andres Freund 推送

Magnus Hagander 推送

Robert Haas 推送

  • amcheck：移除重複的 XID/MXID 範圍檢查。Commit 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0 導致相同的 xmin 和 xmax 範圍檢查在 check_tuple() 和 check_tuple_visibility() 中都執行。移除重複的檢查。同時，調整該 commit 中被忽略的一些程式碼註解。Mark Dilger 討論：http://postgr.es/m/AC5479E4-6321-473D-AC92-5EC36299FBC2@enterprisedb.com https://git.postgresql.org/pg/commitdiff/4573f6a9af6e232ba073392716a051ae2017d1e9

  • amcheck：修復 TOAST 指標驗證的數個問題。首先，不要在持有緩衝區鎖定時執行資料庫存取。在檢查堆積時，我們可以透過對 TOAST 索引執行掃描，並查找與主表中 TOAST 指標中出現的每個值 ID 對應的區塊，來驗證 TOAST 指標是否正常。但是，在至少持有緩衝區鎖定時執行此操作，可能會導致其他後端無法中斷地等待，並且可能會導致未被偵測到且無法中斷的死鎖。因此，請建立一個在持有鎖定時要執行的檢查清單，然後在釋放鎖定後執行這些檢查。其次，調整內容，以便我們不會嘗試追蹤已經符合修剪資格的元組的 TOAST 指標。TOAST 元組與主元組同時符合修剪資格，因此嘗試檢查它們可能會導致虛假的損壞報告，如在 buildfarm 中觀察到的那樣。決定正在檢查的元組是否可修剪的必要基礎架構是由 commit 3b6c1259f9ca8e21860aaf24ec6735a8e5598ea0 新增的，但在這個修補程式之前，它實際上並未用於其預期用途。Mark Dilger，我調整了程式碼以避免記憶體洩漏。討論：http://postgr.es/m/AC5479E4-6321-473D-AC92-5EC36299FBC2@enterprisedb.com https://git.postgresql.org/pg/commitdiff/ec7ffb8096e8eb90f4c9230f7ba9487f0abe1a9f

Bruce Momjian 推送

Thomas Munro 推送

Noah Misch 推送

待處理的修補程式

Bharath Rupireddy 送出另一個修訂版的修補程式，以新增用於多個和單個插入的表格 AM，並將其用於 CTAS、REFRESH MATERIALIZED VIEW 和 COPY。

Sait Talha Nisanci 送出另一個修訂版的修補程式，旨在修復一個錯誤，該錯誤表現為 record_type_typmod_compare 中的崩潰。

Bharath Rupireddy 送出另外兩個修訂版的修補程式，以澄清因將非表格新增至發布而引起的錯誤訊息，命名它是的物件類型，而不是它不是的類型（表格）。

Jaime Casanova 送出一個修補程式，以將 AV worker items 基礎結構用於 GIN 待處理清單的清理。

Jürgen Purtz 送出另一個修訂版的修補程式，以在教學課程中新增一個關於架構的章節。

Andres Freund 送出另一個修訂版的修補程式，以將統計資訊收集器的暫存儲存從檔案移至共享記憶體。

Amul Sul 送出另外三個修訂版的修補程式，以實作 ALTER SYSTEM READ {ONLY | WRITE}。

Michaël Paquier 送出另一個修訂版的修補程式，使其可以使用 NSS 作為 libpq TLS 後端。

Vigneshwaran C、Amit Kapila 和 Masahiko Sawada 交換了使用 HTAB 進行複製槽統計資訊的修補程式。

Bruce Momjian 送出兩個修訂版的修補程式，以修復和澄清間隔算術中一些邊緣案例的文件。

Jaime Casanova 送出一個修補程式，以記錄 BRIN 的 autosummarize 參數預設為關閉的事實。

Heikki Linnakangas 送出另一個修訂版的修補程式，以透過強制預先查看來簡化 COPY FROM 的剖析。

Bruce Momjian 送出另一個修訂版的修補程式，以實作金鑰管理。

Amit Langote 送出另外兩個修訂版的修補程式，以允許在跨分割區更新期間批次處理插入。

Bertrand Drouvot 送出另外三個修訂版的修補程式，使其可以在備用伺服器上進行最小的邏輯解碼。

Himanshu Upadhyaya 送出兩個修訂版的修補程式，以修復 PREPARE TRANSACTION 和 TEMP TABLE 之間的不一致。

Thomas Munro 和 Kyotaro HORIGUCHI 交換了修補程式，以從 XLogReadRecord 移除 read_page 回調函數。

Justin Pryzby 送出另外兩個修訂版的修補程式，以使 pg_ls_* 顯示目錄和共享檔案集。

Hou Zhijie、Masahiko Sawada、Amit Langote 和 Shi Yu 交換了修補程式，以插入邏輯複製中的表格參考洩漏。

Fabien COELHO 和 Michaël Paquier 交換了修補程式，以向 psql 新增 SHOW_ALL_RESULTS 選項。

Takamichi Osumi 送出另一個修訂版的修補程式，使其可以停用 WAL 日誌記錄以加速資料載入。

Yugo Nagata 送出另一個修訂版的修補程式，以實作增量檢視維護。

Michael Banck 送出另一個修訂版的修補程式，以新增新的 PGC_ADMINSET GUC 內容、管理員，並新增 pg_change_role_settings 預定義角色。

Pavel Borisov 送出一個修補程式，以確保在頁面初始化期間對頁面標頭和頁面特殊大小對齊進行相同的處理。現在僅檢查兩者是否與斷言正確對齊，而不是靜默地對任何東西進行 MAXALIGNing。呼叫者應將正確的 maxalinged 值提供給頁面初始化函數。

Thomas Munro 送出了一個補丁的另一個修訂版本，用於為 psql 的 \watch 命令添加 PSQL_WATCH_PAGER 設定。

Tom Lane 送出了三個補丁的另一個修訂版本，使 psql \df 可以通過函數的參數來選擇函數。

Vigneshwaran C 送出了一個補丁的另一個修訂版本，以識別在 CREATE/ALTER SUBSCRIPTION 期間，來自發布者的缺失的發布 (publications)。

Ajin Cherian 和 Amit Kapila 交換了補丁，以添加串流傳輸進行中交易的遺漏文件。

Peter Smith 送出了三個補丁的另一個修訂版本，以添加兩階段交易的邏輯解碼。

Thomas Munro 送出了一個補丁的另一個修訂版本，以實作 WAL 預取 (prefetching)。

Thomas Munro 和 Andrey Borodin 交換了補丁，以使所有 SLRU 緩衝區大小可配置。

Andrey V. Lepikhov 送出了一個補丁的另一個修訂版本，以移除 64k rangetable 限制。

Haotian Wu 送出了一個補丁，以在 pg_dump/restore 中添加一個 --drop-cascade 選項。

Bharath Rupireddy 送出了一個補丁，禁止 CREATE SEQUENCE 的 RESTART 選項，因為它只在 ALTER SEQUENCE 的情況下才有意義。

Andres Freund 送出了一個補丁，以修復 InvalidateObsoleteReplicationSlots() 中的競爭條件，並重新移除 SlotAcquireBehavior。

Bharath Rupireddy 送出了三個補丁的修訂版本，以簡化 postgres_fdw 測試中後端終止和等待邏輯。

Justin Pryzby 送出了一個補丁的另一個修訂版本，將 track_activity_query_size 從先前的正確 Resource Usage / Memory 變更為 STATS_COLLECTOR 類別，將 log_autovacuum_min_duration 變更為 LOGGING_WHAT，將 track_commit_timestamp 變更為 REPLICATION_SENDING，並將 force_parallel_mode 變更為 DEVELOPER GUC，並將其從範例配置中移除，以幫助避免使用者找到此選項並更改它，希望這能使他們的查詢更快，但卻沒有閱讀文件或了解它的作用。

Justin Pryzby 送出了一個補丁的另一個修訂版本，以加速 COPY FROM 到具有外部分割區的分割資料表。

Thomas Munro 送出了一個補丁，使用 SIGIO 來檢測 postmaster 終止。

Pavel Borisov 送出了一個補丁，以穩定分割索引的表空間測試。在執行表空間測試時，有時（非常罕見）父資料表和子資料表的順序會發生變化，從而導致測試失敗。

Maxim Orlov 送出了一個補丁的另一個修訂版本，旨在修復一個錯誤，該錯誤表現為大量連接/斷開連接時的 SSL 協商錯誤。

Andrey V. Lepikhov 送出了一個補丁的另一個修訂版本，通過教導優化器考慮非分割資料表與分割資料表的每個分割區的 partitionwise join，使非對稱 partitionwise join 更有效地工作。 此技術會導致對「reparameterize by child」機制的變更。

Michaël Paquier 送出了一個補丁，將表空間路徑重新建立從 makefile 移動到 pg_regress。

Pavel Stěhule 送出了一個補丁的另一個修訂版本，以實作 schema 變數。

Tom Lane 送出了一個補丁，旨在修復一個錯誤，該錯誤表現為類型 (type) 的參考洩漏，方法是完全放棄將長期存在的 tupdesc refcount 與這些表達式節點關聯，而是依賴於 typcache 條目一旦建立就永遠不會消失的事實。

Rémi Lapeyre 送出了三個補丁的另一個修訂版本，以添加標頭支援到 "COPY TO" 文字格式，以及相應的標頭匹配模式到 "COPY FROM"。

Justin Pryzby 送出了一個補丁的另一個修訂版本，以使 ALTER TABLE ... DETACH CONCURRENTLY 避免建立多餘的約束。

Pavel Stěhule 送出了一個補丁的另一個修訂版本，以在 pg_dump/pg_restore 中添加一個 --options-file 選項。

Tom Lane 送出了一個補丁，以使 PGWARNING 和 PGERROR 普遍可用。

Peter Geoghegan 送出了一個補丁，旨在修復一個錯誤，該錯誤表現為 PANIC: 傳遞給 visibilitymap_clear 的緩衝區錯誤，方法是再次在 lazy_vacuum_heap_rel() 中獲取超獨佔鎖。

Ranier Vilela 送出了一個補丁，以修復 src/backend/statistics/extended_stats.c 中未初始化的純量變數。