2025年9月25日: PostgreSQL 18 釋出！

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

釋出於 2021-11-15 by 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 提供。

請在太平洋標準時間（PST8PDT）週日晚上3:00之前將新聞和公告發送至 david@fetter.org。

已應用補丁

David Rowley 提交

Tom Lane 提交

  • 在 SSL 或 GSS 加密握手後拒絕多餘資料。伺服器在從客戶端套接字讀取資料時會收集最多一個緩衝區量的資料。當在啟動過程中請求 SSL 或 GSS 加密時，在初始請求訊息中收到的任何額外資料都會保留在緩衝區中，並且在加密握手完成後會被視為已解密的資料。因此，能夠將資料注入 TCP 連線的中間人可以將一些明文資料塞入一個本應受加密保護的資料庫會話的開頭。這可能會被濫用以傳送偽造的 SQL 命令給伺服器，儘管這隻有在伺服器不要求任何身份驗證資料時才有效。（但是，依賴 SSL 證書身份驗證的伺服器可能不會這樣做。）為了解決這個問題，如果在加密握手後內部緩衝區不為空，則丟擲協議違反錯誤。感謝 Jacob Champion 報告此問題。安全：CVE-2021-23214 https://git.postgresql.org/pg/commitdiff/28e24125541545483093819efae9bca603441951

  • libpq：在 SSL 或 GSS 加密握手後拒絕多餘資料。libpq 在從套接字讀取資料時會收集最多一個緩衝區量的資料。當在啟動過程中請求 SSL 或 GSS 加密時，在伺服器的 yes-or-no 回覆中收到的任何額外資料都會保留在緩衝區中，並且在加密握手完成後會被視為已解密的資料。因此，能夠將資料注入 TCP 連線的中間人可以將一些明文資料塞入一個本應受加密保護的資料庫會話的開頭。這很可能被濫用以注入偽造的響應給客戶端的最初幾個查詢，儘管 libpq 行為的其他細節使其比聽起來更難實現。另一條攻擊路線是竊取客戶端的密碼，或其他可能在會話早期傳送的敏感資料。這已被證明可以對易受 CVE-2021-23214 攻擊的伺服器進行攻擊。為了解決這個問題，如果在加密握手後內部緩衝區不為空，則丟擲協議違反錯誤。感謝 Jacob Champion 報告此問題。安全：CVE-2021-23222 https://git.postgresql.org/pg/commitdiff/160c0258802d10b0600d7671b1bbea55d8e17d45

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

  • 修復 026_overwrite_contrecord.pl 測試中的不穩定性。我們在較慢的構建農場機器上看到了此測試間歇性失敗，我認為這可以透過假設 autovacuum 發出了一些額外的 WAL 來解釋。停用 autovacuum 以穩定它。順便，使用字串比較而不是數字比較來比較 WAL 檔名。目前無關緊要，但它們是十六進位制字串而不是十進位制……討論：https://postgr.es/m/1372189.1636499287@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b66767b56b1cd082f3499a7e5a21b480dd004f51

  • 文件：改進邏輯複製 Type 訊息的協議規範。protocol.sgml 記錄了 Type 訊息的佈局，但除此之外完全沒有提及，未能解釋它們是什麼，何時傳送，或者它們有什麼用。在此過程中，對 Relation 訊息的描述進行一些文案編輯。順便，調整 apply_handle_type() 的註釋，使其更清楚我們選擇在收到 Type 訊息時不做任何操作，而不是認為它沒有任何用途。根據 Stefen Hillman 的問題。討論：https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c3b33698cf88550b017620f73b94b53029897f39

  • 回退到 unsigned int，而不是 int，用於 socklen_t。這兩種假設是好是壞很難說。然而，在我們擁有的構建農場機器中，唯一依賴於回退 socklen_t 定義的是舊的 HPUX，在該平臺上 unsigned int 是正確的選擇。對 ee3a1a5b6 的小調整。討論：https://postgr.es/m/1440792.1636558888@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/01ec41a5fe4aa590dde18a2c551432aa1925caea

  • postgres_fdw：在有限情況下抑制常量上的轉換。在解析 "remote_var OP constant" 形式的表示式時，我們通常會為常量應用一個轉換，以確保遠端解析器認為它與我們的型別相同。然而，這樣做通常不是必需的，並且如果使用者故意將本地列宣告為與遠端列不同的型別，則會導致問題。一個可能的用例是使用 text 來表示遠端列舉型別。對這種列的比較會被髮送為 "var = 'foo'::text"，這會在遠端端因為沒有 enum = text 運算子而失敗。但如果我們簡單地省略顯式轉換，比較就會按照使用者想要的方式進行。在沒有重大語義問題風險的情況下，可以透過依賴長期存在的解析器啟發式方法來完成，即“如果運算元的一個運算元是未知型別，而另一個具有已知型別，則假設未知運算元也具有該型別”。因此，此補丁僅在以下情況下省略轉換：(a) 運算元的輸入在本地具有相同的型別；(b) 該常量將被列印為字串字面量或 NULL，兩者都最初被視為未知型別；(c) 非 Const 輸入是普通的外部 Var。規則 (c) 保證遠端解析器將知道非 Const 輸入的型別；此外，它意味著如果這種省略轉換確實引起了任何語義上的意外，那隻能發生在本地列的型別與遠端列的型別不同的情況下。這 anyway 並不保證能正常工作，而此補丁應該代表了這些情況下可用性的淨增長。我（tgl）仍然有些不安的一點是，我們在判斷非 Const 輸入是否為普通 Var 時會忽略隱式的 RelabelType。這使得爭論遠端應該將 Const 解析為與其 Var 相同型別變得有點棘手，因為那時我們的 Const 與我們的 Var 型別不匹配。然而，如果我們不這樣做，那麼當用戶選擇使用 varchar 而不是 text 來表示某個遠端列時，這個技巧將無法按預期工作。這似乎很有用，所以暫時這樣做。如果出現任何問題，我們可能不得不放棄忽略 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 版的伺服器相容。）另外，為了減少混淆，在密碼提示中包含將要操作的角色名稱。與文件的差異使其成為一個 bug，因此回溯到所有支援的分支。由我提交補丁；感謝 Nathan Bossart 的審查。討論：https://postgr.es/m/747443.1635536754@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d6eb5a0c258d3da5471814bcc6ed6498129fee16

