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

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

發布於 2021-11-15 作者：PWN
PWN

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

PostgreSQL 14.1、13.5、12.9、11.14、10.19 和 9.6.24 已發布。 這是 9.6 系列的最後一個版本，如果您還沒有升級計畫，請立即採取行動。

PostgreSQL 產品新聞

Pgpool-II 4.3 beta1，PostgreSQL 的連線池和語句複製系統，已發布

Odyssey 1.2，適用於 PostgreSQL 的多線程連線池，已發布。 https://github.com/yandex/odyssey/releases

pgbouncer 1.16.1，PostgreSQL 的連線池等，已發布

11 月的 PostgreSQL 職缺

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

PostgreSQL 新聞報導

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

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

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

已應用的修補程式

David Rowley 推送

Tom Lane 推送

  • 拒絕 SSL 或 GSS 加密握手後的多餘資料。 每當伺服器從客戶端套接字讀取資料時，它最多會收集一個 bufferload 的資料。 如果在啟動期間請求 SSL 或 GSS 加密，則隨著初始請求訊息接收到的任何其他資料將保留在緩衝區中，並且在加密握手完成後將被視為已解密的資料。 因此，具有將資料注入 TCP 連線能力的中間人可能會將一些明文資料放入據稱受加密保護的資料庫會話的開始位置。 這可能會被濫用以將偽造的 SQL 命令發送到伺服器，但只有在伺服器不要求任何身份驗證資料的情況下才會有效。 （但是，依賴 SSL 憑證驗證的伺服器可能不會這樣做。） 為了修復，如果加密握手後內部緩衝區不為空，則拋出協定違規錯誤。 感謝 Jacob Champion 報告此問題。 安全性：CVE-2021-23214 https://git.postgresql.org/pg/commitdiff/28e24125541545483093819efae9bca603441951

  • libpq：拒絕 SSL 或 GSS 加密握手後的多餘資料。 每當 libpq 從套接字讀取資料時，它最多會收集一個 bufferload 的資料。 如果在啟動期間請求 SSL 或 GSS 加密，則隨著伺服器的是或否回覆接收到的任何其他資料將保留在緩衝區中，並且在加密握手完成後將被視為已解密的資料。 因此，具有將資料注入 TCP 連線能力的中間人可能會將一些明文資料放入據稱受加密保護的資料庫會話的開始位置。 這可能會被濫用以將偽造的回應注入到客戶端的前幾個查詢中，儘管 libpq 行為的其他細節使得這比聽起來更困難。 另一種攻擊方式是洩漏客戶端的密碼，或會話早期可能發送的其他敏感資料。 這已被證明可以使用容易受到 CVE-2021-23214 攻擊的伺服器實現。 為了修復，如果加密握手後內部緩衝區不為空，則拋出協定違規錯誤。 感謝 Jacob Champion 報告此問題。 安全性：CVE-2021-23222 https://git.postgresql.org/pg/commitdiff/160c0258802d10b0600d7671b1bbea55d8e17d45

  • 修正不正確的格式佔位符。 根據 buildfarm 警告。 https://git.postgresql.org/pg/commitdiff/b0cf5444f9a8d915b2e9b44790025f17a7dc107f

  • 修正 026_overwrite_contrecord.pl 測試中的不穩定性。 我們在較慢的 buildfarm 機器上看到此測試中斷斷續續的失敗，我認為這可以透過假設 autovacuum 發出了一些額外的 WAL 來解釋。 禁用 autovacuum 以使其穩定。 順便說一句，使用字符串而不是數字比較來比較 WAL 檔案名。 目前沒關係，但它們是十六進位字符串而不是十進位 ... Discussion: https://postgr.es/m/1372189.1636499287@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b66767b56b1cd082f3499a7e5a21b480dd004f51

  • Doc：改進邏輯複製 Type 訊息的協定規範。 protocol.sgml 記錄了 Type 訊息的佈局，但完全忽略了其他方面，未能解釋它們是什麼、何時發送以及它們的用途。 同時，對 Relation 訊息的描述進行一些複製編輯。 順便說一句，調整 apply_handle_type() 的註解，使其更清楚的是，我們選擇在收到 Type 訊息時不執行任何操作，而不是我們認為它沒有任何用途。 根據 Stefen Hillman 的提問。 Discussion: https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c3b33698cf88550b017620f73b94b53029897f39

  • socklen_t 回退到 unsigned int，而不是 int。 哪一個是更好的預設假設，這是一個擲硬幣的結果。 但是，在我們在 buildfarm 中擁有的機器中，唯一依賴於回退 socklen_t 定義的是古老的 HPUX，並且在該平台上 unsigned int 是正確的選擇。 對 ee3a1a5b6 進行了微小的調整。 Discussion: https://postgr.es/m/1440792.1636558888@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/01ec41a5fe4aa590dde18a2c551432aa1925caea

  • postgres_fdw：在特定情況下抑制常數的類型轉換。當反剖析 "remote_var OP constant" 形式的運算式時，我們通常會對常數套用類型轉換，以確保遠端剖析器認為它的類型與我們相同。然而，這樣做通常是不必要的，並且如果使用者有意將本地欄位宣告為與遠端欄位不同的類型，則會導致問題。一個合理的用例是使用 text 來表示遠端的 enum 類型。對此類欄位的比較將以 "var = 'foo'::text" 的形式傳送，這會在遠端爆炸，因為沒有 enum = text 運算子。但是，如果我們只是省略顯式類型轉換，則比較將完全按照使用者想要的方式進行。透過依賴長期的剖析器啟發法，可以在沒有重大語意問題風險的情況下完成此操作，即「如果運算子的一個運算元是 unknown 類型，而另一個運算元具有已知類型，則假設 unknown 運算元也是該類型」。因此，只有在以下情況下，此修補程式才會省略類型轉換：（a）運算子的輸入在本地具有相同的類型；（b）常數將印出為字串文字或 NULL，兩者最初都被視為 unknown 類型；以及（c）非 Const 輸入是一個普通的 foreign Var。規則 (c) 確保遠端剖析器將知道非 Const 輸入的類型；此外，這意味著如果此類型轉換省略確實導致任何語意上的意外，則只能在本地欄位具有與遠端欄位不同的類型的情況下發生。無論如何，這都不能保證有效，並且此修補程式應代表這些情況的淨可用性提升。我 (tgl) 仍然有點不舒服的一點是，當我們決定非 Const 輸入是否為普通 Var 時，我們將忽略隱式的 RelabelType。這使得很難論證遠端應該將 Const 解析為與其 Var 類型相同，因為我們的 Const 與我們的 Var 類型不同。但是，如果我們不這樣做，那麼如果使用者選擇使用 varchar 而不是 text 來表示某些遠端欄位，則此 hack 將無法按預期工作。這似乎很有用，所以暫時這樣做。如果出現任何問題，我們可能必須放棄 RelabelType 忽略位元。Dian Fay，經我審閱和建議 討論：https://postgr.es/m/C9LU294V7K4F.34LRRDU449O45@lamia https://git.postgresql.org/pg/commitdiff/f8abb0f5e114d8c309239f0faa277b97f696d829

  • 使 psql 的 \password 預設為 CURRENT_USER，而不是 PQuser(conn)。 文件清楚地表明 \password 預設作用於「目前使用者」。 它實際作用於或試圖作用於的是用於登入目前連線的使用者名稱。 如果之後執行了 SET ROLE 或 SET SESSION AUTHENTICATION，這就不一樣了。 除了可能造成的意外之外，目前的角色很可能沒有權限設定原始角色的密碼。 若要修正，請使用 "SELECT CURRENT_USER" 取得要作用的角色名稱。 (此語法至少適用於 7.0 的伺服器。) 此外，為了減少混淆，請在密碼提示中包含將要作用的角色名稱。 與文件中的差異使這成為一個錯誤，因此將修補程式向後移植到所有支援的分支。 由我修補; 感謝 Nathan Bossart 的審閱。 討論：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d6eb5a0c258d3da5471814bcc6ed6498129fee16

