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

PostgreSQL 每週新聞 - 2021 年 6 月 27 日

發布於 2021-06-28，作者：PWN
PWN

PostgreSQL 每週新聞 - 2021 年 6 月 27 日

PostgreSQL 14 Beta 2 已發布。測試！

第 12 屆古巴 PostgreSQL 會議 (PostgresqlCUBA, @PgCuba) 將於 2021 年 11 月 18 日至 19 日在 Habana Libre 飯店舉行。此活動是 TECNOGET 會議的一部分，我們將舉辦一個專門討論 PostgreSQL 相關主題的軌道。如需更多詳細資訊，請聯絡 cu AT postgresql DOT org。

PostgreSQL 產品新聞

JDBC 42.2.22 已發布

pgpoolAdmin 4.2.0，Pgpool-II 的管理工具，已發布。

pgCenter 0.9.0，用於觀察和疑難排解 PostgreSQL 的命令列管理工具，已發布

六月的 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已應用修補程式

Tom Lane 推送

  • 解決較新版本 mktime() 的可攜性問題。 最近的 glibc 版本在 tm_isdst 與現行時區不一致時，會導致 mktime() 失敗； 特別是當區域為 UTC 時，tm_isdst = 1 會失敗。 （這似乎與 POSIX 規定的對 struct tm 其他欄位“不正確”值的處理方式非常不一致，所以如果你問我，這是一個錯誤，但我敢打賭他們會說這是故意的。） 已經觀察到這會導致在 pg_restore 從不同時區建立的封存檔時出現表面問題。 為了修復，請使用封存檔中的欄位值執行 mktime()，如果失敗，請使用 tm_isdst = -1 再次嘗試。 這將給出一個與原始時區的 UTC 偏移差異不同的結果，但之前也是如此。 這並不是很重要，因為我們除了可能列印它之外，沒有對結果做任何事情。 （有一天我們應該刷新所有這些邏輯，並在封存檔中記錄標準格式的時間戳記。但這對於向後移植的錯誤修復來說是不可以的。） 此外，保護我們對 mktime() 的唯一另一個使用，讓 initdb 的 build_time_t() 設定 tm_isdst = -1 而不是 0。 這種情況只會在全年都是 DST 的區域中出現問題； 但我認為有些確實存在，或者將來可能會存在。 根據 Wells Oliver 的報告。 向後移植到所有受支援的版本，因為它們中的任何一個都可能需要使用較新的 glibc 執行。 討論：https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f807e3410fdfc29ced6590c7c2afa76637e001ad

  • 移除孤立的預期結果檔案。 這應該已在 43e084197 中刪除，該檔案刪除了對應的規格檔案。 在使用 isolationtester 時注意到。 https://git.postgresql.org/pg/commitdiff/ffbe9dec13599fa786ea6567df1c6a3f3ee3c673

  • 更新變體預期結果檔案。 這應該已在 d2d8a229b 中更新，但被忽略了。 根據新增它的 31a877f18，此檔案旨在顯示在 default_transaction_isolation = serializable 下獲得的結果。 我們在其他隔離測試中基本上已經忘記了這個目標，但只要我們有這個，它應該是正確的。 在使用 isolationtester 時注意到。 https://git.postgresql.org/pg/commitdiff/0a1e80c5c4f094087257fc4284a87e0bc7bca591

  • 移除另一個孤立的預期結果檔案。 當新增 aborted-keyrevoke_2.out 時（在 commit 0ac5ad513 中），顯然需要處理序列化交易模式的情況。 然而，序列化模式的輸出實際上與常規的 aborted-keyrevoke.out 檔案相符，並且 AFAICT 已經這樣做了很長時間。 沒有必要繼續拖累這個變體。 https://git.postgresql.org/pg/commitdiff/f6352a0d4e437ac8bc266f77df22d064592056c9

  • 更新另一個變體預期結果檔案。 這應該已在 533e9c6b0 中更新，但被忽略了。 鑑於沒有任何投訴，我不會費心進行向後移植。 https://git.postgresql.org/pg/commitdiff/d3c878499c9d639ff06e0664d06b8c731e30c2fc

  • 改善某些與複製相關程式碼中的 SQLSTATE 報告。 我最初的目標是在 walrcv_connect() 失敗時報告 ERRCODE_CONNECTION_FAILURE，但當我四處查看時，我意識到編寫此程式碼的人認為錯誤代碼是完全可選的。 這不是我對我們專案政策的理解。 因此，請確保在每個 ereport 中提供錯誤代碼，其中 (a) 為 ERROR 或更高等級，且 (b) 不能說是內部邏輯錯誤。 此外，修正一些非常可疑的現有錯誤代碼分配。 雖然這不符合政策，但它在很大程度上也是表面上的，因為很少有這些情況可以報告給應用程式。 因此，我認為沒有必要進行向後移植。 討論：https://postgr.es/m/2189704.1623512522@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6b787d9e32005867ee3660d1ea20f447810a403d

  • 修正 ExecuteQuery 中錯誤後的 plancache 引用計數洩漏。 當將 plancache 中的計畫塞入入口網站時，不應該冒在 GetCachedPlan 和 PortalDefineQuery 之間拋出錯誤的風險； 如果發生這種情況，GetCachedPlan 遞增的計畫引用計數將會洩漏。 我在 9dbf2b7d7 中重構程式碼時設法打破了這個規則。 除了某些記憶體洩漏之外，沒有明顯的後果，而且由於沒有人很可能連續多次觸發相關的錯誤條件，因此我們沒有注意到這點也不足為奇。 儘管如此，這是一個錯誤，因此重新排列操作順序以消除危險。 在尋找錯誤 #17053 的更好修復方法時注意到。 這個錯誤相當舊，因此向後移植到所有受支援的分支。 https://git.postgresql.org/pg/commitdiff/131ea3e908d3c97a2fe1ab25cce5046dd5cb905f

  • 集中保護複製工具陳述式（utility statements）的邏輯。在「簡單查詢（simple Query）」程式碼路徑中，對於剖析分析（parse analysis）或執行工具陳述式而言，修改陳述式的節點樹是可以的，因為之後會將其丟棄。然而，如果節點樹位於計畫快取（plan cache）中，則情況並非如此，因為這樣會損壞後續的執行。到目前為止，我們透過讓個別的工具陳述式函式在要修改樹時應用 copyObject() 來處理這個問題。但這很容易出現遺漏錯誤。Charles Samborski 提出的錯誤 #17053 顯示 CREATE/ALTER DOMAIN 沒有收到這個備忘錄，並且如果從計畫快取重複執行，可能會崩潰。在後端分支中，我們將僅對此應用一個狹窄的權宜之計，但在 HEAD 中，更具原則性的修復似乎更為謹慎，這將消除未來其他類似錯誤的可能性。因此，讓我們將 copyObject 的責任從其子項提升到 ProcessUtility 中，從而確保所有工具陳述式類型都會發生這種情況。此外，修改 ProcessUtility 的 API，以便其呼叫者可以告知它是否需要複製步驟。事實證明，在所有情況下，直接呼叫者都知道節點樹是否為暫時性的，因此這不會涉及大量的程式碼修改。透過這種方式，雖然我們在從快取執行的程式碼路徑中會損失一點點，因為有時會複製無論如何都不會變異的節點樹，但我們在簡單查詢程式碼路徑中會獲得一些好處，因為不會複製可拋棄的節點樹。複雜到難以複製的陳述式幾乎可以肯定是要被複製的陳述式，因此快取程式碼路徑中的損失應該不大。（請注意，整個問題僅適用於工具陳述式。可最佳化的陳述式沒有這個問題，因為我們很久以前就讓執行器將計畫樹視為唯讀。也許有一天我們會讓工具陳述式的執行也這樣做，但我並不抱太大期望。）討論：https://postgr.es/m/931771.1623893989@sss.pgh.pa.us 討論：https://postgr.es/m/17053-3ca3f501bbc212b4@postgresql.org https://git.postgresql.org/pg/commitdiff/7c337b6b527b7052e6a751f966d5734c56f668b5

  • 改善 pgbench 中的版本報告。 Commit 547f04e73 導致 pgbench 開始列印其版本號，這似乎是個好主意，但還需要做更多工作： * 如果伺服器版本號不同，也要列印伺服器版本號。 * 列印 PG_VERSION 字串，而不是一些重建的近似值。此修補程式複製了 psql 用於相同目的的經過良好測試的程式碼。討論：https://postgr.es/m/1226654.1624036821@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/84bee9610965331d5110971d8de390a5bbe2effc

  • 修正 DROP OWNED BY 在 polroles 條目重複時的錯誤行為。通常，pg_policy.polroles 陣列不會多次列出相同的角色；但 CREATE POLICY 並不阻止這種情況。如果我們對多次列出的角色執行 DROP OWNED BY，則 RemoveRoleFromObjectPolicy 會發生斷言失敗或遇到 tuple-updated-by-self 錯誤。重寫它以正確處理重複的條目，並添加 CommandCounterIncrement 呼叫以防止另一個問題。根據討論，這裡應該進行其他清理，但這似乎是最小的基本修復。根據 Alexander Lakhin 提出的錯誤 #17062。它一直都壞掉了，所以回溯修補到所有受支援的分支。討論：https://postgr.es/m/17062-11f471ae3199ca23@postgresql.org https://git.postgresql.org/pg/commitdiff/d21fca084356946664bfce19d66d2df2bb873cbd

  • 為 v14 中新增的 libpq 功能提供功能測試巨集。我們收到了一個請求，希望提供一種在編譯時測試新管線功能可用性的方法。更廣泛地說，似乎提供一種透過 #ifdef 測試所有新的 libpq API 功能的方法是個好主意。人們一直在使用來自 pg_config.h 的版本來做這件事；但在伺服器版本和 libpq 版本不同的情況下，這更有可能代表伺服器版本而不是 libpq 版本。如果 libpq-fe.h 本身是它提供的功能的真值來源，則更安全。因此，制定一項政策，即從 v14 開始，當我們在那裡添加新的 API 時，我們將在 libpq-fe.h 中添加一個合適的功能存在巨集。（追溯應用此政策似乎沒有太大意義，但對於 v14 來說還不算太晚。） Tom Lane 和 Alvaro Herrera，根據 Boris Kolpackov 的建議。討論：https://postgr.es/m/boris.20210617102439@codesynthesis.com https://git.postgresql.org/pg/commitdiff/6991e774e0304f5ef488cf1ae4fa79578b6ae3d5

  • 穩定 commit f61db909d 添加的測試案例。 Buildfarm 成員 ayu 和 tern 有時會顯示與此查詢預期不同的計畫。我之前一直無法重現它，但今天我終於意識到發生了什麼。如果存在並發的開放交易（可能是 buildfarm 中的自動清理執行，但這也可以手動安排），那麼由 DELETE 刪除的幾行之上的列的索引條目不會立即被刪除，導致規劃器對 ft2.c1 極端值的估計發生變化，這會將“c1 > 1100”的列數估計移動到足以將聯結計畫從巢狀迴圈更改為雜湊。為了修復這個問題，將查詢條件更改為“c1 > 1000”，導致無論是否存在並發的開放交易，都優先選擇雜湊計畫。由於此 UPDATE 經過定制化處理，因此沒有其他更改。報告：https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-09%2022%3A45%3A48 報告：https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-13%2022%3A38%3A18 報告：https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2021-06-20%2004%3A55%3A36 https://git.postgresql.org/pg/commitdiff/5843659d091bfb6f2c60e010ea1fd00e55ee6ada

  • 也為簡單的表達式恢復入口級別的快照。 Commit 84f5c2908 等遺漏了需要涵蓋 plpgsql 的「簡單表達式」程式碼路徑。如果我們在 COMMIT/ROLLBACK 之後執行的第一件事是其中之一，而不是完整的 SPI 指令，我們必須顯式地執行 EnsurePortalSnapshotExists()，以確保我們有一個外部快照。請注意，僅在表達式執行期間推送快照是不夠的：返回的內容可能會被 toasted，所以我們最好有一個快照來保護它。展示這一事實的測試案例作弊了一點，它將 SQL 函數標記為不可變，即使它從表中提取數據。不過，這並不是用戶沒有做過的事情。根據 Jim Nasby 的報告。像之前的修復一樣，回溯修補到 v11。討論：https://postgr.es/m/378885e4-f85f-fc28-6c91-c4d1c080bf26@amazon.com https://git.postgresql.org/pg/commitdiff/d102aafb6259a6a412803d4b1d8c4f00aa17f67e

  • 使用註解來減少隔離測試結果的不穩定性。長期以來，我們一直面臨隔離測試結果不夠穩定的問題。某些測試腳本會插入長時間的延遲，試圖強制產生穩定的結果，但這並非理想的做法；然而，其他不穩定的失敗模式仍然存在，導致 buildfarm 無法重複的失敗。我花費了相當多的時間，試圖透過改進伺服器端的支援程式碼來解決這個問題，但沒有太大的成功：從根本上來說，這種方法無法應付由於來自不同伺服器進程的消息到達的隨機順序而產生的差異。然而，我們可以透過在測試腳本本身中添加註解來改善客戶端的問題，以顯示可能以不同順序發生的事件的期望報告順序。此修補程式添加了三種註解類型來處理：（a）測試步驟可能完成也可能未完成其等待，然後 isolationtester 才能看到它們正在等待；（b）不同會話中的測試步驟可以合法地以任一順序完成；以及（c）NOTIFY 消息可能在另一個會話中的步驟完成之前或之後到達。我們可能稍後需要更多註解類型，但這似乎足以應付我們在 buildfarm 中看到的那些不穩定性。它還讓我們可以擺脫之前使用的所有長時間延遲，從而將隔離測試的運行時間縮短一分多鐘。向所有支援的分支進行回溯修補，因為 buildfarm 的不穩定性會影響所有分支，並且似乎希望在所有分支中保持 isolationtester 的功能相同，以簡化將來可能進行的測試回溯修補。討論：https://postgr.es/m/327948.1623725828@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/741d7f1047fe52da7ced6fa9cea661ce9320c8d4

  • 改善隔離測試中查詢結果的顯示。之前，isolationtester 使用一些臨時程式碼來顯示 SQL 查詢結果，顯然沒有投入太多精力。長度超過 14 個字元的欄位值沒有與下一個欄位分隔，並且通常也會導致欄位錯位。此外，查詢結果與後續 isolationtester 輸出之間沒有視覺分隔。這使得測試結果檔案令人困惑且難以閱讀。為了改善這種情況，我們來使用 libpq 的 PQprint() 函式。雖然 psql 早已不再使用它，但它仍然足以滿足此處的目的。與 741d7f104 一樣，向所有支援的分支進行回溯修補，以便這不會成為回溯修補隔離測試變更的絆腳石。討論：https://postgr.es/m/582362.1623798221@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/4a054069a36032a59afceb07f3b837f09ab1a2e9

  • 不要假設 GSSAPI 結果字串以空字元結尾。我們對 gss_display_status() 和 gss_display_name() 的使用假設這些函式傳回的 gss_buffer_desc 字串以空字元結尾。考慮到到目前為止沒有出現任何欄位投訴，它們似乎通常是這樣。然而，現有的文件並沒有保證這一點，並且 gss_display_status() 的一些手冊頁顯示了依賴 gss_buffer_desc.length 欄位而不是期望空字元終止的範例。此外，我們現在收到一份報告，指出在某些實現中，clang 的位址清理器認為指定長度後的位元組未定義。因此，變更程式碼以依賴長度欄位。這很可能只是表面上的修改，而不是修復任何真正的錯誤，但很難確定，因此回溯修補到所有支援的分支。同時，也回溯修補 v12 的變更，這些變更使 pg_GSS_error 能夠如實地處理來自 gss_display_status 的多個可用訊息。根據 Sudheer H R 的報告。討論：https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com https://git.postgresql.org/pg/commitdiff/126cdaf47af275f76b2f2ddb023bfdc6f018ae30

  • 文件：修正語法摘要中關於 LEAKPROOF 的混淆。CREATE FUNCTION 和相關命令的語法摘要使 LEAKPROOF 看起來像是 IMMUTABLE/STABLE/VOLATILE 的替代方案，但實際上它是一個正交選項。改善這一點。根據 aazamrafeeque0 的抱怨。感謝 David Johnston 的建議。討論：https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/2031e1668e5577e64cfed29da69a34903d5a5227

  • 允許非引號識別符作為隔離測試會話/步驟名稱。沒有明顯的原因，isolationtester 一直堅持會話和步驟名稱必須用雙引號括起來。這是相當乏味的，並且對測試可讀性沒有太大幫助，特別是因為人們實際選擇的名稱幾乎總是看起來像普通的識別符。因此，我們來調整詞法分析器，允許類似 SQL 的識別符，而不僅僅是雙引號字串。（它們是類似 SQL 的，但不是完全是 SQL，因為我沒有添加任何大小寫摺疊邏輯。此外，沒有為 U&"..." 名稱提供任何條款，也沒有人可能會關心。）此變更引入了一個不相容性：如果您在沒有空格的情況下編寫 "foo""bar"，以前會被視為兩個識別符，但現在只是一個帶有嵌入式引號標記的識別符。我轉換了所有 src/test/isolation/ specfile 以刪除不必要的雙引號，但就到此為止，因為我的眼睛已經開始模糊了。與 741d7f104 一樣，向所有支援的分支進行回溯修補，以便這不會成為回溯修補隔離測試變更的絆腳石。討論：https://postgr.es/m/759113.1623861959@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/a443c1b2d6a646cf90a8afc193c07ed12a2bf045

  • 進一步穩定 postgres_fdw 測試。涉及 ft1_nopw 的查詢不再穩定地返回相同的行。我推測在 f61db909d/5843659d0 引入的更新之後，自動清理擊中了 "S 1"."T 1"，釋放了一些空間，從而改變了後續插入的儲存位置。不過，在之前這些結果是穩定的，只是因為運氣好而已，因為沒有 ORDER BY 的 LIMIT 沒有明確定義，而且我們從未在此測試腳本中將該表視為僅附加的表。由於我們只真正關心這些命令是否成功，因此只需將 "SELECT *" 替換為 "SELECT 1"。報告：https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2021-06-23%2019%3A52%3A08 https://git.postgresql.org/pg/commitdiff/802177090992511c610804da54a4603d4f50c594

  • 文件：從 v14 發布說明中移除提交 f560209c6。既然已經進行了回溯修補，那麼它就不再是 v14 的新功能了。https://git.postgresql.org/pg/commitdiff/8a80562d732c0da1ddcc9fb88dfb976f4b846577

  • 移除 RemoveRoleFromObjectPolicy() 中不必要的失敗情況。這個函式並不需要開啟或鎖定與其修改的 pg_policy 條目相關的關聯。它對 rel 進行的錯誤檢查如果有的話，反而會適得其反 (例如，如果我們不希望在系統目錄上安裝策略，這裡不是阻止它的地方)。特別是，堅持所有權檢查似乎是錯誤的。這實際上會迫使人們使用超級使用者進行 DROP OWNED BY，這絕對不是我們想要的效果。此外，重建策略表達式的依賴關係也沒有意義，因為它們並沒有被更改。最後，鎖定表似乎也會適得其反；它無助於防止競爭條件，因為我們在獲得鎖定後未能重新讀取 pg_policy 列。這意味著並行的 DDL 很有可能會導致「tuple concurrently updated/deleted」錯誤；這與此程式碼將產生的行為相同，但開銷更少。根據錯誤 #17062 的討論。向所有支援的版本進行回溯修補，因為這些消除的失敗情況在 9.6 中與在 HEAD 中一樣不受歡迎。討論：https://postgr.es/m/1573181.1624220108@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5a0f1c8c0193f0dd7fba50c22d96781fa2414007

  • 移除 libpq 對 stringinfo.c 不必要的依賴。Commit c0cb87fbb 不明智地在 fe-connect.c 中引入了對 StringInfo 機制的依賴。我們絕對不能在 libpq 中使用它，因為如果它遇到 OOM (記憶體不足)，它會執行一個總結性的 exit(1)，這對於通用程式庫來說是不適當的行為。允許服務檔案中出現任意行長度的目標似乎不值得花費大量精力，因此恢復到以前使用堆疊分配的緩衝區並在緩衝區溢位時失敗的方法。但這並不是一個完全的回退。我保留了該修補程式的重構，使其具有單一的退出路徑，因為這似乎比讓每個錯誤路徑都知道如何清理更乾淨。此外，我將固定大小的緩衝區設為 1024 位元組而不是 256 位元組，只是為了盡可能延遲對可擴展緩衝區的需求。這裡還有更多的事情要做；特別是，現在缺乏對此類錯誤的任何機械檢查似乎相當危險。但無論如何，這個修復使我們回到了 v13 中的穩健性水平。討論：https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com https://git.postgresql.org/pg/commitdiff/8ec00dc5cd70e0e579e9fbf8661bc46f5ccd8078

  • 文件：更新 v14 發佈說明，以說明回退 commit c0cb87fbb。https://git.postgresql.org/pg/commitdiff/dcffc9ba8a1e0ab1b0a57e9b9d38e3dc9960f83f

  • 移除 isolationtester 中的記憶體洩漏。specscanner.l 每個 spec 檔案的 token 洩漏了一 KB 的記憶體。顯然，有人認為引導程式碼塊會執行一次；但它是每個 yylex() 呼叫執行一次。isolationtester.c 中的幾個函式由於沒有費心釋放一次性分配而洩漏了少量的記憶體。最好也改善這些，以便 valgrind 給予此程式乾淨的健康證明。此外，擺脫一個醜陋的靜態變數。Coverity 抱怨其中一個一次性洩漏，這導致我嘗試 valgrind'ing isolationtester，進而發現了更大的洩漏。https://git.postgresql.org/pg/commitdiff/642c0697c96b9c6ba5d194653a329f7820565f01