Robert Haas 提交

  • 針對未終止 tar 歸檔問題的最小修復。提交 23a1c6578c87fca0e361c4f5f9a07df5ae1f9858 改進了 pg_basebackup 解析 tar 歸檔的能力，但也安排僅在我們進行一些歸檔內容修改時才解析它們。這是一個問題，因為伺服器實際上不會終止 tar 歸檔。當新的解析邏輯被啟用時，pg_basebackup 會正確終止 tar 檔案，但當它被跳過時，pg_basebackup 只會寫入從伺服器獲取的內容，這意味著缺少終止符。大多數版本的 tar 都願意忽略缺少終止符，但 AIX 構建農場中的機器則不然。透過發明一種新的 bbstreamer 來盲目新增一個終止符來修復此問題，並在我們不解析 tar 歸檔時使用它。討論：http://postgr.es/m/CA+TgmoZbNzsWwM4BE5Jb_qHncY817DYZwGf+2-7hkMQ27ZwsMQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/57b5a9646d97a3e8a5b6b6d86b375cc8da6ac85c

  • 讓伺服器正確終止 tar 歸檔。PostgreSQL 的早期版本有一個 pg_basebackup 版本，它想要編輯 tar 歸檔但太笨拙而無法正確解析它們。伺服器透過未能新增應該結束 tar 檔案的兩個零位元組塊來簡化客戶端的工作，將其留給客戶端處理。但自提交 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 中，用新的區域性變數 replayTLI 和 newTLI 替換區域性變數 ThisTimeLineID 和 PrevTimeLineID。在舊方案中，ThisTimeLineID 是回放 TLI，直到我們建立一個新的時間線，然後回放 TLI 儲存在 PrevTimeLineID 中。現在，replayTLI 是我們在整個函式中最後回放 WAL 的 TLI，而 newTLI 是其中之一，或者是提升時建立的新時間線。移除宣告 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 中斷言的思考錯誤。提交 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 時向 CFLAGS 添加了一個 -Wno，如果編譯器支援該標誌，則可以抑制所有這些警告。上游 Perl 已修復此問題，但要將其傳播到構建農場還需要一些時間，並且我們注意到有些動物在使用額外的 -Werror 來幫助檢測不正確的佔位符（參見 b0cf544）時會很有用，dango-mushi 就是其中之一。審閱者：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 提交