Robert Haas 推送

  • 未終止的 tar 封存檔問題的最小修正。 Commit 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 改善了 pg_basebackup 剖析 tar 封存檔的能力，但也安排僅在需要對封存檔的內容進行一些修改時才剖析它們。 這是一個問題，因為伺服器實際上並未終止 tar 封存檔。 當新的剖析邏輯被啟用時，pg_basebackup 將正確地終止 tar 檔案，但當它被跳過時，pg_basebackup 將只寫入它從伺服器收到的任何內容，這意味著終止符遺失了。 大多數版本的 tar 願意忽略遺失的終止符，但 AIX buildfarm 動物不願意。 透過發明一種新的 bbstreamer，它只是盲目地添加終止符，並在我們不剖析 tar 封存檔時使用它來修復。 討論：http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/57b5a9646d97a3e8a5b6b6d86b375cc8da6ac85c

  • 讓伺服器正確終止 tar 封存檔。 早期版本的 PostgreSQL 具有一個想要編輯 tar 封存檔但太笨無法正確剖析它們的 pg_basebackup 版本。 伺服器透過未能添加應該結束 tar 檔案的兩個零位元組區塊，讓用戶端更容易，讓用戶端來完成。 但是自 commit 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 以來，我們不再需要這個 hack，因為 pg_basebackup 現在更聰明了，即使它們被正確終止，也可以剖析 tar 檔案！ 因此，請變更伺服器以始終正確終止 tar 檔案。 舊版本的 pg_basebackup 無法與新伺服器通訊，因此沒有相容性中斷。 在 pg_basebackup 方面，如果我們與舊伺服器通訊，我們仍然需要添加終止零位元組，但伺服器是 v15+ 時則不需要。 希望在某些時候我們將能夠刪除一些此相容性垃圾，但現在最好還是保留它。 順便一提，在 bbstreamer_tar.c 中新增一個檔案標頭註解，以更清楚地說明這裡發生了什麼。 討論：http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5a1007a5088cd6ddf892f7422ea8dbaef362372f

  • 進一步清理 'ThisTimeLineID'。在 XLogCtlData 中，將結構成員 ThisTimeLineID 重新命名為 InsertTimeLineID，並更新註解以明確說明它只應在恢復完成後設置。在 StartupXLOG 中，將區域變數 ThisTimeLineID 和 PrevTimeLineID 替換為新的區域變數 replayTLI 和 newTLI。在舊的方案中，ThisTimeLineID 是重播 TLI，直到我們建立新的時間線，之後重播 TLI 就位於 PrevTimeLineID 中。現在，replayTLI 是我們上次重播 WAL 的 TLI，貫穿整個函數，而 newTLI 則是該 TLI，或者是在升級時建立的新時間線。移除 recoveryTargetTimeLineGoal 及其相關變數上方註解區塊中的一些誤導性註解。它變得不正確，不僅因為變數 ThisTimeLineID 現在已消失，還因為 rmgr 代碼不關心 ThisTimeLineID，並且自從頁面標頭中的 TLI 欄位被重新用於儲存頁面校驗和以來就一直如此。新增一則註解 GetFlushRecPtr，說明它僅應在正常執行中使用，並新增一個斷言來驗證這一點。根據 Michael Paquier 的一些想法和我自己的一些想法。也由 Michael Paquier 審閱。討論：http://postgr.es/m/CA+TgmoY1a2d1AnVR3tJcKmGGkhj7GGrwiNwjtKr21dxOuLBzCQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/a27048cbcb582056bfbf15aa2f898b4a3ec74304

  • 修正 basebackup.c 中斷言的錯誤。Commit 5a1007a5088cd6ddf892f7422ea8dbaef362372f 試圖引入一個斷言，即區塊大小至少是 tar 區塊大小的兩倍，但我算錯了。有人在非公開郵件中向我報告了我的錯誤。 https://git.postgresql.org/pg/commitdiff/10eae82b27cebbb9586cda8baf8e3226496891d0

  • 提升 pgarch_readyXlog() 在處理大量狀態檔案時的效能。目前，會針對每個要封存的檔案掃描 archive_status 目錄。當存在大量狀態檔案時，例如 archive_command 已經失敗了很長時間，這些目錄掃描可能會變得非常慢。透過此變更，封存器會在每次目錄掃描期間記住幾個要封存的檔案，從而加快速度。為了確保時間線歷史記錄檔案能盡快封存，XLogArchiveNotify() 會強制封存器在建立時間線歷史記錄檔案的 .ready 檔案後立即執行新的目錄掃描。Nathan Bossart，經過多人參與的長時間討論。我不清楚所有這些人中究竟是誰審閱了這個特定的修補程式。討論：http://postgr.es/m/CA+TgmobhAbs2yabTuTRkJTq_kkC80-+jw=pfpypdOJ7+gAbQbw@mail.gmail.com 討論：http://postgr.es/m/620F3CE1-0255-4D66-9D87-0EADE866985A@amazon.com https://git.postgresql.org/pg/commitdiff/beb4e9ba1652a04f66ff20261444d06f678c0b2d