Michaël Paquier 推送了

Bruce Momjian 推送

Álvaro Herrera 推送

Noah Misch 推送了

Amit Kapila 推送了

Alexander Korotkov 推送了

Peter Geoghegan 推送了

  • 從 VACUUM 狀態移除不需要的欄位。錯誤修復 commit 5fc89376 有效地將 vacuumlazy.c 全域狀態 struct 中的 lock_waiter_detected 欄位變成了 lazy_truncate_heap() 擁有的私有狀態。透過將 struct 欄位替換為區域變數來完成此操作。https://git.postgresql.org/pg/commitdiff/958cfbcf2dd338e3179c2d8a35f48bde020eba60

  • 支援透過 VACUUM 停用索引繞過功能。將 INDEX_CLEANUP VACUUM 參數（以及對應的 reloption）一般化：將其變成三元樣式的布林參數。現在它公開了第三個選項「auto」。「auto」選項（目前是預設值）啟用了 commit 1e55e7d1 增加的「繞過索引清理」最佳化。「VACUUM (INDEX_CLEANUP TRUE)」被重新定義為讓 VACUUM 簡單地執行任何所需的索引清理，無論在目標堆積關係的第一次掃描中遇到多少死亡元組（除非恰好為零）。這為使用者提供了一種選擇退出「繞過索引清理」最佳化的方法，如果出於任何原因需要這樣做。PostgreSQL 開發人員預期也會不時將其用作測試選項。「VACUUM (INDEX_CLEANUP FALSE)」的作用與以往相同：它強制停用索引清理和索引清除。預計在 PostgreSQL 中不會經常使用。

  • commit 1e55e7d1 增加的故障安全機制以更簡單的方式解決了相同的問題。現在可以將 INDEX_CLEANUP 視為測試和相容性選項。作者：Peter Geoghegan pg@bowt.ie 審閱者：Masahiko Sawada sawada.mshk@gmail.com 審閱者：Justin Pryzby pryzby@telsasoft.com 討論：https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/3499df0dee8c4ea51d264a674df5b5e31991319a

  • 移除過於嚴格的 VACUUM 故障安全斷言。當索引處理已經停用時，可能會觸發故障安全機制。當 VACUUM 的 INDEX_CLEANUP 參數為「off」並且恰好觸發故障安全機制時，可能會發生這種情況。移除假設索引處理與故障安全機制直接相關的斷言。commit c242baa4 中的疏忽，使得故障安全機制有可能在雙通道策略 VACUUM 中觸發，而該 VACUUM 尚未首次呼叫 lazy_vacuum_all_indexes()。https://git.postgresql.org/pg/commitdiff/e8f201ab82be234b2f103234cf9f262f9afeaeba

  • 新增 git-blame 可忽略的 pgindent 提交清單。新增一個 .git-blame-ignore-revs 檔案，其中包含 pgindent、pgperlyidy 和 reformat-dat-files 提交雜湊的清單。配置 git 以使用忽略檔案的 Postgres hackers 將獲得 git-blame 輸出，避免將程式碼行變更歸因於被忽略的縮排提交。這使得 git-blame 輸出在實務上更容易使用。作者：Peter Geoghegan pg@bowt.ie 審閱者：Tom Lane tgl@sss.pgh.pa.us 討論：https://postgr.es/m/CAH2-Wz=cVh3GHTP6SdLU-Gnmt2zRdF8vZkcrFdSzXQ=WhbWm9Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/8e638845ff6bb255ad1dea15831089a234535391

