PostgreSQL 每週新聞 - 2021 年 1 月 17 日

由 PWN 於 2021-01-18 發布
PWN

PostgreSQL 每週新聞 - 2021 年 1 月 17 日

本週人物:https://postgresql.life/post/gunnar_bluth/

PostgreSQL 產品新聞

pspg 4.0.0 發布,一個專為 PostgreSQL 設計的分頁器。https://github.com/okbob/pspg/releases/tag/4.0.0

DBConvert Studio 2.0 發布,一個支援 PostgreSQL 的資料庫遷移和同步套件。https://dbconvert.com/dbconvert-studio

一月份的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已套用的修補程式

Thomas Munro 推送了

Tom Lane 推送了

  • 在 libpq 中,始終將新的錯誤訊息附加到 conn->errorMessage。先前,我們在 libpq 內使用 printfPQExpBuffer 和 appendPQExpBuffer 呼叫來報告錯誤,方式混亂且缺乏規範。此 commit 建立了一個統一的規則,應使用 appendPQExpBuffer[Str]。conn->errorMessage 僅在應用程式請求開始時重置,然後累積訊息直到完成。我們可以刪除至少三種不同的 ad-hoc 機制,這些機制用於在操作序列中實現錯誤訊息的串聯效果。雖然這在概念上使事情變得更加清晰,但這樣做的主要原因是為了使添加到一段時間之前的多目標主機功能更加安全。先前,在個別主機連線嘗試期間發生的錯誤會清除先前嘗試期間發生的事件記錄,這種情況很多。(報告仍然不足,因為很難判斷哪個主機發生了故障,但這似乎是另一個 commit 的問題。)目前,lo_import 和 lo_export 包含「永遠不要使用 printfPQExpBuffer」規則的例外情況。如果我們更改它們,我們可能會在實際的讀取或寫入失敗之前報告偶然的 lo_close 失敗,這會令人困惑,尤其是在主要失敗之後發生 lo_close 的情況下。我們可以透過發明一個不重置 errorMessage 的內部版本 lo_close 來改進這一點;但我們也需要一個這樣做的 PQfn() 版本,而且現在似乎不值得這麼麻煩。討論:https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com https://git.postgresql.org/pg/commitdiff/ffa2e4670123124b92f037d335a1e844c3782d3f

  • 允許 pg_regress.c 包裝器後處理測試結果檔案。向 regression_main() 添加一個可選的回調,如果提供,則在我們嘗試將其與預期結果檔案進行比較之前,會在每個測試輸出檔案上調用它。main 和 isolation 測試程式不需要這個(尚未)。在 pg_regress_ecpg 中,添加一個過濾器,從「無法連線」錯誤報告中消除目標主機詳細資訊。截至此 commit,此過濾器不執行任何操作,但下一個過濾器將需要它。從長遠來看,我們可能想要為測試輸出提供一些更通用、可能基於模式的過濾機制。現在,這將解決迫在眉睫的問題。討論:https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com https://git.postgresql.org/pg/commitdiff/800d93f314b0f7c10193e48b259f87800cb85d84

  • 在 libpq 連線失敗報告中,統一識別目標主機。在 socket() 呼叫之後發生的所有連線失敗案例中,加上 "could not connect to host-or-socket-path:" 前綴,並移除附加在某些訊息上的特定伺服器識別資料。這應該能在多目標主機的情況下產生更容易理解的錯誤報告,尤其是對於任何程度的非典型錯誤案例(因為這些案例都沒有提供伺服器識別資訊)。例如,變更前,使用錯誤連接埠號碼(例如 "psql -p 12345 -h localhost,/tmp")進行連線嘗試可能會產生以下訊息: psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 12345? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 12345? could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.12345"? 現在看起來會是這樣:psql: error: could not connect to host "localhost" (::1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to host "localhost" (127.0.0.1), port 12345: Connection refused Is the server running on that host and accepting TCP/IP connections? could not connect to socket "/tmp/.s.PGSQL.12345": No such file or directory Is the server running locally and accepting connections on that socket? 這需要調整幾個回歸測試,以允許連線失敗訊息內容的變化。討論:https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com https://git.postgresql.org/pg/commitdiff/52a10224e3cc1d706ba9800695f97cb163b747d5

  • 在 "cannot connect now" 失敗後嘗試下一個主機。如果伺服器回傳 ERRCODE_CANNOT_CONNECT_NOW,則嘗試下一個主機(如果提供了多個主機名稱)。這允許優雅地處理可能尚未處於熱備援模式的備用伺服器。在前一個提交之後,重試比現在更多的錯誤案例可能是可行的,但我 (tgl) 對於過於積極地採取行動感到猶豫 --- 例如,對於錯誤密碼的情況,不清楚這是否是理想的。但這種情況似乎足夠安全。Hubert Zhang,由 Takayuki Tsunakawa 審閱。討論:https://postgr.es/m/BN6PR05MB3492948E4FD76C156E747E8BC9160@BN6PR05MB3492.namprd05.prod.outlook.com https://git.postgresql.org/pg/commitdiff/c1d589571c497a952d7fbe40d9828655859d746f

  • 重新思考 ERRCODE_IDLE_SESSION_TIMEOUT 的 SQLSTATE 代碼。將其移動到 57 類(Operator Intervention),從客戶端的角度來看,它看起來更像例如 ERRCODE_ADMIN_SHUTDOWN。如果沒有歷史包袱,我也會將 ERRCODE_IDLE_IN_TRANSACTION_SESSION_TIMEOUT 放在這裡。但它已經存在好幾年了,現在更改其 SQLSTATE 代碼可能太晚了。討論:https://postgr.es/m/763A0689-F189-459E-946F-F0EC4458980B@hotmail.com https://git.postgresql.org/pg/commitdiff/4edf96846a02693e4416478b3302e5133d2e8e01

  • 使 pg_dump 的物件類型優先順序表更易於維護。歷史上,將新的物件類型塞入此表中需要手動重新編號許多現有條目。(雖然看起來有些人偷懶,重複使用了現有物件類型的優先順序,即使它沒有特別相關。)我們可以讓編譯器通過發明一個枚舉類型來完成計數,該枚舉類型按順序枚舉所需的優先順序級別。現在,如果您想添加或刪除優先順序級別,這只需一行程式碼即可完成。這個修補程式並非純粹的美化,因為我分開了 DO_COLLATION 和 DO_TRANSFORM 的優先順序,以及 DO_ACCESS_METHOD 和 DO_OPERATOR 的優先順序,在我看來,這些優先順序是被權宜之計合併在一起,而不是因為這是個好主意。 Shell 類型繼續與完整類型互換排序,opclass 與 opfamily 互換排序。https://git.postgresql.org/pg/commitdiff/d5ab79d815783fe60062cefc423b54e82fbb92ff

  • 將 ALTER TABLE ... ATTACH PARTITION 傾印為單獨的 ArchiveEntry。先前,我們將 ATTACH PARTITION 指令作為子表格的 ArchiveEntry 的一部分發出。這是一個糟糕的選擇,因為它使將分割區恢復為獨立表格變得複雜;您必須忽略來自 ATTACH 的錯誤,當使用 pg_restore 直接恢復到資料庫時,這甚至不是一個選項。(pg_restore 將把整個 ArchiveEntry 作為一個 PQexec 發出,因此任何錯誤都會回滾表格的建立。)因此,將它作為自己的 ArchiveEntry 分離出來,就像我們對索引 ATTACH PARTITION 指令所做的那樣。Justin Pryzby 討論:https://postgr.es/m/20201023052940.GE9241@telsasoft.com https://git.postgresql.org/pg/commitdiff/9a4c0e36fbd671b5e7426a5a0670bdd7ba2714a0

  • 文件:修正 ALTER PUBLICATION 所需權限的描述。將表格添加到發布需要擁有該表格的所有權(除了擁有該發布的所有權之外)。這在任何地方都沒有提到。https://git.postgresql.org/pg/commitdiff/cc865c0f319fde22540625e02863f42e9853b3e4

  • pg_dump:使用擁有者標記 INDEX ATTACH ArchiveEntries。雖然分割索引對其父項的附加沒有單獨的所有權,但無論如何都需要使用擁有者標記其 ArchiveEntry,以確保在使用 --use-set-session-authorization 恢復時,ALTER 指令由適當的角色運行。如果沒有這個,ALTER 將由啟動恢復會話的角色運行,這通常會起作用,但形式上是錯誤的。Back-patch 到 v11,此類型的 ArchiveEntry 在那裡被添加。在 HEAD 中,將等效的評論添加到剛剛添加的 TABLE ATTACH 案例中,我已經使其正確執行。討論:https://postgr.es/m/1094034.1610418498@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9eabfe300a22ad3d776dc293265e15379790bd9a

  • 文件:闡明 pg_dump 中 back-half 選項的行為。當傾印到封存格式時,更改如何將封存資料轉換為 SQL 文字的選項會被忽略。先前的文件說 "not meaningful",這沒有幫助。討論:https://postgr.es/m/161052021249.12228.9598689907884726185@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/06ed235adeb621a73cafd6ab35fa2405b3177329

  • 禁止在 pgbench 中使用數字作為變數名稱的第一個字元。 此限制的目的是為了避免嘗試將變數代入時間戳記的字面值,因為這些字面值可能包含類似 '12:34' 的字串。 為了減少 pgbench 不應進行替換的傾向,還有很多事情要做。 但這足以解決 Jaime Soler 反映的問題,而且也很容易回溯修補。 回溯修補至 v11;在 commit 9d36a3866 之前,pgbench 對於變數名稱的定義略有不同,而且無論如何,為了這個問題而變更長期穩定的分支似乎並不智。 Fabien Coelho 討論:https://postgr.es/m/alpine.DEB.2.22.394.2006291740420.805678@pseudo https://git.postgresql.org/pg/commitdiff/c21ea4d53e9404279273da800daa49b7b9a5e81e

  • 文件,或多或少:取消註解很久以前已修復的教學範例。 還原 commit 344190b7e 的一部分。 顯然,在 20 世紀,我們在多語句 SQL 函數方面遇到了一些問題,但它們已經正常工作了很長時間。 Daniel Westermann 討論:https://postgr.es/m/GVAP278MB04242DCBF5E31F528D53FA18D2A90@GVAP278MB0424.CHEP278.PROD.OUTLOOK.COM https://git.postgresql.org/pg/commitdiff/dce62490818170b6479dfe08a28aae4bcdf7cc2d

  • 執行 reformat-dat-files 以整理目錄資料檔案。 顯然,這裡的情況變得相當混亂,大部分(但並非全部)是 multirange 補丁的錯。 沒有功能上的變更。 https://git.postgresql.org/pg/commitdiff/8b411b8ff41566a1aa601d1f05aeebbebbdb4a54

  • 將 inet_server_addr() 和 inet_server_port() 標記為平行限制 (parallel-restricted)。 這些需要 PR,因為它們存取 MyProcPort 資料結構,該結構不會複製到平行工作程序。 非常相似的函數 inet_client_addr() 和 inet_client_port() 已經被標記為 PR,但有人遺漏了這兩個函數。 雖然這是一個已存在的錯誤,但我們無法輕易地在回溯分支中修復它,因為我們無法強制 initdb。 考慮到這兩個函數的使用率很小,而且它們被推送到平行工作程序的可能性更小,建議 DBA 手動修復似乎不值得。 Masahiko Sawada 討論:https://postgr.es/m/CAD21AoAT4aHP0Uxq91qpD7NL009tnUYQe-b14R3MnSVOjtE71g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5a6f9bce8dabd371bdb4e3db5dda436f7f0a680f

  • pg_dump:使用擁有者標記 PUBLICATION TABLE ArchiveEntries。 這與應用於 INDEX ATTACH 條目的 commit 9eabfe300 的修復程式相同,但適用於表到發布的附件。 在這種情況下,即使後端沒有記錄附件的「擁有權」,我們仍然應該在轉儲封存中標記應執行 ALTER PUBLICATION 指令的角色名稱。 現有的行為會導致 ALTER 由啟動還原的原始角色完成; 這通常可以正常工作,但可能存在失敗的邊角案例。 補丁的大部分內容都與變更 struct PublicationRelInfo 以包含指向關聯的 PublicationInfo 物件的指標有關,以便我們可以在適當的時候從中取得擁有者的名稱。 同時,我重寫了 getPublicationTables(),使其只查詢一次 pg_publication_rel,而不是每個表查詢一次。 回溯修補至引入此程式碼的 v10。 討論:https://postgr.es/m/1165710.1610473242@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8e396a773b80c72e5d5a0ca9755dffe043c97a05

  • 改進我們在 macOS 上選擇 PG_SYSROOT 的啟發式方法。 如果 Xcode 比底層 macOS 版本新,則向 xcodebuild 詢問 SDK 路徑會產生指向 Xcode 附帶的 SDK 的指標,這最終可能會建置無法在底層 macOS 版本上運作的程式碼。 似乎在這種情況下,xcodebuild 的答案也無法與 Apple 編譯器的預設行為相符:假設已安裝 Xcode 的「命令列工具」,則在 /Library/Developer/CommandLineTools 中將有一個適用於 OS 自身版本的 SDK,並且編譯器預設會使用該 SDK。 這些都沒有很好的文檔說明,但實驗表明,「xcrun --show-sdk-path」給出了編譯器實際使用的 sysroot 路徑,至少在某些情況下是這樣。 因此,首先嘗試這種方法,但如果 xcrun 失敗,則還原為 xcodebuild(在非常舊的 Xcode 中,它遺失或缺少 --show-sdk-path 參數)。 此外,「xcrun --show-sdk-path」可能會提供一個有效但缺少任何 OS 版本識別碼的路徑。 我們真的不想要這樣,因為將 -isysroot 連接到建置標誌中的大部分動機都是為了確保 PG 安裝的所有部分都是針對相同的 SDK 建置的,即使考慮到稍後和/或在不同的機器上建置的擴充功能也是如此。 在接受結果之前,堅持在目錄名稱中找到 "N.N"。 (在 xcrun 呼叫中新增 "--sdk macosx" 似乎會產生與 xcodebuild 相同的答案,但通常會更快,因為它已被快取,因此我們也嘗試將其作為後備。) 在這種情況下,我們不想使用 Xcode 的預設 SDK 的核心原因是 Apple 用於引入新 syscall 的技術與 Autoconf 不相容:例如,configure 會認為在使用 Big Sur SDK 時存在 preadv/pwritev,即使在較舊的 macOS 版本上建置它們時也是如此。 如果能更好地解決該問題就好了,但此修補程式並未嘗試修復該問題。 根據 Sergey Shinderuk 的報告。 回溯修補至所有支援的版本。 討論:https://postgr.es/m/ed3b8e5d-0da8-6ebd-fd1c-e0ac80a4b204@postgrespro.ru https://git.postgresql.org/pg/commitdiff/4823621db312a0597c40686c4c94d47428889fef

  • 將遺失的陣列擴充邏輯新增至 test_regex.c。 報告「部分」匹配的節可能超出最初分配的輸出陣列,因此它需要自己的陣列調整大小邏輯副本,該邏輯位於主迴圈中。 我在 ca8217c10 中忽略了對此的需求。 根據 Alexander Lakhin 的報告。 討論:https://postgr.es/m/3206aace-50db-e02a-bbea-76d5cdaa2cb6@gmail.com https://git.postgresql.org/pg/commitdiff/0c7d3bb99f72d66ec6ac63aee4c5fe6d683eee86

