PostgreSQL 14 已發布！ https://postgres.tw/about/news/postgresql-14-released-2318/
pgtt 2.6，一個用於實現全域臨時表的擴充套件，已發布。 https://github.com/darold/pgtt/releases/tag/v2.6
oracle_fdw 2.4.0 已發布。 https://laurenz.github.io/oracle_fdw
pgFormatter 5.1，一個用於 SQL 程式碼的格式化器/美化器，已發布。 https://github.com/darold/pgFormatter/blob/master/ChangeLog
https://archives.postgresql.org/pgsql-jobs/2021-10/
Planet PostgreSQL：https://planet.postgresql.org/
本週的 PostgreSQL 每週新聞由 David Fetter 帶給您
請在太平洋標準時間/太平洋夏令時間星期日下午 3:00 前將新聞和公告提交至 david@fetter.org。
Thomas Munro 推送
Peter Geoghegan 推送
移除不需要的 nbtree latestRemovedXid 註解。 現在討論 btvacuumpage() 中 nbtree VACUUM 和恢復衝突的底層問題似乎不合適。 同樣的問題在 nbtxlog.h 以及 _bt_delitems_vacuum() 上方的註解區塊中討論。 當註解區塊是更廣泛的 nbtree VACUUM "pin scans" 討論的一部分時，它更有意義。 這些已由 commit 9f83468b 移除。 https://git.postgresql.org/pg/commitdiff/895267a3266484440c0b2f42f613bcff28844cc1
在系統目錄索引中啟用重複資料刪除。 之前，"相等意味著映像相等" 的 opclass 基礎架構不允許在系統目錄索引和 TOAST 索引中進行重複資料刪除。 自從 commit 612a1ab7 新增基礎架構以來，這似乎是正確的方法，因為 ALTER INDEX 無法將 deduplicate_items 設定為 'off' (由於舊的實作限制)。 但現在這個決定充其量似乎是隨意的。 移除實作此策略的特殊情況處理。 沒有 catversion 增加，因為現有的目錄索引仍然可以使用。 作者：Peter Geoghegan pg@bowt.ie 討論：https://postgr.es/m/CAH2-Wz=rYQHFaJ3WYBdK=xgwxKzaiGMSSrh-ZCREa-pS-7Zjew@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2903f1404df37e11ecc303dbc164826c4717194b
Michaël Paquier 推送
修復程式碼註解中的拼字錯誤和文法。 隨著時間的推移，程式碼註解中累積了一些錯誤，包括不正確的文法、函數名稱和簡單的拼字錯誤。 此 commit 處理了其中的一部分。 沒有進行反向移植，因為這只是表面上的。 作者：Justin Pryzby 討論：https://postgr.es/m/20210924215827.GS831@telsasoft.com https://git.postgresql.org/pg/commitdiff/e767ddcd354b51fc4c12d6b02e268861bd871fbc
重構在 EXEC_BACKEND 下 Forking syslogger 時的輸出檔案處理。 EXEC_BACKEND 中的 Forked 日誌收集器會通過命令傳遞檔案描述符 (或 WIN32 中的 HANDLE)，以便重新開啟檔案 (用於 stderr 和 csvlog)。 它的一些邏輯是重複的，這個 commit 使用一些包裝常式重構程式碼，以便在 fork 後重新開啟檔案，並在建構 fork 命令時獲取 fd。 同時，這簡化了程式碼中 "long" 的使用，這是由 ab0ba6e 引入的，以處理將 intptr_t 映射到列印值時與 MinGW-W64 相關的警告。 "long" 在 Windows 上是 32 位元，而 Win32 和 Win64 的互通性確保句柄始終是 32 位元，所以我們可以只使用 "int" 來獲得相同的結果。 這也使新的常式更加對稱。 此變更使在日誌收集器中引入新的日誌目的地變得更容易，而且這不是唯一計劃的重構。 我已經在 Linux、macOS 上，當然還有 MSVC (Win32 和 Win64) 上使用 EXEC_BACKEND 測試了此變更，但沒有使用 MinGW，所以 buildfarm 可能有一些話要說。 作者：Sehrope Sarkuni、Michael Paquier 討論：https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/5b0b699f748ead1b7414c58aaa7cf0ea83808147
doc：修復一些拼字錯誤和標記。 作者：Ekaterina Kiryanova 討論：https://postgr.es/m/8a14e78f-6991-7a6e-4711-fe376635f2ad@postgrespro.ru Backpatch-through：14 https://git.postgresql.org/pg/commitdiff/c8dd2cb49405d2a39a714bd5adc31d39b8372a4e
闡明程式碼中 "statistics objects" 的使用。 程式碼不一致地使用 "statistic object" 或 "statistics"，而正確的術語，正如所討論的，實際上是 "statistics object"。 這改善了程式碼的狀態，使其更加一致。 同時，修復了 a4d75c8 中引入的錯誤訊息。 正如程式碼所述，這個錯誤永遠不會發生，但它會產生誤導。 作者：Justin Pryzby 審閱者：Álvaro Herrera、Michael Paquier 討論：https://postgr.es/m/20210924215827.GS831@telsasoft.com Backpatch-through：14 https://git.postgresql.org/pg/commitdiff/070d2e19e40897d857f570f24888fc30727ed9c0
pg_stat_statements：為仍然可用的舊版本新增一些測試。 當載入最新版本時，後端會從最舊的完整 SQL 檔案 (這裡為 1.4) 載入物件，然後使用轉換腳本 (目前最多為 1.9) 更新到最新版本。 這為 pg_stat_statements 的升級提供了一些覆蓋範圍，但沒有測試來顯示每個版本中發生的變化。 這為使用每個支援版本的物件的升級路徑新增了一些測試，強調了每個支援版本中行為發生變化的物件。 作者：Erica Zhang 審閱者：Julien Rouhaud、Michael Paquier 討論：https://postgr.es/m/tencent_BBA974AFF61379F2345E782FD6C55891950A@qq.com https://git.postgresql.org/pg/commitdiff/2b0da0365bec6c62cc9c5c317bab6cbee3d52ef4
Tom Lane 推送
重新啟用 contrib/bloom 的 TAP 測試。 這些測試早在 2018 年 (commit d3c09b9b1) 就因為在建置農場中觀察到的失敗而被停用。 但是，我一直無法在 longfin 的主機上重現任何失敗，所以我很好奇我們在多大程度上解決了這個問題。 讓我們重新啟用它 (僅在 HEAD 中) 並看看會發生什麼。 討論：https://postgr.es/m/2769443.1632773967@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/7d1aa6bf1c27bf7438179db446f7d1e72ae093d0
修正 contrib/bloom TAP 測試中的不穩定性。事實證明，commit d3c09b9b 中所抱怨的不穩定性，其解釋非常簡單。測試腳本等待備用伺服器將傳入的 WAL 刷新到磁碟，但它應該等待 WAL 被重播，因為我們正在測試該重播是否會產生可見的影響。同時，使用 wait_for_catchup 而不是重新發明該邏輯，並調整 $Test::Builder::Level 以改善未來的錯誤報告。向後移植到 v12，因為必要的基礎結構是在該版本中引入的 (參見上述 commit)。同時也向後移植 7d1aa6bf1，以便實際運行該測試。討論：https://postgr.es/m/2854602.1632852664@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6bc6bd47cf715c8717a8af3f617957045772d38b
將 ETIMEDOUT 視為指示無法恢復的連線故障。將 ETIMEDOUT 加入 ALL_CONNECTION_FAILURE_ERRNOS 的清單中，作為 "識別先前建立的網路連線硬故障的錯誤代碼"。儘管可以想像有時這是可以恢復的，但其他條目（例如 ENETDOWN）也是如此。為了支持這一點，在相關的基礎結構（例如 TranslateSocketError()）中，以與其他 socket 錯誤相同的方式處理 ETIMEDOUT。（我也在 TranslateSocketError() 中做了一些外觀上的調整。）現在程式碼假設 ETIMEDOUT 在任何地方都有定義，鑑於 POSIX 自 SUSv2 以來就已經要求這樣做。也許應該向後移植這個修改，但我猶豫是否要這樣做，因為之前沒有任何抱怨，而且重新定義符號會在 Windows 上產生輕微的 ABI 破壞的風險。即使我們決定這樣做，也最好先在 HEAD 中測試一段時間。Jelte Fennema 討論：https://postgr.es/m/AM5PR83MB01782BFF2978505F6D6C559AF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com https://git.postgresql.org/pg/commitdiff/b484ddf4d2eb81736512efa35ed3e5d2a72993d8
移除 002_types.pl 測試中不必要的環境依賴性。透過減去 "N 天" 來計算相關的時間戳記，會受到目前時區的影響，因為我們將其解釋為 "在第 N 天之前同一當地時間"。即使所涉及的間隔只有兩到四天，但由於非常不幸地跨越了 2014 年齋月結束的日子，如果時區設定為 Africa/Casablanca，會導致測試輸出發生變化。（可能在其他穆斯林地區也是如此；我沒有檢查。）這個測試絕對沒有理由去執行間隔減法，所以只需擺脫它，並使用表示預期值的純 timestamptz 常數即可。根據 Andres Freund 的報告。向後移植到 v10，因為這個測試腳本是在該版本中引入的。討論：https://postgr.es/m/20210930183641.7lh4jhvpipvromca@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/20f8671ef69b864c25ffa59471814102c1260d78
修正 Portal 快照追蹤，以正確處理子交易。Commit 84f5c2908 忘記考慮 EnsurePortalSnapshotExists 可能在 lifespan 短於 Portal 的子交易中運行的可能性。在這種情況下，新的活動快照將在子交易結束時被彈出，在 Portal 中留下懸空的指標，導致混亂。為了修正這個問題，請確保 ActiveSnapshot 堆疊條目標記的子交易嵌套層級與相關 Portal 的相同。這樣做絕對是安全的，因為除非堆疊為空，否則我們根本不會來到這裡；因此，我們無法建立一個亂序的堆疊。同時，讓我們也在 PortalRunUtility 設定 portalSnapshot 的情況下應用這個邏輯，以確保該路徑不會導致類似的問題。不太清楚該路徑是否會建立一個亂序的堆疊，所以新增一個斷言來保護它。由 Bertrand Drouvot 報告和修補（經過我的評論）。向後移植到 v11，就像之前的 commit 一樣。討論：https://postgr.es/m/ff82b8c5-77f4-3fe7-6028-fcf3303e82dd@amazon.com https://git.postgresql.org/pg/commitdiff/7b5d4c29ed0262e537026cb3a85161d6cf98abcc
避免在 get_variable_range() 中信任不完整的僅 MCV 統計資料。get_variable_range() 會不小心地相信僅包含 MCV 清單的統計資料足以得出範圍估計值。對於僅包含 MCV 的枚舉類型欄位來說還可以，但除此之外，估計值可能會非常糟糕。除非 MCV 加上 nullfrac 佔據整個表格，否則讓它報告範圍是不確定的。我不認為這需要一個專門的測試案例，因為快速的程式碼涵蓋率檢查可以驗證現有的迴歸測試會遍歷所有替代方案。無論如何，很難建立一個面向未來的測試案例，因為提交的範例在 v11 之前意外地沒有失敗。根據 Simon Perepelitsa 的錯誤 #17207。向後移植到 v10。原則上，這一直是壞的，但我猶豫是否要在 9.6 中進行這樣的更改，因為如果有人對 9.6.24 的行為不滿意，將沒有第二次機會修復它。討論：https://postgr.es/m/17207-5265aefa79e333b4@postgresql.org https://git.postgresql.org/pg/commitdiff/8c1144ba73478b818d9cebe8ecd64a14b7d45bde
重新按照字母順序排列 win32_tzmap[] 陣列。最初的意圖似乎是按 Windows 區域名稱不區分大小寫地排序，但多年來的各種更改並未遵循該備忘錄。此 commit 只是移動了一些條目以恢復精確的字母順序，以便更容易地與處理腳本的輸出進行比較。向後移植到所有支援的分支，這是我們更新時區資料的慣例做法。討論：https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/ad740067aea5b643ca2f79da086808573d35b5f4
更新我們使用 CLDR 資訊的 Windows 時區名稱對應。這修正了 win32_tzmap[] 中的一些條目，並根據 CLDR 專案的 windowsZones.xml 檔案新增了一些新條目。非外觀上的變更主要分為四個類別： * 明顯的錯誤： US/Aleutan 不存在 America/Salvador 不存在 Asia/Baku 對於 Yerevan 是錯誤的 Asia/Dhaka (孟加拉國) 對於 Astana (哈薩克) 是錯誤的 Europe/Bucharest 對於 Chisinau 是錯誤的 America/Mexico_City 對於 Chetumal 是錯誤的 America/Buenos_Aires 對於 Cayenne 是錯誤的 America/Caracas 有自己的時區，因此不適合 La Paz US/Eastern 對於海地是錯誤的 US/Eastern 對於印第安納州 (東部) 是錯誤的 Asia/Karachi 對於塔什干是錯誤的 Etc/UTC+12 不存在 Etc/GMT 時區的符號是反向的 * 判斷性決定： (這些變更遵循 CLDR 的選擇，除了第一個) 使用 Europe/London 作為 "Greenwich Standard Time"，因為這似乎比 Africa/Casablanca 更可能是人們認為該時區名稱的含義。CLDR 在這裡使用 Atlantic/Reykjavik，但也好不到哪裡去。 Asia/Shanghai 似乎比香港更適合 "China Standard Time"。 Europe/Sarajevo 現在是貝爾格萊德的連結，即 "Central Europe Standard Time"；因此使用 Warsaw 作為 "Central European Standard Time"。 America/Sao_Paulo 似乎比 Araguaina 更能代表 "E. South America Standard Time"。 Africa/Johannesburg 似乎比 Harare 更能代表 "South Africa Standard Time"。 * 新的 Windows 時區名稱： "Israel Standard Time" "Kaliningrad Standard Time" "Russia Time Zone N" 對於不同的 N "Singapore Standard Time" "South Sudan Standard Time" "W. Central Africa Standard Time" "West Bank Standard Time" "Yukon Standard Time" 其中一些替換了舊的拼寫，但我保留了舊的拼寫，以防我們的程式碼在具有舊資料的機器上運行。 * 將別名 (tzdb Links) 替換為底層的城市名稱時區： (這遵循 tzdb 長期的做法，並減少與其他條目以及 CLDR 的不一致性。) US/Alaska Asia/Kuwait Asia/Muscat Canada/Atlantic Australia/Canberra Canada/Saskatchewan US/Central US/Eastern US/Hawaii US/Mountain Canada/Newfoundland US/Pacific 回溯修補到所有支援的分支，這是我們通常對時區資料更新的做法。 討論： https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9b8d68cc6589814d121344f59e927a7e4506fb8c
修正 plpgsql 中 RETURN QUERY 命令的查詢類型檢查。 在 v14 之前，我們堅持 RETURN QUERY 中的查詢必須是返回元組的類型。(例如，允許 INSERT RETURNING，但不允許普通的 INSERT。) 這是間接發生的，因為我們為查詢開啟了一個游標，因此 spi.c 檢查了 SPI_is_cursor_plan()。 因此，錯誤訊息並不是特別到位，但至少它在那裡。 Commit 2f48ede08 遺失了這個細節。 相反，普通的 RETURN QUERY 堅持查詢必須是 SELECT (透過檢查 SPI_OK_SELECT)，而 RETURN QUERY EXECUTE 完全沒有檢查查詢類型。 這些變更都不是有意的。 在 EXECUTE 案例中檢查此問題的唯一方便的地方是在 _SPI_execute_plan 內部，因為我們在那之前沒有進行過語法分析。 因此，我們需要傳遞一個標誌來說明是否強制查詢返回元組。 幸運的是，我們可以在不中斷 ABI 的情況下將另一個布林值擠入 struct SPIExecuteOptions 中，因為那裡有填充空間。(不太可能有任何擴充程式已經在使用這個新的結構，但在 v14 中保留 ABI 似乎是一個明智的想法。) 在 spi.c 內部，似乎 _SPI_execute_plan 的參數列表已經非常荒謬，我不想讓它更長。 因此，我考慮將 SPIExecuteOptions 按原樣傳遞下去，允許該參數列表變得更短。 這使得這個修補程式比其他情況更具侵入性，但這一切都在 spi.c 內部，所以這似乎沒問題。 根據 Marc Bachmann 的報告。 回溯修補到出現錯誤程式碼的 v14。 討論： https://postgr.es/m/1F2F75F0-27DF-406F-848D-8B50C7EEF06A@gmail.com https://git.postgresql.org/pg/commitdiff/a0558cfa395b47adb245972f5eba7978461e7baa
Peter Eisentraut 推送了
支援序列的 amcheck。 序列被排除在 verify_heapam 知道如何檢查的關係類型列表中，儘管允許它們相當簡單。 這樣做，並且同時更新 pg_amcheck 以將序列包含在 table 和 relation 模式匹配的關係中。 作者：Mark Dilger mark.dilger@enterprisedb.com 討論： https://postgres.tw/message-id/flat/81ad4757-92c1-4aa3-7bee-f609544837e3%40enterprisedb.com https://git.postgresql.org/pg/commitdiff/c3b011d9918100c6ec2d72297fb51635bce70e80
修正不正確的格式佔位符。 https://git.postgresql.org/pg/commitdiff/0b947c3101d1d05c55531731d6b778f82cb21350
psql：新增各種測試。 新增 psql 功能的測試 - AUTOCOMMIT - ON_ERROR_ROLLBACK - ECHO 錯誤 Reviewed-by: Fabien COELHO coelho@cri.ensmp.fr 討論： https://postgres.tw/message-id/6954328d-96f2-77f7-735f-7ce493a40949%40enterprisedb.com https://git.postgresql.org/pg/commitdiff/14d755b00037ce04b9e24504f4b540d9e731c29e
Magnus Hagander 推送了
Fujii Masao 推送了
pgbench：更正 socket wait 方法失敗時的訊息輸出日誌層級。 像 "select()" 這樣的 socket wait 方法的失敗不會終止 pgbench。 因此，發生故障時的錯誤訊息的日誌層級應為 ERROR。 但以前在這種情況下使用了 FATAL。 回溯修補到 pgbench 開始使用通用日誌記錄 API 的 v13。 作者：Yugo Nagata, Fabien COELHO Reviewed-by: Kyotaro Horiguchi, Fujii Masao 討論： https://postgr.es/m/20210617005934.8bd37bf72efd5f1b38e6f482@sraoss.co.jp https://git.postgresql.org/pg/commitdiff/d33674708948e10806480ee628b072a2ef8ecba1
pgbench：修正在基準測試期間處理 socket 錯誤。 以前，基準測試期間的 socket 錯誤，例如無效的 socket 或 socket wait 方法失敗，會導致 pgbench 以狀態 0 退出。 相反，運行期間的錯誤應導致退出狀態 2。 回溯修補到 pgbench 開始報告退出狀態的 v12。 原始投訴和修補程式由 Hayato Kuroda 提供。 作者：Yugo Nagata, Fabien COELHO Reviewed-by: Kyotaro Horiguchi, Fujii Masao 討論： https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com https://git.postgresql.org/pg/commitdiff/2acb7cc6b56c2b80029c202217e19553578456e9
Álvaro Herrera 推送了
修正不完整紀錄存在時的 WAL 重播問題。實體複製總是會在 WAL 區段檔完成後，立即將它們傳送到副本。如果一個 WAL 紀錄跨越了區段邊界，而且主要伺服器在寫入包含該 WAL 紀錄的下一部分的區段之前崩潰，就會產生問題：崩潰恢復後的 WAL 寫入會很高興地從損壞紀錄開始的地方繼續，覆寫該紀錄...但是任何備用伺服器或備份伺服器可能已經收到該區段的副本，而且它們不會回溯。這會導致備用伺服器在主要伺服器崩潰後停止追隨主要伺服器：LOG: invalid contrecord length 7262 at A8/D9FFFBC8，因為備用伺服器仍然試圖讀取原始長 WAL 紀錄的連續紀錄 (contrecord)，但是它不存在，而且永遠不會存在。一個權宜之計是停止副本，刪除 WAL 檔案，然後重新啟動它--此時會從主要伺服器攜帶一份全新的副本。但這相當費力，而且我敢打賭很多使用者會直接放棄並重新複製備用伺服器。commit 515e3d84a0b5 已經嘗試修復這個問題，但它只解決了 WAL 歸檔的情況，因此串流複製仍然會是一個問題（以及其他事情，例如在伺服器崩潰後關閉時進行檔案系統層級的備份），而且它也存在效能擴充性的問題；因此它必須被還原。這個 commit 使用 Andres Freund 建議的方法來修正這個問題，即保留分割的 WAL 紀錄的初始部分，並在遺失 contrecord 的地方寫入一種特殊的 WAL 紀錄，以便副本中的 WAL 重播知道跳過損壞的部分。使用這種方法，我們可以繼續在區段檔完成後立即串流/歸檔它們，並且損壞紀錄的重播將順利地跨越崩潰點進行。因為新增了一種新的 WAL 紀錄類型，使用者應該小心先升級備用伺服器，然後再升級主要伺服器。否則，如果主要伺服器碰巧寫入這樣的紀錄，他們可能會面臨備用伺服器無法啟動的風險。新增了一個 TAP 測試來練習這個問題，但它的可移植性還有待觀察。這個問題自從引入實體複製以來就一直存在，所以回溯所有版本。在穩定分支中，將新的 XLogReaderState 成員保留在結構體的末尾，以避免 ABI 中斷。作者：Álvaro Herrera alvherre@alvh.no-ip.org 審閱人：Kyotaro Horiguchi horikyota.ntt@gmail.com 審閱人：Nathan Bossart bossartn@amazon.com 討論：https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/ff9f111bce24fd9bbca7a20315586de877d74923
修復新測試的兩個可移植性疏忽。首先，正如 Tom Lane 和 Michael Paquier 指出的那樣，我沒有意識到 Windows 的 PostgresNode 需要額外的 pg_hba.conf 行（由 PostgresNode->set_replication_conf 添加，當給定 'allows_streaming=>1' 時，由 ->init() 在內部呼叫 -- 但我特意省略了這一點）。我認為一個好的修復方法是也為僅設定 'has_archiving=>1' 的節點設定複製，但這是一個更大的討論。通過呼叫 ->set_replication_conf 來修復它，正如 Andrew Dunstan 指出的那樣，這並非前所未聞。我也忘記取消註釋針對可泵 IPC::Run 檔案描述器的 ->finish() 呼叫。顯然，這在幾乎所有平台上都是無害的。回溯到 14。較舊的分支也添加了這個檔案，但沒有添加這個測試的特定部分。討論：https://postgr.es/m/3000074.1632947632@sss.pgh.pa.us 討論：https://postgr.es/m/YVT7qwhR8JmC2kfz@paquier.xyz https://git.postgresql.org/pg/commitdiff/d03bca4d70c29cca4f09e3a0e78a56cf97e237f3
移除不穩定、不必要的測試；修正錯字。Commit ff9f111bce24 添加了一些不可移植且沒有添加有意義覆蓋範圍的測試程式碼。移除它，而不是嘗試讓它在所有地方都能工作。同時，修復上述 commit 添加的日誌訊息中的錯字。回溯到 14。討論：https://postgr.es/m/3000074.1632947632@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d186d233dfde4afb9dff346e13c8adaf4deec6b3
如果同時指定 SKIP LOCKED 和 WITH TIES，則產生錯誤。Bug #16676[1] 和 #17141[2] 都說明了當涉及返回給訪問同一行的其他會話的行時，SKIP LOCKED 和 FETCH FIRST WITH TIES 的組合打破了預期。由於這種情況可以從語法中檢測到，並且很難以其他方式修復，因此目前禁止使用，並有可能在將來修復。[1] https://postgr.es/m/16676-fd62c3c835880da6@postgresql.org [2] https://postgr.es/m/17141-913d78b9675aac8e@postgresql.org Backpatch-through: 13，WITH TIES 在此版本中引入。作者：David Christensen david.christensen@crunchydata.com 討論：https://postgr.es/m/CAOxo6XLPccCKru3xPMaYDpa+AXyPeWFs+SskrrL+HKwDjJnLhg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/c6bc655ee2ef09449da7ff688a8be19a13db5c4a
David Rowley 推送
Amit Kapila 推送
Daniel Gustafsson 推送
Andres Freund 推送