Andrew Dunstan 推送了

Heikki Linnakangas 推送了

  • 修正關於 WAL 檔案搜尋位置的過時註解。自 commit c24dcd0cfd 以來，我們一直使用 pg_pread() 讀取 WAL 檔案，這不會變更搜尋位置（除非我們回退到 src/port/pread.c 中的實作）。相應地更新註解。回溯到：12，我們從那時開始使用 pg_pread() https://git.postgresql.org/pg/commitdiff/d0303bc8d2670d11c9df9220aa08a2c33529e100

  • 整理 GetMultiXactIdMembers() 在發生錯誤時的行為。其中一個錯誤路徑使 *members 未初始化。這不是一個實際的錯誤，因為大多數呼叫者在函數返回 -1 時不會查看 *members，但讓我們整理一下。有一個呼叫者，在 heap_lock_tuple() 中，執行「if (members != NULL) pfree(members)」，但 AFAICS 它從未傳遞無效的 'multi' 值，因此它不應到達該錯誤情況。呼叫者的期望也有點不一致。heap_lock_tuple() 會在 'members' 陣列不是 NULL 時釋放它，其他呼叫者會在「nmembers >= 0」時 pfree() 它，還有其他呼叫者會在「nmembers > 0」時 pfree() 它。這也不是一個實際的錯誤，因為該函數永遠不應返回 0，但為此新增一個 Assert 以使其更清楚。我暫時沒有修改呼叫者。我也移動了我們設定 *nmembers 的行。以前沒有錯，但我喜歡在 'return' 語句旁邊執行此操作，以清楚地表明它始終在返回時設定。另外，為了簡潔起見，並為了與緊隨其後的類似 if 區塊保持一致，移除 ereport(ERROR) 之後的一個無法到達的 return 語句。作者：Greg Nancarrow 進行了我的額外變更 回溯到：9.6，所有支援的版本 https://git.postgresql.org/pg/commitdiff/d24c5658a80c8f5037e9e1948de311d3f3350f12

  • 防止讀取 relmapper 檔案時出現競爭狀況。與此處的註解相反，如果另一個程序同時呼叫 write()，則 POSIX 不保證 read() 的原子性。或者至少 Linux 不保證。新增鎖定到 load_relmap_file() 以避免競爭狀況。修正錯誤 #17064。感謝 Alexander Lakhin 提供的報告和測試案例。回溯到：9.6，所有支援的版本。討論：https://postgres.tw/message-id/17064-bb0d7904ef72add3@postgresql.org https://git.postgresql.org/pg/commitdiff/b6d8d2073f228d9f7198f1f9826d8f6ab643c219

  • 另一個 relmapper 競爭狀況的修復。在之前的提交中，我遺漏了 relmap_redo() 也沒有取得 RelationMappingLock。感謝 Thomas Munro 指出這一點。回溯到：9.6，與之前的提交一樣。討論：https://postgres.tw/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com https://git.postgresql.org/pg/commitdiff/9b8ed0f52bffceaccf6fa650ffe482e7da20fbf2