Amit Kapila 推送

Álvaro Herrera 推送了

Michaël Paquier 推送

Heikki Linnakangas 推送

Magnus Hagander 推送

Fujii Masao 推送

Peter Geoghegan 推送

  • 傳遞「邏輯上未更改的索引」提示。新增一個 executor aminsert() 提示機制,通知索引 AM,傳入的索引元組(伴隨提示的元組)不是透過執行邏輯上修改任何索引鍵欄位的 SQL 語句來插入的。當 UPDATE 發生時,索引會收到提示,但前提是 UPDATE 沒有應用像 heapam 的 HOT 這樣的最佳化(但僅適用於所有索引鍵欄位在邏輯上未更改的索引)。預計在插入時收到提示的任何索引元組都至少是邏輯列所需的至少一個現有舊版本的副本。相關版本通常會儲存在同一個索引頁面上,至少在應用提示的索引 AM 內。在索引 AM 層級識別 MVCC 版本變動副本和真實邏輯列副本之間的差異,可以幫助清理垃圾索引元組。清理可以智慧地鎖定可能為垃圾的元組,而不會在不太有希望的元組/頁面上浪費太多週期(版本變動很少或沒有的索引頁面)。這是即將到來的 commit 的基礎架構,該 commit 將教導 nbtree 執行自下而上的索引刪除。目前沒有索引 AM 實際應用提示。作者:Peter Geoghegan pg@bowt.ie 審閱人:Victor Yegorov vyegorov@gmail.com 討論:https://postgr.es/m/CAH2-Wz=CEKFa74EScx_hFVshCOn6AA5T-ajFASTdzipdkLTNQQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9dc718bdf2b1a574481a45624d42b674332e2903

  • 強化 nbtree 索引元組刪除功能。教導 nbtree 和 heapam 協同合作,以便積極移除代表已失效 MVCC 版本的重複元組。這稱為「由下而上的刪除」。每個由下而上的刪除過程,都是在 nbtree 葉節點頁面上的版本氾濫時,以延遲的方式觸發。這通常涉及「邏輯上未變更的索引」提示(這些提示是由 commit 9dc718bd 添加的執行器機制所產生的)。由下而上的索引刪除的直接目標是避免完全由版本重複導致的「不必要的」頁面分割。然而,它自然地具有更有效的作用:它可以作為一個後盾,防止針對任何給定的邏輯列累積過多的索引元組版本。由下而上的索引刪除,補充了我們現在可能稱之為「由上而下的索引刪除」的功能:由 VACUUM 執行的索引清理。由下而上的索引刪除,回應了查詢的直接本地需求,同時將對索引執行不頻繁的全面清理的工作,留給 autovacuum 處理。總體效果是避免與 UPDATE 產生的「版本變動」相關的某些病態效能問題。先前由索引 AM 用於執行元組刪除的 tableam 介面(`table_compute_xid_horizon_for_tuples()` 函數),已被一個新的介面取代,該介面支援某些新的需求。此 commit 添加到 nbtree 的許多(也許是全部)功能,也可以擴展到其他索引 AM。這將留待以後的 commit 處理。透過添加邏輯來考慮額外的索引元組(未標記為 LP_DEAD),來擴展 nbtree 中 LP_DEAD 標記的索引元組的刪除。在許多情況下,這會顯著增加刪除的索引元組數量。LP_DEAD 刪除過程(現在稱為「簡單刪除」,以便清楚地區分它與由下而上的刪除)通常不需要訪問任何額外的資料表區塊來檢查這些額外的元組。無論如何,我們必須訪問相同的資料表區塊,以產生 latestRemovedXid 值(至少在索引刪除操作的 WAL 記錄需要此值的情況下)。測試表明,「額外元組」簡單刪除增強功能,幾乎可以增加任何在葉節點頁面中設置了 LP_DEAD 位的 workload 所刪除的索引元組數量。也就是說,它幾乎從未無法刪除至少幾個額外的索引元組。在自然地擁有大量可安全刪除的元組的情況下,它最有幫助。單個刪除操作最終刪除的索引元組數量,與舊的簡單方法相比,高出一個數量級的情況並不罕見(例如,patch 的自定義儀器顯示,在運行迴歸測試時,這種情況經常發生)。添加另一個增強功能,以增強使用重複資料刪除的索引中的簡單刪除和由下而上的刪除:教導 nbtree 的 `bt_delitems_delete()` 函數支援在 posting list 元組中進行細粒度的 TID 刪除。現在可以從 posting list 元組中刪除單個 TID,前提是這些 TID 具有作為刪除過程的一部分訪問的資料表區塊的 tableam 區塊編號(可以直接或間接地觸發訪問資料表區塊)。設置 posting list 元組的 LP_DEAD 位仍然是一件全有或全無的事情,但現在刪除只需要從關於哪些索引元組可刪除的正確一般概念開始,這就顯得不那麼重要了。由於 xl_btree_delete 已更改,因此增加了 XLOG_PAGE_MAGIC。BTREE_VERSION 沒有增加,因為 nbtree 索引的磁碟上表示形式沒有任何變更。在 pg_upgrade 之後,基於 PostgreSQL 12 或 PostgreSQL 13 構建的索引將自動受益於由下而上的索引刪除(即,不需要重新建立索引)。無論用戶從哪個 PostgreSQL 版本升級,「簡單刪除」的增強功能都適用於所有 B-Tree 索引。作者:Peter Geoghegan pg@bowt.ie 審閱者:Heikki Linnakangas hlinnaka@iki.fi 審閱者:Victor Yegorov vyegorov@gmail.com 討論:https://postgr.es/m/CAH2-Wzm+maE3apHB8NOtmM=p-DO65j2V5GzAWCOEEuy3JZgb2g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/d168b666823b6e0bcf60ed19ce24fb5fb91b8ccf

