postgresql.git, branch REL_17_STABLE

Tolerate partial pgstats entries in pgstat_gc_entry_refs()

2026-09-17T10:25:27Z

pgstat_get_entry_ref_cached() inserts a local entry_ref with shmem-related fields set to NULL, expecting pgstat_get_entry_ref() (its sole caller) to fill them up before returning. If an ERROR happens while pgstat_get_entry_ref() runs, it could be possible to finish with a local pgstats entry partially filled. This could lead to a crash of pgstat_gc_entry_refs(), which tolerates a NULL shared_stats in an assertion but unconditionally dereferenced its "dropped" and "generation" fields. This extends 4069df21beb8, being a cheap insurance against NULL pointer dereference, if some code paths of pgstat_get_entry_ref() are not able to perform any cleanup actions (for example after a dsm_create() throwing an ERROR). Reviewed-by: Grigorev Jurij Discussion: https://postgr.es/m/aqtiKTvl519bu8-V@paquier.xyz Backpatch-through: 15

Fix assertion after aborting internal subtransaction at transaction end

2026-09-17T05:26:11Z

Previously, aborting an internal subtransaction during COMMIT or PREPARE TRANSACTION could cause the following assertion failure. This could happen, for example, when a deferred constraint trigger fired at COMMIT and its PL/pgSQL exception block caught an error raised while executing the trigger function. TRAP: failed Assert("s->blockState == TBLOCK_SUBINPROGRESS || s->blockState == TBLOCK_INPROGRESS || s->blockState == TBLOCK_IMPLICIT_INPROGRESS || s->blockState == TBLOCK_PARALLEL_INPROGRESS || s->blockState == TBLOCK_STARTED"), File: "xact.c", Line: 4851, PID: 73455 An internal subtransaction should be able to be aborted while the parent transaction is in the COMMIT or PREPARE TRANSACTION phase. However, RollbackAndReleaseCurrentSubTransaction()'s assertion check previously did not allow TBLOCK_END and TBLOCK_PREPARE as parent transaction states, causing the assertion failure. This commit fixes the assertion check by allowing those two parent transaction states. Backpatch to all supported versions. Reported-by: Fabrízio de Royes Mello Author: Patrick Reynolds Reviewed-by: Fujii Masao Reviewed-by: Chao Li Reviewed-by: Fabrízio de Royes Mello Discussion: https://postgr.es/m/CABo-N97AeMbWuYTWg-3%3D2DkTR3EkvS%2BFt%3DyEaWB181STsR1mBg%40mail.gmail.com Backpatch-through: 14

Use the join collation when unique-ifying a semijoin's RHS

2026-09-16T09:44:20Z

A semijoin whose RHS is unique-ified groups the RHS on the expressions in SpecialJoinInfo.semi_rhs_exprs. Those were recorded with whatever collation the RHS expression itself exposes, which need not be the collation the join compares with. Neither SortGroupClause nor the pathkey machinery carries a collation of its own, so both Unique-over-Sort and HashAggregate then grouped by the wrong equality: values the join considers equal survived, and the following inner join emitted the outer row once per survivor. With a non-deterministic collation on one side, "SELECT count(*) FROM t WHERE c IN (SELECT c0 FROM t2)" therefore counted more rows than the same predicate reports for the rows of t. Label each RHS expression with the operator's input collation, the same treatment process_equivalence() gives to equivalence class members. Every consumer of semi_rhs_exprs reads the collation off the expression, so this fixes the sort-based and hash-based paths together; in the branches where create_unique_path() also passes these expressions to relation_has_unique_index_for(), it likewise stops a unique index built with a different collation from being taken as proof that unique-ification can be skipped. The same goes for a subquery's DISTINCT computed under a different collation, since translate_sub_tlist() punts on the relabeled expressions. Reported-by: Suyang Zhong Author: Andrey Rachitskiy Reviewed-by: Tender Wang Reviewed-by: Richard Guo Reviewed-by: Alexander Korotkov Discussion: https://postgr.es/m/19633-647cd4c73a84b085%40postgresql.org Backpatch-through: 14

Fix missing SIREAD lock on the row found by ON CONFLICT.

2026-09-15T10:47:08Z

INSERT ... ON CONFLICT decides what to do based on the conflicting row found by the arbiter index probe, but SSI never saw that read: the probe runs with a dirty snapshot, which predicate locking ignores, and the later fetch of the row uses SnapshotAny. When the statement then writes nothing, as with DO NOTHING, DO UPDATE with a WHERE clause rejecting the row, or DO SELECT, nothing records the read at all. A concurrent writer of that row went unnoticed and write skew could commit at SERIALIZABLE, even though the same schedule with a plain SELECT of the row fails with a serialization error. To fix, read the conflicting tuple again with the query snapshot, right where the probe finds it. The table AM takes the SIREAD lock and checks for a concurrent writer of the tuple as part of that read, both under the buffer lock, so a writer either sees the lock or is seen. A predicate lock by itself acquired separately after the probe could not offer that: a writer passing its conflict check in between would be missed. Doing this in the probe covers every conflict action, including rows that the WHERE clause of DO UPDATE or DO SELECT then rejects. The DO NOTHING and DO UPDATE cases have been broken since ON CONFLICT was added in 9.5; DO SELECT is new in v19. Backpatch to all supported branches. Author: Zsolt Parragi Author: Andrey Borodin Reported-by: Andrey Borodin Reported-by: Zsolt Parragi Discussion: https://postgr.es/m/787936C5-4155-4CF9-939D-39DC0EC1C892@yandex-team.ru Discussion: https://postgr.es/m/CAN4CZFM1GkHJkpMeo4G5rxtacVsfeKCJYiik9E9AKX1E9VYQ1w@mail.gmail.com Backpatch-through: 14