Tomáš Vondra 推送了

  • 修正使用 FDW 批次處理時複製資料到 slots 的問題。Commit b676ac443b 優化了 bulk inserts 到外部資料表時 tuple slots 的處理方式，使 slots 只初始化一次，並在所有批次處理中重複使用。然而，資料是在初始化之後才複製到 slots 中，導致 slot 被重複使用時插入重複的值。已修正將 ExecCopySlot 移到 init 分支之外。現有的 postgres_fdw 測試未能發現此問題，因為它們在沒有唯一索引的外部資料表中插入資料，然後僅檢查插入的列數。此變更新增了一個新的測試，同時包含唯一索引和對插入值的檢查。報告者：Alexander Pyhalov 討論：https://postgr.es/m/7a8cf8d56b3d18e5c0bccd6cd42d04ac%40postgrespro.ru https://git.postgresql.org/pg/commitdiff/99cea49d6525e30bc3768e4ffb95377e7584dea1

Fujii Masao 推送了變更

Peter Eisentraut 推送了變更

David Rowley 推送了變更

  • 修正 expand_grouping_sets 中的 assert 失敗。如果給定的指標不是指定的類型，linitial_node() 在啟用 assert 的組建中會失敗。此處的類型為 IntList。程式碼認為它應該期望 List，但它是錯誤的。在執行此程式碼的現有測試中，初始列表元素始終為 NIL。由於 linitial_node() 允許 NULL，我們沒有在現有的迴歸測試中觸發任何 assert 失敗。關於我們是否需要在此領域進行更多測試仍然存在一些討論，但現在，由於 beta2 即將推出，因此首先修正錯誤。錯誤：#17067 討論：https://postgr.es/m/17067-665d50fa321f79e0@postgresql.org 報告者：Yaoguang Chen https://git.postgresql.org/pg/commitdiff/8d29d45d9b3cab95a866efbcdd9138b3d76741b3