Tomáš Vondra 推送

Noah Misch 推送

  • 修正 pg_dump 關於初始權限中 GRANT OPTION 的問題。情境是物件不再擁有最初擁有的某些 aclitem。(使用者針對物件發出了 REVOKE 或 GRANT 語句。)pg_dump 正在形成 SQL 以重現物件 ACL。由於 initdb 不會建立帶有 GRANT OPTION 的 ACL,因此要遇到此錯誤,需要一個擴充,其建立腳本會建立這樣的 ACL。沒有 PGXN 擴充會這樣做。如果安裝遇到了此錯誤,pg_dump 將省略分號,導致 REVOKE 和下一個 SQL 語句失敗。另外,由於受影響的程式碼存在於消除整個 aclitem,因此它需要普通的 REVOKE,而不是 REVOKE GRANT OPTION FOR。回溯到 9.6,commit 23f34fa4ba358671adab16773e79c17c92cbc870 首次出現。討論:https://postgr.es/m/20210109102423.GA160022@rfd.leadboat.com https://git.postgresql.org/pg/commitdiff/f713ff7c646e5912e08089de74dacdfaaac3d03b

  • 防止過度的 SimpleLruTruncate() 刪除。每個核心 SLRU 都會環繞。除了 pg_notify 之外,環繞點可能會落在頁面的中間。在 PagePrecedes 回呼規格以及 SimpleLruTruncate() 對該回呼的使用中,考慮到這一點。更新每個回呼實作以符合新的規格。這將 SerialPagePrecedesLogically() 從 asyncQueuePagePrecedes() 的樣式更改為 CLOGPagePrecedes() 的樣式。(雖然 pg_clog 和 pg_serial 共用一個鍵空間,但 pg_serial 與 pg_notify 完全不同。)此處修正的錯誤具有與 592a589a04bd456410b853d86bd05faa9432cbbb 相同的症狀和使用者後續步驟。回溯到 9.5(所有支援的版本)。由 Andrey Borodin 和(在早期版本中)由 Tom Lane 審閱。討論:https://postgr.es/m/20190202083822.GC32531@gust.leadboat.com https://git.postgresql.org/pg/commitdiff/6db992833c04c0322f7f34a486adece01651f929

