summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
20 hoursFix assertion after aborting internal subtransaction at transaction endREL_14_STABLEFujii Masao
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 <fabrizio@planetscale.com> Author: Patrick Reynolds <piki@planetscale.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Fabrízio de Royes Mello <fabrizio@planetscale.com> Discussion: https://postgr.es/m/CABo-N97AeMbWuYTWg-3%3D2DkTR3EkvS%2BFt%3DyEaWB181STsR1mBg%40mail.gmail.com Backpatch-through: 14
40 hoursUse the join collation when unique-ifying a semijoin's RHSAlexander Korotkov
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 <syzhong16@gmail.com> Author: Andrey Rachitskiy <pl0h0yp1@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Reviewed-by: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Discussion: https://postgr.es/m/19633-647cd4c73a84b085%40postgresql.org Backpatch-through: 14
3 daysFix missing SIREAD lock on the row found by ON CONFLICT.Dean Rasheed
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 <zsolt.parragi@percona.com> Author: Andrey Borodin <x4mmm@yandex-team.ru> Reported-by: Andrey Borodin <x4mmm@yandex-team.ru> Reported-by: Zsolt Parragi <zsolt.parragi@percona.com> 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
6 dayspg_ctl: Silence warnings about unused global variablesPeter Eisentraut
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 <andreas@proxel.se> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org
6 daysRemove unused global variablesPeter Eisentraut
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 <andreas@proxel.se> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/eb013f9d-2247-444e-8815-9d17b4ce78e7%40eisentraut.org
8 daysFix concurrency issues with DROP TABLESPACEAndrew Dunstan
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 <ayushtiwari.slg01@gmail.com> Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/CAJTYsWXjAQFnGKzXsht3XK8KHhyhontwFJw4JAHsUSfs_ptR4g@mail.gmail.com Backpatch-through: 14
10 daysRevert "Mark modified the FSM buffer as dirty during recovery"Alexander Korotkov
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 <noah@leadboat.com> Discussion: https://postgr.es/m/20260901211837.f6.noahmisch%40microsoft.com Backpatch-through: 14 Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
10 daysStabilize 026_overwrite_contrecord testFujii Masao
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 <exclusion@gmail.com> Author: Fujii Masao <masao.fujii@gmail.com> 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
10 daysFix nestloop parameter handling for PlaceHolderVars in child joinsRichard Guo
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 <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19653-9352cc6ba17b662f@postgresql.org Backpatch-through: 14
13 daysFix incorrect error message in xlogreader.cMichael Paquier
When neither BKPIMAGE_HAS_HOLE nor BKPIMAGE_COMPRESSED is set, DecodeXLogRecord() checks that bimg_len needs to be equal to BLCKSZ. However, the associated error message reported the data length associated to a block (DecodedBkpBlock.data_len), and not the length of the block (DecodedBkpBlock.bimg_len). Oversight in 57aa5b2bb11a, probably due to some copy-paste from the surroundings. Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Discussion: https://postgr.es/m/CAJTYsWVz9ymE7aMt2ZiQvs1bxNvhjfTf+XaJEsdFw7MT5dvtYQ@mail.gmail.com Backpatch-through: 14
2026-09-03Fix lack of message pluralizationPeter Eisentraut
Fixups for commits b99b74144f9, 79b101486c1, bf7d19be9b1.
2026-09-03Avoid backend hang during temp table cleanup in deferrable transactionsFujii Masao
Previously, a session that had created temporary objects could hang during exit if its default transaction mode was SERIALIZABLE READ ONLY DEFERRABLE and a concurrent serializable transaction was prepared. During backend exit, temporary-relation cleanup pushed a regular transaction snapshot, which honored the session's default settings and could wait for a safe serializable snapshot. So, if the conflicting transaction was prepared, this wait could last indefinitely. The wait occurred while the backend was already exiting and interrupts were held off, so even pg_terminate_backend() could not cancel it. The backend therefore remained until the prepared transaction was resolved. Temporary-relation cleanup only needs an active MVCC snapshot for fetching TOAST data from catalog tuples while dropping temporary objects. It does not need a transaction snapshot affected by the user's default isolation settings. So, use a catalog snapshot instead, which provides the needed protection without entering the deferrable safe-snapshot wait. Backpatch to all supported versions. Bug: #19441 Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Andrey Rachitskiy <pl0h0yp1@gmail.com> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/19441-ec29f3b1363b4a68@postgresql.org Backpatch-through: 14
2026-09-02Fix checkpointer restartpoint assertion failureFujii Masao
When recovery starts from a backup without a signal file, pg_subtrans is not started at the beginning of recovery and remains unstarted throughout recovery. However, previously, a restartpoint run by the checkpointer during recovery nevertheless tried to truncate pg_subtrans, triggering the assertion failure: TRAP: failed Assert("TransactionIdIsValid(initial)") This commit fixes this by tracking whether pg_subtrans has been started during recovery, and have the checkpointer check this flag before truncating pg_subtrans at restartpoints. Backpatch to all supported versions. Reported-by: Imran Zaheer <imran.zhir@gmail.com> Author: Imran Zaheer <imran.zhir@gmail.com> Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/CA+UBfamzfEReT0VOGRUW_=_AecCYQ-CNKLR_T4Q+YEmJAH3fdg@mail.gmail.com Backpatch-through: 14
2026-09-01Handle PG_INT32_MIN negation overflow in right()Daniel Gustafsson
A negative n means "return all but the first |n| characters", so text_right() negates n before clipping. Negating PG_INT32_MIN overflows; with -fwrapv the result is PG_INT32_MIN again, still negative, and pg_mbcharcliplen() then returns an offset of zero, so the whole string is returned where the correct answer is an empty string: SELECT right('abcdef', (-2147483648)::int4); -- 'abcdef', want '' SELECT right('abcdef', -2147483647); -- '', correct Clamp to PG_INT32_MAX instead. Any n whose absolute value is at least the string's length skips all of it, and a text value cannot be longer than PG_INT32_MAX, so this gives the same answer for every other input. Erroring out, as text_format_string_conversion() does for a width of INT_MIN, would not be correct here: unlike a format width, an out-of-range skip count has a well-defined result. Using pg_neg_s32_overflow() would be a slightly more optimal fix but as it's only available in PostgreSQL 18 and later the decision was taken to apply the same fix to all backbranches. Backpatch to all supported versions. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAON2xHNnBz-AcPJgDmd5_39+8qR5AUKEZk4X3ZM-0zdsATn8kQ@mail.gmail.com Backpatch-through: 14
2026-09-01Fix integer to_char() overflow with V formatFujii Masao
When to_char() formatted an integer value with a V pattern, it could return an incorrect result instead of reporting an overflow. V shifts the decimal point by multiplying the input value by a power of ten before formatting it, so, for example, to_char(3, '9V999999999') requires computing 3 * 10^9. This result does not fit in int4, but the integer variant of to_char() performed the multiplication using a plain int32 expression. The intermediate result could therefore overflow, causing the function to output incorrect digits instead of raising "integer out of range". Use dtoi4() and int4mul() for this calculation so that both an out-of-range multiplier and an out-of-range product are detected, as with ordinary integer arithmetic. This also matches the existing int8 implementation, which uses dtoi8() and int8mul() for the same operation. After this change, to_char() with V format either returns the correctly formatted result when the scaled value fits in int4, or raises "integer out of range" when it does not. Backpatch to all supported versions. Reported-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Author: Andrey Rachitskiy <pl0h0yp1@gmail.com> Reviewed-by: Miłosz Bieniek <bieniek.milosz@proton.me> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAB8bMivEfqZxOVdzc3kZDN++XshmkEz2t7dfGBU8+oUm864EZg@mail.gmail.com Backpatch-through: 14
2026-08-29Harden spell.c against out-of-order FLAG lines in Hunspell files.Tom Lane
The compound flags collected from COMPOUNDFLAG and friends are stored in either the string or the integer member of a union, according to the flag mode that the affix file's FLAG line declares. NIImportOOAffixes() converted each flag as soon as it read it, using the mode in effect at that point, and recorded that mode in the entry. Since FLAG may appear anywhere in the file, including after the compound flags, entries written before and after it could disagree about which member of the union holds the flag. In assert-enabled builds, this would result in an assertion failure. Otherwise, cmpcmdflag() takes the mode from its first argument and applies it to both, so it can read an integer as a char pointer and pass that to strcmp(). Depending on which way the mismatch goes, the result is a segfault while sorting the array, a segfault in the bsearch() that later looks flags up (the lookup key is built with the final mode, so this happens even when the array itself is consistent), or, when both members happen to be readable, no crash at all and a compound flag that is never found, which silently disables compound word splitting. This isn't a security bug because we consider dictionary files to be trusted data, but it's still worth fixing. (In practice, dictionary files usually put the FLAG line first, which is why this went unreported for so long.) Fix by keeping the flags as strings while the file is read and converting them once it has been read in full, when the mode is final. This also makes the position of the FLAG line irrelevant, which is how the flags on AF, SFX and PFX lines are already treated: those are parsed in a second pass and so always use the final mode. That precedent is reason for behaving this way rather than throwing an error. The old ispell file format reaches addCompoundAffixFlagValue() too, from NIImportAffixes(), and returns without entering NIImportOOAffixes(), so it needs the conversion step as well. While we're here, also fix some integer width mismatches: store the result of strtol() into a "long", and cast to int only after we've done range checks. Typically a value too wide for int would fail the range checks anyway, but in some cases it would be silently accepted after truncation to int. Author: Ewan Young <kdbase.hack@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAON2xHN3QmsaySM6DGWa1gttcbJoFh0wjAE-_ZpSPo=LKN1hYw@mail.gmail.com Backpatch-through: 14
2026-08-28Fix incorrect multi-column RANGE partition pruningDavid Rowley
When performing partition pruning with a RANGE partitioned table where the pruning quals are only present for a leading prefix of the partition key, it was possible that partition pruning would accidentally prune away some partitions which shouldn't be pruned and include some partitions that were not needed. This happened due to an incorrectly coded loop bound which was terminating the loop when the bound reached the first or last element in the partition bound array. This resulted in those end elements not being checked in cases where they should be checked. It appears that it might have been coded this way to avoid stepping off the array, but that was done incorrectly as it failed to take into account the direction of travel through the array (the loop can go forwards or backwards). I.e., it's valid to loop when 'off' is the last element if we're going backwards through the array, and valid to loop if 'off' is 0 and we're looping forward through the array, but the code as it was didn't allow that. Here we fix this by moving the loop condition check to after we've calculated the array element to process, and break from the loop if that element is beyond either end of the array. Example of accidentally pruned partition: p: partition by range (a, b); p1: for values from (1, 4) to (1, 7); p2: for values from (1, 7) to (3, 8); p3: for values from (4, 8) to (6, 9); def: default; select * from p where a <= 1; Here p2 was pruned by mistake. Example of accidentally not pruning a partition: p: partition by range (a, b); p1: for values from (7, 2) to (7, 7); def: default; select * from p where a > 7; No partitions would be pruned in this case, despite it being impossible for matching rows to exist in p1. Author: David Rowley <dgrowleyml@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/CAApHDvp5ne9AWaH-tG1Lke-USLz3NwWLWTUdP5NT7ypKtcFqcg@mail.gmail.com Backpatch-through: 14
2026-08-27Fix temporary WAL receiver slot handling on timeline switchesFujii Masao
Previously, when wal_receiver_create_temp_slot was enabled, a timeline switch could cause the walreceiver to try to create the same temporary replication slot again on the same connection. The slot had already been created before the first streaming attempt and still existed, so the second creation attempt failed with a FATAL error such as "could not create replication slot ...". The walreceiver would later be restarted and streaming replication could continue, so this did not permanently break replication. Nevertheless, the unexpected failure is a bug and should be fixed. Fix this by tracking whether the temporary replication slot has already been created for the lifetime of the walreceiver and skipping subsequent creation attempts. Also copy the retained slot name to shared memory on each streaming attempt, since RequestXLogStreaming() clears it when streaming is restarted without a configured primary slot. This also keeps pg_stat_wal_receiver.slot_name populated after timeline switches. Backpatch to all supported versions. Author: ChangAo Chen <cca5507@qq.com> Reviewed-by: Quan Zongliang <quanzongliang@yeah.net> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/tencent_628FDAF814231923BC8E8357BBBC50F94207@qq.com Backpatch-through: 14
2026-08-27Stabilize 019_replslot_limitFujii Masao
The test assumed that advancing WAL would lead to a checkpoint that invalidates the obsolete replication slot. If a checkpoint that started before the WAL switch completes first, the following checkpoint can be skipped as idle, so the expected walsender termination is not logged. Force a CHECKPOINT in a background psql session after advancing WAL, so the slot invalidation is exercised deterministically. This has been observed on buildfarm members alligator and partridge: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=alligator&dt=2024-12-13%2001%3A24%3A58 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-08-06%2018%3A00%3A11 Backpatch to all supported versions. Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Hayato Kuroda <kuroda.hayato@fujitsu.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/0b07ead5-a5da-445e-9698-a7d340708bdf@gmail.com Backpatch-through: 14
2026-08-27Don't create a shell type for function returning an arrayHeikki Linnakangas
Refactor the checks in the function to move all the conditions for when to attempt creating a shell type into one place. Add a check for the array syntax. In addition to rejecting array syntax, another user-visible effect is that the error message is now different if the type specified a typmod. You now get "type does not exist" instead of the more specific "type modifier cannot be specified for shell type". That seems better; the implicit shell type creation exists only for backwards compatibility, and it never worked with type modifiers, so if there's a type modifier it's most likely not because the user tried to create a shell type, Add test for the array syntax, the type modifier, and some other cases for which we don't create shell types. Discussion: https://www.postgresql.org/message-id/de673feb-41b4-4685-b24b-6408b95e58ab@iki.fi Backpatch-through: 14
2026-08-26Export subxip[] for snapshots taken during recovery.Peter Geoghegan
A snapshot taken during recovery stores all of its in-progress XIDs in subxip, every running top-level XID included, leaving xip empty. Unlike with other snapshots, its suboverflowed flag does not mean that subxip is redundant. We nevertheless treated it that way during snapshot export, so an importing session could see in-progress transactions as aborted. This misbehavior could also lead to hint bits being incorrectly set on the standby; affected tuples then wrongly appeared visible or invisible to sessions that never imported the snapshot. To fix, teach snapshot export to include the subxip[] array regardless of the overflow flag when the snapshot is taken during recovery. This is in line with how CopySnapshot() and SerializeSnapshot() already handle the same issue. Claude Code diagnosed this problem. The committed TAP test is a simplified version of the one that it wrote to demonstrate this bug. Oversight in commit 6c2003f8a, which enabled snapshot export and import during recovery. Author: Peter Geoghegan <pg@bowt.ie> Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Bug: #17846 Discussion: https://postgr.es/m/CAH2-WzmHVeYY%3Dpjz9x8DhhxVjXHX0pvoQ-MdiB1Tt6%3Do2GTiKg%40mail.gmail.com Discussion: https://postgr.es/m/17846-1a0e5ce976f4c01a@postgresql.org Backpatch-through: 14
2026-08-25Don't assume DISTINCT ON implies uniqueness when the tlist has SRFsRichard Guo
query_is_distinct_for() treated a subquery's DISTINCT ON clause as proof that its output is unique over the DISTINCT ON columns, even if the targetlist contains set-returning functions. That's not true: when the query has an ORDER BY, the planner postpones evaluation of SRFs that are not DISTINCT ON or ORDER BY columns until after the Unique step, so the subquery can produce duplicates of the DISTINCT ON columns. Relying on this bogus uniqueness proof allowed join removal and unique-inner joins to produce wrong results. Plain DISTINCT is not affected, since all tlist columns are DISTINCT columns there, and so any SRFs get expanded before the Unique step. To fix, make query_supports_distinctness() and query_is_distinct_for() refuse to prove distinctness via DISTINCT ON if the targetlist contains any SRFs. This is more conservative than necessary, since the SRFs are only postponed when there is an ORDER BY and none of them appear in a sort/group column, but it doesn't seem worth the trouble to check that precisely. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAMbWs4-hfd1Pyy_zBejsVUSy-3dx16rz2hgUakkKnAg3qg2q=Q@mail.gmail.com Backpatch-through: 14
2026-08-22Fix GIN posting tree page deletion with incomplete splits.Peter Geoghegan
GIN posting tree page deletion failed to consider whether the target page's left sibling page, or the deletion target itself, was marked as incompletely split. Page deletion finds the target page's left sibling by walking the parent's downlinks, but an incompletely split page's new right half is part of the sibling chain despite having no downlink. Deletion could therefore overwrite the rightlink of the wrong page, disconnecting the split's still-live right half from the sibling chain. Scans would then silently miss tuples from that page. To fix, teach the relevant page deletion path to avoid deleting a posting tree page whose left sibling is marked incompletely split (and to avoid doing so when the target page itself is so marked). This is essentially the same approach used by nbtree page deletion. Claude Code found this problem. The committed test case is a simplified version of the one that it wrote to demonstrate this bug. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-Wz=sKJcn+OtfVN9rdg+Ps9e4cuQWNP-9t12UE2d8nEG90Q@mail.gmail.com Backpatch-through: 14
2026-08-21Attempt to stabilize plan of self-join test in tidscan.sqlDavid Rowley
The test that checks the expected plan for this self-join test has been known to have failed in the past due to badly timed VACUUMs causing small variations in row estimates on one of the tables, resulting in a swapped join order. Currently, failures have only been seen in v14, and seemingly due to 74388a1ac and 4496020e6 the failures have not been seen in more recent versions. Here we shrink down the number of matching rows on one side of the join to make the alternative join order's costs more expensive relative to the cheapest join order. Previously the alternative order had the same cost. We do this in all supported versions to reduce the chances of future changes reintroducing stability issues with these queries. Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/f5d1f4c2-6224-4797-be17-c86e77f96c9c@gmail.com Backpatch-through: 14
2026-08-20Fix snapshot import xmin ProcArrayLock bug.Peter Geoghegan
ProcArrayInstallImportedXmin verifies that the source transaction (the transaction whose snapshot we're importing) is still running, and then installs the caller's imported xmin. These steps have to be atomic. But it was just about possible for VACUUM to fail to observe the imported xmin in either the source proc or the importing one. This could result in VACUUM pruning away deleted tuples that were still visible to the imported snapshot. To fix, take ProcArrayLock in exclusive mode while importing an exported snapshot's xmin within ProcArrayInstallImportedXmin. That guarantees that a concurrent VACUUM's OldestXmin cannot advance past the xmin (one proc or the other always advertises an xmin that holds it back). Author: Chee Wooson <chee.wooson@gmail.com> Reviewed-by: Peter Geoghegan <pg@bowt.ie> Discussion: https://postgr.es/m/20260730042128.714201-1-chee.wooson@gmail.com Backpatch-through: 14
2026-08-20Reject too many arguments in CREATE TRIGGERMichael Paquier
The number of trigger arguments is stored as a smallint, but there was no check that the number of arguments fits with the catalog data type. This could result in an invalid negative value being stored once one defined more than INT16_MAX arguments, with an overflowed value stored in the catalogs. Looking at other catalogs that store a number of arguments, we have similar protections already in place (aggregates, functions, etc.). Reported-by: Xingwang Xiang <v3rdant.xiang@gmail.com> Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/19627-5b72a57e332e2b3f@postgresql.org Backpatch-through: 14
2026-08-19GiST: Invalidate killed items consistently.Peter Geoghegan
GiST neglected to invalidate its killedItems[] array on a rescan. As a result, it was just about possible for the wrong tuples from the wrong index page to be LP_DEAD-marked on a rescan. The scan mistakenly believed that the previous rescan's killedItems[] were for this rescan's curBlkno, causing index corruption. To fix, bring GiST in line with nbtree and hash: call gistkillitems from both gistrescan and gistendscan (the existing gistgettuple caller still handles the common case where we need to LP_DEAD-mark before moving on to the next page). That way the scan's pending killedItems[] are passed to gistkillitems while they still describe items from curBlkno. When gistkillitems runs, it'll invalidate the array in passing (and won't needlessly miss out on an opportunity to LP_DEAD-mark eligible index tuples). Back branches just get minimal hardening: we invalidate killedItems[] at the places where the master branch gets new calls to gistkillitems (and we invalidate curBlkno and curPageLSN on a rescan). The test that proved corruption on master didn't result in corruption on any stable branch, though only because, without commit 9c9ddf109, we'd clobber curPageLSN without also updating curBlkno -- which accidentally prevented it. Relying on gistkillitems to not LP_DEAD-mark by passing it a curBlkno whose curPageLSN was taken from an entirely different page seems like a very bad idea, which is why this issue is being treated as a bug affecting all stable branches. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-WzmwEThnQf17Ju+t0N9_KJLsEQSXzYrFnaS2=s4KnGGrqw@mail.gmail.com Backpatch-through: 14
2026-08-19Fix GIN multiple-VACUUM-scans pending list bug.Peter Geoghegan
ginbulkdelete performs pending list cleanup before it searches the entry tree (and any posting trees) for dead TIDs. This is necessary to avoid leaving behind dangling TID references that index vacuuming is required to remove; nothing prevents recently inserted pending list tuples from containing TIDs that VACUUM already considers dead. However, ginbulkdelete neglected to perform pending list cleanup on VACUUM's second or subsequent call. It was therefore possible for a VACUUM that requires multiple rounds of index vacuuming to leave behind dangling references. To fix, teach ginbulkdelete to perform pending list cleanup during every call. In passing, tweak some related comments in the pending list cleanup path to make it clear why it's safe for VACUUM to not _fully_ empty an index's pending list. This was arguably an oversight in commit e2c79e14, which fixed a similar issue where pending list cleanup by VACUUM could end early, but missed this closely related problem. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-Wzmsa-RPA2Ko8A5LaGOnmbpimJ--71xkiBqwgjk3Fq8YEg@mail.gmail.com Backpatch-through: 14
2026-08-19Fix GIN VACUUM posting tree root split bug.Peter Geoghegan
ginVacuumPostingTreeLeaves swaps a shared buffer lock for an exclusive one when it encounters a leaf page. It neglected to re-verify whether a page that was initially a leaf root page became an internal page due to a concurrent root page split (during the window when no lock was held). It was therefore possible for GIN VACUUM to spuriously treat an internal page as a leaf page, leading to data corruption. VACUUM could miss dead TIDs that it was required to remove, leaving behind dangling references in the index. To fix, re-verify that a leaf page is still a leaf page after an exclusive lock is acquired. If it isn't, drop our exclusive lock and acquire a shared lock so that the non-leaf root page gets processed in the usual way. Oversight in commit fd83c83d, which fixed a deadlock bug in GIN posting tree vacuuming. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/CAH2-Wz=RBpJTQgvOxr6C=J04dExmFSt1E3F-r+cRTQ56hEotkg@mail.gmail.com Backpatch-through: 14
2026-08-19psql: Fix psql slash option leaksFujii Masao
psql_scan_slash_option() returns a malloc'd string, but \getresults, \gset in pipeline mode, \restrict, and \unrestrict did not free it after consuming or copying the value. Free these option strings after use. Backpatch to all supported versions. In v17 and older, only \restrict and \unrestrict are affected, so those branches need only that part of the fix. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEh3R3=1tx_a5=fTDJ+ycuwxWMEn6bG_Yt4B5P+hE7AVw@mail.gmail.com Backpatch-through: 14
2026-08-19psql: Avoid returning oom_buffer from psql slash option scannerFujii Masao
psql_scan_slash_option() builds option text in a local PQExpBufferData and returns the buffer's data pointer to its caller. If either the initial allocation or a later enlargement failed, that data pointer could be the static PQExpBuffer OOM buffer rather than malloc-owned storage. The callers could then eventually pass it to free(), causing undefined behavior. Detect a broken option buffer before returning it, report OOM, and return NULL instead. Also avoid evaluating a backtick substitution when the option buffer is already broken, since doing so could otherwise touch the static OOM buffer. This keeps the existing NULL-return convention for slash options. Callers are not generally changed to distinguish OOM from no option. Backpatch to all supported versions. Reported-by: Junwang Zhao <zhjwpku@gmail.com> Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEh3R3=1tx_a5=fTDJ+ycuwxWMEn6bG_Yt4B5P+hE7AVw@mail.gmail.com Backpatch-through: 14
2026-08-19psql: Avoid returning oom_buffer from psql slash command scannerFujii Masao
psql_scan_slash_command() builds the command name in a local PQExpBufferData and returns the buffer's data pointer to its caller. If either the initial allocation or a later enlargement failed, that data pointer could be the static PQExpBuffer OOM buffer rather than malloc-owned storage. HandleSlashCmds() could then eventually pass it to free(), causing undefined behavior. Detect a broken command-name buffer before returning it, report OOM, and return NULL instead. Teach HandleSlashCmds() to treat a NULL command name as a command error before trying to compare or dispatch it. Backpatch to all supported versions. Reported-by: Junwang Zhao <zhjwpku@gmail.com> Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Discussion: https://postgr.es/m/CAHGQGwEh3R3=1tx_a5=fTDJ+ycuwxWMEn6bG_Yt4B5P+hE7AVw@mail.gmail.com Backpatch-through: 14
2026-08-19Fix relcache reference leak when decoding TRUNCATEMichael Paquier
ReorderBufferProcessTXN() opens every relation referenced by a TRUNCATE change. When RelationIsLogicallyLogged() returns false, it skips the relation without releasing the reference acquired by RelationIdGetRelation(). Looking at the in-core code paths building XLOG_HEAP_TRUNCATE records, no relation OIDs would be included if they do not satisfy RelationIsLogicallyLogged(). One pattern that could go through is if a table is switched to SET UNLOGGED, but that would not be reachable in practice as the decoding happens after a historical snapshot is taken, so the relation should still be valid. This is a defense-in-depth measure in practice, and we tend to be careful about how Relations are handled when sending changes to output plugins, so backpatch all the way down. Author: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/7DD65D03-3B5A-43B2-99AD-8E6AF5372BAB@gmail.com Backpatch-through: 14
2026-08-19Report single-page checksum failures in pg_stat_databaseMichael Paquier
Base backups reported checksum failures to pg_stat_database only for files with more than one failing page. Commit 6b9e875f728 placed the report inside the block emitting the per-file summary WARNING, which was skipped for a single failure. As a result, a backup failing on files with one corrupted page each left checksum_failures untouched. To fix, emit the per-file summary and the pgstat report for any non-zero failure count. The end-of-backup total WARNING had the same off-by-one and is now also emitted for a single failure. Author: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/CAN4CZFN+Bi6XmaH8zOdMWjoycYFx9nKtOr+dzQf0o-UQ+Rdqmw@mail.gmail.com Backpatch-through: 14
2026-08-18Defend against null "SV *" pointers in plperl modules.Tom Lane
Tied hashes, and probably tied arrays, are capable of returning Perl value pointers that are actually NULL, not the usual pointer to an undef SV. We were not defending against that everywhere, leading to possible SIGSEGV. Fix the code to consistently treat a null pointer returned from hv_iternext or av_fetch like a !SvOK one. (Note that the large diff in SV_to_JsonbValue is actually quite trivial, but it required reindenting a chunk of existing code.) Claude Code found the instance in hstore_plperl, and I found the others by code auditing. Perhaps the other instances aren't actually reachable, but I see little reason to assume that. The known test cases for these errors require perl's Tie modules, which may not be present, so it doesn't seem worth the trouble to create regression test cases that would cover them. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14
2026-08-17Tighten up tsqueryrecv().Tom Lane
tsqueryrecv() accepted zero-length lexemes, which tsqueryin() doesn't. It also accepted phrase distance values larger than MAXENTRYPOS, which tsqueryin() doesn't. While neither of these omissions are very harmful in themselves, they do allow accepting tsquery values that will fail in a subsequent textual dump/reload. Commit 23d9ad771 performed similar tightening of tsvectorrecv(), but I left off these changes at the time because they didn't seem to have security implications. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/455079.1786897319@sss.pgh.pa.us Backpatch-through: 14
2026-08-17GiST: Deprecate F_TUPLES_DELETED opaque area flag.Peter Geoghegan
This flag hasn't been useful since the removal of old-style VACUUM FULL, so remove it now (this includes removing vestigial code that unnecessarily set the flag). Also add test coverage of gistprunepage(). Had that test case been available before now, the issue fixed by this commit would have been detected by wal_consistency_checking buildfarm animals. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Michael Paquiër <michael@paquier.xyz> Discussion: https://postgr.es/m/CAH2-WznbTsQCrjmd=eSawfPqcxCjSFUkk6Qzd3z+gpNte5i03Q@mail.gmail.com Backpatch-through: 14
2026-08-17Make plperl's handling of Perl arrays safer and more consistent.Tom Lane
plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14
2026-08-14Add missing PGDLLIMPORT marker.Nathan Bossart
Oversight in commit ffca23839c. Reported-by: Anton Voloshin <a.voloshin@postgrespro.ru> Author: Anton Voloshin <a.voloshin@postgrespro.ru> Backpatch-through: 14
2026-08-14psql: count every COPY FROM STDIN when scanning a query string.Tom Lane
When SendQuery() is not told how many COPY FROM STDIN commands the query string contains (as for -c, \gexec, and \watch), it scans the string to count them itself. But it called psql_scan() only once, which stops at the first semicolon, so any COPY FROM STDIN past the first sub-command was not counted, causing failure of cases that used to work. Oversight in commit 3045a25ba. Author: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAN4CZFPqa6c+u4uX5jJ8LANHTQ4dxM3m4_8G9WmX_A4-2wuv2A@mail.gmail.com Backpatch-through: 14
2026-08-13Consistently enforce tsvector/tsquery maximum lengths.Tom Lane
Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14
2026-08-12Fix poll_query_until() timeout handling with an undefined query in Cluster.pmMichael Paquier
On timeout, poll_query_until() would fail to print its report when "$query" was undefined. Instead of the expected report, this prevented the contents of stdout and stderr from being shown. Note that some of the in-core tests use an undefined query for connection-only polls. Author: Bryan Green <dbryan.green@gmail.com> Reviewed-by: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> Discussion: https://postgr.es/m/0f515c6d-6032-4c5f-80ac-5c78faae9522@gmail.com Backpatch-through: 14
2026-08-11Tweak allocation rule for tzload()'s "union local_storage" variable.Tom Lane
By default, allocate this via malloc, as we've been doing since commit 62c8421e8. Commit aeb07c55f adopted upstream tzdb's default of allocating it on the stack, but that still doesn't seem like a good idea for the reasons given in 62c8421e8 (and now memorialized in a comment, in hopes that we don't make the same mistake again). However, under USE_VALGRIND, put it on the stack as upstream does. This accidentally prevents a crash when Python 3.14 is used under Valgrind. The reasons for that are obscure, and it's most likely not our bug, and even if we figured it out it'd be nice to have a fix for buildfarm member skink now rather than after persuading the guilty party to fix it. In the normal non-USE_VALGRIND case, this has no effect on the logic in released branches, and it reverts master to match them. Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/f071e691-5930-4738-9dbd-43ed2da367fe@gmail.com Backpatch-through: 14
2026-08-10psql: Don't do backquote expansion in \unrestrict.Nathan Bossart
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
2026-08-10Fix out-of-bound reads with ascii() for invalid multibyte charactersMichael Paquier
This commit addresses two defects in this SQL function, the code assuming that: - The user-supplied string was long enough to contain a character of the length implied by the first byte. It is possible to provide in input data that was able to disclose a few bytes of server memory, allowing out-of-bound reads. - Specific bytes had values within the expected range, using a set of assertions to validate them. The assertions could be triggered on invalid input. These are replaced by tests and error reports. Reported-by: Hcamael <baiyjrh@gmail.com> Author: Michael Paquier <michael@paquier.xyz> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Backpatch-through: 14 Security: CVE-2026-18024
2026-08-10Teach psql to skip in-line COPY ... FROM STDIN data after a failure.Tom Lane
If the COPY command fails before sending PGRES_COPY_IN, psql did not realize that it ought to consume any in-line data following the command. Failing to do so leads to trying to execute that data as SQL commands, which in the best case is wrong and in the worst case is a SQL-injection hazard. To fix: 1. Extend psqlscan.l to recognize COPY ... FROM STDIN. This can be done with a pretty simple extension to the logic that already recognizes nested BEGIN blocks within CREATE FUNCTION et al. But unlike that case, we need to consider and count multiple COPY commands within a single query string (separated by "\;"). The fallout from that is that psql_scan_reset must now always be called before starting a new query string. (The comment for it that claimed we didn't need that because "the scan state must be INITIAL" was really obsolete already, since it has long reset more state besides start_state.) 2. Teach handleCopyIn() to read and discard data when passed NULL for "conn". 3. Add logic to SendQuery() to call handleCopyIn() that way if the query string contained COPY ... FROM STDIN command(s) that remain unaccounted-for at the end. Now that we have this counting logic, we can also detect if the backend sends an unexpected PGRES_COPY_IN message. That should never happen, but perhaps a malicious server could try to extract data that way. A side-effect of doing this is that we have to adjust a number of test scripts that thought they needn't write "\." after a COPY FROM STDIN that they expect to fail. On the whole this is an improvement, since there's now a uniform rule "write \. after COPY FROM STDIN, whether you expect it to work or not". But it is an annoying amount of test churn. A loose end in this patch is that if it has to skip data, it assumes that that data is text not binary. It seems unduly difficult to detect whether the COPY command requested binary (we could handle the old-style COPY BINARY ... syntax, but not the new style with format options). In practice, copying in-line binary data is unsupported anyway, because there's no way to write an end marker: the textual terminator sequence "\n\\.\n" could appear in binary data and there's no provision for escaping it, so neither psql nor the server look for it when in binary mode. Reported-by: Alexander Lakhin <exclusion@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Noah Misch <noah@leadboat.com> Backpatch-through: 14 Security: CVE-2026-6464
2026-08-10Save/restore more lexer state when skipping text due to \if.Tom Lane
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 e717a9a18 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
2026-08-10Invalidate plan cache after role changes.Nathan Bossart
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
2026-08-10Check for USAGE privilege on the composite type in ALTER TABLE OF.Nathan Bossart
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
2026-08-10Check for USAGE privilege on types used by stored expressions.Nathan Bossart
This omission allowed roles without USAGE on a type to create stored expressions that depend on it, which could prevent the owner from changing the type later. The checks deliberately live in the command paths rather than the dependency-recording routines. Those routines also run whenever the server re-derives an existing expression, and re-checking there would break routine maintenance for an owner who has since lost USAGE on a type its objects already reference. (Checking in the dependency-recording routines would also require additional CommandCounterIncrement() calls to avoid spurious errors.) The addition of a parameter to AlterDomainAddConstraint() breaks ABI compatibility, but we are unaware of any impacted third-party code. Reported-by: Noah Misch <noah@leadboat.com> Author: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Security: CVE-2026-6470 Backpatch-through: 14
generated by cgit v1.2.3 (git 2.46.0) at 2026-09-18 01:40:32 +0000