Andres Freund 推送了變更

Joe Conway 推送了變更

Thomas Munro 推送了變更

待處理的 Patches

Nitin Jadhav 送出了另一個 patch 版本，以提供一種方法來追蹤啟動過程中執行的操作進度。

Yuzuko Hosoya 送出了一個 patch，通過新的 GUC autovacuum_analyze_attach_partition、autovacuum_analyze_detach_partition 和 autovacuum_analyze_drop_partition 來控制是否為分割區操作執行 autoanalyze。

Peter Eisentraut 送出了一個 patch，為 DECLARE_INDEX 加入索引 OID 巨集參數。不再明確定義像 AmOidIndexId 這樣的符號，而是將它們作為 DECLARE_INDEX() 的參數，並讓 genbki.pl 以類似於 CATALOG() 宣告中的資料表 OID 符號的方式產生。

Filip Gospodinov 送出了一個 patch，旨在修復一個錯誤，該錯誤表現為已發布的 pkg-config 檔案在靜態連結 libpq 時會損壞，因為缺少 libpgcommon 和 libpgport。此修復加入了這兩個缺失的私有相依性。

Heikki Linnakangas 送出了另一個修訂版的 patch，將 xlog.c 分割成 xlog.c 和 xlogrecovery.c。這將與執行 WAL 恢復相關的函式移動到新的 xlogrecovery.c 原始程式檔案中，使 xlog.c 負責維護 WAL 緩衝區、協調啟動和從恢復到正常操作的轉換，以及其他一直存在於 xlog.c 中的雜項。