Jeff Davis 推送

待處理的 Patch

Andrey V. Lepikhov 發送了另一個修訂版本的 patch,以移除在安全的情況下不必要的自我聯結。

Tom Lane 提交了一個修補程式,旨在修復在非熱備援模式下,連接字串中多個主機無法故障轉移的錯誤,方法是修正一些用於連接的重試和錯誤邏輯。

David Fetter 提交了另一個修補程式版本,將 popcount 引入 SQL。

Andrey V. Lepikhov 提交了另一個修補程式版本,將批次插入介面新增到 FDW API,並在 PostgreSQL FDW 中使用相同介面。這應該能加速大量載入到具有外部分割區的資料表。

Masahiko Sawada 和 Bharath Rupireddy 交換了修補程式,以避免在 conversion_error_callback 中存取目錄。

Konstantin Knizhnik 和 Tomáš Vondra 交換了修補程式,以實作 libpq 的壓縮。

Ian Barwick 和 Greg Sabino Mullane 交換了修補程式,透過包含函式的引數資料類型來幫助 psql 自動完成函式。

Mark Dilger 提交了另一個修補程式版本,新增 contrib 模組 pg_amcheck,這是一個命令列介面,用於針對資料表和索引執行 amcheck 的驗證。

Bharath Rupireddy 提交了兩個修補程式版本,使其可以在 CTAS 中使用平行插入。

