postgres

Commit Graph

Author	SHA1	Message	Date
Heikki Linnakangas	d2f58c42a2	Don't call CheckAttributeType() with InvalidOid on dropped cols If CheckAttributeType() is called with InvalidOid, it performs a bunch of pointless, futile syscache lookups with InvalidOid, but ultimately tolerates it and has no effect. We were calling it with InvalidOid on dropped columns, but it seems accidental that it works, so let's stop doing it. Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://www.postgresql.org/message-id/93ce56cd-02a6-4db1-8224-c8999372facc@iki.fi Backpatch-through: 14	7 hours ago
Heikki Linnakangas	c7a1d5fc65	Don't allow composite type to be member of itself via multirange CheckAttributeType() checks that a composite type is not made a member of itself with ALTER TABLE ADD COLUMN or ALTER TYPE ADD ATTRIBUTE, even indirectly via a domain, array, another composite type or a range type. But it missed checking for multiranges. That was a simple oversight when multiranges were added. Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://www.postgresql.org/message-id/93ce56cd-02a6-4db1-8224-c8999372facc@iki.fi Backpatch-through: 14	7 hours ago
Tom Lane	8a6f08c0c7	Guard against overly-long numeric formatting symbols from locale. to_char() allocates its output buffer with 8 bytes per formatting code in the pattern. If the locale's currency symbol, thousands separator, or decimal or sign symbol is more than 8 bytes long, in principle we could overrun the output buffer. No such locales exist in the real world, so it seems sufficient to truncate the symbol if we do see it's too long. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/638232.1776790821@sss.pgh.pa.us Backpatch-through: 14	1 day ago
Tom Lane	21a24d7095	Prevent some buffer overruns in spell.c's parsing of affix files. parse_affentry() and addCompoundAffixFlagValue() each collect fields from an affix file into working buffers of size BUFSIZ. They failed to defend against overlength fields, so that a malicious affix file could cause a stack smash. BUFSIZ (typically 8K) is certainly way longer than any reasonable affix field, but let's fix this while we're closing holes in this area. I chose to do this by silently truncating the input before it can overrun the buffer, using logic comparable to the existing logic in get_nextfield(). Certainly there's at least as good an argument for raising an error, but for now let's follow the existing precedent. Reported-by: Igor Stepansky <igor.stepansky@orca.security> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/864123.1776810909@sss.pgh.pa.us Backpatch-through: 14	1 day ago
Tom Lane	6cae0c2bd2	Prevent buffer overrun in spell.c's CheckAffix(). This function writes into a caller-supplied buffer of length 2 * MAXNORMLEN, which should be plenty in real-world cases. However a malicious affix file could supply an affix long enough to overrun that. Defend by just rejecting the match if it would overrun the buffer. I also inserted a check of the input word length against Affix->replen, just to be sure we won't index off the buffer, though it would be caller error for that not to be true. Also make the actual copying steps a bit more readable, and remove an unnecessary requirement for the whole input word to fit into the output buffer (even though it always will with the current caller). The lack of documentation in this code makes my head hurt, so I also reverse-engineered a basic header comment for CheckAffix. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/641711.1776792744@sss.pgh.pa.us Backpatch-through: 14	1 day ago
Michael Paquier	d809b16d1b	Allow ALTER INDEX .. ATTACH PARTITION to validate a parent index This commit tweaks ALTER INDEX .. ATTACH PARTITION to attempt a validation of a parent index in the case where an index is already attached but the parent is not yet valid. This occurs in cases where a parent index was created invalid such as with CREATE INDEX ONLY, but was left invalid after an invalid child index was attached (partitioned indexes set indisvalid to false if at least one partition is !indisvalid, indisvalid is true in a partitioned table iff all partitions are indisvalid). This could leave a partition tree in a situation where a user could not bring the parent index back to valid after fixing the child index, as there is no built-in mechanism to do so. This commit relies on the fact that repeated ATTACH PARTITION commands on the same index silently succeed. An invalid parent index is more than just a passive issue. It causes for example ON CONFLICT on a partitioned table if the invalid parent index is used to enforce a unique constraint. Some test cases are added to track some of problematic patterns, using a set of partition trees with combinations of invalid indexes and ATTACH PARTITION. Reported-by: Mohamed Ali <moali.pg@gmail.com> Author: Sami Imseih <sanmimseih@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Haibo Yan <tristan.yim@gmail.com> Discussion: http://postgr.es/m/CAGnOmWqi1D9ycBgUeOGf6mOCd2Dcf=6sKhbf4sHLs5xAcKVCMQ@mail.gmail.com Backpatch-through: 14	2 days ago
Tom Lane	babf2f740d	Make plpgsql_trap test more robust and less resource-intensive. We were using "select count(*) into x from generate_series(1, 1_000_000_000_000)" to waste one second waiting for a statement timeout trap. Aside from consuming CPU to little purpose, this could easily eat several hundred MB of temporary file space, which has been observed to cause out-of-disk-space errors in the buildfarm. Let's just use "pg_sleep(10)", which is far less resource-intensive. Also update the "when others" exception handler so that if it does ever again trap an error, it will tell us what error. The cause of these intermittent buildfarm failures had been obscure for awhile. Discussion: https://postgr.es/m/557992.1776779694@sss.pgh.pa.us Backpatch-through: 14	2 days ago
Richard Guo	8e39951bea	Fix incorrect NEW references to generated columns in rule rewriting When a rule action or rule qualification references NEW.col where col is a generated column (stored or virtual), the rewriter produces incorrect results. rewriteTargetListIU removes generated columns from the query's target list, since stored generated columns are recomputed by the executor and virtual ones store nothing. However, ReplaceVarsFromTargetList then cannot find these columns when resolving NEW references during rule rewriting. For UPDATE, the REPLACEVARS_CHANGE_VARNO fallback redirects NEW.col to the original target relation, making it read the pre-update value (same as OLD.col). For INSERT, REPLACEVARS_SUBSTITUTE_NULL replaces it with NULL. Both are wrong when the generated column depends on columns being modified. Fix by building target list entries for generated columns from their generation expressions, pre-resolving the NEW.attribute references within those expressions against the query's targetlist, and passing them together with the query's targetlist to ReplaceVarsFromTargetList. Back-patch to all supported branches. Virtual generated columns were added in v18, so the back-patches in pre-v18 branches only handle stored generated columns. Reported-by: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> Author: Richard Guo <guofenglinux@gmail.com> Author: Dean Rasheed <dean.a.rasheed@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAHg+QDexGTmCZzx=73gXkY2ZADS6LRhpnU+-8Y_QmrdTS6yUhA@mail.gmail.com Backpatch-through: 14	3 days ago
Fujii Masao	f33874c3a9	doc: Correct context description for some JIT support GUCs The documentation for jit_debugging_support and jit_profiling_support previously stated that these parameters can only be set at server start. However, both parameters use the PGC_SU_BACKEND context, meaning they can be set at session start by superusers, but cannot be changed within an active session. This commit updates the documentation to reflect the actual behavior. Backpatch to all supported versions. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CAHGQGwEpMDpB-K8SSUVRRHg6L6z3pLAkekd9aviOS=ns0EC=+Q@mail.gmail.com Backpatch-through: 14	3 days ago
Fujii Masao	0a26194683	doc: Improve description of pg_ctl -l log file permissions The documentation stated only that the log file created by pg_ctl -l is inaccessible to other users by default. However, since commit `c37b3d0`, the actual behavior is that only the cluster owner has access by default, but users in the same group as the cluster owner may also read the file if group access is enabled in the cluster. This commit updates the documentation to describe this behavior more clearly. Backpatch to all supported versions. Author: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Andreas Karlsson <andreas@proxel.se> Reviewed-by: Xiaopeng Wang <wxp_728@163.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/OS9PR01MB1214959BE987B4839E3046050F54BA@OS9PR01MB12149.jpnprd01.prod.outlook.com Backpatch-through: 14	7 days ago
Thomas Munro	e5fb1ff5be	Fix comments for Korean encodings in encnames.c * JOHAB: replace the incorrect "simplified Chinese" description with a correct one that identifies it as the Korean combining (Johab) encoding standardized in KS X 1001 annex 3. * EUC_KR: drop a stray space before the comma in the existing comment, and note that the encoding covers the KS X 1001 precomposed (Wansung) form. * UHC: spell out "Unified Hangul Code", clarify that it is Microsoft Windows CodePage 949, and describe its relationship to EUC-KR (superset covering all 11,172 precomposed Hangul syllables). Backpatch-through: 14 Author: Henson Choi <assam258@gmail.com> Discussion: https://postgr.es/m/CAAAe_zAFz1v-3b7Je4L%2B%3DwZM3UGAczXV47YVZfZi9wbJxspxeA%40mail.gmail.com	1 week ago
Michael Paquier	e138b78cdc	Add tests for low-level PGLZ [de]compression routines The goal of this module is to provide an entry point for the coverage of the low-level compression and decompression PGLZ routines. The new test is moved to a new parallel group, with all the existing compression-related tests added to it. This includes tests for the cases detected by fuzzing that emulate corrupted compressed data, as fixed by 2b5ba2a0a141: - Set control bit with read of a match tag, where no data follows. - Set control bit with read of a match tag, where 1 byte follows. - Set control bit with match tag where length nibble is 3 bytes (extended case). While on it, some tests are added for compress/decompress roundtrips, and for check_complete=false/true. Like `2b5ba2a0a1`, backpatch to all the stable branches. Discussion: https://postgr.es/m/adw647wuGjh1oU6p@paquier.xyz Backpatch-through: 14	1 week ago
Andrew Dunstan	de32a01e7b	Fix heap-buffer-overflow in pglz_decompress() on corrupt input. When decoding a match tag, pglz_decompress() reads 2 bytes (or 3 for extended-length matches) from the source buffer before checking whether enough data remains. The existing bounds check (sp > srcend) occurs after the reads, so truncated compressed data that ends mid-tag causes a read past the allocated buffer. Fix by validating that sufficient source bytes are available before reading each part of the match tag. The post-read sp > srcend check is no longer needed and is removed. Found by fuzz testing with libFuzzer and AddressSanitizer. Backpatch-through: 14	2 weeks ago
Tatsuo Ishii	a7c41df1f2	Enhance make_ctags and make_etags. make_ctags did not include field members of structs since the commit `964d01ae90`. For example, in the following field of RestrictInfo: Selectivity norm_selec pg_node_attr(equal_ignore); pg_node_attr was mistakenly interpreted to be the name of the field. To fix this, add -I option to ctags command if the command is Exuberant ctags or Universal ctags (for plain old ctags, struct members are not included in the tags file anyway). Also add "-e" and "-n" options to make_ctags. The -e option invokes ctags command with -e option, which produces TAGS file for emacs. This allows to eliminate duplicate codes in make_etags so that make_etags just exec make_ctags with -e option. The -n option allows not to produce symbolic links in each sub directory (the default is producing symbolic links). This includes the follow-up fixes: `87f21d2c68` and `ae66716bf3`. This change is applied to v15 and v14, v16 and nwer versions already including these improvements. One reason why I am doing this backpatch is that this can be really useful for backpatching purposes, especially the -n option that limits the number of TAGS/tags files created in the tree. Author: Yugo Nagata Reviewers: Alvaro Herrera, Tatsuo Ishii Discussion: https://postgr.es/m/flat/20221007154442.76233afc7c5b255c4de6528a%40sraoss.co.jp Discussion: https://postgr.es/m/adcKr7fob5ZvjhlH@paquier.xyz Backpatch-through: 14	2 weeks ago
Richard Guo	305cf0df0c	Fix integer overflow in nodeWindowAgg.c In nodeWindowAgg.c, the calculations for frame start and end positions in ROWS and GROUPS modes were performed using simple integer addition. If a user-supplied offset was sufficiently large (close to INT64_MAX), adding it to the current row or group index could cause a signed integer overflow, wrapping the result to a negative number. This led to incorrect behavior where frame boundaries that should have extended indefinitely (or beyond the partition end) were treated as falling at the first row, or where valid rows were incorrectly marked as out-of-frame. Depending on the specific query and data, these overflows can result in incorrect query results, execution errors, or assertion failures. To fix, use overflow-aware integer addition (ie, pg_add_s64_overflow) to check for overflows during these additions. If an overflow is detected, the boundary is now clamped to INT64_MAX. This ensures the logic correctly treats the boundary as extending to the end of the partition. Bug: #19405 Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/19405-1ecf025dda171555@postgresql.org Backpatch-through: 14	2 weeks ago
Tom Lane	40fa04e7c8	Avoid unsafe access to negative index in a TupleDesc. Commit `aa606b931` installed a test that would reference a nonexistent TupleDesc array entry if a system column is used in COPY FROM WHERE. Typically this would be harmless, but with bad luck it could result in a phony "generated columns are not supported in COPY FROM WHERE conditions" error, and at least in principle it could cause SIGSEGV. (Compare `570e2fcc0` which fixed the identical problem in another place.) Also, since `c98ad086a` it throws an Assert instead. In the back branches, just guard the test to make it a safe no-op for system columns. Commit `21c69dc73` installed a more aggressive answer in master. Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/6f435023-8ab6-47c2-ba07-035d0c4212f9@gmail.com Backpatch-through: 14-18	2 weeks ago
Thomas Munro	9b354cfc55	jit: No backport::SectionMemoryManager for LLVM 22. LLVM 22 has the fix that we copied into our tree in commit `9044fc1d` and a new function to reach it[1][2], so we only need to use our copy for Aarch64 + LLVM < 22. The only change to the final version that our copy didn't get is a new LLVM_ABI macro, but that isn't appropriate for us. Our copy is hopefully now frozen and would only need maintenance if bugs are found in the upstream code. Non-Aarch64 systems now also use the new API with LLVM 22. It allocates all sections with one contiguous mmap() instead of one per section. We could have done that earlier, but commit `9044fc1d` wanted to limit the blast radius to the affected systems. We might as well benefit from that small improvement everywhere now that it is available out of the box. We can't delete our copy until LLVM 22 is our minimum supported version, or we switch to the newer JITLink API for at least Aarch64. [1] https://github.com/llvm/llvm-project/pull/71968 [2] https://github.com/llvm/llvm-project/pull/174307 Backpatch-through: 14 Discussion: https://postgr.es/m/CA%2BhUKGJTumad75o8Zao-LFseEbt%3DenbUFCM7LZVV%3Dc8yg2i7dg%40mail.gmail.com	3 weeks ago
Thomas Munro	b4e7cd428c	jit: Stop emitting lifetime.end for LLVM 22. The lifetime.end intrinsic can now only be used for stack memory allocated with alloca[1][2][3]. We use it to tell LLVM about the lifetime of function arguments/isnull values that we keep in palloc'd memory, so that it can avoid spilling registers to memory. We might need to rearrange things and put them on the stack, but that'll take some research. In the meantime, unbreak the build on LLVM 22. [1] https://github.com/llvm/llvm-project/pull/149310 [2] https://llvm.org/docs/LangRef.html#llvm-lifetime-end-intrinsic [3] https://llvm.org/docs/LangRef.html#i-alloca Backpatch-through: 14 Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> (earlier attempt) Reviewed-by: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> (earlier attempt) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier attempt) Discussion: https://postgr.es/m/CA%2BhUKGJTumad75o8Zao-LFseEbt%3DenbUFCM7LZVV%3Dc8yg2i7dg%40mail.gmail.com	3 weeks ago
Nathan Bossart	9a53249c5b	doc: Add missing description for DROP SUBSCRIPTION IF EXISTS. Oversight in commit `665d1fad99`. Author: Peter Smith <smithpb2250@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAHut%2BPv72haFerrCdYdmF6hu6o2jKcGzkXehom%2BsP-JBBmOVDg%40mail.gmail.com Backpatch-through: 14	3 weeks ago
Tom Lane	7cd23aad2a	Be more careful to preserve consistency of a tuplestore. Several places in tuplestore.c would leave the tuplestore data structure effectively corrupt if some subroutine were to throw an error. Notably, if WRITETUP() failed after some number of successful calls within dumptuples(), the tuplestore would contain some memtuples pointers that were apparently live entries but in fact pointed to pfree'd chunks. In most cases this sort of thing is fine because transaction abort cleanup is not too picky about the contents of memory that it's going to throw away anyway. There's at least one exception though: if a Portal has a holdStore, we're going to call tuplestore_end() on that, even during transaction abort. So it's not cool if that tuplestore is corrupt, and that means tuplestore.c has to be more careful. This oversight demonstrably leads to crashes in v15 and before, if a holdable cursor fails to persist its data due to an undersized temp_file_limit setting. Very possibly the same thing can happen in v16 and v17 as well, though the specific test case submitted failed to fail there (cf. `095555daf`). The failure is accidentally dodged as of v18 because `590b045c3` got rid of tuplestore_end's retail tuple deletion loop. Still, it seems unwise to permit tuplestores to become internally inconsistent in any branch, so I've applied the same fix across the board. Since the known test case for this is rather expensive and doesn't fail in recent branches, I've omitted it. Bug: #19438 Reported-by: Dmitriy Kuzmin <kuzmin.db4@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/19438-9d37b179c56d43aa@postgresql.org Backpatch-through: 14	3 weeks ago
David Rowley	6ce5c310ba	Fix datum_image_()'s inability to detect sign-extension variations Functions such as hash_numeric() are not careful to use the correct PG_RETURN_() macro according to the return type of that function as defined in pg_proc. Because that function is meant to return int32, when the hashed value exceeds 2^31, the 64-bit Datum value won't wrap to a negative number, which means the Datum won't have the same value as it would have had it been cast to int32 on a two's complement machine. This isn't harmless as both datum_image_eq() and datum_image_hash() may receive a Datum that's been formed and deformed from a tuple in some cases, and not in other cases. When formed into a tuple, the Datum value will be coerced into an integer according to the attlen as specified by the TupleDesc. This can result in two Datums that should be equal being classed as not equal, which could result in (but not limited to) an error such as: ERROR: could not find memoization table entry Here we fix this by ensuring we cast the Datum value to a signed integer according to the typLen specified in the datum_image_eq/datum_image_hash function call before comparing or hashing. Author: David Rowley <dgrowleyml@gmail.com> Reported-by: Tender Wang <tndrwang@gmail.com> Backpatch-through: 14 Discussion: https://postgr.es/m/CAHewXNmcXVFdB9_WwA8Ez0P+m_TQy_KzYk5Ri5dvg+fuwjD_yw@mail.gmail.com	4 weeks ago
Heikki Linnakangas	a6d03067ff	Avoid memory leak on error while parsing pg_stat_statements dump file By using palloc() instead of raw malloc(). Reported-by: Gaurav Singh <gaurav.singh@yugabyte.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://www.postgresql.org/message-id/CAEcQ1bYR9s4eQLFDjzzJHU8fj-MTbmRpW-9J-r2gsCn+HEsynw@mail.gmail.com Backpatch-through: 14	4 weeks ago
Fujii Masao	bf7ecf3531	Fix premature NULL lag reporting in pg_stat_replication pg_stat_replication is documented to keep the last measured lag values for a short time after the standby catches up, and then set them to NULL when there is no WAL activity. However, previously lag values could become NULL prematurely even while WAL activity was ongoing, especially in logical replication. This happened because the code cleared lag when two consecutive reply messages indicated that the apply location had caught up with the send location. It did not verify that the reported positions were unchanged, so lag could be cleared even when positions had advanced between messages. In logical replication, where the apply location often quickly catches up, this issue was more likely to occur. This commit fixes the issue by clearing lag only when the standby reports that it has fully replayed WAL (i.e., both flush and apply locations have caught up with the send location) and the write/flush/apply positions remain unchanged across two consecutive reply messages. The second message with unchanged positions typically results from wal_receiver_status_interval, so lag values are cleared after that interval when there is no activity. This avoids showing stale lag data while preventing premature NULL values. Even with this fix, lag may rarely become NULL during activity if identical position reports are sent repeatedly. Eliminating such duplicate messages would address this fully, but that change is considered too invasive for stable branches and will be handled in master only later. Backpatch to all supported branches. Author: Shinya Kato <shinya11.kato@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAOzEurTzcUrEzrH97DD7+Yz=HGPU81kzWQonKZvqBwYhx2G9_A@mail.gmail.com Backpatch-through: 14	4 weeks ago
John Naylor	4dc9346531	Fix copy-paste error in test_ginpostinglist The check for a mismatch on the second decoded item pointer was an exact copy of the first item pointer check, comparing orig_itemptrs[0] with decoded_itemptrs[0] instead of orig_itemptrs[1] with decoded_itemptrs[1]. The error message also reported (0, 1) as the expected value instead of (blk, off). As a result, any decoding error in the second item pointer (where the varbyte delta encoding is exercised) would go undetected. This has been wrong since commit `bde7493d1`, so backpatch to all supported versions. Author: Jianghua Yang <yjhjstz@gmail.com> Discussion: https://postgr.es/m/CAAZLFmSOD8R7tZjRLZsmpKtJLoqjgawAaM-Pne1j8B_Q2aQK8w@mail.gmail.com Backpatch-through: 14	1 month ago
Heikki Linnakangas	e35e466f61	Fix multixact backwards-compatibility with CHECKPOINT race condition If a CHECKPOINT record with nextMulti N is written to the WAL before the CREATE_ID record for N, and N happens to be the first multixid on an offset page, the backwards compatibility logic to tolerate WAL generated by older minor versions (before commit `789d65364c`) failed to compensate for the missing XLOG_MULTIXACT_ZERO_OFF_PAGE record. In that case, the latest_page_number was initialized at the start of WAL replay to the page for nextMulti from the CHECKPOINT record, even if we had not seen the CREATE_ID record for that multixid yet, which fooled the backwards compatibility logic to think that the page was already initialized. To fix, track the last XLOG_MULTIXACT_ZERO_OFF_PAGE that we've seen separately from latest_page_number. If we haven't seen any XLOG_MULTIXACT_ZERO_OFF_PAGE records yet, use SimpleLruDoesPhysicalPageExist() to check if the page needs to be initialized. Reported-by: duankunren.dkr <duankunren.dkr@alibaba-inc.com> Analyzed-by: duankunren.dkr <duankunren.dkr@alibaba-inc.com> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Discussion: https://www.postgresql.org/message-id/c4ef1737-8cba-458e-b6fd-4e2d6011e985.duankunren.dkr@alibaba-inc.com Backpatch-through: 14-18	1 month ago
Jeff Davis	c6f369e585	Fix dependency on FDW handler. ALTER FOREIGN DATA WRAPPER could drop the dependency on the handler function if it wasn't explicitly specified. Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Discussion: https://postgr.es/m/35c44a4b7fb76d35418c4d66b775a88f4ce60c86.camel@j-davis.com Backpatch-through: 14	1 month ago
Fujii Masao	f154714646	Fix WAL flush LSN used by logical walsender during shutdown Commit `6eedb2a5fd` made the logical walsender call XLogFlush(GetXLogInsertRecPtr()) to ensure that all pending WAL is flushed, fixing a publisher shutdown hang. However, if the last WAL record ends at a page boundary, GetXLogInsertRecPtr() can return an LSN pointing past the page header, which can cause XLogFlush() to report an error. A similar issue previously existed in the GiST code. Commit `b1f14c9672` introduced GetXLogInsertEndRecPtr(), which returns a safe WAL insertion end location (returning the start of the page when the last record ends at a page boundary), and updated the GiST code to use it with XLogFlush(). This commit fixes the issue by making the logical walsender use XLogFlush(GetXLogInsertEndRecPtr()) when flushing pending WAL during shutdown. Backpatch to all supported versions. Reported-by: Andres Freund <andres@anarazel.de> Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/vzguaguldbcyfbyuq76qj7hx5qdr5kmh67gqkncyb2yhsygrdt@dfhcpteqifux Backpatch-through: 14	1 month ago
Tomas Vondra	ff78b8fac4	Tighten asserts on ParallelWorkerNumber The comment about ParallelWorkerNumbr in parallel.c says: In parallel workers, it will be set to a value >= 0 and < the number of workers before any user code is invoked; each parallel worker will get a different parallel worker number. However asserts in various places collecting instrumentation allowed (ParallelWorkerNumber == num_workers). That would be a bug, as the value is used as index into an array with num_workers entries. Fixed by adjusting the asserts accordingly. Backpatch to all supported versions. Discussion: https://postgr.es/m/5db067a1-2cdf-4afb-a577-a04f30b69167@vondra.me Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Backpatch-through: 14	1 month ago
Tomas Vondra	c0ffc725f8	Use GetXLogInsertEndRecPtr in gistGetFakeLSN The function used GetXLogInsertRecPtr() to generate the fake LSN. Most of the time this is the same as what XLogInsert() would return, and so it works fine with the XLogFlush() call. But if the last record ends at a page boundary, GetXLogInsertRecPtr() returns LSN pointing after the page header. In such case XLogFlush() fails with errors like this: ERROR: xlog flush request 0/01BD2018 is not satisfied --- flushed only to 0/01BD2000 Such failures are very hard to trigger, particularly outside aggressive test scenarios. Fixed by introducing GetXLogInsertEndRecPtr(), returning the correct LSN without skipping the header. This is the same as GetXLogInsertRecPtr(), except that it calls XLogBytePosToEndRecPtr(). Initial investigation by me, root cause identified by Andres Freund. This is a long-standing bug in gistGetFakeLSN(), probably introduced by `c6b92041d3` in PG13. Backpatch to all supported versions. Reported-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/vf4hbwrotvhbgcnknrqmfbqlu75oyjkmausvy66ic7x7vuhafx@e4rvwavtjswo Backpatch-through: 14	1 month ago
Michael Paquier	70f7c5badc	xml2: Fix failure with xslt_process() under -fsanitize=undefined The logic of xslt_process() has never considered the fact that xsltSaveResultToString() would return NULL for an empty string (the upstream code has always done so, with a string length of 0). This would cause memcpy() to be called with a NULL pointer, something forbidden by POSIX. Like `46ab07ffda` and similar fixes, this is backpatched down to all the supported branches, with a test case to cover this scenario. An empty string has been always returned in xml2 in this case, based on the history of the module, so this is an old issue. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/c516a0d9-4406-47e3-9087-5ca5176ebcf9@gmail.com Backpatch-through: 14	1 month ago
Fujii Masao	a84a9a4260	doc: Document IF NOT EXISTS option for ALTER FOREIGN TABLE ADD COLUMN. Commit `2cd40adb85` added the IF NOT EXISTS option to ALTER TABLE ADD COLUMN. This also enabled IF NOT EXISTS for ALTER FOREIGN TABLE ADD COLUMN, but the ALTER FOREIGN TABLE documentation was not updated to mention it. This commit updates the documentation to describe the IF NOT EXISTS option for ALTER FOREIGN TABLE ADD COLUMN. While updating that section, also this commit clarifies that the COLUMN keyword is optional in ALTER FOREIGN TABLE ADD/DROP COLUMN. Previously, part of the documentation could be read as if COLUMN were required. This commit adds regression tests covering these ALTER FOREIGN TABLE syntaxes. Backpatch to all supported versions. Suggested-by: Fujii Masao <masao.fujii@gmail.com> Author: Chao Li <lic@highgo.com> Reviewed-by: Robert Treat <rob@xzilla.net> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAHGQGwFk=rrhrwGwPtQxBesbT4DzSZ86Q3ftcwCu3AR5bOiXLw@mail.gmail.com Backpatch-through: 14	2 months ago
Michael Paquier	eb11d7a915	Fix size underestimation of DSA pagemap for odd-sized segments When make_new_segment() creates an odd-sized segment, the pagemap was only sized based on a number of usable_pages entries, forgetting that a segment also contains metadata pages, and that the FreePageManager uses absolute page indices that cover the entire segment. This miscalculation could cause accesses to pagemap entries to be out of bounds. During subsequent reuse of the allocated segment, allocations landing on pages with indices higher than usable_pages could cause out-of-bounds pagemap reads and/or writes. On write, 'span' pointers are stored into the data area, corrupting the allocated objects. On read (aka during a dsa_free), garbage is interpreted as a span pointer, typically crashing the server in dsa_get_address(). The normal geometric path correctly sizes the pagemap for all pages in the segment. The odd-sized path needs to do the same, but it works forward from usable_pages rather than backward from total_size. This commit fixes the sizing of the odd-sized case by adding pagemap entries for the metadata pages after the initial metadata_bytes calculation, using an integer ceiling division to compute the exact number of additional entries needed in one go, avoiding any iteration in the calculation. An assertion is added in the code path for odd-sized segments, ensuring that the pagemap includes the metadata area, and that the result is appropriately sized. This problem would show up depending on the size requested for the allocation of a DSA segment. The reporter has noticed this issue when a parallel hash join makes a DSA allocation large enough to trigger the odd-sized segment path, but it could happen for anything that does a DSA allocation. A regression test is added to test_dsa, down to v17 where the test module has been introduced. This adds a set of cheap tests to check the problem, the new assertion being useful for this purpose. Sami has proposed a test that took a longer time than what I have done here; the test committed is faster and good enough to check the odd-sized allocation path. Author: Paul Bunn <paul.bunn@icloud.com> Reviewed-by: Sami Imseih <samimseih@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/044401dcabac$fe432490$fac96db0$@icloud.com Backpatch-through: 14	2 months ago
Fujii Masao	3bf6f22ce1	Fix publisher shutdown hang caused by logical walsender busy loop. Previously, when logical replication was running, shutting down the publisher could cause the logical walsender to enter a busy loop and prevent the publisher from completing shutdown. During shutdown, the logical walsender waits for all pending WAL to be written out. However, some WAL records could remain unflushed, causing the walsender to wait indefinitely. The issue occurred because the walsender used XLogBackgroundFlush() to flush pending WAL. This function does not guarantee that all WAL is written. For example, WAL generated by a transaction without an assigned transaction ID that aborts might not be flushed. This commit fixes the bug by making the logical walsender call XLogFlush() instead, ensuring that all pending WAL is written and preventing the busy loop during shutdown. Backpatch to all supported versions. Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAO6_Xqo3co3BuUVEVzkaBVw9LidBgeeQ_2hfxeLMQcXwovB3GQ@mail.gmail.com Backpatch-through: 14	2 months ago
Fujii Masao	921f4a15c1	doc: Clarify that COLUMN is optional in ALTER TABLE ... ADD/DROP COLUMN. In ALTER TABLE ... ADD/DROP COLUMN, the COLUMN keyword is optional. However, part of the documentation could be read as if COLUMN were required, which may mislead users about the command syntax. This commit updates the ALTER TABLE documentation to clearly state that COLUMN is optional for ADD and DROP. Also this commit adds regression tests covering ALTER TABLE ... ADD/DROP without the COLUMN keyword. Backpatch to all supported versions. Author: Chao Li <lic@highgo.com> Reviewed-by: Robert Treat <rob@xzilla.net> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAEoWx2n6ShLMOnjOtf63TjjgGbgiTVT5OMsSOFmbjGb6Xue1Bw@mail.gmail.com Backpatch-through: 14	2 months ago
Michael Paquier	1346794feb	Fix rare instability in recovery TAP test 004_timeline_switch This fixes a problem similar to `ad8c86d22c`. In this case, the test could fail under the following circumstances: - The primary is stopped with teardown_node(), meaning that it may not be able to send all its WAL records to standby_1 and standby_2. - If standby_2 receives more records than standby_1, attempting to reconnect standby_2 to the promoted standby_1 would fail because of a timeline fork. This race condition is fixed with a simple trick: instead of tearing down the primary, it is stopped cleanly so as all the WAL records of the primary are received and flushed by both standby_1 and standby_2. Once we do that, there is no need for a wait_for_catchup() before stopping the node. The test wants to check that a timeline jump can be achieved when reconnecting a standby to a promoted standby in the same cluster, hence an immediate stop of the primary is not required. This failure is harder to reach than the previous instability of 009_twophase, still the buildfarm has been able to detect this failure at least once. I have tried Alexander Lakhin's test trick with the bgwriter and very aggressive standby snapshots, but I could not reproduce it directly. It is reachable, as the buildfarm has proved. Backpatch down to all supported branches, and this problem can lead to spurious failures in the buildfarm. Discussion: https://postgr.es/m/493401a8-063f-436a-8287-a235d9e065fc@gmail.com Backpatch-through: 14	2 months ago
Álvaro Herrera	e0a9c64635	Don't malloc(0) in EventTriggerCollectAlterTSConfig Author: Florin Irion <florin.irion@enterprisedb.com> Discussion: https://postgr.es/m/c6fff161-9aee-4290-9ada-71e21e4d84de@gmail.com	2 months ago
Heikki Linnakangas	ffe53037df	Skip prepared_xacts test if max_prepared_transactions < 2 This reduces maintenance overhead, as we no longer need to update the dummy expected output file every time the .sql file changes. Discussion: https://www.postgresql.org/message-id/1009073.1772551323@sss.pgh.pa.us Backpatch-through: 14	2 months ago
Michael Paquier	bce98e49e8	Fix rare instability in recovery TAP test 009_twophase The phase of the test where we want to check that 2PC transactions prepared on a primary can be committed on a promoted standby relied on an immediate stop of the primary. This logic has a race condition: it could be possible that some records (most likely standby snapshot records) are generated on the primary before it finishes its shutdown, without the promoted standby know about them. When the primary is recycled as new standby, the test could fail because of a timeline fork as an effect of these extra records. This fix takes care of the instability by doing a clean stop of the primary instead of a teardown (aka immediate stop), so as all records generated on the primary are sent to the promoted standby and flushed there. There is no need for a teardown of the primary in this test scenario: the commit of 2PC transactions on a promoted standby do not care about the state of the primary, only of the standby. This race is very hard to hit in practice, even slow buildfarm members like skink have a very low rate of reproduction. Alexander Lakhin has come up with a recipe to improve the reproduction rate a lot: - Enable -DWAL_DEBUG. - Patch the bgwriter so as standby snapshots are generated every milliseconds. - Run 009_twophase tests under heavy parallelism. With this method, the failure appears after a couple of iterations. With the fix in place, I have been able to run more than 50 iterations of the parallel test sequence, without seeing a failure. Issue introduced in `30820982b2`, due to a copy-pasto coming from the surrounding tests. Thanks also to Hayato Kuroda for digging into the details of the failure. He has proposed a fix different than the one of this commit. Unfortunately, it relied on injection points, feature only available in v17. The solution of this commit is simpler, and can be applied to v14~v16. Reported-by: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/b0102688-6d6c-c86a-db79-e0e91d245b1a@gmail.com Backpatch-through: 14	2 months ago
Fujii Masao	7ab6ac1d7f	doc: Clarify that empty COMMENT string removes the comment. Clarify the documentation of COMMENT ON to state that specifying an empty string is treated as NULL, meaning that the comment is removed. This makes the behavior explicit and avoids possible confusion about how empty strings are handled. Also adds regress test cases that use empty string to remove a comment. Backpatch to all supported versions. Author: Chao Li <lic@highgo.com> Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Reviewed-by: Shengbin Zhao <zshengbin91@gmail.com> Reviewed-by: Jim Jones <jim.jones@uni-muenster.de> Reviewed-by: zhangqiang <zhang_qiang81@163.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/26476097-B1C1-4BA8-AA92-0AD0B8EC7190@gmail.com Backpatch-through: 14	2 months ago
Michael Paquier	858c83b3e6	test_custom_types: Test module with fancy custom data types This commit adds a new test module called "test_custom_types", that can be used to stress code paths related to custom data type implementations. Currently, this is used as a test suite to validate the set of fixes done in `3b7a6fa157`, that requires some typanalyze callbacks that can force very specific backend behaviors, as of: - typanalyze callback that returns "false" as status, to mark a failure in computing statistics. - typanalyze callback that returns "true" but let's the backend know that no interesting stats could be computed, with stats_valid set to "false". This could be extended more in the future if more problems are found. For simplicity, the module uses a fake int4 data type, that requires a btree operator class to be usable with extended statistics. The type is created by the extension, and its properties are altered in the test. Like `3b7a6fa157`, this module is backpatched down to v14, for coverage purposes. Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/aaDrJsE1I5mrE-QF@paquier.xyz Backpatch-through: 14	2 months ago
Michael Paquier	038c7d4a3b	Fix set of issues with extended statistics on expressions This commit addresses two defects regarding extended statistics on expressions: - When building extended statistics in lookup_var_attr_stats(), the call to examine_attribute() did not account for the possibility of a NULL return value. This can happen depending on the behavior of a typanalyze callback — for example, if the callback returns false, if no rows are sampled, or if no statistics are computed. In such cases, the code attempted to build MCV, dependency, and ndistinct statistics using a NULL pointer, incorrectly assuming valid statistics were available, which could lead to a server crash. - When loading extended statistics for expressions, statext_expressions_load() did not account for NULL entries in the pg_statistic array storing expression statistics. Such NULL entries can be generated when statistics collection fails for an expression, as may occur during the final step of serialize_expr_stats(). An extended statistics object defining N expressions requires N corresponding elements in the pg_statistic array stored for the expressions, and some of these elements can be NULL. This situation is reachable when a typanalyze callback returns true, but sets stats_valid to indicate that no useful statistics could be computed. While these scenarios cannot occur with in-core typanalyze callbacks, as far as I have analyzed, they can be triggered by custom data types with custom typanalyze implementations, at least. No tests are added in this commit. A follow-up commit will introduce a test module that can be extended to cover similar edge cases if additional issues are discovered. This takes care of the core of the problem. Attribute and relation statistics already offer similar protections: - ANALYZE detects and skips the build of invalid statistics. - Invalid catalog data is handled defensively when loading statistics. This issue exists since the support for extended statistics on expressions has been added, down to v14 as of `a4d75c86bf`. Backpatch to all supported stable branches. Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Corey Huinker <corey.huinker@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/aaDrJsE1I5mrE-QF@paquier.xyz Backpatch-through: 14	2 months ago
Etsuro Fujita	e72bde9017	postgres_fdw: Fix thinko in comment for UserMappingPasswordRequired(). This commit also rephrases this comment to improve readability. Oversight in commit `6136e94dc`. Reported-by: Etsuro Fujita <etsuro.fujita@gmail.com> Author: Andreas Karlsson <andreas@proxel.se> Co-authored-by: Etsuro Fujita <etsuro.fujita@gmail.com> Discussion: https://postgr.es/m/CAPmGK16pDnM_wU3kmquPj-M9MYqG3y0BdntRZ0eytqbCaFY3WQ%40mail.gmail.com Backpatch-through: 14	2 months ago
Jeff Davis	058710d415	Fix more multibyte issues in ltree. Commit `84d5efa7e3` missed some multibyte issues caused by short-circuit logic in the callers. The callers assumed that if the predicate string is longer than the label string, then it couldn't possibly be a match, but it can be when using case-insensitive matching (LVAR_INCASE) if casefolding changes the byte length. Fix by refactoring to get rid of the short-circuit logic as well as the function pointer, and consolidate the logic in a replacement function ltree_label_match(). Discussion: https://postgr.es/m/02c6ef6cf56a5013ede61ad03c7a26affd27d449.camel@j-davis.com Backpatch-through: 14	2 months ago
Tom Lane	746dae69c3	Fix Solution.pm for change in pg_config.h contents. In commits `1d97e4788` et al, I forgot that pre-v17 branches require updating Solution.pm when changing the set of symbols generated in pg_config.h. Per buildfarm.	2 months ago
Tom Lane	231570d335	Use CXXFLAGS instead of CFLAGS for linking C++ code Otherwise, this would break if using C and C++ compilers from different families and they understand different options. It already used the right flags for compiling, this is only for linking. Also, the meson setup already did this correctly. Back-patch of v18 commit `365b5a345` into older supported branches. At the time we were only aware of trouble in v18, but as shown by buildfarm member siren, older branches can hit the problem too. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Author: Peter Eisentraut <peter@eisentraut.org> Discussion: https://www.postgresql.org/message-id/228700.1722717983@sss.pgh.pa.us Discussion: https://postgr.es/m/3109540.1771698685@sss.pgh.pa.us Backpatch-through: 14-17	2 months ago
Noah Misch	e056563066	EUC_CN, EUC_JP, EUC_KR, EUC_TW: Skip U+00A0 tests instead of failing. Settings that ran the new test euc_kr.sql to completion would fail these older src/pl tests. Use alternative expected outputs, for which psql \gset and \if have reduced the maintenance burden. This fixes "LANG=ko_KR.euckr LC_MESSAGES=C make check-world". (LC_MESSAGES=C fixes IO::Pty usage in tests 010_tab_completion and 001_password.) That file is new in commit `c67bef3f32`. Back-patch to v14, like that commit. Discussion: https://postgr.es/m/20260217184758.da.noahmisch@microsoft.com Backpatch-through: 14	2 months ago
Fujii Masao	ec84a1f16f	doc: Clarify INCLUDING COMMENTS behavior in CREATE TABLE LIKE. The documentation for the INCLUDING COMMENTS option of the LIKE clause in CREATE TABLE was inaccurate and incomplete. It stated that comments for copied columns, constraints, and indexes are copied, but regarding comments on constraints in reality only comments on CHECK and NOT NULL constraints are copied; comments on other constraints (such as primary keys) are not. In addition, comments on extended statistics are copied, but this was not documented. The CREATE FOREIGN TABLE documentation had a similar omission: comments on extended statistics are also copied, but this was not mentioned. This commit updates the documentation to clarify the actual behavior. The CREATE TABLE reference now specifies that comments on copied columns, CHECK constraints, NOT NULL constraints, indexes, and extended statistics are copied. The CREATE FOREIGN TABLE reference now notes that comments on extended statistics are copied as well. Backpatch to all supported versions. Documentation updates related to CREATE FOREIGN TABLE LIKE and NOT NULL constraint comment copying are not applied to v17 and earlier, since those features were introduced in v18. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHSOSGcaYDvHF8EYCUCfGPjbRwGFsJ23cx5KbJ1X6JouQ@mail.gmail.com Backpatch-through: 14	2 months ago
Fujii Masao	5d2dec77ef	Fix ProcWakeup() resetting wrong waitStart field. Previously, when one process woke another that was waiting on a lock, ProcWakeup() incorrectly cleared its own waitStart field (i.e., MyProc->waitStart) instead of that of the process being awakened. As a result, the awakened process retained a stale lock-wait start timestamp. This did not cause user-visible issues. pg_locks.waitstart was reported as NULL for the awakened process (i.e., when pg_locks.granted is true), regardless of the waitStart value. This bug was introduced by commit `46d6e5f567`. This commit fixes this by resetting the waitStart field of the process being awakened in ProcWakeup(). Backpatch to all supported branches. Reported-by: Chao Li <li.evan.chao@gmail.com> Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: ji xu <thanksgreed@gmail.com> Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de> Discussion: https://postgr.es/m/537BD852-EC61-4D25-AB55-BE8BE46D07D7@gmail.com Backpatch-through: 14	2 months ago
Tom Lane	ff9bd96754	Allow PG_PRINTF_ATTRIBUTE to be different in C and C++ code. Although clang claims to be compatible with gcc's printf format archetypes, this appears to be a falsehood: it likes __syslog__ (which gcc does not, on most platforms) and doesn't accept gnu_printf. This means that if you try to use gcc with clang++ or clang with g++, you get compiler warnings when compiling printf-like calls in our C++ code. This has been true for quite awhile, but it's gotten more annoying with the recent appearance of several buildfarm members that are configured like this. To fix, run separate probes for the format archetype to use with the C and C++ compilers, and conditionally define PG_PRINTF_ATTRIBUTE depending on __cplusplus. (We could alternatively insist that you not mix-and-match C and C++ compilers; but if the case works otherwise, this is a poor reason to insist on that.) This commit back-patches `0909380e4` into supported branches. Discussion: https://postgr.es/m/986485.1764825548@sss.pgh.pa.us Discussion: https://postgr.es/m/3988414.1771950285@sss.pgh.pa.us Backpatch-through: 14-18	2 months ago
Tom Lane	244c047205	Fix some cases of indirectly casting away const. Newest versions of gcc+glibc are able to detect cases where code implicitly casts away const by assigning the result of strchr() or a similar function applied to a "const char " value to a target variable that's just "char ". This of course creates a hazard of not getting a compiler warning about scribbling on a string one was not supposed to, so fixing up such cases is good. This patch fixes a dozen or so places where we were doing that. Most are trivial additions of "const" to the target variable, since no actually-hazardous change was occurring. Thanks to Bertrand Drouvot for finding a couple more spots than I had. This commit back-patches relevant portions of `8f1791c61` and `9f7565c6c` into supported branches. However, there are two places in ecpg (in v18 only) where a proper fix is more complicated than seems appropriate for a back-patch. I opted to silence those two warnings by adding casts. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/1324889.1764886170@sss.pgh.pa.us Discussion: https://postgr.es/m/3988414.1771950285@sss.pgh.pa.us Backpatch-through: 14-18	2 months ago

1 2 3 4 5 ...

53927 Commits (REL_14_STABLE) All Branches Search

53927 Commits (REL_14_STABLE)

All Branches