Greg Nancarrow 送出了兩個修訂版的 patch，以移除 BIGINT 序列 MINVALUE/MAXVALUE 值的無用 int64 範圍檢查。

Peter Geoghegan 送出了三個修訂版的 patch，為 "git blame" 加入一個可忽略的 pgindent commits 清單。

David Rowley 送出了另一個修訂版的 patch，以新增一種具有穩定指標的新雜湊表類型，並使用它來加速 SMgr。

Peter Smith 和 Ajin Cherian 交換了 patches，以新增一個選項，支援內建邏輯複製的預備交易。

Daniel Gustafsson 和 Michaël Paquier 交換了 patches，以記錄一些與 SSL/TLS 相關的縮寫，並將 SSL 的使用替換為 SSL/TLS，後者更準確且最新。

Simon Riggs 送出了三個修訂版的 patch，以新增一個關於雜湊索引的文件章節。

Atsushi Torikoshi 送出了另一個修訂版的 patch，以新增一個函式，用於記錄完整查詢字串及其執行計畫，以用於在具有指定程序 ID 的後端上執行的查詢。

Li Japin 送出了一個 patch，以在 RelationGetIdentityKeyBitmap 中進行小的程式碼美化。

Bertrand Drouvot 送出了另一個修訂版的 patch，以在備用伺服器上啟用最小邏輯解碼。