Anastasia Lubennikova 提交了兩個修補程式版本,以在 COPY FREEZE 中設定 PD_ALL_VISIBLE 和可見性圖位元。

Masahiko Sawada 提交了一個修補程式,以實作緩衝區加密,以確保 KMS 修補程式可以使用 kmgr 管理的加密金鑰與其他組件一起運作。

Simon Riggs 提交了另一個修補程式版本,以實作系統版本的時間資料表。

Ian Barwick 提交了一個修補程式,修復了使用 attnums 和不存在的資料行的 has_column_privilege() 函式,方法是確認資料行的存在,即使使用者具有資料表層級的權限,否則如果提供了無效的 attnum,該函式會很高興地報告使用者擁有已刪除或不存在的資料行的權限。

Yugo Nagata 提交了另一個修補程式版本,以實作增量視觀表維護。

Atsushi Torikoshi 提交了另一個修補程式版本,將計劃類型(一般或自訂)新增到 pg_stat_statements。

Peter Smith 提交了兩個修補程式版本,使其可以將背景工作者用於 tablesync。

Kyotaro HORIGUCHI 提交了兩個修補程式版本,使其可以在不進行堆積重寫的情況下更改資料表的持久性(LOGGED/UNLOGGED)。

Atsushi Torikoshi 提交了另一個修補程式版本,使其可以透過新函式 pg_get_target_backend_memory_contexts() 收集指定程序的記憶體上下文。

