Cherry-pick Apache Cloudberry → REL_2_STABLE - #60
Closed
Alena0704 wants to merge 218 commits into
Closed
Conversation
Alena0704
changed the title
Alena0704
force-pushed
the
cherry-apache-rel2
branch
6 times, most recently
from
September 3, 2026 20:59
4c91eee to
81f09ae
Compare
When the relkind of a relache entry changes, because a table is converted into a view, pgstats can get confused in 15+, leading to crashes or assertion failures. For HEAD, Tom fixed this in b23cd18, by removing support for converting a table to a view, removing the source of the inconsistency. This commit just adds an assertion that a relcache entry's relkind does not change, just in case we end up with another case of that in the future. As there's no cases of changing relkind anymore, we can't add a test that that's handled correctly. For 15, fix the problem by not maintaining the association with the old pgstat entry when the relkind changes during a relcache invalidation processing. In that case the pgstat entry needs to be unlinked first, to avoid PgStat_TableStatus->relation getting out of sync. Also add a test reproducing the issues. No known problem exists in 11-14, so just add the test there. Reported-by: vignesh C <vignesh21@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com Backpatch: 15-
When pg_dump retrieves the list of database objects and performs the data dump, there was possibility that objects are replaced with others of the same name, such as views, and access them. This vulnerability could result in code execution with superuser privileges during the pg_dump process. This issue can arise when dumping data of sequences, foreign tables (only 13 or later), or tables registered with a WHERE clause in the extension configuration table. To address this, pg_dump now utilizes the newly introduced restrict_nonsystem_relation_kind GUC parameter to restrict the accesses to non-system views and foreign tables during the dump process. This new GUC parameter is added to back branches too, but these changes do not require cluster recreation. Back-patch to all supported branches. Reviewed-by: Noah Misch Security: CVE-2024-7348 Backpatch-through: 12
Full and right outer joins were not supported in the initial implementation of Parallel Hash Join because of deadlock hazards (see discussion). Therefore FULL JOIN inhibited parallelism, as the other join strategies can't do that in parallel either. Add a new PHJ phase PHJ_BATCH_SCAN that scans for unmatched tuples on the inner side of one batch's hash table. For now, sidestep the deadlock problem by terminating parallelism there. The last process to arrive at that phase emits the unmatched tuples, while others detach and are free to go and work on other batches, if there are any, but otherwise they finish the join early. That unfairness is considered acceptable for now, because it's better than no parallelism at all. The build and probe phases are run in parallel, and the new scan-for-unmatched phase, while serial, is usually applied to the smaller of the two relations and is either limited by some multiple of work_mem, or it's too big and is partitioned into batches and then the situation is improved by batch-level parallelism. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CA%2BhUKG%2BA6ftXPz4oe92%2Bx8Er%2BxpGZqto70-Q_ERwRaSyA%3DafNg%40mail.gmail.com
Hash join tuples reuse the HOT status bit to indicate match status during hash join execution. Correct reuse requires clearing the bit in all tuples. Serial hash join and parallel multi-batch hash join do so upon inserting the tuple into the hashtable. Single batch parallel hash join and batch 0 of unexpected multi-batch hash joins forgot to do this. It hadn't come up before because hashtable tuple match bits are only used for right and full outer joins and parallel ROJ and FOJ were unsupported. 11c2d6f introduced support for parallel ROJ/FOJ but neglected to ensure the match bits were reset. Author: Melanie Plageman <melanieplageman@gmail.com> Reported-by: Richard Guo <guofenglinux@gmail.com> Discussion: https://postgr.es/m/flat/CAMbWs48Nde1Mv%3DBJv6_vXmRKHMuHZm2Q_g4F6Z3_pn%2B3EV6BGQ%40mail.gmail.com
As reported by buildfarm member conchuela, one of the regression tests added by 558c9d7 is having some ordering issues. This commit adds an ORDER BY clause to make the output more stable for the problematic query. Fix suggested by Tom Lane. The plan of the query updated still uses a parallel hash full join. Author: Melanie Plageman Discussion: https://postgr.es/m/623596.1684541098@sss.pgh.pa.us
cbdb_parallel.sql: add a new test block covering:
- Parallel Hash Full Join (HashedWorkers FULL JOIN HashedWorkers
produces HashedOJ with parallel_workers=2)
- Parallel Hash Right Join (pj_t1 is 3x larger than pj_t2, so the
planner hashes the smaller pj_t2 and probes with pj_t1; result
locus HashedWorkers)
- Correctness checks: count(*) matches serial execution
- Locus propagation: HashedOJ(parallel) followed by INNER JOIN
produces HashedOJ; followed by FULL JOIN produces HashedOJ
join_hash.sql/out: CBDB-specific adaptations for the upstream parallel
full join test -- disable parallel mode for tests that require serial
plans, fix SAVEPOINT inside a parallel worker context, and update
expected output to match CBDB plan shapes.
Add yagp_hooks_collector, a shared-preload module that hooks into ExecutorStart and ExecutorFinish to capture query lifecycle events. Includes Makefile with protobuf code generation, GRPC-based delivery, QueryInfo generation (query text, plan text, query_id, plan_id, session metadata), and basic protobuf message filling.
Guard against NULL plan state when generating EXPLAIN output.
… normalized texts Collect spill info (file count, bytes written). Generate normalized query and plan texts using a pg_stat_statements-derived parser. Collect buffer I/O counters, tuple counts, timing, and /proc/self CPU/memory/IO statistics.
…ility Use query_info_collect_hook for finer-grained lifecycle tracking. Fix two segfaults in early init paths. Skip hooks in UTILITY mode. General robustness improvements.
…ion GUCs Add missing Greenplum node types to pg_stat_statements parser. Move stats reporting to ExecutorEnd hook. Improve GRPC failure handling. Track CDB-specific metrics and initial query nesting level. Add resource group collection. Add GUCs for controlling collection. Skip nested and utility statements by default.
…safety Capture /proc stats at query start and compute diff at end rather than reporting lifetime totals. Suppress error rethrows from the collector to avoid breaking other extensions. Add missing hooks deinitialization. Modernize ereport style.
…ocesses Delay initialization of static singletons and GRPC connections to actual query handling time rather than _PG_init, since both are incompatible with fork().
Mute PG-destined signals in GRPC reconnection thread. Move debian config to CI. Redirect debug output to log file. Harden memory handling. Remove thread-unsafe logging and dead code.
Add a comma-separated GUC to suppress metrics collection for specified roles. Parse using SplitIdentifierString and cache in an unordered_set.
Remove GRPC dependency. Serialize metrics as protobuf messages and deliver them over a Unix domain socket. Replace server-side message queue with incremental per-query message building. Add clang-format configuration. Use deprecated protobuf API for bionic compatibility.
Add SQL functions stat_messages() and stat_messages_reset() exposing per-segment UDS transport counters: total_messages, send_failures, connection_failures, other_errors, max_message_size.
pax-ic-good-opt-off/on fail on Rocky Linux 10: - 712 bytes | 36.75 + 728 bytes | 35.95 mpp17012_compress_test2 is a zlib-compressed AOCO table, so its exact on-disk size depends on the deflate implementation the platform ships. Rocky 8 and Rocky 9 produce 712 bytes, Rocky 10 produces 728. src/test/regress stopped asserting the exact numbers in be38ff5: the query stays inside start_ignore for reference, and the size and the ratio are checked to be within 10% instead. main's copy of the pax suite carries the same treatment for both the zlib and the rle_type table since the PostgreSQL 16 merge (0f4cf8d); this branch's copy predates that. Take both blocks from main verbatim, so the assertions survive and the two branches do not drift further apart. The rle_type table does not depend on zlib and passes today, but it is included to keep the file in sync.
The core of this patch is to prevent array_to_tsvector() from generating invalid tsvectors. It did not check for overly-long lexemes (so that WordEntry.len fields could overflow), nor did it check that the total "datalen" fits within MAXSTRPOS (so that WordEntry.pos fields could overflow, and the number of entries in the tsvector could be much more than the normal limit). While the field overflows couldn't do anything much worse than produce a corrupted tsvector value, a sufficiently large number of tsvector entries could cause integer overflows in later processing, such as tsvectorout. Another important fix is to prevent tsvectorrecv() from accepting invalid tsvectors. The main problem there is that it did not reject empty-string lexemes. Hence, even though it did (mostly) enforce the MAXSTRPOS limit, it could still produce a result with an unreasonable number of tsvector entries, if they were primarily empty strings. Also, fix tsvectorout's calculation of its required output buffer size: it was multiplying the string lengths by pg_database_encoding_max_length() for no reason. That contributed to the risk of integer overflow there. With valid tsvector input, there's no risk, but there's still no reason to make the output buffer several times bigger than needed. I also tried to make a couple of related routines more robust, and spent some effort on improving the comments in ts_type.h. Also, standardize on a single spelling of the "string is too long for tsvector" message, using %zu instead of an assortment of formats. These changes aren't security per se but came out of inspecting the code for problems. Reported-by: Yuhang Wu <yuhang@depthfirst.com> and Zhenpeng Lin Reported-by: Zheng Yu <zheng@depthfirst.com> Reported-by: Hcamael <baiyjrh@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662
The only overflow hazards I could find in tsquery construction are in QTN2QT(), which builds a flat tsquery datum from the QTNode tree representation used by tsquery_or, tsquery_rewrite, and allied functions. There are two: 1. It seems theoretically possible for the outputs of cntsize() to overflow an int, so I widened them to size_t. There's no hazard certainly in tsquery_or and friends, but tsquery_rewrite could expand the query tree by large multiples (by replacing many identical subtrees with a large replacement tree), so in a 64-bit machine with plenty of available memory it should be possible to build a QTNode tree large enough to cause that. If these counters did overflow then we'd under-allocate the output tsquery and have a heap overwrite problem. size_t is sufficient, since it's counting the size of a subset of an in-memory data structure. We also have to fix the TSQUERY_TOO_BIG() macro to not get confused if sumlen exceeds MaxAllocSize. 2. fillQT() neglects to check that the new "distance" value for a QI_VAL item fits into the available 20-bit field. It's quite easy to reach this, for example by tsquery_or'ing two near-megabyte-sized tsquerys. However, the result is only a corrupt tsquery that does not represent the expected query, so perhaps this doesn't rise to the level of a security bug. Nonetheless it should be fixed. Note: I followed the practice used in other tsquery code of checking each distance value as it's assigned, which means that the last operand string could extend past the MAXSTRPOS boundary. This is a bit different from the pattern used for tsvectors, which insist that the total data length not exceed MAXSTRPOS and thereby avoid making per-item checks. Perhaps that should be harmonized sometime, but for now it's okay for the two types to do this differently as long as each one is self-consistent. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Amit Langote <amitlangote09@gmail.com> Backpatch-through: 14 Security: CVE-2026-14662
setup_regexp_matches() sizes the buffer used to convert matched substrings back from pg_wchar form at the smaller of maxlen*eml and the original string's byte length, on the assumption that such a conversion cannot produce more bytes than the string it came from. That assumption holds only for validly encoded input. But pg_mb2wchar_with_len() silently accepts bytes that are invalid in the database encoding, turning each such byte into one pg_wchar, and converting that back can take more bytes than the input did. A string made of such bytes therefore overruns the conversion buffer by up to its own length, corrupting the following memory. regexp_match(), regexp_matches(), regexp_split_to_table() and regexp_split_to_array() are all affected. Fix by dropping the tighter bound and always allocating maxlen*eml + 1 bytes. Reported-by: Francesco Verardi <frevadiscor89@gmail.com> Author: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-14664
The special case here for estimating conditions involving a ctid column failed to check that the RHS constant is of type tid. While that'd always be true for the built-in operators that reference this selectivity estimator, a maliciously constructed operator could provide a user-controlled Datum value that would get interpreted as an ItemPointer pointer. That at least risks SIGSEGV, and perhaps with a bit of sweat it could be used for server memory disclosure. Reported-by: Hcamael <baiyjrh@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Noah Misch <noah@leadboat.com> Backpatch-through: 14 Security: CVE-2026-14668
MatchNamedCall's arggiven array was declared FUNC_MAX_ARGS long, but we may actually use up to pronallargs elements, and that can be more than FUNC_MAX_ARGS if the function has OUT arguments (cf. ProcedureCreate). Convert it to a palloc'd array. Reported-by: Zheng Yu <zheng@depthfirst.com> Reported-by: ylwangtju <ylwangtju@qq.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-14679
The maximum number of arguments allowed for an aggregate function is FUNC_MAX_ARGS-1 (since the underlying transfn and/or finalfn will be called with one more argument). parse_func.c failed to enforce this, allowing construction of calls that would try to pass FUNC_MAX_ARGS+1 to the underlying functions, resulting in a memory stomp in the executor. Add correct checking there. Since it's possible that a bad call has been stored in a view or SQL function, also add checks in various aggregate-related and window-function-related code that there are not more than FUNC_MAX_ARGS arguments. These will also protect us against the possibility that we're trying to run a stored view that was made by a server executable with different FUNC_MAX_ARGS. (Arguably, that scenario does not qualify as a security problem. But let's just tighten up all of this while we're here, rather than split hairs over whether an overrun is reachable.) Likewise check in compute_function_hashkey. Here the hazard is directly from a pg_proc row, but the scenario is the same. PL/Tcl has a similar issue with a fixed-size string buffer. Let's just replace that buffer with a Tcl_DString, removing the whole issue and making the code look more like what's around it. There are a lot of other FUNC_MAX_ARGS-sized arrays, but the rest have nearby guards already, some with comments explicitly pointing out the hazard of FUNC_MAX_ARGS changing. I also used palloc_array() in a few related places in funcapi.c. Those aren't live hazards AFAICS, but nearby code has been palloc_array-ified already, so it seemed inconsistent to not use it here. Reported-by: Masahiko Sawada <sawada.mshk@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-14679
The CACHESIGN.sign field is a BITVECP, not a TRGM, so you should not use GETSIGN() on it. You don't get a compiler warning because the GETSIGN() macro includes a cast. It resulted in a bogus read beyond end of buffer, which would cause bad split decisions or a crash if you're very unlucky. Reported-by: Mehmet D. INCE <mehmet@mehmetince.net> Backpatch-through: 14 Security: CVE-2026-14678
Some of these could overflow on 32-bit systems with the right input. Convert all cases where we called palloc() with multiplication to fix them. Not all of them were bugs, but it's better to be safe than sorry. Reported-by: Tulya Project, Team Dhiutsa, Bitecope Technologies Private Ltd Backpatch-through: 14 Security: CVE-2026-14677
ECPG assumes that any bytea data it receives from a backend starts with '\x' as its first two bytes, but a check was missed to enforce that. A rogue server sending some garbage bytea data would be able to crash a client, resulting in a client-side DoS, in the most common cases. Reported-by: ylwangtju <ylwangtju@qq.com> Backpatch-through: 14 Security: CVE-2026-16241
The parser accepts any string as an EXTRACT() field name, but deparsing does not quote and escape it accordingly. To fix, quote and escape the field name during deparsing as needed. It might be a good idea to validate the field name during parsing and deparsing, too, but that is left as a future exercise. Reported-by: Ben Morris in collaboration with Claude and Anthropic Research Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Etsuro Fujita <etsuro.fujita@gmail.com> Security: CVE-2026-15741 Backpatch-through: 14
When an EXECUTE or FETCH statement is executed, there are two portals: an outer portal that is created for the EXECUTE or FETCH statement itself, and an inner portal for the statement being executed on its behalf. Before this commit, nothing checked that these two portals agreed on the tuple descriptor of the rows being returned. This can be leveraged to disclose server memory contents and achieve arbitrary code execution. To prevent that, we can make use of an existing safety mechanism, added by Tom Lane in commit 2f48ede, which allows a tuplestore DestReceiver to be informed of the tupleDesc required by the caller, and which will cause an ERROR to occur if that doesn't match the tupleDesc of what emerges from the executor (modulo dropped columns, which aren't an issue in the case at hand). Reported-by: Ben Morris in collaboration with Claude and Anthropic Research Reported-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Michael Paquier <michael@paquier.xyz> Security: CVE-2026-16239
This omission allowed roles without USAGE on a type to create range types that depend on it, which could prevent the owner from changing the type later. Reported-by: Jingzhou Fu <fuboat@outlook.com> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Security: CVE-2026-6470 Backpatch-through: 14
This omission allowed roles without USAGE on a type to create tables that depend on it, which could prevent the owner from changing the type later. Reported-by: Nathan Bossart <nathandbossart@gmail.com> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Security: CVE-2026-6470 Backpatch-through: 14
Role membership, role attribute, and database ownership changes may impact the expected behavior of row-level security policies, but currently the plan cache doesn't take notice. To fix, register syscache callbacks on pg_auth_members, pg_authid, and pg_database that invalidate the role-dependent plans. Changes to other databases' pg_database rows are ignored. Reported-by: Ilya Staroverov <i.staroverov@ftdata.ru> Reported-by: Shinya Kato <shinya11.kato@gmail.com> Author: Ilya Staroverov <i.staroverov@ftdata.ru> Author: Shinya Kato <shinya11.kato@gmail.com> Co-authored-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Security: CVE-2026-14666 Backpatch-through: 14
When we implemented \if ... \endif in psql, we arranged to save/restore the lexer's parenthesis depth counter across any chunk of input that we're ignoring. At the time, that was sufficient, because no other part of PsqlScanState could need to be restored to its prior value. However, commit e717a9a and follow-ons added more state fields that ought to be restored to their prior values. A problem would only be observed if someone tries to \if out a portion of a CREATE FUNCTION/PROCEDURE command that is relevant to BEGIN/END matching, which seems like a pretty unusual usage, so the lack of field reports isn't surprising. Nonetheless it's a bug. To fix, replace the simple counter field in ConditionalStack entries with a pointer to a struct defined by psqlscan_int.h. (In the back branches, keep the old field and associated functions to minimize the risk of API/ABI breakage, even though it seems unlikely that any third-party code is using this. Making the new struct private to psqlscan-related code should prevent API/ABI issues for future additions of this type.) In itself this is only a minor bug fix, but it's prerequisite infrastructure for the fix for CVE-2026-6464, which will add another such field. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Noah Misch <noah@leadboat.com> Backpatch-through: 14 Security: CVE-2026-6464
PGP encryption was using px_cipher_encrypt without checking if any error was returned. When OpenSSL is running in FIPS mode, or when the legacy provider hasn't been loaded, not all ciphers which are supported by the PGP code are available and fail the init step in px_cipher_encrypt. Since the PGP encryption failed to notice this it XORed the non-encrypted block with the plaintext, effectively disabling the encryption. This was found due to a report of PGP encryption not respecting the pgcrypto.builtin_crypto_enabled flag and allowing Blowfish and DES. This however turned out to be a false positive, since the PGP code only use ciphers from OpenSSL and not the built in ciphers. Bug: #19457 Reported-by: Shishir Sharma <ansh01072001@gmail.com> Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://postgr.es/m/19457-4bab15c17aea36c7@postgresql.org Security: CVE-2026-14663 Backpatch-through: 14
The previous commit raises an ERROR during PGP operations if OpenSSL does not support the cipher in use. However, any existing messages created with faulty encryption will no longer be accessible via pgp_[sym|pub]_decrypt(). To help users out of this situation, add a new ignore-cipher-failure option which reverts to the broken behavior during decryption only. A faulty encryption wrapper, created by an OpenSSL configuration that does not support the cipher, can then be stripped back off by that same OpenSSL in order to safely reencrypt it. (Note that when OpenSSL does support the cipher, corrupted messages will not be decrypted regardless of the ignore-cipher-failure setting; this is unchanged.) The new tests add a corrupted Blowfish message for both public- and symmetric-key decryption, resulting in the following test matrix: - Blowfish supported, default behavior: fails to decrypt - Blowfish supported, ignore-cipher-failure: fails to decrypt - Blowfish unsupported, default behavior: fails to load cipher - Blowfish unsupported, ignore-cipher-failure: strips faulty encryption The previous commit's change to the pubkey tests is expanded similarly: correctly encrypted messages cannot be decrypted by an OpenSSL that does not support the cipher, regardless of the option's setting, though the failure mode will change. Suggested-by: Noah Misch <noah@leadboat.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Noah Misch <noah@leadboat.com> Security: CVE-2026-14663 Backpatch-through: 14
This oversight in commit 71ea0d6795 allows a malicious server to inject shell commands into plain-text dump output that are run at restore time on the machine running psql. To fix, interpret all text after \unrestrict until the end of the line as its argument. Reported-by: Lucas Velgus <velgusgus599@gmail.com> Reported-by: Filip Janus <fjanus@redhat.com> Reported-by: Daniel Bakker <daniel@jackds.nl> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Security: CVE-2026-18408 Backpatch-through: 14
While typical abbreviations are only a few bytes long, a user-supplied time_zone setting could specify a much longer abbreviation, enough to overflow to_char's allocation of 12 bytes per format character. If so, throw an error in the same style as commit 9241c84 (CVE-2015-0241). Reported-by: Hcamael <baiyjrh@gmail.com> Reported-by: Amjad Shahzad <amjadshahzad2000@gmail.com> Reported-by: Tan Zhen of AntAISecurityLab <TanZhen.AntAI@outlook.com> Reported-by: Tomer Fichman <tomer@irregular.com> Reported-by: Zheng Yu <zheng@depthfirst.com> Reported-by: Amy Burnett (OpenAI Codex Security) Reported-by: Rick de Jager <rick@v12.sh> Reported-by: Heewon Song <asteria121@78researchlab.com> Reported-by: Sylvie Mayer <smayer@cloudflare.com> Reported-by: Aleksander Alekseev <aleksander@tigerdata.com> Reported-by: Hillai Ben Sasson <hillai.bensasson@wiz.io> Author: Tom Lane <tgl@sss.pgh.pa.us> Backpatch-through: 14 Security: CVE-2026-14669
Revalidation of a plancache entry (after a cache invalidation event) requires acquiring a snapshot. Normally that is harmless, but not if the cached statement is one that needs to run without acquiring a snapshot. We were already aware of that for TransactionStmts, but for some reason hadn't extrapolated to the other statements that PlannedStmtRequiresSnapshot() knows mustn't set a snapshot. This can lead to unexpected failures of commands such as SET TRANSACTION ISOLATION LEVEL. We can fix it in the same way, by excluding those command types from revalidation. However, we can do even better than that: there is no need to revalidate for any statement type for which parse analysis, rewrite, and plan steps do nothing interesting, which is nearly all utility commands. To mechanize this, invent a parser function stmt_requires_parse_analysis() that tells whether parse analysis does anything beyond wrapping a CMD_UTILITY Query around the raw parse tree. If that's what it does, then rewrite and plan will just skip the Query, so that it is not possible for the same raw parse tree to produce a different plan tree after cache invalidation. stmt_requires_parse_analysis() is basically equivalent to the existing function analyze_requires_snapshot(), except that for obscure reasons that function omits ReturnStmt and CallStmt. It is unclear whether those were oversights or intentional. I have not been able to demonstrate a bug from not acquiring a snapshot while analyzing these commands, but at best it seems mighty fragile. It seems safer to acquire a snapshot for parse analysis of these commands too, which allows making stmt_requires_parse_analysis and analyze_requires_snapshot equivalent. In passing this fixes a second bug, which is that ResetPlanCache would exclude ReturnStmts and CallStmts from revalidation. That's surely *not* safe, since they contain parsable expressions. Per bug #18059 from Pavel Kulakov. Back-patch to all supported branches. Discussion: https://postgr.es/m/18059-79c692f036b25346@postgresql.org
Update the release version from 2.1.0-incubating to 2.2.0-incubating in the following files: * configure.ac * configure (regenerated by autoconf 2.69) * pom.xml
We have merged in apache#1843 all fixes that converts PG 14.8 to PG 14.9. Change also the `PG_PACKAGE_VERSION=` value in configure.ac and configure file.
The branch carried two implementations of the same feature: gp_toolkit (as in apache/cloudberry) and contrib/pg_aux_catalog (open-gpdb's own relocation of it). Both export pg_create_mdb_admin_role() and create the same role at the fixed OID MDB_ADMIN_ROLEID (8067), so installing both extensions fails on the duplicate definition. Keep the upstream layout and drop contrib/pg_aux_catalog: - remove contrib/pg_aux_catalog and its entry in contrib/Makefile - drop contrib/pg_aux_catalog:installcheck from the build workflows; gpcontrib/gp_toolkit:installcheck already covers the feature - point the comments in acl.h, transam.h and oid_dispatch.[ch] back at gp_toolkit, matching apache/cloudberry verbatim gpcontrib/gp_toolkit's mdb_admin files are byte-identical to apache/cloudberry REL_2_STABLE, as are the isolation2 resgroup tests.
Alena0704
force-pushed
the
cherry-apache-rel2
branch
from
September 3, 2026 21:10
81f09ae to
6de627f
Compare
Author
|
Merged through rebase |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Syncs the branch with upstream Apache Cloudberry: 2.2.0-incubating release, PostgreSQL kernel upgrade to 14.9, and related backports.
Release & versions
Security & hardening (PG backports)
ORCA
PAX
Cloudberry-specific
CI & build
Docs