Alexander Pyhalov 送出了另一個修訂版的 patch，以允許將 CASE 運算式推送到外部伺服器。

Peter Eisentraut 送出了一個 patch，以使 Unicode makefile 更能平行處理，使 UCS_to_most.pl 以排序後的順序處理編碼，移除產生的 C 輸出中的一些空白，使其與專案其他部分的程式碼風格一致，簡化程式碼產生程式碼，並修復產生輸出的縮排。

Maxim Orlov 送出了另一個修訂版的 patch，以修復平行 worker 的失敗斷言和核心傾印。

Vigneshwaran C 送出了兩個修訂版的 patch，以新增 PUBLICATION 的 schema 層級支援。

Mike Fiedler 送出了一個 patch，以在後複製輸出中發出命名空間。

Emre Hasegeli 送出了一個 patch，以將運算子類別與索引存取方法分開。

Jacob Champion 送出了兩個修訂版的 patch，以將 SASL 框架與 SCRAM 程式碼分開，因為它可能單獨使用。

Yugo Nagata 送出了另一個修訂版的 patch，透過使用 Variables 結構來處理客戶端變數，以解決一些 Pgbench 錯誤。這在使用於在序列化/死鎖失敗後重複交易期間重設客戶端變數時最為重要。不要一個一個地分配 Variable 結構。而是每次溢位時新增一個常數邊界。還包括一個針對 pgbench 錯誤和序列化/死鎖重試的修復。

