postgresql.git, branch master

Detect overflows in various numerical aggregate transfns

2026-10-28T00:25:21Z

Here we add overflow checks to guard against overflowing the int8 sum of all inputs for sum(int2), sum(int4), avg(int2) and avg(int4). Such an overflow is very unlikely for the int2 versions, but somewhat possible to hit for the int4 versions when given billions of large enough inputs. Since our code and machines are getting faster, and with the advent of things like columnar table AMs, it's getting more likely that such an overflow could occur in a real use case. No guards have been added to the average count. That would require 2^63 input rows, which is not possible to achieve in a single instance of PostgreSQL, given other limitations such as 64-bit LSNs. Fixing this only in master as we can probably get away with that today due to this still being unlikely for users to ever hit. Author: Andrei Lepikhov Reviewed-by: David Rowley Reviewed-by: Tom Lane Reviewed-by: Chao Li Discussion: https://postgr.es/m/1ddc2a6f-4b26-43d9-9f3b-5b5db98a486d@gmail.com

Avoid torn copy of the control file in base backups

2026-10-27T23:42:35Z

Base backups read the control file (pg_control) from disk without any protection against concurrent writes by the server, making it exposed to torn copies. Attempting to use such a control file at startup would cause a failure with a CRC not matching. Base backups now read the control file while holding ControlFileLock. c558e6fd92f has done the same for some SQL functions. The contents of the file are saved in memory and sent over the wire as-is. Backpatch down to v15. This issue is older than v15 but v14 is left out of the picture as it is going to be EOL soon, so it does not seem worth taking a risk for. Author: David Steele Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/d1697de1-eb7f-41bf-a4b7-bba7203df11f@pgbackrest.org Backpatch-through: 15

Fix broken indentation caused by 34d52e6d3

2026-10-27T22:42:22Z

Per buildfarm member koel Backpatch to 19 to avoid unnecessary variations. Backpatch-through: 19

Add PG_RETURN_ARG macro and use it for sum(int2) and sum(int4)

2026-10-27T21:36:38Z

This is intended for SQL-level functions written in C for cases when they want to return an input parameter unmodified; NULL if that parameter is NULL, or the exact value of the parameter otherwise. The return type and the given input parameter must have matching types. The caller must verify whether it's safe to not copy non-byval types and not de-toast variable-length typed inputs. Here we introduce two usages of the new macro for the transition functions for sum(int4) and sum(int2). These just need to return the int8 aggregate state value unmodified when asked to transition a NULL input; the aggregate state may or may not be NULL at that point. PG_RETURN_ARG() is coded to work for either case. This is primarily being added to partially circumvent an argument against adding overflow checks on sum(int2) and sum(int4), which a pending patch proposes to do. Effectively, here we're removing 1 jump per transition function, and that commit plans to add a new jump, so this commit allows a net zero increase in jumps for both of those functions. Author: David Rowley Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAApHDvp-3v1OWbo7RavBf37=MjNScqhj4vyAyHOUDY51nGUnog@mail.gmail.com

Fix deparsing of AT TIME ZONE and similar as FROM-clause functions.

2026-10-27T21:24:33Z

ruleutils.c's looks_like_function() assumed that all COERCE_SQL_SYNTAX cases produce output that looks like a function call (or at least like one of the syntaxes the func_expr_windowless production accepts). But AT TIME ZONE, AT LOCAL, OVERLAPS and IS xxx NORMALIZED print as other sorts of a_expr, so those cases would produce invalid SQL syntax when used in a FROM clause. Extend the logic to detect which specific functions are safe or unsafe. Author: Henson Choi Reviewed-by: Prashant Chinnam Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAAAe_zC68s-DwVX1o7C1HVcRk+Z+RTS6Vw19auZFfz=KaX8tZA@mail.gmail.com Backpatch-through: 14

Reintroduce hash_mem cap on buckets in BuildTupleHashTable

2026-10-27T20:06:30Z

8f29467c5 removed the hash_mem cap from the nbuckets calculation in BuildTupleHashTable() and put the trust into the planner to provide that function with a sane value, which it would only cap at 2^32. There are various places in the planner which cannot provide good estimates here and it's been demonstrated that it's not difficult to craft a query which requests 2^32 buckets. Here we reintroduce the sanity checks so we don't end up making the hash table's initial size to something that would exceed hash_mem. This may cause the hash table to have to grow several times before it fills, but that seems much better than having the executor OOM due to the request being too large. Users are also used to work_mem and hash_mem_multiplier having an effect on query performance, so this shouldn't be too surprising. It also restores the limits that were imposed pre-8f29467c5, which were tried and tested. Bug: #19759 Reported-by: Alperen Keles Author: David Rowley Reviewed-by: shihao zhong Discussion: https://postgr.es/m/19759-acd3f33402e54f36@postgresql.org Backpatch-through: 19

doc: Add note about promotion waits on backends stuck sending to clients.

2026-10-27T18:13:04Z

Commit df1be4ddc83 made promotion skip waiting for the barrier that refreshes each process's cached logical WAL logging state in some cases, but promotion still waits for it on a standby with wal_level = replica that has a valid logical slot. A backend blocked sending data to a client that has stopped reading can't process the barrier, so promotion can wait for a long time. Add a note about this case in the failover section, along with ways to get out of the wait and to bound it in advance. Backpatch to v19, where commit 67c20979ce7 introduced this wait. Author: shihao zhong Reviewed-by: Amit Kapila Reviewed-by: Hayato Kuroda Reviewed-by: shveta malik Reviewed-by: Zhijie Hou Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/CAGRkXqToBk9c2sPAgha-kCgxJhVwn90j1sCyUXrvydq51LKAqA@mail.gmail.com Backpatch-through: 19