John Naylor 提交了一個修補程式,以移除對現在已移除的 replication_timeout GUC 的參照。

Hou Zhijie 提交了兩個修補程式版本,為 eval_const_expressions_mutator 新增了 Nullif 案例。

Justin Pryzby 提交了另一個 pg_upgrade 的修補程式版本,以新增測試來執行二進位相容性。

Álvaro Herrera 提交了另一個修補程式版本,在 REINDEX CONCURRENTLY 期間設定 PROC_IN_SAFE_IC。

Tomáš Vondra 提交了四個修補程式版本,為外部資料表新增批次插入。

Li Japin 和 Bharath Rupireddy 交換了修補程式,以修復 ALTER PUBLICATION...DROP TABLE 的行為,方法是安排當 rel_sync_cache_publication_cb() 中的項目失效時,將 pubactions 標記為 false,並讓 get_rel_sync_entry() 重新計算 pubactions。

Takamichi Osumi 提交了三個修補程式版本,新增了一個新的 wal_level 以停用 WAL 記錄,該設計旨在使大量載入更快,但如果中途失敗,則會留下無法恢復的叢集。

Bruce Momjian 提交了三個修補程式版本,以實作金鑰管理。

DRU 提交了三個修補程式版本,以新增有關資料頁面校驗和的文件,並支援在正在運行的叢集中啟用/停用校驗和。