Jacob Champion、Michaël Paquier 和 Tom Lane 交換了 patches，以使 jsonapi 可以與 libpq 一起使用。

Gurjeet Singh 送出了一個 patch，以新增頂部交易 ID 的自動通知。

Haiying Tang 送出了另一個修訂版的 patch，以支援 psql 中大寫輸入的查詢結果的 tab 鍵自動完成。

Peter Eisentraut 送出了一個 patch，以透過計算錯誤並在結束時報錯，而不是僅為無效的跨目錄查詢寫入警告，從而使 genbki 錯誤處理更有用。

Daniel Gustafsson 送出了另一個修訂版的 patch，以支援 NSS 作為 libpq 的 TLS 後端。

Andrey V. Lepikhov 送出了一個 patch，以告知 genericcostestimate() 的索引選擇性值，在唯一單列 btree 索引的情況下，只能傳回掃描的一列。

Tomáš Vondra 送出了另一個修訂版的 patch，以使序列可以在邏輯解碼中複製。

Ranier Vilela 送出了一個 patch，以修復 src/backend/commands/subscriptioncmds.c 中的未初始化 copy_data 變數。

Peter Eisentraut 送出了另一個修訂版的 patch，透過縮短主要錯誤訊息並更直接地說明嘗試的操作是不可能的，來改善關於不匹配 relkind 的錯誤訊息。

Peter Eisentraut 送出了一個 patch，以新增 UNBOUNDED 語法不明確性的測試。

Simon Riggs 送出了一個 patch，以使 pgbench 使用 COPY FREEZE。

Justin Pryzby 送出了一個 patch，以避免雙括號，並修復 tablefunc.c 中的註解以引用正確的註解。

Craig Ringer 送出了一個 patch，以新增更多 PGDLLIMPORTs，以公開迄今為止在 Windows 上不可用的一些內容。

Amit Kapila 送出了一個 patch，以允許在推測中止後串流變更。

Hayato Kuroda 送出了一個 patch，以使 ECPG 的新 DECLARE STATEMENT 適用於 DEALLOCATE 和 DESCRIBE。

Bruce Momjian 送出了另一個修訂版的 patch，以實作叢集檔案加密。

Jie Zhang 送出了一個 patch，使產生的範例 postgresql.conf 與實際上 shared_buffers 的預設值一致。

Richard Guo 送出了一個 patch，以將每個 rel 用作反聯結的外層和內層。

Tom Lane 送出了一個 patch，以防止從 libpq 內部呼叫 abort() 或 exit()。

Alexander Korotkov 送出了一個 patch，以修復多重範圍運算子的目錄定義中的一些小不一致之處。

Julien Rouhaud 送出了另一個修訂版的 patch，以在產生 const 節點時保留 param 位置。

Andrey Borodin 送出了另一個修訂版的 patch，以重新組織 pglz 壓縮程式碼。

Julien Rouhaud 和 Ranier Vilela 交換了 patches，以新增 pg_get_query_def()，以反解析和列印重新編寫的 SQL 語句。

Tomáš Vondra 送出了一個 PoC patch，以使用運行時取樣來進行基數估計。