Amit Kapila 推送了

Fujii Masao 推送了

Michaël Paquier 推送了

  • 讓一些註解使用術語 "ProcSignal" 以保持一致性。procsignal.c 中的周圍程式碼更喜歡使用 "ProcSignal" 而不是 "procsignal"。作者：Bharath Rupireddy 討論：https://postgr.es/m/CALj2ACX99ghPmm1M_O4r4g+YsXFjCn=qF7PeDXntLwMpht_Gdg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/4cd046c203bbca2955182f78eabc06e831ffdbb1

  • 改善 XLogReadRecord() 的某些呼叫者的錯誤訊息。與邏輯解碼相關的幾個程式碼路徑（WAL 傳送器、插槽前進等）使用 XLogReadRecord()，並以 walreader.c 產生的錯誤訊息為基礎。所有這些訊息都沒有上下文，即使不應該發生這些錯誤，也很難找出錯誤可能來自哪裡。XLogReadRecord() 的所有其他呼叫者已經這樣做了。審閱者：Kyotaro Horiguchi 討論：https://postgr.es/m/YYnTH6OyOwQcAdkw@paquier.xyz https://git.postgresql.org/pg/commitdiff/c9c401a5e13accc4a3a775e3feeabdc5940c9178

  • 清除來自 PL/Perl 與 clang-12~ 的編譯警告。clang-12 引入了 -Wcompound-token-split-by-macro，由於它與上游 Perl 的互動，導致在建置 PL/Perl 時產生大量警告。如果編譯器支援該標記，則此提交會在 ./configure 時將一個 -Wno 新增至 CFLAGS，以消除所有這些警告。上游 perl 已經修正了這個問題，但這需要一些時間才能在整個 buildfarm 中傳播，並且我們注意到一些動物需要額外的 -Werror 來幫助偵測不正確的佔位符（請參閱 b0cf544），dangomushi 就是其中之一。審閱者：Tom Lane 討論：https://postgr.es/m/YYr3qYa/R3Gw+Sbg@paquier.xyz 向後移植到：10 https://git.postgresql.org/pg/commitdiff/9ff47ea414c4e6ace347fc4e59866e38b9bbceaf

  • 修正使用空輸入進行 Unicode 字串正規化時的緩衝區溢位問題。PostgreSQL 13 及更新版本會直接受到影響，因為 SQL 函數 `normalize()` 會在以 NFC 和 NFKC 重新組合字串後，使用空字串作為輸入時，導致此函數的呼叫超出其分配的記憶體寫入一個位元組。舊版本 (v10~v12) 不會直接受到此問題的影響，因為唯一使用正規化的程式碼路徑是 SCRAM 身份驗證中的 SASLprep，它禁止使用空字串的情況，但無論如何，讓我們讓程式碼更強健，以便涵蓋此函數的任何核心外的呼叫者。為了解決這個問題，選擇的解決方案很簡單，如果發現分解後的字串為空，則添加快速退出路徑。這只會發生在空字串的情況下，因為在其最低層級，如果程式碼點在分解表中沒有條目，或者其分解大小為 0，則會將其分解為自身。添加了一些測試來涵蓋 v13~ 中的這個問題。請注意，自從 2991ac5 引入此功能以來，對於所有允許的操作 (NFC、NFD、NFKC 和 NFKD)，空字串一直被認為是正規化的 (語法 "IS NF[K]{C,D} NORMALIZED"，通過 SQL 函數 `is_normalized()`)。此行為保持不變，但在 v13~ 中添加了一些測試來檢查之後的情況。在處理此問題時，我也檢查了 src/common/unicode/ 中的 "make normalization-check" (在 13~ 中有效，並且在較舊的穩定分支中獨立於此提交而中斷)。發布說明應僅提及 v13~ 的此提交。報告者：Matthijs van der Vleuten 討論：https://postgr.es/m/17277-0c527a373794e802@postgresql.org 向後移植：10 https://git.postgresql.org/pg/commitdiff/098c134556664d37b78ae87853a82f4a9d23a2c8

  • 修正查詢 pg_stat_slru 時的記憶體溢位問題。pgstatfuncs.c 中的 pg_stat_get_slru() 在完成掃描其條目時，會指向陣列 PgStat_SLRUStats 的結尾後的一個元素。這沒有直接的後果，因為沒有從額外的記憶體區域讀取任何資料，但靜態分析器會在此處提出正確的抱怨。所以讓我們保持乾淨。在處理此問題時，這會在系統檢視保留的區域中添加一個回歸測試。報告者：Alexander Kozhemyakin，通過 AddressSanitizer 作者：Kyotaro Horiguchi 討論：https://postgr.es/m/17280-37da556e86032070@postgresql.org 向後移植：13 https://git.postgresql.org/pg/commitdiff/a45ed975c58fde7303eeae488b313bf0314383f7

Peter Eisentraut 推送

Jeff Davis 推送

Álvaro Herrera 推送

Peter Geoghegan 推送

Noah Misch 推送

Andrew Dunstan 推送

Daniel Gustafsson 推送