Heikki Linnakangas 和 Andrey Borodin 交換了修補程式,以新增函式到 'pageinspect' 以檢查 GiST 索引。

Dilip Kumar 提交了另一個修補程式版本,以支援資料表的自訂壓縮方法。

Yuzuko Hosoya 提交了一個修補程式,使其可以使用 DISCARD ALL 釋放參考完整性的 SPI 計劃,這將減少在具有多個分割區的資料表上建立或使用外部鍵時使用的記憶體量。

Stephen Frost 提交了一個修補程式,引入了一個已過時的附錄,將舊術語連結到新文件。

Stephen Frost 提交了另一個修補程式版本,使用預先提取來進行 ANALYZE,並使自動分析記錄的詳細資料與自動清理的詳細資料一致。

Michaël Paquier 和 Aleksey Kondratov 交換了修補程式,以重構實用程式陳述式選項。

Peter Eisentraut 提交了另一個 pageinspect 的修補程式版本,該修補程式將區塊編號引數更改為 bigint,以避免可能的溢位。

Tomáš Vondra 提交了三個修補程式版本,以實作 BRIN 多範圍索引。

Heikki Linnakangas 提交了兩個修補程式版本,移動了一些 ResourceOwnerEnlarge() 呼叫,以確保安全和清晰,並透過使用單一陣列和雜湊,而不是每個物件類型一個陣列和雜湊,使 resowners 更容易擴展。