Disallow NOT NULL NO INHERIT constraints on partitioned tables

2026-10-27T06:46:12Z

This was blocked during normal CREATE TABLE, but cases such as CREATE TABLE (LIKE) would copy the source table's NOT NULL NO INHERIT constraints and apply them to the partitioned table being created. This could mean that partitions didn't correctly receive the NOT NULL constraint when they were created, thus could contain NULL values. cacef1722 added a test to ensure CREATE TABLE (LIKE) PARTITION BY fails when the source table has any CHECK NO INHERIT constraints. Here we do the same for NOT NULL constraints. It's probably unlikely that people have commonly done this, but the release notes may wish to note that people should check if this has happened to them. The following query can used each database to identify problematic constraints: SELECT conrelid::regclass, conname, connoinherit FROM pg_constraint WHERE contype = 'n' AND connoinherit = true AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p'); If no results are shown, the queried database isn't affected. To resolve these issues, unwanted constraints can simply be dropped from the partitioned table with: ALTER TABLE ... DROP CONSTRAINT ...; To remove the NO INHERIT flag, use: ALTER TABLE ... ALTER CONSTRAINT ... INHERIT; This will fail if any partition contains a NULL value in the given column. Finding the cause of failures is made more difficult by the planner trusting that "WHERE col IS NULL" cannot be true because of the presence of a NOT NULL constraint. Affected users may need to resort to tricks like WHERE col+0 IS NULL to find these. If it was thought to be a common problem, then we could adjust get_relation_notnullatts(), and the equivalent functions on older branches to ignore constraints marked as NO INHERIT on partitioned tables, but currently that would require an expensive lookup to find the pg_constraint row. Backpatch to v18 where NOT NULL NO INHERIT constraints were added by 14e87ffa5. Bug: #19770 Reported-by: Ann C Author: David Rowley Author: Nitin Motiani Reviewed-by: Chao Li Reviewed-by: Nitin Motiani Discussion: https://postgr.es/m/19770-7c6e75fc30df7e06@postgresql.org Discussion: https://postgr.es/m/CAH5HC96YCzOy+9JZLQ4n0sMchVnharTOXrr4sbYuh=_d+ffjAA@mail.gmail.com Backpatch-through: 18

pg_stat_statements: Fix toplevel tracking across nesting levels

2026-10-27T06:17:17Z

pg_stat_statements decides whether a query is toplevel from the nesting level at the time each hook runs. A QueryDesc can outlive the level it started at. For example, a cursor's query starts at level 1, inside DECLARE, but if the cursor is closed implicitly at COMMIT, ExecutorEnd runs at level 0. The entry created for the query at parse analysis has toplevel = false, so ExecutorEnd misses it and stores a duplicate with the raw query text and toplevel = true. The same happens with track = top when another extension such as auto_explain requests query instrumentation. ExecutorEnd stores the query even though ExecutorStart did not track it. PGSS is upgraded to save the nesting level in the extension state of the QueryDesc when ExecutorStart() tracks a query. ExecutorEnd() then uses it in place of the current level and skips the query if no state was saved. For now, only the nesting level is tracked in the private extension state attached to QueryDesc by PGSS. auto_explain is not touched either. All these pieces are left as future improvements. No backpatch is done, due to the ABI changes required in QueryDesc. This relies on the work done previously in e5d5d1ad1e3a. Reported-by: Gaurav Singh Author: Sami Imseih Author: Michael Paquier Discussion: https://postgr.es/m/CAEcQ1bZrgwKsauC=03otebkLk77Zc_hYNjhTP3OUdpXs++u+BA@mail.gmail.com Discussion: https://postgr.es/m/CAA5RZ0v281uwSudcFrY8BymSRDM4J6PAHfzqg_9R+i7zWbTb2A@mail.gmail.com

Add custom extension states to QueryDesc

2026-10-27T06:05:59Z

Extensions sometimes need to carry private data from one executor hook to another for a given query. ExecutorEnd() can run in a different context than ExecutorStart(), so backend-wide variables cannot be used for that. This commit adds a way for loadable modules to attach private state to a QueryDesc, modeled in the same fashion as what is already done for PlannerGlobal, PlannerInfo, RelOptInfo and ExplainState. GetQueryDescExtensionId() maps an extension name to a backend-local ID. SetQueryDescExtensionState() and GetQueryDescExtensionState() store and fetch an opaque pointer for that ID. The array of pointers is allocated in the memory context of the QueryDesc, and is freed by FreeQueryDesc(). What the pointers refer to is owned by the extensions. There are no users of this facility yet. A follow-up commit will make use of it. Some potential use cases have been identified for pg_stat_statements and auto_explain, where both need to be able to co-exist in peace. Extensions living outside of core may also find a use for it. Author: Michael Paquier Reviewed-by: Sami Imseih Discussion: https://postgr.es/m/CAEcQ1bZrgwKsauC=03otebkLk77Zc_hYNjhTP3OUdpXs++u+BA@mail.gmail.com