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

PostgreSQL 每週新聞 - 2021 年 9 月 12 日

由 PWN 於 2021-09-13 發布
PWN

PostgreSQL 每週新聞 - 2021 年 9 月 12 日

PostgreSQL 產品新聞

pg_dumpbinary 2.5，用於以二進制格式轉儲 PostgreSQL 數據庫的程序，已發布。

pgBadger v11.6，一個用 Perl 編寫的 PostgreSQL 日誌分析器和圖形工具，已發布。

[pgagroal 1.3.0，一個用於 PostgreSQL 的高性能協議原生連線池，已發布

九月份 PostgreSQL 工作

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

PostgreSQL 新聞

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

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

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

已應用的修補程式

Michaël Paquier 推送

Peter Eisentraut 推送

Fujii Masao 推送了

  • 修正註解中的錯字。Author: Hou Zhijie Discussion: https://postgr.es/m/OS0PR01MB5716E6A6535FDFDC5A1B004194CE9@OS0PR01MB5716.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/78aa616be74a13156f4fc8db3a131f1fdc2cce47

  • postgres_fdw：允許透過 GUC 設定遠端連線的 application_name。此提交新增了 postgres_fdw.application_name GUC，該 GUC 指定一個 application_name 設定參數的值，該參數在 postgres_fdw 建立與外部伺服器的連線時使用。此 GUC 設定始終會覆寫外部伺服器物件的 application_name 選項。當我們想要為每個遠端連線指定我們自己的 application_name 時，此 GUC 非常有用。先前，遠端連線的 application_name 基本上只能透過伺服器物件的選項進行設定。但這意味著連線到同一個外部伺服器的每個會話基本上都應該使用相同的 application_name。此外，如果我們想要變更設定，我們必須執行 "ALTER SERVER ... OPTIONS ..." 命令。這很不方便。Author: Hayato Kuroda Reviewed-by: Masahiro Ikeda, Fujii Masao Discussion: https://postgr.es/m/TYCPR01MB5870D1E8B949DAF6D3B84E02F5F29@TYCPR01MB5870.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/449ab6350526e99d33363706b759951ebad7928e

  • postgres_fdw：還原 postgres_fdw.application_name 的不穩定測試。提交 449ab63505 新增了用於檢查 postgres_fdw.application_name GUC 是否按預期工作的測試。但它們不穩定，並導致一些 buildfarm 成員報告失敗。此提交會還原這些不穩定的測試。Reported-by: Tom Lane as per buildfarm Discussion: https://postgr.es/m/3220909.1631054766@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/98dbef90eb29b13079ba3bd260b3c5818904ee86

  • 修正待機模式下 WAL 封存的問題。先前，在 walreceiver 完成當前區段的寫入並收到應寫入下一個區段的任何 WAL 資料後，它總是會關閉目前開啟的 WAL 區段並建立其封存通知檔案。如果 walreceiver 在下一個區段中的任何 WAL 資料到達待機伺服器之前退出，即使已知該區段已完成，它也不會建立當前區段的封存通知檔案。這種行為可能會導致該區段的 WAL 封存延遲到後續的 restartpoint 或檢查點建立其通知檔案為止。為了修正此問題，此提交變更了 walreceiver，以便它會在收到下一個 WAL 資料之前立即建立已知已完成的當前 WAL 區段的封存通知檔案。反向移植到所有受支援的分支。Reported-by: Kyotaro Horiguchi Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/20200630.165503.1465894182551545886.horikyota.ntt@gmail.com https://git.postgresql.org/pg/commitdiff/596ba75cb11173a528c6b6ec0142a282e42b69ec

  • pgbench：一旦超出計時器，就停止將跳過的交易計數。使用節流時，延遲超過延遲限制的交易將被計數並報告為跳過。先前，存在這樣一種情況：即使超過了 -T 選項中指定的計時器，pgbench 仍會計算所有跳過的交易。這樣做可能需要很長時間，尤其是在 -R 選項中不切實際的高速率設定導致大量交易落後於排程時。這可能會阻止 pgbench 立即結束，因此 pgbench 看起來像是卡住了。為了修正此問題，此提交變更了 pgbench，以便它會在計時器超出後立即停止計算跳過的交易。即使存在大量尚未計算的跳過的交易，計時器也可以使 pgbench 很快結束。請注意，不能保證在 -T 下計算所有跳過的交易，儘管在 -t 下可以。這在實務中是可以接受的，因為在實際設定下，這種情況不太可能發生。此外，這不是此提交新引入的問題。在之前，pgbench 曾經在沒有計算所有跳過的交易的情況下結束。反向移植到 v14。經過討論，我們決定不麻煩地反向移植到穩定分支，因為很難想像這種情況會在實務中發生（使用實際設定）。Author: Yugo Nagata, Fabien COELHO Reviewed-by: Greg Sabino Mullane, Fujii Masao Discussion: https://postgr.es/m/20210613040151.265ff59d832f835bbcf8b3ba@sraoss.co.jp https://git.postgresql.org/pg/commitdiff/9bcbd7c581a5de3b915ef8fe0262e4abd9cb6e59

Tom Lane 推送了

  • 使 timetz_zone() 穩定，並修正 DYNTZ 縮寫的錯誤。 歷史上，timetz_zone() 使用 time(NULL) 作為決定 DST 是否啟用的參考點。這表示它的結果可能會在語句中變更，因此需要將其標記為 VOLATILE（參見 35979e6c3）。但這種定義與我們在其他地方處理時間戳記的方式非常不一致。 讓我們改為使用事務開始時間 ("now()") 作為參考點。 這使其可以標記為 STABLE，並且還可以節省每次調用時的核心呼叫。 同時，移除該函數對 pg_time_t 和 pg_localtime 的使用。 這些與該區域中的其他程式碼不一致，這確實產生了一個錯誤：如果區域由動態 TZ 縮寫指定，timetz_zone() 會傳回完全錯誤的答案。 （我們需要在後續分支中解決此問題，但修復方式會與此不同。） Aleksander Alekseev 和 Tom Lane 討論： https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/388e71af880d579212c2489686903c2cfdea9032

  • 修正關於 struct pg_tm 內容的錯誤引導性註解。 pgtime.h 在 tm_year 的 POSIX 解釋旁邊記錄了 PG 對 tm_mon 的解釋，沒有任何提示表明這兩個註解在我們的程式碼中都是不正確的。 或許有一天我們應該切換到使用兩個單獨的 struct 定義，以更清楚地表明在何處使用哪種語義。 但我擔心繁瑣與安全增益之間的權衡不會很好。 討論： https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/89dba59590fdd03799a47daf8019890d4324fbcf

  • 進一步修正 psql 查詢取消測試。 等待 pg_sleep 執行的查詢實際上並沒有做到這一點，因為它使用的正則表達式模式可以匹配它自身。 報告： https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2021-09-06%2018%3A00%3A20 https://git.postgresql.org/pg/commitdiff/bd5846e4a9c1338ded5efcef53511f0d71f53f0e

  • 修正重寫器以在重寫的查詢上正確設定 hasModifyingCTE。 如果我們將資料修改 CTE 從原始查詢複製到替換查詢（來自 DO INSTEAD 規則），我們必須在替換查詢中正確設定 hasModifyingCTE。 如果不這樣做，可能會導致各種不愉快的事情，例如不安全地使用平行計畫。 該程式碼也忽略了傳播 hasRecursive，儘管目前這只是表面功夫。 如果規則動作是 INSERT...SELECT，則會出現困難。 我們將原始查詢的 RTE 和 CTE 附加到子 SELECT Query，但資料修改 CTE 只能出現在最頂層的 Query 中。 目前，在這種情況下拋出錯誤。 也許可以通過將 CTE 附加到頂層 INSERT Query 來避免此錯誤； 但這需要大量新程式碼來調整 ctelevelsup 參考。 考慮到用例的狹窄性以及向後移植此修復的需要，目前似乎不值得付出這些努力。 如果我們收到現場投訴，我們可以重新審視這一點。 根據 Greg Nancarrow 的報告。 向後移植到所有支援的分支。 （此處新增的測試案例在 v10 之前不會失敗，但是在 9.6 中有很多地方檢查頂層 hasModifyingCTE，因此我毫不懷疑此程式碼變更也是必要的。） Greg Nancarrow 和 Tom Lane 討論： https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com 討論： https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com https://git.postgresql.org/pg/commitdiff/362e2dcc46195faadd3fa0ba011dd9a8e3829e7a

  • 在 psql tab 補全中，提供拼寫完整的命令，而不是縮寫。 各種 psql 反斜線命令都有單字母和長形式，例如 \e 和 \edit。 以前，tab 補全通常提供單字母形式，但不提供長形式。 提供長形式似乎更合理，因為 (a) 當您已經輸入單個字母時，不會發生有用的補全，並且 (b) 如果您不熟悉該命令集，長形式可能不太容易混淆。 Haiying Tang，由 Dagfinn Ilmari Mannsåker 和我自己審閱 討論： https://postgr.es/m/OS0PR01MB61136018064660F095CB57A8FB129@OS0PR01MB6113.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/7cffa2ed0c9f7f4d96bac7af5284c47e82af5ffa

  • 修正關於 TOAST 存取巨集的錯誤引導性註解。 似乎是我的錯誤在 commit aeb1631ed 中。 Christoph Berg 指出。 討論： https://postgr.es/m/YTeLipdnSOg4NNcI@msg.df7cb.de https://git.postgresql.org/pg/commitdiff/490798451a3adc32b71b30e285bd99875d67fa2b

  • 避免 getFormattedTypeName() 周圍無用的 malloc/free 流量。 Coverity 抱怨 getFormattedTypeName() 的一個呼叫者未能釋放傳回的字串。 這是真的，但與其修正這一個，不如擺脫這個繁瑣且容易出錯的要求。 既然 getFormattedTypeName() 緩存了它的結果，strdup'ing 該結果並期望呼叫者釋放它除了浪費週期外幾乎沒有任何作用。 如果 getTypes 沒有為該類型建立 TypeInfo，我們確實會建立一個洩漏，但這基本上永遠不應該發生。 向後移植，如同 commit 6c450a861 一樣。 這不是一個特別有趣的錯誤修復，但是如果我們不向後移植它，API 變更對於未來的向後移植活動來說似乎是一個危險。 https://git.postgresql.org/pg/commitdiff/072e2f8a62002cb01ed6c4e161442e133509349e

  • 儘早檢查關係長度溢出。 我們不允許關係超過 2^32-1 個塊，因為塊號是 32 位，並且最後一個可能的塊號保留為表示 InvalidBlockNumber。 在 mdextend 中有一個檢查，但這確實太晚了，因為 smgr API 要求我們為要新增的塊建立一個緩衝區，並且我們不希望有任何 blocknum 為 InvalidBlockNumber 的緩衝區。 （這種情況可能會觸發 bufmgr.c 中的斷言，而且我認為它可能會混淆 ReadBuffer 稍後對資料超出 EOF 的邏輯。） 因此，將檢查放入 ReadBuffer 中。 根據 Christoph Berg 的報告。 一直以來都是這樣，因此向後移植到所有支援的分支。 討論： https://postgr.es/m/YTn1iTkUYBZfcODk@msg.credativ.de https://git.postgresql.org/pg/commitdiff/8481f99896a192e9fd57f5e1a99e255e27680a10

  • 避免從已經終止的計畫中獲取。 某些計畫節點類型在返回 NULL 後再次呼叫時反應不佳。 如果 PortalRunSelect() 看到我們已經將 portal 執行到最後，長期以來一直通過使用 NoMovementScanDirection 呼叫執行器來處理這個問題。 然而，commit ba2c6d6ce 忽略了這一點，因此如果持久化一個已經完全獲取的游標具有這樣的計畫，它將會失敗。 根據 Tomas Barton 的報告。 向後移植到 v11，因為錯誤的 commit 是這樣。 （我省略了一個測試案例，因為導致問題的計畫類型並不是很穩定。） 討論： https://postgr.es/m/CAPV2KRjd=ErgVGbvO2Ty20tKTEZZr6cYsYLxgN_W3eAo9pf5sw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cba79a163267a44205e391137deb543f4f89bc8b

  • 修正 NO SCROLL 游標的一些異常行為。我們長期以來禁止從 NO SCROLL 游標向後提取資料，但該禁令並未擴展到完全重繞查詢然後重新向前提取資料的情況。我認為原因是這個邏輯主要是為了保護無法反向執行的計畫節點。然而，如果查詢是易變的（包括 SELECT FOR UPDATE，而不僅僅是具有易變函數的查詢），則重新讀取查詢輸出是有問題的：重新讀取可能會產生不同的結果，這會完全混淆游標導航邏輯。另一個不喜歡這種方法的原因是，某些程式碼路徑會根據到目標列的距離來向後提取或重繞後向前提取；因此，看似相同的用例可能會或可能不會產生「游標只能向前掃描」的錯誤。因此，讓我們清理一下，禁止 NO SCROLL 游標中的重繞和向後提取。通常，我們只會在 HEAD 中進行這樣的定義更改，但現在有第三個理由考慮此更改。提交 ba2c6d6ce 為具有 WITH HOLD 的不可滾動游標建立了一些新的使用者可見的異常，如果游標在提交之前已被部分讀取，則游標結果中的導航會變得混亂。解決這些異常的唯一好方法是禁止重繞這樣的游標，這允許移除 ba2c6d6ce 添加到 PersistHoldablePortal 的不正確的游標狀態操作。為了盡量減少後續分支（包括 v14）的行為變更，僅當 NO SCROLL 游標具有 holdStore 時（即由於 WITH HOLD 從先前的事務中保留下來）才拒絕重繞。這應該可以避免破壞大多數對於是否將游標宣告為可滾動不夠嚴謹的應用程式。我們將從 v15 開始全面強制執行該禁令。回溯修補到 v11，就像 ba2c6d6ce 一樣。討論：https://postgr.es/m/3712911.1631207435@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/c1b7a6c2731241cf5af4c08de54a64fc8999d727

  • 使 pg_regexec() 對超出範圍的 search_start 具有穩健性。如果 search_start 大於字串的長度，我們應該立即返回 REG_NOMATCH。（請注意，不應拒絕相等的情況，因為模式可能能夠匹配零個字元。）這保護了各種內部假設，即字串位置範圍的最小值不大於最大值。違反這些假設可能會導致嘗試獲取 string[search_start-1]，可能導致崩潰。Jaime Casanova 指出，使用接受使用者指定起始位置的新 regexp_xxx 函數可以達到這種情況。我不認為在 v14 及更低版本中的任何核心呼叫點都可以達到這種情況。但是，擴充套件可能會使用超出範圍的 search_start 呼叫 pg_regexec，所以讓我們無論如何都回溯修補該修復。討論：https://postgr.es/m/20210911180357.GA6870@ahch-to https://git.postgresql.org/pg/commitdiff/e757080e041214cf6983e3e77ef01e83f1371d72

Álvaro Herrera 推送

Noah Misch 推送

Amit Kapila 推送

Heikki Linnakangas 推送了

Andres Freund 推送了

  • windows：僅在 stderr 無效時才認為我們正在作為服務執行。先前，如果 postgres 是從服務中的某個位置啟動的，但不是作為服務啟動，pgwin32_is_service() 會錯誤地傳回 true。例如，windows docker 容器總是這種情況，一些 CI 服務使用這些容器來執行 windows 測試。當 postgres 錯誤地認為它正在作為服務執行時，不會將任何訊息寫入 stdout / stderr。這可能會非常令人困惑，並導致一些測試失敗。為了修復此問題，請額外檢查 pgwin32_is_service() 中的 stderr 是否無效。為了使它在後端程序中工作，pg_ctl 被更改為傳遞句柄，以便 postgres 可以執行相同的檢查（否則會建立「預設」句柄）。雖然此問題存在於所有分支中，但沒有使用者報告，預期的 CI 使用目前僅適用於 master，而且我不是 windows 專家。因此，目前僅在 master 中進行更改似乎是最明智的方法。作者：Andres Freund andres@anarazel.de 審閱者：Magnus Hagander magnus@hagander.net 討論：https://postgr.es/m/20210305185752.3up5eq2eanb7ofmb@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/76e38b37a5f179d4c9d2865ff31b79130407530b

Magnus Hagander 推送了

Daniel Gustafsson 推送了