Fix const-folding of JSON constructors inside a simple CASE

2026-09-14T08:08:17Z

A JSON constructor with a RETURNING clause uses a CaseTestExpr as the placeholder for its result in the coercion expression. When such a constructor appears in a WHEN clause of a simple CASE whose test expression is a constant, eval_const_expressions substituted that constant for the placeholder, so the coercion produced the CASE's test value instead of the constructor's result. For instance, CASE 'x' WHEN JSON_OBJECT('a': 'b' RETURNING text) THEN 1 ELSE 0 END evaluated to 1. To fix, keep case_val out of scope while simplifying the coercion, as is already done for the elemexpr of an ArrayCoerceExpr. Back-patch to v16, where the SQL/JSON constructor functions were introduced. Author: Richard Guo Discussion: https://postgr.es/m/CAMbWs48A=VCFbteTkuCoknO1_0-Cu0aMBT0M07dm7vj1QyixDg@mail.gmail.com Backpatch-through: 16

Fix stale copies of PHVs in subqueries

2026-09-14T03:29:44Z

When a subquery references an output of another subquery that gets pulled up, and that output must be wrapped in a PlaceHolderVar because of an intermediate outer join, the PHV expression is pushed down into the subquery. That copy is not preprocessed along with the outer query's expressions, so the two copies can diverge. This used to be harmless, but since commit 2ebf25e7d join removal edits the whole query tree, walking into subqueries, and can trip an assert in ChangeVarNodes if it removes a rel whose Var survives only in such a copy. To fix, preprocess these copies at their owning query level, early in subquery_planner, before anything can consume them (in particular before SubLinks are turned into SubPlans). This covers copies pushed into both LATERAL subquery RTEs and SubLink subselects, and handles nested copies innermost-first. extract_lateral_references no longer preprocesses the copies it pulls out. Correspondingly, the subquery's own processing must leave the contents of an upper-level PHV alone, since the owning level has already preprocessed them: eval_const_expressions returns such a PHV unchanged, and flatten_join_alias_vars no longer recurses into it. Back-patch to v16, as with commit 2ebf25e7d. Reported-by: Tender Wang Author: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAHewXN=kWGAXV537mKtSyBYobGdHhYJVDJJMXXZEmmPWE_zaPw@mail.gmail.com Backpatch-through: 16

doc: Fix output column name for pg_stat_get_backend_subxact()

2026-09-12T00:04:10Z

pg_stat_get_backend_subxact()'s second attribute was written as "subxact_overflow" in the docs, but its name is "subxact_overflowed". Note that the attribute name is still wrong in the TupleDesc generated in the function; pg_proc agrees with "overflowed". Author: Shihao Zhong Reviewed-by: Jim Jones Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAGRkXqTBZ+zbVuDC8xGEB6Btj61hsui5H5nGqzFBDyOXc=4bjQ@mail.gmail.com Backpatch-through: 16

Fix option argument lookup in in-tree getopt_long().

2026-09-11T20:18:40Z

The in-tree getopt_long() moves each non-option to the end of argv, which might put it right where an option's argument lookup expects to find the argument. For example, "vacuumdb postgres --jobs" takes "postgres" as the number of jobs instead of complaining that --jobs is missing its argument. To fix, stop the argument lookups at the start of the moved non-options, which we already track to know when to stop scanning. Oversight in commit 411b720343. Author: Sehrope Sarkuni Reviewed-by: solai v Discussion: https://postgr.es/m/CAH7T-arxDuVCSkorO%3Dk7%2BM-_JV0JFzMpN_EtKMyD2K0RDqZ2OA%40mail.gmail.com Backpatch-through: 17

pg_ctl: Silence warnings about unused global variables

2026-09-11T17:52:15Z

Several global variables are only used in Windows build. This causes -Wunused-but-set-global warnings that the new clang 23 enables via -Wall. This commit marks these with an unused attribute to silence the warnings. (In the master branch, this is addressed differently, but for backpatching, this just silences the warnings without any behavior change.) Reviewed-by: Andreas Karlsson Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org

Remove unused global variables

2026-09-11T17:52:15Z

The new clang 23 has a new warning about set-but-unused static (internal-linkage) global variables: -Wunused-but-set-global, which is activated in PostgreSQL builds via -Wall. This triggers a few warnings in PostgreSQL code. This commit removes several such variables that were either never used or whose last use was removed some time ago. For pq_init_crypto_lib, we apply the same #ifdef HAVE_CRYPTO_LOCK that the other uses of the variable already have, so that the variable is either fully used or fully nonexistent, depending on the configuration, not half-way. Reviewed-by: Andreas Karlsson Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org