Kyotaro HORIGUCHI 提交了一個修補程式,修復了一些 RelationNeedsWAL 的誤用。

Dilip Kumar 提交了另一個修補程式版本,以確保 pg_is_wal_replay_paused 等待恢復暫停。

Kyotaro HORIGUCHI 提交了另一個修補程式版本,將統計資訊收集器的臨時儲存從檔案移動到共享記憶體。

Kyotaro HORIGUCHI 提交了另一個修補程式版本,透過新增 CatCache 過期功能來保護 syscache 免受負面快取項目膨脹的影響。

Pavel Stěhule 提交了另一個修補程式版本,以實作結構描述變數。

Li Japin 提交了一個修補程式,修復了 WalSndPrepareWrite 上註解中的拼字錯誤。

Simon Riggs 提交了一個修補程式,使其可以在不驗證索引的情況下更改索引的唯一性,並提供了一種單獨進行驗證的方法。

Takayuki Tsunakawa 提交了一個修補程式,透過將一些不正確的 += 賦值更改為 = 來修復 shmem TOC 的大小計算。

Peter Geoghegan 提交了一個修補程式,將 vacuum_cost_page_miss 的預設值降低到 3。

Ian Barwick 提交了另一個修補程式版本,將鎖定取得等待開始時間新增到 pg_lock_status 函式。

Andy Fan 提交了一個修補程式,使 cost_sort 更準確。

Masahiko Sawada 提交了另一個修補程式版本,使其可以執行涉及多個 postgres 外部伺服器的交易。

Fujii Masao 和 Bharath Rupireddy 交換了修補程式,新增了一個 postgres_fdw 函式來丟棄快取的連線,以及一個 postgres_fdw 特定的和一個系統範圍的 GUC,keep_connections。

Hou Zhijie 提交了一個修補程式,以移除 reorderbuffer.c 中遺留的撇號。

Álvaro Herrera 提交了一個修補程式,讓 VACUUM 在計算要移除的元組的 Xid horizon 時,忽略執行 CIC 和 RC 的程序。

Álvaro Herrera 提交了一個修補程式,以增加 pg_commit_ts 緩衝區的大小。

David Zhang 提交了一個修補程式,以更新資料表空間文件,使其與 pgbench 的新資料表存取方法選項保持一致。

Iwata Aya 提交了 libpq 追蹤功能的另一個修訂版本。

Tomáš Vondra 提交了涵蓋擴展統計資訊的表達式的另兩個修訂版本。

Tom Lane 提交了一個修補程式,以修正 pull_varnos() 中的錯誤計算。

Thomas Munro 提交了另一個修訂版本,使 pgbench 可以在連線建立後延遲查詢。