postgresql.git, branch REL_14_STABLE

Fix assertion after aborting internal subtransaction at transaction end

2026-09-17T05:28:49Z

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:45:21Z

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:11Z

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

pg_ctl: Silence warnings about unused global variables

2026-09-11T19:27:58Z

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-11T19:27:58Z

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. Reinit was already documented in a comment as dead code, and it was removed in a later branch. To minimize the surgery there, just add an unused attribute to silence the warning. Reviewed-by: Andreas Karlsson Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org

Fix concurrency issues with DROP TABLESPACE

2026-09-09T15:32:37Z

DROP TABLESPACE checked pg_shdepend for dependent objects without first locking the tablespace. A concurrent command that recorded a shared dependency on the tablespace right after that check could still commit, leaving an object whose pg_shdepend entry (or, for a relation, pg_class.reltablespace) pointed to a tablespace that no longer existed. Close the race by having DropTableSpace() take an AccessExclusiveLock on the tablespace before calling checkSharedDependencies(). That conflicts with the AccessShareLock shdepLockAndCheckObject() takes when recording a new dependency, so the loser of the race blocks and rechecks once the winner commits. That AccessExclusiveLock creates a new deadlock: ALTER TABLESPACE RENAME/SET and the internal ACL/owner updates in DROP OWNED and REASSIGN OWNED touched the catalog tuple without locking the tablespace, risking a lock-order cycle with DROP. Fix by taking an AccessShareLock first in all four paths, rechecking pg_shdepend after any wait in the DROP OWNED and REASSIGN OWNED cases. GRANT, REVOKE, and ALTER TABLESPACE ... OWNER TO already lock the object. Add isolation tests covering both orderings of the original race (dependency-first and drop-first) and all four previously-unlocked update paths. Author: Ayush Tiwari Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/CAJTYsWXjAQFnGKzXsht3XK8KHhyhontwFJw4JAHsUSfs_ptR4g@mail.gmail.com Backpatch-through: 14

Revert "Mark modified the FSM buffer as dirty during recovery"

2026-09-08T10:32:57Z

This reverts commit c06d1a4ba6b26eef27b04074683cccade6c277ee. The commit assumed that if the FSM code tolerates torn pages, everything else does so. Readers that do not tolerate that include RelationCopyStorage(), used by ALTER TABLE ... SET TABLESPACE for every fork, the read stream in RelationCopyStorageUsingBuffer() used by CREATE DATABASE ... STRATEGY = wal_log, and, most awkwardly, the checksum verification in base backups and pg_checksums. Reported-by: Noah Misch Discussion: https://postgr.es/m/20260901211837.f6.noahmisch%40microsoft.com Backpatch-through: 14 Reviewed-by: Andrey Borodin

doc: Remove unnecessary CVE items from release notes

2026-09-08T08:27:19Z

The following CVEs were listed in the release notes of some stable branches, but they should not: - CVE-2026-16238, not on v17 and older - CVE-2026-14676, not on v17 and older - CVE-2026-14681, not on v16 and older - CVE-2026-14672, not on v15 and older Author: Yogesh Sharma Discussion: https://postgr.es/m/340842e1-31ce-4551-9d79-71de490f67e9@CatProSystems.com Backpatch-through: 14-17

Stabilize 026_overwrite_contrecord test

2026-09-08T07:49:39Z

On slow machines, this test can take long enough to generate WAL that a time-based checkpoint occurs before the primary is stopped. If the checkpoint record is written to the tail WAL segment that the test later removes, a standby initialized from the resulting backup tries to read the missing checkpoint record and fails with a PANIC during startup. This caused the test to fail on buildfarm member skink. Fix this by setting checkpoint_timeout high enough to prevent unrelated checkpoints during the test. This follows the approach used by other recovery tests, such as 043_no_contrecord_switch.pl, that depend on a specific WAL layout. Backpatch to all supported versions. Reported-by: Alexander Lakhin Author: Fujii Masao Discussion: https://postgr.es/m/CAHGQGwFajfjKhvNSTkTcE-wFn30p_A0_i1cvk-Q=FJhDr_5cXA@mail.gmail.com Discussion: https://postgr.es/m/9ffdb19a-7a89-424e-925a-dd981c37f0ba@gmail.com Backpatch-through: 14

Fix nestloop parameter handling for PlaceHolderVars in child joins

2026-09-08T01:13:50Z

When creating a nestloop plan for a partitionwise child join, the outer rel's relids are child relids, but PlaceHolderInfo.ph_eval_at is always expressed in terms of the topmost parent rels. As a result, replace_nestloop_params() and identify_current_nestloop_params() failed to recognize that a PlaceHolderVar evaluated at the outer child rel can be supplied as a nestloop param. Instead, the Vars within the PHV's expression were replaced with params, but the outer child rel emits only the PHV, not those bare Vars, leading to "variable not found in subplan target list" errors from setrefs.c. To fix, also include the outer rel's top parent relids in the relid set used for these checks, so that ph_eval_at comparisons are done in terms of parent rels while Var checks continue to work in terms of child rels. On v18 and later, the required-outer set passed to identify_current_nestloop_params() has the same problem: it is in terms of child rels once a parameterized child join path has been reparameterized by an upper child join. With the above fix in place, a PlaceHolderVar that depends on both the outer rel and the parameter source becomes a single NestLoopParam, and that param was never claimed by any nestloop node, leading to "failed to assign all NestLoopParams to plan nodes" errors. To fix, also include the top parents of any child rels in that set. Older branches lack this code path, so they receive only the first change. Back-patch to all supported branches. Bug: #19653 Reported-by: Annie <10215501441@stu.ecnu.edu.cn> Author: Richard Guo Reviewed-by: Tom Lane Discussion: https://postgr.es/m/19653-9352cc6ba17b662f@postgresql.org Backpatch-through: 14