PostgreSQL 19.0 (upcoming) commit log

commit   : 9f4fd119b2cbb9a41ec0c19a8d6ec9b59b92c125    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Feb 2026 12:16:16 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Feb 2026 12:16:16 -0800    

Commit 1e7fe06c10c0a8da9dd6261a6be8d405dc17c728 changed  
pg_mbstrlen_with_len() to ereport(ERROR) if the input ends in an  
incomplete character.  Most callers want that.  text_substring() does  
not.  It detoasts the most bytes it could possibly need to get the  
requested number of characters.  For example, to extract up to 2 chars  
from UTF8, it needs to detoast 8 bytes.  In a string of 3-byte UTF8  
chars, 8 bytes spans 2 complete chars and 1 partial char.  
  
Fix this by replacing this pg_mbstrlen_with_len() call with a string  
traversal that differs by stopping upon finding as many chars as the  
substring could need.  This also makes SUBSTRING() stop raising an  
encoding error if the incomplete char is past the end of the substring.  
This is consistent with the general philosophy of the above commit,  
which was to raise errors on a just-in-time basis.  Before the above  
commit, SUBSTRING() never raised an encoding error.  
  
SUBSTRING() has long been detoasting enough for one more char than  
needed, because it did not distinguish exclusive and inclusive end  
position.  For avoidance of doubt, stop detoasting extra.  
  
Back-patch to v14, like the above commit.  For applications using  
SUBSTRING() on non-ASCII column values, consider applying this to your  
copy of any of the February 12, 2026 releases.  
  
Reported-by: SATŌ Kentarō <ranvis@gmail.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Bug: #19406  
Discussion: https://postgr.es/m/19406-9867fddddd724fca@postgresql.org  
Backpatch-through: 14  

commit   : 4644f8b23bb8cd5cf3454bcd69bc28a5fd5623a9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Feb 2026 12:16:16 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Feb 2026 12:16:16 -0800    

The prior order caused spurious Valgrind errors.  They're spurious  
because the ereport(ERROR) non-local exit discards the pointer in  
question.  pg_mblen_cstr() ordered the checks correctly, but these other  
two did not.  Back-patch to v14, like commit  
1e7fe06c10c0a8da9dd6261a6be8d405dc17c728.  
  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20260214053821.fa.noahmisch@microsoft.com  
Backpatch-through: 14  

commit   : ef3c3cf6d021ff9884c513afd850a9fe85cad736    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Sat, 14 Feb 2026 13:50:06 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Sat, 14 Feb 2026 13:50:06 +0700    

Radix sort can be much faster than quicksort, but for our purposes it  
is limited to sequences of unsigned bytes. To make tuples with other  
types amenable to this technique, several features of tuple comparison  
must be accounted for, i.e. the sort key must be "normalized":  
  
1. Signedness -- It's possible to modify a signed integer such that  
it can be compared as unsigned. For example, a signed char has range  
-128 to 127. If we cast that to unsigned char and add 128, the range  
of values becomes 0 to 255 while preserving order.  
  
2. Direction -- SQL allows specification of ASC or DESC. The  
descending case is easily handled by taking the complement of the  
unsigned representation.  
  
3. NULL values -- NULLS FIRST and NULLS LAST must work correctly.  
  
This commmit only handles the case where datum1 is pass-by-value  
Datum (possibly abbreviated) that compares like an ordinary  
integer. (Abbreviations of values of type "numeric" are a convenient  
counterexample.) First, tuples are partitioned by nullness in the  
correct NULL ordering. Then the NOT NULL tuples are sorted with radix  
sort on datum1. For tiebreaks on subsequent sortkeys (including the  
first sort key if abbreviated), we divert to the usual qsort.  
  
ORDER BY queries on pre-warmed buffers are up to 2x faster on high  
cardinality inputs with radix sort than the sort specializations added  
by commit 697492434, so get rid of them. It's sufficient to fall back  
to qsort_tuple() for small arrays. Moderately low cardinality inputs  
show more modest improvents. Our qsort is strongly optimized for very  
low cardinality inputs, but radix sort is usually equal or very close  
in those cases.  
  
The changes to the regression tests are caused by under-specified sort  
orders, e.g. "SELECT a, b from mytable order by a;". For unstable  
sorts, such as our qsort and this in-place radix sort, there is no  
guarantee of the order of "b" within each group of "a".  
  
The implementation is taken from ska_byte_sort() (Boost licensed),  
which is similar to American flag sort (an in-place radix sort) with  
modifications to make it better suited for modern pipelined CPUs.  
  
The technique of normalization described above can also be extended  
to the case of multiple keys. That is left for future work (Thanks  
to Peter Geoghegan for the suggestion to look into this area).  
  
Reviewed-by: Chengpeng Yan <chengpeng_yan@outlook.com>  
Reviewed-by: zengman <zengman@halodbtech.com>  
Reviewed-by: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com> (earlier version)  
Discussion: https://postgr.es/m/CANWCAZYzx7a7E9AY16Jt_U3+GVKDADfgApZ-42SYNiig8dTnFA@mail.gmail.com  

commit   : aa082bed0b6433b58815683dde425bce57ed931c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 12:12:11 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 12:12:11 +0100    

Commit dfd79e2d added a TODO comment to update this paragraph  
when support for PASSING was added.  Commit 6185c9737cf added  
PASSING but missed resolving this TODO.  Fix by expanding the  
paragraph with a reference to PASSING.  
  
Author: Aditya Gollamudi <adigollamudi@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/20260117051406.sx6pss4ryirn2x4v@pgs  

commit   : 4469fe176118607f1a1dbcbbe5de57f9156e293f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 11:50:17 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 11:50:17 +0100    

The URL for Ditaa linked to the old Sourceforge version which is  
too old for what we need, the fork over on Github is the correct  
version to use for re-generating the SVG files for the docs. The  
required Ditaa version is 0.11.0 as it when SVG support as added.  
Running the version found on Sourceforge produce the error below:  
  
$ ditaa -E -S --svg in.txt out.txt  
Unrecognized option: --svg  
usage: ditaa <INPFILE> [OUTFILE] [-A] [-b <BACKGROUND>] [-d] [-E] [-e  
      <ENCODING>] [-h] [--help] [-o] [-r] [-S] [-s <SCALE>] [-T] [-t  
      <TABS>] [-v] [-W]  
  
While there, also mention that meson rules exists for building  
images.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://postgr.es/m/CAN55FZ2O-23xERF2NYcvv9DM_1c9T16y6mi3vyP=O1iuXS0ASA@mail.gmail.com  

commit   : 4ec0e75afd488d41482ae10f6b5df9fa9a586dee    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 11:50:14 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 11:50:14 +0100    

This adds an 'images' target to the meson build system in order to  
be able to regenerate the images used in the docs.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAN55FZ0c0Tcjx9=e-YibWGHa1-xmdV63p=THH4YYznz+pYcfig@mail.gmail.com  

commit   : 6736dea14afbe239588dad1c947ceb6e50adbf72    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Feb 2026 19:48:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Feb 2026 19:48:35 +0900    

The idea is to encourage more the use of these allocation routines  
across the tree, as these offer stronger type safety guarantees than  
pg_malloc() & co (type cast in the result, sizeof() embedded).  This set  
of changes is dedicated to the pg_dump code.  
  
Similar work has been done as of 31d3847a37be, as one example.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Reviewed-by: Aleksander Alekseev <aleksander@tigerdata.com>  
Discussion: https://postgr.es/m/CAHut+PvpGPDLhkHAoxw_g3jdrYxA1m16a8uagbgH3TGWSKtXNQ@mail.gmail.com  

commit   : 53c6bd0aa3de58baf828e60c6c8934d0a10a8501    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 11:36:31 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Feb 2026 11:36:31 +0100    

Use BackgroundPsql's published API for automatically restarting  
its timer for each query, rather than manually reaching into it  
to achieve the same thing.  
  
010_tab_completion.pl's logic for this predates the invention  
of BackgroundPsql (and 664d75753 missed the opportunity to  
make it cleaner).  030_pager.pl copied-and-pasted the code.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1100715.1712265845@sss.pgh.pa.us  

commit   : 775fc014156bdfa6938ef02dce3d85364b1bd220    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Feb 2026 12:17:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 13 Feb 2026 12:17:08 +0900    

This log message was referring to conflicts, but it is about checksum  
failures.  The log message improved in this commit should never show up,  
due to the fact that pgstat_prepare_report_checksum_failure() should  
always be called before pgstat_report_checksum_failures_in_db(), with a  
stats entry already created in the pgstats shared hash table.  The three  
code paths able to report database-level checksum failures follow  
already this requirement.  
  
Oversight in b96d3c389755.  
  
Author: Wang Peng <215722532@qq.com>  
Discussion: https://postgr.es/m/tencent_9B6CD6D9D34AE28CDEADEC6188DB3BA1FE07@qq.com  
Backpatch-through: 18  

commit   : d7edcec35c7c28edb3bf283dfe9c892b042ca158    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 12 Feb 2026 19:41:06 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 12 Feb 2026 19:41:06 +0200    

It's currently only used in the server, but it was placed in src/port  
with the idea that it might be useful in client programs too. However,  
it will currently fail to link if used in a client program, because  
CHECK_FOR_INTERRUPTS() is not usable in client programs. Fix that by  
wrapping it in "#ifndef FRONTEND".  
  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://www.postgresql.org/message-id/21cc7a48-99d9-4f69-9a3f-2c2de61ac8e5%40iki.fi  
Backpatch-through: 18  

commit   : d7a4291bb73e891243de7649ba92e7337a476434    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 12 Feb 2026 19:41:02 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 12 Feb 2026 19:41:02 +0200    

I renamed the field in commit ddc3250208, but missed this one  
reference.  

commit   : a4688988835f1f5e607040c8d89e52cbfba9369b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 12 Feb 2026 11:32:49 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 12 Feb 2026 11:32:49 -0600    

The uses of these functions do not justify the level of  
micro-optimization we've done and may even hurt performance in some  
cases (e.g., due to using function pointers).  This commit removes  
all architecture-specific implementations of pg_popcount{32,64} and  
converts the portable ones to inlined functions in pg_bitutils.h.  
These inlined versions should produce the same code as before (but  
inlined), so in theory this is a net gain for many machines.  A  
follow-up commit will replace the remaining loops over these  
word-length popcount functions with calls to pg_popcount(), further  
reducing the need for architecture-specific implementations.  
  
Suggested-by: John Naylor <johncnaylorls@gmail.com>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Discussion: https://postgr.es/m/CANWCAZY7R%2Biy%2Br9YM_sySNydHzNqUirx1xk0tB3ej5HO62GdgQ%40mail.gmail.com  

commit   : cb7b2e5e8efb3e5fb08052425cd00f067a56f877    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 12 Feb 2026 11:32:49 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 12 Feb 2026 11:32:49 -0600    

Over the past few releases, we've added a huge amount of complexity  
to our popcount implementations.  Commits fbe327e5b4, 79e232ca01,  
8c6653516c, and 25dc485074 did some preliminary refactoring, but  
many opportunities remain.  In particular, if we disclaim interest  
in micro-optimizing this code for 32-bit builds and in unnecessary  
alignment checks on x86-64, we can remove a decent chunk of code.  
I cannot find public discussion or benchmarks for the code this  
commit removes,  but it seems unlikely that this change will  
noticeably impact performance on affected systems.  
  
Suggested-by: John Naylor <johncnaylorls@gmail.com>  
Reviewed-by: John Naylor <johncnaylorls@gmail.com>  
Discussion: https://postgr.es/m/CANWCAZY7R%2Biy%2Br9YM_sySNydHzNqUirx1xk0tB3ej5HO62GdgQ%40mail.gmail.com  

commit   : 88327092ff06c48676d2a603420089bf493770f3    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 12 Feb 2026 09:55:06 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 12 Feb 2026 09:55:06 +0000    

This adds a new ON CONFLICT action DO SELECT [FOR UPDATE/SHARE], which  
returns the pre-existing rows when conflicts are detected. The INSERT  
statement must have a RETURNING clause, when DO SELECT is specified.  
  
The optional FOR UPDATE/SHARE clause allows the rows to be locked  
before they are are returned. As with a DO UPDATE conflict action, an  
optional WHERE clause may be used to prevent rows from being selected  
for return (but as with a DO UPDATE action, rows filtered out by the  
WHERE clause are still locked).  
  
Bumps catversion as stored rules change.  
  
Author: Andreas Karlsson <andreas@proxel.se>  
Author: Marko Tiikkaja <marko@joh.to>  
Author: Viktor Holmberg <v@viktorh.net>  
Reviewed-by: Joel Jacobson <joel@compiler.org>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Jian He <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/d631b406-13b7-433e-8c0b-c6040c4b4663@Spark  
Discussion: https://postgr.es/m/5fca222d-62ae-4a2f-9fcb-0eca56277094@Spark  
Discussion: https://postgr.es/m/2b5db2e6-8ece-44d0-9890-f256fdca9f7e@proxel.se  
Discussion: https://postgr.es/m/CAL9smLCdV-v3KgOJX3mU19FYK82N7yzqJj2HAwWX70E=P98kgQ@mail.gmail.com  

commit   : 788ec96d591d0a7c916f2f4332765f46410d73b5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 12 Feb 2026 14:38:31 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 12 Feb 2026 14:38:31 +0530    

Following e68b6adad9, the reason for skipping slot synchronization is  
stored as a slot property. This commit removes redundant function  
parameters that previously tracked this state, instead relying directly on  
the slot property.  
  
Additionally, this change centralizes the logic for skipping  
synchronization when required WAL has not yet been received or flushed. By  
consolidating this check, we reduce code duplication and the risk of  
inconsistent state updates across different code paths.  
  
In passing, add an assertion to ensure a slot is marked as temporary if a  
consistent point has not been reached during synchronization.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Shveta Malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/TY4PR01MB16907DD16098BE3B20486D4569463A@TY4PR01MB16907.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/CAFPTHDZAA+gWDntpa5ucqKKba41=tXmoXqN3q4rpjO9cdxgQrw@mail.gmail.com  

commit   : 706cadde3239842a41a3375d50dda8b33325c008    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 12 Feb 2026 09:01:42 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 12 Feb 2026 09:01:42 +0000    

The only place that used p_is_insert was transformAssignedExpr(),  
which used it to distinguish INSERT from UPDATE when handling  
indirection on assignment target columns -- see commit c1ca3a19df3.  
However, this information is already available to  
transformAssignedExpr() via its exprKind parameter, which is always  
either EXPR_KIND_INSERT_TARGET or EXPR_KIND_UPDATE_TARGET.  
  
As noted in the commit message for c1ca3a19df3, this use of  
p_is_insert isn't particularly pretty, so have transformAssignedExpr()  
use the exprKind parameter instead. This then allows p_is_insert to be  
removed entirely, which simplifies state management in a few other  
places across the parser.  
  
Author: Viktor Holmberg <v@viktorh.net>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/badc3b4c-da73-4000-b8d3-638a6f53a769@Spark  

commit   : cf74558feb8f41b2bc459f59ed3f991024d04893    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 12 Feb 2026 15:30:13 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 12 Feb 2026 15:30:13 +0900    

For a LEFT JOIN, if any var from the right-hand side (RHS) is forced  
to null by upper-level quals but is known to be non-null for any  
matching row, the only way the upper quals can be satisfied is if the  
join fails to match, producing a null-extended row.  Thus, we can  
treat this left join as an anti-join.  
  
Previously, this transformation was limited to cases where the join's  
own quals were strict for the var forced to null by upper qual levels.  
This patch extends the logic to check table constraints, leveraging  
the NOT NULL attribute information already available thanks to the  
infrastructure introduced by e2debb643.  If a forced-null var belongs  
to the RHS and is defined as NOT NULL in the schema (and is not  
nullable due to lower-level outer joins), we know that the left join  
can be reduced to an anti-join.  
  
Note that to ensure the var is not nullable by any lower-level outer  
joins within the current subtree, we collect the relids of base rels  
that are nullable within each subtree during the first pass of the  
reduce-outer-joins process.  This allows us to verify in the second  
pass that a NOT NULL var is indeed safe to treat as non-nullable.  
  
Based on a proposal by Nicolas Adenis-Lamarre, but this is not the  
original patch.  
  
Suggested-by: Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>  
Author: Tender Wang <tndrwang@gmail.com>  
Co-authored-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/CACPGbctKMDP50PpRH09in+oWbHtZdahWSroRstLPOoSDKwoFsw@mail.gmail.com  

commit   : 9863c90759ecb3c200520db9a8b02c33eaec6e17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Feb 2026 16:53:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Feb 2026 16:53:14 -0500    

If the variable's value is null, exec_stmt_return() missed filling  
in estate->rettype.  This is a pretty old bug, but we'd managed not  
to notice because that value isn't consulted for a null result ...  
unless we have to cast it to a domain.  That case led to a failure  
with "cache lookup failed for type 0".  
  
The correct way to assign the data type is known by exec_eval_datum.  
While we could copy-and-paste that logic, it seems like a better  
idea to just invoke exec_eval_datum, as the ROW case already does.  
  
Reported-by: Pavel Stehule <pavel.stehule@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAFj8pRBT_ahexDf-zT-cyH8bMR_qcySKM8D5nv5MvTWPiatYGA@mail.gmail.com  
Backpatch-through: 14  

commit   : 78a5e3074b824b4bbcb75ea4dd565ce735f54293    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 Feb 2026 18:50:57 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 Feb 2026 18:50:57 +0200    

The pg_stat_activity view shows information for aux processes, but the  
pg_stat_get_backend_wait_event() and  
pg_stat_get_backend_wait_event_type() functions did not. To fix, call  
AuxiliaryPidGetProc(pid) if BackendPidGetProc(pid) returns NULL, like  
we do in pg_stat_get_activity().  
  
In version 17 and above, it's a little silly to use those functions  
when we already have the ProcNumber at hand, but it was necessary  
before v17 because the backend ID was different from ProcNumber. I  
have other plans for wait_event_info on master, so it doesn't seem  
worth applying a different fix on different versions now.  
  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/c0320e04-6e85-4c49-80c5-27cfb3a58108@iki.fi  
Backpatch-through: 14  

commit   : 1d92e0c2cc4789255c630d8776bbe85ca9ebc27f    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 11 Feb 2026 10:36:15 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 11 Feb 2026 10:36:15 -0600    

This commit adds a new parameter called  
password_expiration_warning_threshold that controls when the server  
begins emitting imminent-password-expiration warnings upon  
successful password authentication.  By default, this parameter is  
set to 7 days, but this functionality can be disabled by setting it  
to 0.  This patch also introduces a new "connection warning"  
infrastructure that can be reused elsewhere.  For example, we may  
want to warn about the use of MD5 passwords for a couple of  
releases before removing MD5 password support.  
  
Author: Gilles Darold <gilles@darold.net>  
Co-authored-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Reviewed-by: songjinzhou <tsinghualucky912@foxmail.com>  
Reviewed-by: liu xiaohui <liuxh.zj.cn@gmail.com>  
Reviewed-by: Yuefei Shi <shiyuefei1004@gmail.com>  
Reviewed-by: Steven Niu <niushiji@gmail.com>  
Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/129bcfbf-47a6-e58a-190a-62fc21a17d03%40migops.com  

commit   : a3fd53babb8e8bde688739ec367a6d170495cfb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Feb 2026 11:03:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Feb 2026 11:03:01 -0500    

The buildfarm occasionally shows a variant row order in the output  
of this UPDATE ... RETURNING, implying that the preceding INSERT  
dropped one of the rows into some free space within the table rather  
than appending them all at the end.  It's not entirely clear why that  
happens some times and not other times, but we have established that  
it's affected by concurrent activity in other databases of the  
cluster.  In any case, the behavior is not wrong; the test is at fault  
for presuming that a seqscan will give deterministic row ordering.  
Add an ORDER BY atop the update to stop the buildfarm noise.  
  
The buildfarm seems to have shown this only in v18 and master  
branches, but just in case the cause is older, back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 1efdd7cc630a963e56f34d44877d2097b98166d6    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 11 Feb 2026 16:38:18 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 11 Feb 2026 16:38:18 +0100    

* Remove an unused variable  
* Use "default log level" consistently (instead of "generic")  
* Keep the process types in alphabetical order (missed one place in the  
  SGML docs)  
* Since log_min_messages type was changed from enum to string, it  
  is a good idea to add single quotes when printing it out.  Otherwise  
  it fails if the user copies and pastes from the SHOW output to SET,  
  except in the simplest case.  Using single quotes reduces confusion.  
* Use lowercase string for the burned-in default value, to keep the same  
  output as previous versions.  
  
Author: Euler Taveira <euler@eulerto.com>  
Author: Man Zeng <zengman@halodbtech.com>  
Author: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/202602091250.genyflm2d5dw@alvherre.pgsql  

commit   : 7984ce7a1d21819865e473f17cb6b928cf58a10d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 Feb 2026 16:48:45 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 Feb 2026 16:48:45 +0200    

It protects the freeProcs and some other fields in ProcGlobal, so  
let's move it there. It's good for cache locality to have it next to  
the thing it protects, and just makes more sense anyway. I believe it  
was allocated as a separate shared memory area just for historical  
reasons.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/b78719db-0c54-409f-b185-b0d59261143f@iki.fi  

commit   : bc953bf52314ca881a18703f86b68743ef6f3a32    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 11 Feb 2026 10:52:58 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 11 Feb 2026 10:52:58 +0000    

On the INSERT page, mention that SELECT privileges are also required  
for any columns mentioned in the arbiter clause, including those  
referred to by the constraint, and clarify that this applies to all  
forms of ON CONFLICT, not just ON CONFLICT DO UPDATE.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Viktor Holmberg <v@viktorh.net>  
Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com  
Backpatch-through: 14  

commit   : 227a6ea65740bb8c5b1f37df016d7861fcba11c5    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 11 Feb 2026 10:25:05 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 11 Feb 2026 10:25:05 +0000    

On the CREATE POLICY page, the description of per-command policies  
stated that SELECT policies are applied when an INSERT has an ON  
CONFLICT DO NOTHING clause. However, that is only the case if it  
includes an arbiter clause, so clarify that.  
  
While at it, also clarify the comment in the regression tests that  
cover this.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Viktor Holmberg <v@viktorh.net>  
Discussion: https://postgr.es/m/CAEZATCXGwMQ+x00YY9XYG46T0kCajH=21QaYL9Xatz0dLKii+g@mail.gmail.com  
Backpatch-through: 14  

commit   : ab32a9e21d37ede830635f502283883592ab0a62    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 Feb 2026 11:49:18 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 Feb 2026 11:49:18 +0200    

It was a leftover from commit 5764f611e1, which converted the loop to  
use dclist_foreach.  
  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://www.postgresql.org/message-id/3dd6f70c-b94d-4428-8e75-74a7136396be@iki.fi  

commit   : 7358abcc6076f4b2530d10126ab379f8aea612a5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 17:55:59 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 17:55:59 -0500    

An extension (or core code) might want to reconstruct the planner's  
decisions about whether and where to perform partitionwise joins from  
the final plan. To do so, it must be possible to find all of the RTIs  
of partitioned tables appearing in the plan. But when an AppendPath  
or MergeAppendPath pulls up child paths from a subordinate AppendPath  
or MergeAppendPath, the RTIs of the subordinate path do not appear  
in the final plan, making this kind of reconstruction impossible.  
  
To avoid this, propagate the RTI sets that would have been present  
in the 'apprelids' field of the subordinate Append or MergeAppend  
nodes that would have been created into the surviving Append or  
MergeAppend node, using a new 'child_append_relid_sets' field for  
that purpose. The value of this field is a list of Bitmapsets,  
because each relation whose append-list was pulled up had its own  
set of RTIs: just one, if it was a partitionwise scan, or more than  
one, if it was a partitionwise join. Since our goal is to see where  
partitionwise joins were done, it is essential to avoid losing the  
information about how the RTIs were grouped in the pulled-up  
relations.  
  
This commit also updates pg_overexplain so that EXPLAIN (RANGE_TABLE)  
will display the saved RTI sets.  
  
Co-authored-by: Robert Haas <rhaas@postgresql.org>  
Co-authored-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Haibo Yan <tristan.yim@gmail.com>  
Reviewed-by: Alexandra Wang <alexandra.wang.oss@gmail.com>  
Discussion: http://postgr.es/m/CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com  

commit   : 9181c870bada196711206f3a795bde6b8c43dcd3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Feb 2026 07:33:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Feb 2026 07:33:24 +0900    

This commit changes the definition of varlena to a typedef, so as it  
becomes possible to remove "struct" markers from various declarations in  
the code base.  Historically, "struct" markers are not the project style  
for variable declarations, so this update simplifies the code and makes  
it more consistent across the board.  
  
This change has an impact on the following structures, simplifying  
declarations using them:  
- varlena  
- varatt_indirect  
- varatt_external  
  
This cleanup has come up in a different path set that played with  
TOAST and varatt.h, independently worth doing on its own.  
  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/aW8xvVbovdhyI4yo@paquier.xyz  

commit   : 0d4391b265f83023d0b7eed71817517410f76e60    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 16:46:05 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 16:46:05 -0500    

An extension (or core code) might want to reconstruct the planner's  
choice of join order from the final plan. To do so, it must be possible  
to find all of the RTIs that were part of the join problem in that plan.  
Commit adbad833f3d9e9176e8d7005f15ea6056900227d, together with the  
earlier work in 8c49a484e8ebb0199fba4bd68eaaedaf49b48ed0, is enough to  
let us match up RTIs we see in the final plan with RTIs that we see  
during the planning cycle, but we still have a problem if the planner  
decides to drop some RTIs out of the final plan altogether.  
  
To fix that, when setrefs.c removes a SubqueryScan, single-child Append,  
or single-child MergeAppend from the final Plan tree, record the type of  
the removed node and the RTIs that the removed node would have scanned  
in the final plan tree. It would be natural to record this information  
on the child of the removed plan node, but that would require adding an  
additional pointer field to type Plan, which seems undesirable.  So,  
instead, store the information in a separate list that the executor need  
never consult, and use the plan_node_id to identify the plan node with  
which the removed node is logically associated.  
  
Also, update pg_overexplain to display these details.  
  
Reviewed-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Haibo Yan <tristan.yim@gmail.com>  
Reviewed-by: Alexandra Wang <alexandra.wang.oss@gmail.com>  
Discussion: http://postgr.es/m/CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com  

commit   : adbad833f3d9e9176e8d7005f15ea6056900227d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 15:33:39 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 15:33:39 -0500    

Suppose that we're currently planning a query and, when that same  
query was previously planned and executed, we learned something about  
how a certain table within that query should be planned. We want to  
take note when that same table is being planned during the current  
planning cycle, but this is difficult to do, because the RTI of the  
table from the previous plan won't necessarily be equal to the RTI  
that we see during the current planning cycle. This is because each  
subquery has a separate range table during planning, but these are  
flattened into one range table when constructing the final plan,  
changing RTIs.  
  
Commit 8c49a484e8ebb0199fba4bd68eaaedaf49b48ed0 allows us to match up  
subqueries seen in the previous planning cycles with the subqueries  
currently being planned just by comparing textual names, but that's  
not quite enough to let us deduce anything about individual tables,  
because we don't know where each subquery's range table appears in  
the final, flattened range table.  
  
To fix that, store a list of SubPlanRTInfo objects in the final  
planned statement, each including the name of the subplan, the offset  
at which it begins in the flattened range table, and whether or not  
it was a dummy subplan -- if it was, some RTIs may have been dropped  
from the final range table, but also there's no need to control how  
a dummy subquery gets planned. The toplevel subquery has no name and  
always begins at rtoffset 0, so we make no entry for it.  
  
This commit teaches pg_overexplain's RANGE_TABLE option to make use  
of this new data to display the subquery name for each range table  
entry.  
  
Reviewed-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Haibo Yan <tristan.yim@gmail.com>  
Reviewed-by: Alexandra Wang <alexandra.wang.oss@gmail.com>  
Discussion: http://postgr.es/m/CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com  

commit   : 0f4c8d33d49da012a04076159a008c9fa80bcc47    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 11:50:28 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 11:50:28 -0500    

Commit 94f3ad3961a2cb32d30c79f01a70db4caff13318 failed to do this  
because I couldn't think of a use for the information, but this has  
proven to be short-sighted. Best to fix it before this code is  
officially released.  
  
Now, the only argument to standard_planenr that isn't passed to  
planner_setup_hook is boundParams, but that is accessible via  
glob->boundParams, and so doesn't need to be passed separately.  
  
Discussion: https://www.postgresql.org/message-id/CA+TgmoYS4ZCVAF2jTce=bMP0Oq_db_srocR4cZyO0OBp9oUoGg@mail.gmail.com  

commit   : cbdf93d4712229fd82d40d823882a5bc84e407e5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 11:49:07 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 10 Feb 2026 11:49:07 -0500    

Commit 4020b370f214315b8c10430301898ac21658143f had the idea that it  
would be a good idea to handle testing PGS_CONSIDER_NONPARTIAL within  
cost_material to save callers the trouble, but that turns out not to be  
a very good idea. One concern is that it makes cost_material() dependent  
on the caller having initialized certain fields in the MaterialPath,  
which is a bit awkward for materialize_finished_plan, which wants to use  
a dummy path.  
  
Another problem is that it can result in generated materialized nested  
loops where the Materialize node is disabled, contrary to the intention  
of joinpath.c's logic in match_unsorted_outer() and  
consider_parallel_nestloop(), which aims to consider such paths only  
when they would not need to be disabled. In the previous coding, it was  
possible for the pgs_mask on the joinrel to have PGS_CONSIDER_NONPARTIAL  
set, while the inner rel had the same bit clear. In that case, we'd  
generate and then disable a Materialize path.  
  
That seems wrong, so instead, pull up the logic to test the  
PGS_CONSIDER_NONPARTIAL bit into joinpath.c, restoring the historical  
behavior that either we don't generate a given materialized nested loop  
in the first place, or we don't disable it.  
  
Discussion: http://postgr.es/m/CA+TgmoawzvCoZAwFS85tE5+c8vBkqgcS8ZstQ_ohjXQ9wGT9sw@mail.gmail.com  
Discussion: http://postgr.es/m/CA+TgmoYS4ZCVAF2jTce=bMP0Oq_db_srocR4cZyO0OBp9oUoGg@mail.gmail.com  

commit   : be5257725d7f65708f5955a3a4beaedaa370e45b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 10 Feb 2026 16:23:10 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 10 Feb 2026 16:23:10 +0200    

Two changes here:  
  
1. Introduce a separate RECOVERY_CONFLICT_BUFFERPIN_DEADLOCK flag to  
indicate a suspected deadlock that involves a buffer pin. Previously  
the startup process used the same flag for a deadlock involving just  
regular locks, and to check for deadlocks involving the buffer  
pin. The cases are handled separately in the startup process, but the  
receiving backend had to deduce which one it was based on  
HoldingBufferPinThatDelaysRecovery(). With a separate flag, the  
receiver doesn't need to guess.  
  
2. Rewrite the ProcessRecoveryConflictInterrupt() function to not rely  
on fallthrough through the switch-statement. That was difficult to  
read.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/4cc13ba1-4248-4884-b6ba-4805349e7f39@iki.fi  

commit   : 17f51ea818753093f929b4c235f3b89ebcc7c5fb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 10 Feb 2026 16:23:08 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 10 Feb 2026 16:23:08 +0200    

Share the same PROCSIG_RECOVERY_CONFLICT flag for all recovery  
conflict reasons. To distinguish, have a bitmask in PGPROC to indicate  
the reason(s).  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/4cc13ba1-4248-4884-b6ba-4805349e7f39@iki.fi  

commit   : ddc3250208bd5980a25b0421d607bae202fef06c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 10 Feb 2026 16:23:05 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 10 Feb 2026 16:23:05 +0200    

This helps the next commit.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/4cc13ba1-4248-4884-b6ba-4805349e7f39@iki.fi  

commit   : f33c585774223757b01c8eddd134d364492ed94c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Feb 2026 16:59:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Feb 2026 16:59:19 +0900    

The log messages used in this file applied too much quoting logic:  
- No need for quote_identifier(), which is fine to not use in the  
context of a log entry.  
- The usual project style is to group the namespace and object together  
in a quoted string, when mentioned in an log message.  This code quoted  
the namespace name and the extended statistics object name separately,  
which was confusing.  
  
Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20260210.143752.1113524465620875233.horikyota.ntt@gmail.com  

commit   : 307447e6dbc035c0e6e7a8ce9cee704a3b710ee9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Feb 2026 12:36:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Feb 2026 12:36:57 +0900    

This commit adds three attributes to the system view pg_stats_ext_exprs,  
whose data can exist when involving a range type in an expression:  
range_length_histogram  
range_empty_frac  
range_bounds_histogram  
  
These statistics fields exist since 918eee0c497c, and have become  
viewable in pg_stats later in bc3c8db8ae2f.  This puts the definition of  
pg_stats_ext_exprs on par with pg_stats.  
  
This issue has showed up during the discussion about the restore of  
extended statistics for expressions, so as it becomes possible to query  
the stats data to restore from the catalogs.  Having access to this data  
is useful on its own, without the restore part.  
  
Some documentation and some tests are added, written by me.  Corey has  
authored the part in system_views.sql.  
  
Bump catalog version.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aYmCUx9VvrKiZQLL@paquier.xyz  

commit   : f41ab51573a4c3d11f906b32a068182a1fd8596d    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 10 Feb 2026 10:19:25 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 10 Feb 2026 10:19:25 +0900    

In the spirit of 8d19d0e13, this patch teaches the planner about the  
principle that NullTest with !argisrow is fully equivalent to SQL's IS  
[NOT] DISTINCT FROM NULL.  
  
The parser already performs this transformation for literal NULLs.  
However, a DistinctExpr expression with one input evaluating to NULL  
during planning (e.g., via const-folding of "1 + NULL" or parameter  
substitution in custom plans) currently remains as a DistinctExpr  
node.  
  
This patch closes the gap for const-folded NULLs.  It specifically  
targets the case where one input is a constant NULL and the other is a  
nullable non-constant expression.  (If the other input were otherwise,  
the DistinctExpr node would have already been simplified to a constant  
TRUE or FALSE.)  
  
This transformation can be beneficial because NullTest is much more  
amenable to optimization than DistinctExpr, since the planner knows a  
good deal about the former and next to nothing about the latter.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49BMAOWvkdSHxpUDnniqJcEcGq3_8dd_5wTR4xrQY8urA@mail.gmail.com  

commit   : 0aaf0de7fed8555114aca766e9cdc836dad763a3    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 10 Feb 2026 10:18:47 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 10 Feb 2026 10:18:47 +0900    

The BooleanTest construct (IS [NOT] TRUE/FALSE/UNKNOWN) treats a NULL  
input as the logical value "unknown".  However, when the input is  
proven to be non-nullable, this special handling becomes redundant.  
In such cases, the construct can be simplified directly to a boolean  
expression or a constant.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49BMAOWvkdSHxpUDnniqJcEcGq3_8dd_5wTR4xrQY8urA@mail.gmail.com  

commit   : 0a379612540cc51e54dc1c0cc4b9ef8797d2533c    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 10 Feb 2026 10:17:45 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 10 Feb 2026 10:17:45 +0900    

The IS DISTINCT FROM construct compares values acting as though NULL  
were a normal data value, rather than "unknown".  Semantically, "x IS  
DISTINCT FROM y" yields true if the values differ or if exactly one is  
NULL, and false if they are equal or both NULL.  Unlike ordinary  
comparison operators, it never returns NULL.  
  
Previously, the planner only simplified this construct if all inputs  
were constants, folding it to a constant boolean result.  This patch  
extends the optimization to cases where inputs are non-constant but  
proven to be non-nullable.  Specifically, "x IS DISTINCT FROM NULL"  
folds to constant TRUE if "x" is known to be non-nullable.  For cases  
where both inputs are guaranteed not to be NULL, the expression  
becomes semantically equivalent to "x <> y", and the DistinctExpr is  
converted into an inequality OpExpr.  
  
This transformation provides several benefits.  It converts the  
comparison into a standard operator, allowing the use of partial  
indexes and constraint exclusion.  Furthermore, if the clause is  
negated (i.e., "IS NOT DISTINCT FROM"), it simplifies to an equality  
operator.  This enables the planner to generate better plans using  
index scans, merge joins, hash joins, and EC-based qual deduction.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49BMAOWvkdSHxpUDnniqJcEcGq3_8dd_5wTR4xrQY8urA@mail.gmail.com  

commit   : 158408fef8b96907bb14f89654dd2beab27ff030    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Feb 2026 14:58:02 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 9 Feb 2026 14:58:02 -0600    

For binary upgrades from v16 or newer, pg_upgrade transfers the  
files for pg_largeobject_metadata from the old cluster, as opposed  
to using COPY or ordinary SQL commands to reconstruct its contents.  
While this approach adds complexity, it can greatly reduce  
pg_upgrade's runtime when there are many large objects.  
  
Large objects with comments or security labels are one source of  
complexity for this approach.  During pg_upgrade, schema  
restoration happens before files are transferred.  Comments and  
security labels are transferred in the former step, but the COMMENT  
and SECURITY LABEL commands will fail if their corresponding large  
objects do not exist.  To deal with this, pg_upgrade first copies  
only the rows of pg_largeobject_metadata that are needed to avoid  
failures.  Later, pg_upgrade overwrites those rows by replacing  
pg_largeobject_metadata's files with its files in the old cluster.  
  
Unfortunately, there's a subtle problem here.  Simply put, there's  
no guarantee that pg_upgrade will overwrite all of  
pg_largeobject_metadata's files on the new cluster.  For example,  
the new cluster's version might more aggressively extend relations  
or create visibility maps, and pg_upgrade's file transfer code is  
not sophisticated enough to remove files that lack counterparts in  
the old cluster.  These extra files could cause problems  
post-upgrade.  
  
More fortunately, we can simultaneously fix the aforementioned  
problem and further optimize binary upgrades for clusters with many  
large objects.  If we teach the COMMENT and SECURITY LABEL commands  
to allow nonexistent large objects during binary upgrades,  
pg_upgrade no longer needs to transfer pg_largeobject_metadata's  
contents beforehand.  This approach also allows us to remove the  
associated dependency tracking from pg_dump, even for upgrades from  
v12-v15 that use COPY to transfer pg_largeobject_metadata's  
contents.  
  
In addition to what is described in the previous paragraph, this  
commit modifies the query in getLOs() to only retrieve LOs with  
comments or security labels for upgrades from v12 or newer.  We  
have long assumed that such usage is rare, so this should reduce  
pg_upgrade's memory usage and runtime in many cases.  We might also  
be able to remove the "upgrades from v12 or newer" restriction on  
the recent batch of optimizations by adding special handling for  
pg_largeobject_metadata's hidden OID column on older versions  
(since this catalog previously used the now-removed WITH OIDS  
feature), but that is left as a future exercise.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/3yd2ss6n7xywo6pmhd7jjh3bqwgvx35bflzgv3ag4cnzfkik7m%40hiyadppqxx6w  

commit   : 73d60ac385a93684f68297ae0ccb8f75bc6f23e1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Feb 2026 20:26:23 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Feb 2026 20:26:23 +0200    

Clean up a few leftovers from when the deadlock checker was called  
from signal handler. We stopped doing that in commit 6753333f55, in  
year 2015.  
  
- CheckDeadLock can return a return value directly to the caller,  
  there's no need to use a global variable for that.  
  
- Remove outdated comments that claimed that CheckDeadLock "signals  
  ProcSleep".  
  
- It should be OK to ereport() from DeadLockCheck now. I considered  
  getting rid of InitDeadLockChecking() and moving the workspace  
  allocations into DeadLockCheck, but it's still good to avoid doing  
  the allocations while we're holding all the partition locks. So just  
  update the comment to give that as the reason we do the allocations  
  up front.  

commit   : cbef472558ca50d282414e68083717c44b92ad62    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Feb 2026 19:15:20 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Feb 2026 19:15:20 +0100    

They are not and never have been used by any known code -- apparently we  
just cargo-culted them in commit 37484ad2aace (or their ancestor macros  
anyway, which begat these functions in commit 34694ec888d6).  Allegedly  
they're also potentially dangerous; users are better off going through  
HeapTupleSetHintBits instead.  
  
Author: Andy Fan <zhihuifan1213@163.com>  
Discussion: https://postgr.es/m/87sejogt4g.fsf@163.com  

commit   : 18f0afb2a635b433e778684acabffe1e52da8a86    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Feb 2026 19:15:44 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 9 Feb 2026 19:15:44 +0200    

Commit f3c9e341cd changed the type of objects in the List that  
get_extension_control_directories() returns, from "char *" to  
"ExtensionLocation *", but missed adjusting this one caller.  
  
Author: Chao Li <lic@highgo.com>  
Discussion: https://www.postgresql.org/message-id/362EA9B3-589B-475A-A16E-F10C30426E28@gmail.com  

commit   : c5dc75479b1525a3aa1daaf79028fa5af159800e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Feb 2026 09:08:10 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Feb 2026 09:08:10 -0800    

Backpatch-through: 14  
Security: CVE-2026-2006  

commit   : 8ebdf41c262ccd86407ca684aab3113bdbcf2c66    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 10:14:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 10:14:22 -0500    

While the preceding commit prevented such attachments from occurring  
in future, this one aims to prevent further abuse of any already-  
created operator that exposes _int_matchsel to the wrong data types.  
(No other contrib module has a vulnerable selectivity estimator.)  
  
We need only check that the Const we've found in the query is indeed  
of the type we expect (query_int), but there's a difficulty: as an  
extension type, query_int doesn't have a fixed OID that we could  
hard-code into the estimator.  
  
Therefore, the bulk of this patch consists of infrastructure to let  
an extension function securely look up the OID of a datatype  
belonging to the same extension.  (Extension authors have requested  
such functionality before, so we anticipate that this code will  
have additional non-security uses, and may soon be extended to allow  
looking up other kinds of SQL objects.)  
  
This is done by first finding the extension that owns the calling  
function (there can be only one), and then thumbing through the  
objects owned by that extension to find a type that has the desired  
name.  This is relatively expensive, especially for large extensions,  
so a simple cache is put in front of these lookups.  
  
Reported-by: Daniel Firer as part of zeroday.cloud  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-2004  
Backpatch-through: 14  

commit   : 841d42cc4e2f9ca1cf59758fc15619b00a11e148    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 10:07:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 10:07:31 -0500    

Selectivity estimators come in two flavors: those that make specific  
assumptions about the data types they are working with, and those  
that don't.  Most of the built-in estimators are of the latter kind  
and are meant to be safely attachable to any operator.  If the  
operator does not behave as the estimator expects, you might get a  
poor estimate, but it won't crash.  
  
However, estimators that do make datatype assumptions can malfunction  
if they are attached to the wrong operator, since then the data they  
get from pg_statistic may not be of the type they expect.  This can  
rise to the level of a security problem, even permitting arbitrary  
code execution by a user who has the ability to create SQL objects.  
  
To close this hole, establish a rule that built-in estimators are  
required to protect themselves against being called on the wrong type  
of data.  It does not seem practical however to expect estimators in  
extensions to reach a similar level of security, at least not in the  
near term.  Therefore, also establish a rule that superuser privilege  
is required to attach a non-built-in estimator to an operator.  
We expect that this restriction will have little negative impact on  
extensions, since estimators generally have to be written in C and  
thus superuser privilege is required to create them in the first  
place.  
  
This commit changes the privilege checks in CREATE/ALTER OPERATOR  
to enforce the rule about superuser privilege, and fixes a couple  
of built-in estimators that were making datatype assumptions without  
sufficiently checking that they're valid.  
  
Reported-by: Daniel Firer as part of zeroday.cloud  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-2004  
Backpatch-through: 14  

commit   : 60e7ae41a6987ed05dcfe87bddaccac8e1e93126    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 09:57:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 09:57:43 -0500    

These data types are represented like full-fledged arrays, but  
functions that deal specifically with these types assume that the  
array is 1-dimensional and contains no nulls.  However, there are  
cast pathways that allow general oid[] or int2[] arrays to be cast  
to these types, allowing these expectations to be violated.  This  
can be exploited to cause server memory disclosure or SIGSEGV.  
Fix by installing explicit checks in functions that accept these  
types.  
  
Reported-by: Altan Birler <altan.birler@tum.de>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-2003  
Backpatch-through: 14  

commit   : d536aee5566354e42a1012da9dd3960e45402af5    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Feb 2026 06:14:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 9 Feb 2026 06:14:47 -0800    

pgp_sym_decrypt() and pgp_pub_decrypt() will raise such errors, while  
bytea variants will not.  The existing "dat3" test decrypted to non-UTF8  
text, so switch that query to bytea.  
  
The long-term intent is for type "text" to always be valid in the  
database encoding.  pgcrypto has long been known as a source of  
exceptions to that intent, but a report about exploiting invalid values  
of type "text" brought this module to the forefront.  This particular  
exception is straightforward to fix, with reasonable effect on user  
queries.  Back-patch to v14 (all supported versions).  
  
Reported-by: Paul Gerste (as part of zeroday.cloud)  
Reported-by: Moritz Sanft (as part of zeroday.cloud)  
Author: shihao zhong <zhong950419@gmail.com>  
Reviewed-by: cary huang <hcary328@gmail.com>  
Discussion: https://postgr.es/m/CAGRkXqRZyo0gLxPJqUsDqtWYBbgM14betsHiLRPj9mo2=z9VvA@mail.gmail.com  
Backpatch-through: 14  
Security: CVE-2026-2006  

commit   : 38e0190ced714b33c43c9676d768cc6814fc662a    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Feb 2026 13:23:10 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 9 Feb 2026 13:23:10 +0100    

Change log_min_messages from being a single element to a comma-separated  
list of type:level elements, with 'type' representing a process type,  
and 'level' being a log level to use for that type of process.  The list  
must also have a freestanding level specification which is used for  
process types not listed, which convenientely makes the whole thing  
backwards-compatible.  
  
Some choices made here could be contested; for instance, we use the  
process type `backend` to affect regular backends as well as dead-end  
backends and the standalone backend, and `autovacuum` means both the  
launcher and the workers.  I think it's largely sensible though, and it  
can easily be tweaked if desired.  
  
Author: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Reviewed-by: Tan Yang <332696245@qq.com>  
Discussion: https://postgr.es/m/e85c6671-1600-4112-8887-f97a8a5d07b2@app.fastmail.com  

commit   : c67bef3f3252a3a38bf347f9f119944176a796ce    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 12 Jan 2026 10:20:06 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 12 Jan 2026 10:20:06 +1300    

A security patch changed them today, so close the coverage gap now.  
Test that buffer overrun is avoided when pg_mblen*() requires more  
than the number of bytes remaining.  
  
This does not cover the calls in dict_thesaurus.c or in dict_synonym.c.  
That code is straightforward.  To change that code's input, one must  
have access to modify installed OS files, so low-privilege users are not  
a threat.  Testing this would likewise require changing installed  
share/postgresql/tsearch_data, which was enough of an obstacle to not  
bother.  
  
Security: CVE-2026-2006  
Backpatch-through: 14  
Co-authored-by: Thomas Munro <thomas.munro@gmail.com>  
Co-authored-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  

commit   : 1e7fe06c10c0a8da9dd6261a6be8d405dc17c728    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 7 Jan 2026 22:14:31 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 7 Jan 2026 22:14:31 +1300    

A corrupted string could cause code that iterates with pg_mblen() to  
overrun its buffer.  Fix, by converting all callers to one of the  
following:  
  
1. Callers with a null-terminated string now use pg_mblen_cstr(), which  
raises an "illegal byte sequence" error if it finds a terminator in the  
middle of the sequence.  
  
2. Callers with a length or end pointer now use either  
pg_mblen_with_len() or pg_mblen_range(), for the same effect, depending  
on which of the two seems more convenient at each site.  
  
3. A small number of cases pre-validate a string, and can use  
pg_mblen_unbounded().  
  
The traditional pg_mblen() function and COPYCHAR macro still exist for  
backward compatibility, but are no longer used by core code and are  
hereby deprecated.  The same applies to the t_isXXX() functions.  
  
Security: CVE-2026-2006  
Backpatch-through: 14  
Co-authored-by: Thomas Munro <thomas.munro@gmail.com>  
Co-authored-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Reported-by: Paul Gerste (as part of zeroday.cloud)  
Reported-by: Moritz Sanft (as part of zeroday.cloud)  

commit   : 74ee636cc93d919c845e3e3ad3642e6366ce1802    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 26 Jan 2026 11:22:32 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 26 Jan 2026 11:22:32 +1300    

When converting multibyte to pg_wchar, the UTF-8 implementation would  
silently ignore an incomplete final character, while the other  
implementations would cast a single byte to pg_wchar, and then repeat  
for the remaining byte sequence.  While it didn't overrun the buffer, it  
was surely garbage output.  
  
Make all encodings behave like the UTF-8 implementation.  A later change  
for master only will convert this to an error, but we choose not to  
back-patch that behavior change on the off-chance that someone is  
relying on the existing UTF-8 behavior.  
  
Security: CVE-2026-2006  
Backpatch-through: 14  
Author: Thomas Munro <thomas.munro@gmail.com>  
Reported-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  

commit   : af79c30dc3e5369cd6d2bfdccd2c2c0ffbd60ef3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 5 Feb 2026 01:04:24 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 5 Feb 2026 01:04:24 +1300    

While EUC_CN supports only 1- and 2-byte sequences (CS0, CS1), the  
mb<->wchar conversion functions allow 3-byte sequences beginning SS2,  
SS3.  
  
Change pg_encoding_max_length() to return 3, not 2, to close a  
hypothesized buffer overrun if a corrupted string is converted to wchar  
and back again in a newly allocated buffer.  We might reconsider that in  
master (ie harmonizing in a different direction), but this change seems  
better for the back-branches.  
  
Also change pg_euccn_mblen() to report SS2 and SS3 characters as having  
length 3 (following the example of EUC_KR).  Even though such characters  
would not pass verification, it's remotely possible that invalid bytes  
could be used to compute a buffer size for use in wchar conversion.  
  
Security: CVE-2026-2006  
Backpatch-through: 14  
Author: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  

commit   : 00896ddaf41fa7b725991120678d544c18c6af70    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 20 Jan 2026 11:53:28 +0200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 20 Jan 2026 11:53:28 +0200    

The code made a subtle assumption that the lower-cased version of a  
string never has more characters than the original. That is not always  
true. For example, in a database with the latin9 encoding:  
  
    latin9db=# select lower(U&'\00CC' COLLATE "lt-x-icu");  
       lower  
    -----------  
     i\x1A\x1A  
    (1 row)  
  
In this example, lower-casing expands the single input character into  
three characters.  
  
The generate_trgm_only() function relied on that assumption in two  
ways:  
  
- It used "slen * pg_database_encoding_max_length() + 4" to allocate  
  the buffer to hold the lowercased and blank-padded string. That  
  formula accounts for expansion if the lower-case characters are  
  longer (in bytes) than the originals, but it's still not enough if  
  the lower-cased string contains more *characters* than the original.  
  
- Its callers sized the output array to hold the trigrams extracted  
  from the input string with the formula "(slen / 2 + 1) * 3", where  
  'slen' is the input string length in bytes. (The formula was  
  generous to account for the possibility that RPADDING was set to 2.)  
  That's also not enough if one input byte can turn into multiple  
  characters.  
  
To fix, introduce a growable trigram array and give up on trying to  
choose the correct max buffer sizes ahead of time.  
  
Backpatch to v18, but no further. In previous versions lower-casing was  
done character by character, and thus the assumption that lower-casing  
doesn't change the character length was valid. That was changed in v18,  
commit fb1a18810f.  
  
Security: CVE-2026-2007  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  

commit   : 54598670fe0a191f49848d1a1a8ab09d99616e71    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 20 Jan 2026 14:34:32 +0200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 20 Jan 2026 14:34:32 +0200    

The function assumed that if charlen == bytelen, there are no  
multibyte characters in the string. That's sensible, but the callers  
were a little careless in how they calculated the lengths. The callers  
converted the string to lowercase before calling make_trigram(), and  
the 'charlen' value was calculated *before* the conversion to  
lowercase while 'bytelen' was calculated after the conversion. If the  
lowercased string had a different number of characters than the  
original, make_trigram() might incorrectly apply the fastpath and  
treat all the bytes as single-byte characters, or fail to apply the  
fastpath (which is harmless), or it might hit the "Assert(bytelen ==  
charlen)" assertion. I'm not aware of any locale / character  
combinations where you could hit that assertion in practice,  
i.e. where a string converted to lowercase would have fewer characters  
than the original, but it seems best to avoid making that assumption.  
  
To fix, remove the 'charlen' argument. To keep the performance when  
there are no multibyte characters, always try the fast path first, but  
check the input for multibyte characters as we go. The check on each  
byte adds some overhead, but it's close enough. And to compensate, the  
find_word() function no longer needs to count the characters.  
  
This fixes one small bug in make_trigrams(): in the multibyte  
codepath, it peeked at the byte just after the end of the input  
string. When compiled with IGNORECASE, that was harmless because there  
is always a NUL byte or blank after the input string. But with  
!IGNORECASE, the call from generate_wildcard_trgm() doesn't guarantee  
that.  
  
Backpatch to v18, but no further. In previous versions lower-casing was  
done character by character, and thus the assumption that lower-casing  
doesn't change the character length was valid. That was changed in v18,  
commit fb1a18810f.  
  
Security: CVE-2026-2007  
Reviewed-by: Noah Misch <noah@leadboat.com>  

commit   : 379695d3cc70d040b547d912ce4842090d917ece    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Feb 2026 08:00:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Feb 2026 08:00:59 +0900    

pgp_pub_decrypt_bytea() was missing a safeguard for the session key  
length read from the message data, that can be given in input of  
pgp_pub_decrypt_bytea().  This can result in the possibility of a buffer  
overflow for the session key data, when the length specified is longer  
than PGP_MAX_KEY, which is the maximum size of the buffer where the  
session data is copied to.  
  
A script able to rebuild the message and key data that can trigger the  
overflow is included in this commit, based on some contents provided by  
the reporter, heavily editted by me.  A SQL test is added, based on the  
data generated by the script.  
  
Reported-by: Team Xint Code as part of zeroday.cloud  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Security: CVE-2026-2005  
Backpatch-through: 14  

commit   : 73dd7163c5d19f93b629d1ccd9d2a2de6e9667f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Feb 2026 23:15:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Feb 2026 23:15:20 -0500    

Looking again at commit 7cdb633c8, I wondered why we have hard-wired  
"1034" for the OID of type aclitem[].  Some other entries in the same  
array have numeric type OIDs as well.  This seems to be a hangover  
from years ago when not every built-in pg_type entry had an OID macro.  
But since we made genbki.pl responsible for generating these macros,  
there are macros available for all these array types, so there's no  
reason not to follow the project policy of never writing numeric OID  
constants in C code.  

commit   : c0bf15729f461308f54b7d4d46472c1ad43941a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Feb 2026 20:05:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Feb 2026 20:05:52 -0500    

This thinko caused us to not substitute our own getopt() code,  
which results in failing to parse long options for the postmaster  
since Solaris' getopt() doesn't do what we expect.  This can be seen  
in the results of buildfarm member icarus, which is the only one  
trying to build via meson on Solaris.  
  
Per consultation with pgsql-release, it seems okay to fix this  
now even though we're in release freeze.  The fix visibly won't  
affect any other platforms, and it can't break Solaris/meson  
builds any worse than they're already broken.  
  
Discussion: https://postgr.es/m/2471229.1770499291@sss.pgh.pa.us  
Backpatch-through: 16  

commit   : 1653ce5236c4948550e52d15d54e4b6bb66a23b1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Feb 2026 22:37:02 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Feb 2026 22:37:02 +0100    

Further fix of error message changed in commit 74a116a79b4.  The  
initial fix was not quite correct.  
  
Discussion: https://www.postgresql.org/message-id/flat/tencent_1EE1430B1E6C18A663B8990F%40qq.com  

commit   : 7467041cde9ed1966cb3ea18da8ac119b462c2e4    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Sat, 7 Feb 2026 17:02:35 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Sat, 7 Feb 2026 17:02:35 +0700    

Commit 176dffdf7 added a NULL array pointer check before performing  
a qsort in order to prevent undefined behavior when passing NULL  
pointer and zero length. To head off future degenerate cases, check  
that there are at least two elements to sort before proceeding with  
insertion sort. This has the added advantage of allowing us to remove  
four equivalent checks that guarded against recursion/iteration.  
  
There might be a tiny performance penalty from unproductive  
recursions, but we can buy that back by increasing the insertion sort  
threshold. That is left for future work.  
  
Discussion: https://postgr.es/m/CANWCAZZWvds_35nXc4vXD-eBQa_=mxVtqZf-PM_ps=SD7ghhJg@mail.gmail.com  

commit   : 0af05b5dbb42387957582e76232dc27138382e5a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Feb 2026 10:08:38 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Feb 2026 10:08:38 +0100    

This reverts commit 4cfce4e62c8f09f5b1f6a7f69760ca46a74406e2.  
  
This implementation fails to compile on newer MSVC that support  
__typeof_unqual__.  (Older versions did not support it and compiled  
fine.)  Revert for now and research further.  
  
Reported-by: Bryan Green <dbryan.green@gmail.com>  
Discussion: https://www.postgresql.org/message-id/b03ddcd4-2a16-49ee-b105-e7f609f3c514%40gmail.com  

commit   : 7cdb633c89da82d4c6fdfba007a9ff05a9dff29e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Feb 2026 20:46:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Feb 2026 20:46:03 -0500    

Commit 7b378237a widened AclMode to 64 bits, which implies that  
the alignment of AclItem is now determined by an int64 field.  
That commit correctly set the typalign for SQL type aclitem to  
'd', but it missed the hard-wired knowledge about _aclitem in  
bootstrap.c.  This doesn't seem to have caused any ill effects,  
probably because we never try to fill a non-null value into  
an aclitem[] column during bootstrap.  Nonetheless, it's clearly  
a gotcha waiting to happen, so fix it up.  
  
In passing, also fix a couple of typanalyze functions that were  
using hard-coded typalign constants when they could just as  
easily use greppable TYPALIGN_xxx macros.  
  
Noticed these while working on a patch to expand the set of  
typalign values.  I doubt we are going to pursue that path,  
but these fixes still seem worth a quick commit.  
  
Discussion: https://postgr.es/m/1127261.1769649624@sss.pgh.pa.us  

commit   : ba1e14134a775e56a76c1537936c61102827507f    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 6 Feb 2026 16:24:21 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 6 Feb 2026 16:24:21 -0600    

This commit adjusts a few debugging macros to match the style of  
those in pg_config_manual.h.  Like commits 123661427b and  
b4cbc106a6, these were discovered while reviewing Aleksander  
Alekseev's proposed changes to pgindent.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/aP-H6kSsGOxaB21k%40nathan  

commit   : d8d7c5dc8f74506d35c7e8242be997fd5cf388eb    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 6 Feb 2026 10:31:45 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 6 Feb 2026 10:31:45 -0800    

The main reason that libpq doesn't request protocol version 3.2 by  
default is because other proxy/server implementations don't implement  
the negotiation. This is a bit of a chicken-and-egg problem: We don't  
bump the default version that libpq requests, but other implementations  
may not be incentivized to implement version negotiation if their users  
never run into issues.  
  
One established practice to combat this is to flip Postel's Law on its  
head, by sending parameters that the server cannot possibly support. If  
the server fails the handshake instead of correctly negotiating, then  
the problem is surfaced naturally. If the server instead claims to  
support the bogus parameters, then we fail the connection to make the  
lie obvious. This is called "grease" (or "greasing"), after the GREASE  
mechanism in TLS that popularized the concept:  
  
    https://www.rfc-editor.org/rfc/rfc8701.html  
  
This patch reserves 3.9999 as an explicitly unsupported protocol version  
number and `_pq_.test_protocol_negotiation` as an explicitly unsupported  
protocol extension. A later commit will send these by default in order  
to stress-test the ecosystem during the beta period; that commit will  
then be reverted before 19 RC1, so that we can decide what to do with  
whatever data has been gathered.  
  
The _pq_.test_protocol_negotiation change here is intentionally docs-  
only: after its implementation is reverted, the parameter should remain  
reserved.  
  
Extracted/adapted from a patch by Jelte Fennema-Nio.  
  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Co-authored-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl  

commit   : e3d37853ecd51c87976df7ea5c5d641f45668370    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 6 Feb 2026 10:25:12 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 6 Feb 2026 10:25:12 -0800    

First, split the Protocol Versions table in two, and lead with the list  
of versions that are supported today. Reserved and unsupported version  
numbers go into the second table.  
  
Second, in anticipation of a new (reserved) protocol extension, document  
the extension negotiation process alongside version negotiation, and add  
the corresponding tables for future extension parameter registrations.  
  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/DDPR5BPWH1RJ.1LWAK6QAURVAY%40jeltef.nl  

commit   : 072c8421359730149f4eaf861ce55aa78968ba9d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 19:57:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 19:57:22 +0900    

This routine's internals directly used MyProcNumber to choose which  
object ID to assign for the hash key of a backend's stats entry, while  
the value to use is given as input argument of the function.  
  
The original intention was to pass MyProcNumber as an argument of  
pgstat_create_backend() when called in pgstat_bestart_final(),  
pgstat_beinit() ensuring that MyProcNumber has been set, not use it  
directly in the function.  This commit addresses this inconsistency by  
using the procnum given by the caller of pgstat_create_backend(), not  
MyProcNumber.  
  
This issue is not a cause of bugs currently.  However, let's keep the  
code in sync across all the branches where this code exists, as it could  
matter in a future backpatch.  
  
Oversight in 4feba03d8b92.  
  
Reported-by: Ryo Matsumura <matsumura.ryo@fujitsu.com>  
Discussion: https://postgr.es/m/TYCPR01MB11316AD8150C8F470319ACCAEE866A@TYCPR01MB11316.jpnprd01.prod.outlook.com  
Backpatch-through: 18  

commit   : 74a116a79b47631e163c9814f39f5d218834e94c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 15:38:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 15:38:16 +0900    

These errors are very unlikely going to show up, but in the event that  
they happen, some incorrect information would have been provided:  
- In pg_rewind, a stat() failure was reported as an open() failure.  
- In pg_combinebackup, a check for the new directory of a tablespace  
mapping was referred as the old directory.  
- In pg_combinebackup, a failure in reading a source file when copying  
blocks referred to the destination file.  
  
The changes for pg_combinebackup affect v17 and newer versions.  For  
pg_rewind, all the stable branches are affected.  
  
Author: Man Zeng <zengman@halodbtech.com>  
Discussion: https://postgr.es/m/tencent_1EE1430B1E6C18A663B8990F@qq.com  
Backpatch-through: 14  

commit   : f94e9141a0bbb365f8194517e142746466ee7014    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 31 May 2025 22:50:22 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 31 May 2025 22:50:22 +1200    

Provide a way to disable the use of posix_fallocate() for relation  
files.  It was introduced by commit 4d330a61bb1.  The new setting  
file_extend_method=write_zeros can be used as a workaround for problems  
reported from the field:  
  
 * BTRFS compression is disabled by the use of posix_fallocate()  
 * XFS could produce spurious ENOSPC errors in some Linux kernel  
   versions, though that problem is reported to have been fixed  
  
The default is file_extend_method=posix_fallocate if available, as  
before.  The write_zeros option is similar to PostgreSQL < 16, except  
that now it's multi-block.  
  
Backpatch-through: 16  
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Reported-by: Dimitrios Apostolou <jimis@gmx.net>  
Discussion: https://postgr.es/m/b1843124-fd22-e279-a31f-252dffb6fbf2%40gmx.net  

commit   : e35add48ccc2e5aa94de360f1a43c6c150bda54a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Feb 2026 09:40:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Feb 2026 09:40:05 +0900    

synchronized_standby_slots is defined in guc_parameter.dat as part of  
the REPLICATION_PRIMARY group and is listed under the "Primary Server"  
section in postgresql.conf.sample. However, in the documentation  
its description was previously placed under the "Sending Servers" section.  
  
Since synchronized_standby_slots only takes effect on the primary server,  
this commit moves its documentation to the "Primary Server" section to  
match its behavior and other references.  
  
Backpatch to v17 where synchronized_standby_slots was added.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwE_LwgXgCrqd08OFteJqdERiF3noqOKu2vt7Kjk4vMiGg@mail.gmail.com  
Backpatch-through: 17  

commit   : 9476ef206c64207a4fd2ddcb373759c7ede13a3c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Feb 2026 15:14:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Feb 2026 15:14:53 +0900    

The attribute storing the statistics data for a set of expressions in  
pg_statistic_ext_data is stxdexpr.  stxdexprs does not exist.  
  
Extracted from a larger patch by the same author.  Incorrect as of  
efbebb4e8587.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CADkLM=fPcci6oPyuyEZ0F4bWqAA7HzaWO+ZPptufuX5_uWt6kw@mail.gmail.com  

commit   : 7a1f0f8747a7f7491702be88570a8e4d33686d76    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 4 Feb 2026 17:11:27 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 4 Feb 2026 17:11:27 -0800    

Commit 29d0a77fa6 improved pg_upgrade to allow migrating logical slots  
provided that all logical slots have caught up (i.e., they have no  
pending decodable WAL records). Previously, this verification was done  
by checking each slot individually, which could be time-consuming if  
there were many logical slots to migrate.  
  
This commit optimizes the check to avoid reading the same WAL stream  
multiple times. It performs the check only for the slot with the  
minimum confirmed_flush_lsn and applies the result to all other slots  
in the same database. This limits the check to at most one logical  
slot per database.  
  
During the check, we identify the last decodable WAL record's LSN to  
report any slots with unconsumed records, consistent with the existing  
error reporting behavior. Additionally, the maximum  
confirmed_flush_lsn among all logical slots on the database is used as  
an early scan cutoff; finding a decodable WAL record beyond this point  
implies that no slot has caught up.  
  
Performance testing demonstrated that the execution time remains  
stable regardless of the number of slots in the database.  
  
Note that we do not distinguish slots based on their output plugins. A  
hypothetical plugin might use a replication origin filter that filters  
out changes from a specific origin. In such cases, we might get a  
false positive (erroneously considering a slot caught up). However,  
this is safe from a data integrity standpoint, such scenarios are  
rare, and the impact of a false positive is minimal.  
  
This optimization is applied only when the old cluster is version 19  
or later.  
  
Bump catalog version.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoBZ0LAcw1OHGEKdW7S5TRJaURdhEk3CLAW69_siqfqyAg@mail.gmail.com  

commit   : 3c5ec35dea254892d75d829b5642fc3732c8fcf9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Feb 2026 09:02:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 5 Feb 2026 09:02:12 +0900    

This affects two command patterns, showing information about relations:  
* oid2name -x -d DBNAME, applying to all relations on a database.  
* oid2name -x -d DBNAME -t TABNAME [-t ..], applying to a subset of  
defined relations on a database.  
  
The relative path of a relation is added to the information provided,  
using pg_relation_filepath().  
  
Author: David Bidoc <dcbidoc@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Guillaume Lelarge <guillaume.lelarge@dalibo.com>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Mark Wong <markwkm@gmail.com>  
Discussion: https://postgr.es/m/CABour1v2CU1wjjoM86wAFyezJQ3-+ncH43zY1f1uXeVojVN8Ow@mail.gmail.com  

commit   : 0c8e082fba8d36434552d3d7800abda54acafd57    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 4 Feb 2026 16:56:57 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 4 Feb 2026 16:56:57 +0100    

Instead of assigning the backend type in the Main function of each  
postmaster child, do it right after fork(), by which time it is already  
known by postmaster_child_launch().  This reduces the time frame during  
which MyBackendType is incorrect.  
  
Before this commit, ProcessStartupPacket would overwrite MyBackendType  
to B_BACKEND for dead-end backends, which is quite dubious.  Stop that.  
  
We may now see MyBackendType == B_BG_WORKER before setting up  
MyBgworkerEntry.  As far as I can see this is only a problem if we try  
to log a message and %b is in log_line_prefix, so we now have a constant  
string to cover that case.  Previously, it would print "unrecognized",  
which seems strictly worse.  
  
Author: Euler Taveira <euler@eulerto.com>  
Discussion: https://postgr.es/m/e85c6671-1600-4112-8887-f97a8a5d07b2@app.fastmail.com  

commit   : 36ead7123292c2849be9950f3e552325fad7e6b7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Feb 2026 00:43:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Feb 2026 00:43:06 +0900    

Commit 5f13999aa11 added a TAP test for GUC settings passed via the  
CONNECTION string in logical replication, but the buildfarm member  
sungazer reported test failures.  
  
The test incorrectly used the subscriber's log file position as the  
starting offset when reading the publisher's log. As a result, the test  
failed to find the expected log message in the publisher's log and  
erroneously reported a failure.  
  
This commit fixes the test to use the publisher's own log file position  
when reading the publisher's log.  
  
Also, to avoid similar confusion in the future, this commit splits the single  
$log_location variable into $log_location_pub and $log_location_sub,  
clearly distinguishing publisher and subscriber log positions.  
  
Backpatched to v15, where commit 5f13999aa11 introduced the test.  
  
Per buildfarm member sungazer.  
This issue was reported and diagnosed by Alexander Lakhin.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/966ec3d8-1b6f-4f57-ae59-fc7d55bc9a5a@gmail.com  
Backpatch-through: 15  

commit   : 176dffdf7d2a0ea2615c4e390a2ab7e69d14f90f    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 4 Feb 2026 17:55:49 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 4 Feb 2026 17:55:49 +0700    

Mostly this involves checking for NULL pointer before doing operations  
that add a non-zero offset.  
  
The exception is an overflow warning in heap_fetch_toast_slice(). This  
was caused by unneeded parentheses forcing an expression to be  
evaluated to a negative integer, which then got cast to size_t.  
  
Per clang 21 undefined behavior sanitizer.  
  
Backpatch to all supported versions.  
  
Co-authored-by: Alexander Lakhin <exclusion@gmail.com>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/777bd201-6e3a-4da0-a922-4ea9de46a3ee@gmail.com  
Backpatch-through: 14  

commit   : 084e42bc7109673e46527b0a0f284edf539c3285    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 4 Feb 2026 13:06:04 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 4 Feb 2026 13:06:04 +0200    

We can immediately make use of it in pg_signal_backend(), which  
previously fetched the process type from the backend status array with  
pgstat_get_backend_type_by_proc_number(). That was correct but felt a  
little questionable to me: backend status should be for observability  
purposes only, not for permission checks.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/b77e4962-a64a-43db-81a1-580444b3e8f5@iki.fi  

commit   : 4cfce4e62c8f09f5b1f6a7f69760ca46a74406e2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Feb 2026 08:39:55 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Feb 2026 08:39:55 +0100    

Currently, when the argument of copyObject() is const-qualified, the  
return type is also, because the use of typeof carries over all the  
qualifiers.  This is incorrect, since the point of copyObject() is to  
make a copy to mutate.  But apparently no code ran into it.  
  
The new implementation uses typeof_unqual, which drops the qualifiers,  
making this work correctly.  
  
typeof_unqual is standardized in C23, but all recent versions of all  
the usual compilers support it even in non-C23 mode, at least as  
__typeof_unqual__.  We add a configure/meson test for typeof_unqual  
and __typeof_unqual__ and use it if it's available, else we use the  
existing fallback of just returning void *.  
  
Reviewed-by: David Geier <geidav.pg@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/92f9750f-c7f6-42d8-9a4a-85a3cbe808f3%40eisentraut.org  

commit   : c8ec74713bf2c703c19f231ea4d1e6479630c72d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Feb 2026 16:38:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Feb 2026 16:38:06 +0900    

A failure while closing pg_wal/summaries/ incorrectly generated a report  
about pg_wal/archive_status/.  
  
While at it, this commit adds #undefs for the macros used in  
KillExistingWALSummaries() and KillExistingArchiveStatus() to prevent  
those values from being misused in an incorrect function context.  
  
Oversight in dc212340058b.  
  
Author: Tianchen Zhang <zhang_tian_chen@163.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/SE2P216MB2390C84C23F428A7864EE07FA19BA@SE2P216MB2390.KORP216.PROD.OUTLOOK.COM  
Backpatch-through: 17  

commit   : 78bf28e3bf504db0eea5e3bcb3c43e9908108480    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 3 Feb 2026 19:29:15 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 3 Feb 2026 19:29:15 +0100    

The pg_dump documentation had repetitive notes for the --schema,  
--table, and --extension switches, noting that dependent database  
objects are not automatically included in the dump.  This commit removes  
these notes and replaces them with a consolidated paragraph in the  
"Notes" section.  
  
pg_restore had a similar note for -t but lacked one for -n; do likewise.  
  
Also, add a note to --extension in pg_dump to note that ancillary files  
(such as shared libraries and control files) are not included in the  
dump and must be present on the destination system.  
  
Author: Florents Tselai <florents.tselai@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/284C4D55-4F90-4AA0-84C8-1E6A28DDF271@gmail.com  

commit   : 57bff90160fdee56a0d55d7eaa7ec5ad709fda08    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Feb 2026 15:08:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Feb 2026 15:08:16 +0200    

Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/4cc13ba1-4248-4884-b6ba-4805349e7f39@iki.fi  

commit   : cd375d5b6d5f7d89375541af444e16dd93d27a03    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Feb 2026 15:08:13 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Feb 2026 15:08:13 +0200    

I don't understand how to reach errdetail_abort() with  
MyProc->recoveryConflictPending set. If a recovery conflict signal is  
received, ProcessRecoveryConflictInterrupt() raises an ERROR or FATAL  
error to cancel the query or connection, and abort processing clears  
the flag. The error message from ProcessRecoveryConflictInterrupt() is  
very clear that the query or connection was terminated because of  
recovery conflict.  
  
The only way to reach it AFAICS is with a race condition, if the  
startup process sends a recovery conflict signal when the transaction  
has just entered aborted state for some other reason. And in that case  
the detail would be misleading, as the transaction was already aborted  
for some other reason, not because of the recovery conflict.  
  
errdetail_abort() was the only user of the recoveryConflictPending  
flag in PGPROC, so we can remove that and all the related code too.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/4cc13ba1-4248-4884-b6ba-4805349e7f39@iki.fi  

commit   : 96e2af605043974137d84edf5c0a24561956919e    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 3 Feb 2026 12:33:29 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 3 Feb 2026 12:33:29 +0100    

When using ALTER TABLE ... ADD CONSTRAINT to add a not-null constraint  
with an explicit name, we have to ensure that if the column is already  
marked NOT NULL, the provided name matches the existing constraint name.  
Failing to do so could lead to confusion regarding which constraint  
object actually enforces the rule.  
  
This patch adds a check to throw an error if the user tries to add a  
named not-null constraint to a column that already has one with a  
different name.  
  
Reported-by: yanliang lei <msdnchina@163.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Co-authored-bu: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/19351-8f1c523ead498545%40postgresql.org  

commit   : 955e50766869a5ccf862d7f8439f5d35b723c0f9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Feb 2026 08:36:47 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Feb 2026 08:36:47 +0100    

This allows moving the uses to more natural and useful positions.  
Also, a declaration is the more native use of static assertions in C.  
  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/2273bc2a-045d-4a75-8584-7cd9396e5534%40eisentraut.org  

commit   : 137d05df2f2014c584b229310b8635fa6a8572ba    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Feb 2026 08:36:47 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Feb 2026 08:36:47 +0100    

This keeps run-time assertions and static assertions clearly separate.  
  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/2273bc2a-045d-4a75-8584-7cd9396e5534%40eisentraut.org  

commit   : e05a24c2d4eab3dd76741dc6e6c18bb0584771c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Feb 2026 12:20:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Feb 2026 12:20:41 +0900    

Two wait events are added to the COPY FROM/TO code:  
* COPY_FROM_READ: reading data from a copy_file.  
* COPY_TO_WRITE: writing data to a copy_file.  
  
In the COPY code, copy_file can be set when processing a command through  
the pipe mode (for the non-DestRemote case), the program mode or the  
file mode, when processing fread() or fwrite() on it.  
  
Author: Nikolay Samokhvalov <nik@postgres.ai>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAM527d_iDzz0Kqyi7HOfqa-Xzuq29jkR6AGXqfXLqA5PR5qsng@mail.gmail.com  

commit   : 213fec296f419af8f199a721a9986e879656555c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Feb 2026 11:25:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Feb 2026 11:25:10 +0900    

This routine has an option to bypass an error if a WAL summary file is  
opened for read but is missing (missing_ok=true).  However, the code  
incorrectly checked for EEXIST, that matters when using O_CREAT and  
O_EXCL, rather than ENOENT, for this case.  
  
There are currently only two callers of OpenWalSummaryFile() in the  
tree, and both use missing_ok=false, meaning that the check based on the  
errno is currently dead code.  This issue could matter for out-of-core  
code or future backpatches that would like to use missing_ok set to  
true.  
  
Issue spotted while monitoring this area of the code, after  
a9afa021e95f.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/aYAf8qDHbpBZ3Rml@paquier.xyz  
Backpatch-through: 17  

commit   : 21c1125d660617f71b20304150e4a8583299cf86    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Feb 2026 11:14:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Feb 2026 11:14:00 +0900    

Previously, when synchronous_standby_names was changed (for example,  
by reducing the number of required synchronous standbys or modifying  
the standby list), backends waiting for synchronous replication were not  
released immediately, even if the new configuration no longer required them  
to wait. They could remain blocked until additional messages arrived from  
standbys and triggered their release.  
  
This commit improves walsender so that backends waiting for synchronous  
replication are released as soon as the updated configuration takes effect and  
the new settings no longer require them to wait, by calling  
SyncRepReleaseWaiters() when configuration changes are processed.  
  
As part of this change, the duplicated code that handles configuration changes  
in walsender has been refactored into a new helper function, which is now used  
at the three existing call places.  
  
Since this is an improvement rather than a bug fix, it is applied only to  
the master branch.  
  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/CAOzEurSRii0tEYhu5cePmRcvS=ZrxTLEvxm3Kj0d7_uKGdM23g@mail.gmail.com  

commit   : dddbbc253b923ef27f724c6abb5a6a39e1254d54    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Feb 2026 10:03:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 3 Feb 2026 10:03:19 +0900    

This commit introduces a new prompt escape %i for psql, which shows  
whether the connected server is operating in hot standby mode. It  
expands to standby if the server reports in_hot_standby = on, and  
primary otherwise.  
  
This is useful for distinguishing standby servers from primary ones  
at a glance, especially when working with multiple connections in  
replicated environments where libpq's multi-host connection strings  
are used.  
  
Author: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Discussion: https://www.postgresql.org/message-id/flat/016f6738-f9a9-4e98-bb5a-e1e4b9591d46@uni-muenster.de  

commit   : 4a99ef1a0d11ed464295515635a44aad1b000691    
  
author   : Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 2 Feb 2026 17:44:37 -0500    
  
committer: Melanie Plageman <melanieplageman@gmail.com>    
date     : Mon, 2 Feb 2026 17:44:37 -0500    

The test relies on VACUUM being able to mark a page all-visible, but  
this can fail when autovacuum in other sessions prevents the visibility  
horizon from advancing. Making the test table temporary isolates its  
horizon from other sessions, including catalog table vacuums, ensuring  
reliable test behavior.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/2b09fba6-6b71-497a-96ef-a6947fcc39f6%40gmail.com  

commit   : 12451d9d1f5991739540aefdec77694d59567b34    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 2 Feb 2026 15:43:01 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 2 Feb 2026 15:43:01 -0600    

Oversight in commit 5373bc2a08.  
  
Author: Michael Banck <mbanck@gmx.net>  
Discussion: https://postgr.es/m/20260202173156.GB17962%40p46.dedyn.io%3Blightning.p46.dedyn.io  

commit   : da7a1dc0d62ac3141328f4e6ad51d70e918167aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Feb 2026 14:39:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Feb 2026 14:39:50 -0500    

Separate att_align_nominal() into two macros, similarly to what  
was already done with att_align_datum() and att_align_pointer().  
The inner macro att_nominal_alignby() is really just TYPEALIGN(),  
while att_align_nominal() retains its previous API by mapping  
TYPALIGN_xxx values to numbers of bytes to align to and then  
calling att_nominal_alignby().  In support of this, split out  
tupdesc.c's logic to do that mapping into a publicly visible  
function typalign_to_alignby().  
  
Having done that, we can replace performance-critical uses of  
att_align_nominal() with att_nominal_alignby(), where the  
typalign_to_alignby() mapping is done just once outside the loop.  
  
In most places I settled for doing typalign_to_alignby() once  
per function.  We could in many places pass the alignby value  
in from the caller if we wanted to change function APIs for this  
purpose; but I'm a bit loath to do that, especially for exported  
APIs that extensions might call.  Replacing a char typalign  
argument by a uint8 typalignby argument would be an API change  
that compilers would fail to warn about, thus silently breaking  
code in hard-to-debug ways.  I did revise the APIs of array_iter_setup  
and array_iter_next, moving the element type attribute arguments to  
the former; if any external code uses those, the argument-count  
change will cause visible compile failures.  
  
Performance testing shows that ExecEvalScalarArrayOp is sped up by  
about 10% by this change, when using a simple per-element function  
such as int8eq.  I did not check any of the other loops optimized  
here, but it's reasonable to expect similar gains.  
  
Although the motivation for creating this patch was to avoid a  
performance loss if we add some more typalign values, it evidently  
is worth doing whether that patch lands or not.  
  
Discussion: https://postgr.es/m/1127261.1769649624@sss.pgh.pa.us  

commit   : 0c9f46c4280e31a4f49200f5d2cde37727651869    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Feb 2026 11:13:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Feb 2026 11:13:38 -0500    

Up to now we've used GNU-style local labels for branch targets  
in s_lock.h's assembly blocks.  But there's an alternative style,  
which I for one didn't know about till recently: use regular  
assembler labels, and insert a per-asm-block number in them  
using %= to ensure they are distinct across multiple TAS calls  
within one source file.  gcc has had %= since gcc 2.0, and  
I've verified that clang knows it too.  
  
While the immediate motivation for changing this is that AIX's  
assembler doesn't do local labels, it seems to me that this is a  
superior solution anyway.  There is nothing mnemonic about "1:",  
while a regular label can convey something useful, and at least  
to me it feels less error-prone.  Therefore let's standardize on  
this approach, also converting the one other usage in s_lock.h.  
  
Discussion: https://postgr.es/m/399291.1769998688@sss.pgh.pa.us  

commit   : a9afa021e95f2b0ffaaf26f3a27e685f634f4ac9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 10:21:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 10:21:04 +0900    

A failing unlink() was reporting an incorrect error message, referring  
to stat().  
  
Author: Man Zeng <zengman@halodbtech.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/tencent_3BBE865C5F49D452360FF190@qq.com  
Backpath-through: 17  

commit   : d46aa32ea5ce0c61a464cdc2c74fa9a428df8bc1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 08:02:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 08:02:39 +0900    

The build generates four files based on the wait event contents stored  
in wait_event_names.txt:  
- wait_event_types.h  
- pgstat_wait_event.c  
- wait_event_funcs_data.c  
- wait_event_types.sgml  
  
The SGML file is generated as part of a documentation build, with its  
data stored in doc/src/sgml/ for meson and configure.  The three others  
are handled differently for meson and configure:  
- In configure, all the files are created in src/backend/utils/activity/.  
A link to wait_event_types.h is created in src/include/utils/.  
- In meson, all the files are created in src/include/utils/.  
  
The two C files, pgstat_wait_event.c and wait_event_funcs_data.c, are  
then included in respectively wait_event.c and wait_event_funcs.c,  
without the "utils/" path.  
  
For configure, this does not present a problem.  For meson, this has to  
be combined with a trick in src/backend/utils/activity/meson.build,  
where include_directories needs to point to include/utils/ to make the  
inclusion of the C files work properly, causing builds to pull in  
PostgreSQL headers rather than system headers in some build paths, as  
src/include/utils/ would take priority.  
  
In order to fix this issue, this commit reworks the way the C/H files  
are generated, becoming consistent with guc_tables.inc.c:  
- For meson, basically nothing changes.  The files are still generated  
in src/include/utils/.  The trick with include_directories is removed.  
- For configure, the files are now generated in src/backend/utils/, with  
links in src/include/utils/ pointing to the ones in src/backend/.  This  
requires extra rules in src/backend/utils/activity/Makefile so as a  
make command in this sub-directory is able to work.  
- The three files now fall under header-stamp, which is actually simpler  
as guc_tables.inc.c does the same.  
- wait_event_funcs_data.c and pgstat_wait_event.c are now included with  
"utils/" in their path.  
  
This problem has not been an issue in the buildfarm; it has been noted  
with AIX and a conflict with float.h.  This issue could, however, create  
conflicts in the buildfarm depending on the environment with unexpected  
headers pulled in, so this fix is backpatched down to where the  
generation of the wait-event files has been introduced.  
  
While on it, this commit simplifies wait_event_names.txt regarding the  
paths of the files generated, to mention just the names of the files  
generated.  The paths where the files are generated became incorrect.  
The path of the SGML path was wrong.  
  
This change has been tested in the CI, down to v17.  Locally, I have run  
tests with configure (with and without VPATH), as well as meson, on the  
three branches.  
  
Combo oversight in fa88928470b5 and 1e68e43d3f0f.  
  
Reported-by: Aditya Kamath <aditya.kamath1@ibm.com>  
Discussion: https://postgr.es/m/LV8PR15MB64888765A43D229EA5D1CFE6D691A@LV8PR15MB6488.namprd15.prod.outlook.com  
Backpatch-through: 17  

commit   : 6918434a4acb2b14535b3c1be30d306666db7c24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jan 2026 15:11:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jan 2026 15:11:44 -0500    

Similarly to the preceding commit, 030_pager.pl was assuming  
that patterns it looks for in interactive psql output would  
appear by themselves on a line, but that assumption tends to  
fall over in builds made --without-readline: the output we  
get might have a psql prompt immediately followed by the  
expected line of output.  
  
For several of these tests, just checking for the pattern  
followed by newline seems sufficient, because we could not  
get a false match against the command echo, nor against the  
unreplaced command output if the pager fails to be invoked  
when expected.  However, that's fairly scary for the test  
that was relying on information_schema.referential_constraints:  
"\d+" could easily appear at the end of a line in that view.  
Let's get rid of that hazard by making a custom test view  
instead of using information_schema.referential_constraints.  
  
This test script is new in v19, so no need for back-patch.  
  
Reported-by: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>  
Author: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com>  
Discussion: https://postgr.es/m/db6fdb35a8665ad3c18be01181d44b31@postgrespro.ru  

commit   : a1d7ae2b2e38dd5d783c91316925f9f395da47e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jan 2026 14:59:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Jan 2026 14:59:25 -0500    

BackgroundPsql needs to wait for all the output from an interactive  
psql command to come back.  To make sure that's happened, it issues  
the command, then issues \echo and \warn psql commands that echo  
a "banner" string (which we assume won't appear in the command's  
output), then waits for the banner strings to appear.  The hazard  
in this approach is that the banner will also appear in the echoed  
psql commands themselves, so we need to distinguish those echoes from  
the desired output.  Commit 8b886a4e3 tried to do that by positing  
that the desired output would be directly preceded and followed by  
newlines, but it turns out that that assumption is timing-sensitive.  
In particular, it tends to fail in builds made --without-readline,  
wherein the command echoes will be made by the pty driver and may  
be interspersed with prompts issued by psql proper.  
  
It does seem safe to assume that the banner output we want will be  
followed by a newline, since that should be the last output before  
things quiesce.  Therefore, we can improve matters by putting quotes  
around the banner strings in the \echo and \warn psql commands, so  
that their echoes cannot include banner directly followed by newline,  
and then checking for just banner-and-newline in the match pattern.  
  
While at it, spruce up the pump() call in sub query() to look like  
the neater version in wait_connect(), and don't die on timeout  
until after printing whatever we got.  
  
Reported-by: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>  
Diagnosed-by: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Soumya S Murali <soumyamurali.work@gmail.com>  
Discussion: https://postgr.es/m/db6fdb35a8665ad3c18be01181d44b31@postgrespro.ru  
Backpatch-through: 14  

commit   : e2362eb2bd1459319dacaeaa5dc886dbca546b96    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 30 Jan 2026 18:22:56 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 30 Jan 2026 18:22:56 +0200    

For readability. It was a slight modularity violation to have fields  
in PGShmemHeader that were only used by the allocator code in  
shmem.c. And it was inconsistent that ShmemLock was nevertheless not  
stored there. Moving all the allocator-related fields to a separate  
struct makes it more consistent and modular, and removes the need to  
allocate and pass ShmemLock separately via BackendParameters.  
  
Merge InitShmemAccess() and InitShmemAllocation() into a single  
function that initializes the struct when called from postmaster, and  
when called from backends in EXEC_BACKEND mode, re-establishes the  
global variables. That's similar to all the *ShmemInit() functions  
that we have.  
  
Co-authored-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAExHW5uNRB9oT4pdo54qAo025MXFX4MfYrD9K15OCqe-ExnNvg@mail.gmail.com  

commit   : e76221bd95f0428cc9b5872a4bcbf0b7e40b77b0    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 30 Jan 2026 14:26:02 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 30 Jan 2026 14:26:02 +0100    

These changes should have been done by 2f9661311b83, but were  
overlooked.  I noticed while reviewing the code for commit b8926a5b4bb8.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/18984-0f4778a6599ac3ae@postgresql.org  

commit   : 1eb09ed63a8d8063dc6bb75c8f31ec564bf35250    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 30 Jan 2026 10:11:04 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 30 Jan 2026 10:11:04 +0100    

This makes the arrays somewhat easier to read.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>  
Discussion: https://postgr.es/m/202601281204.sdxbr5qvpunk@alvherre.pgsql  

commit   : bb26a81ee28c9d9c64e6f233fafa2792768ece1b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 30 Jan 2026 09:05:35 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 30 Jan 2026 09:05:35 +0900    

Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/20260128120056.b2a3e8184712ab5a537879eb@sraoss.co.jp  

commit   : 87f7b824f20c1c06884ef0711b4d32dbf4461436    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Jan 2026 17:27:23 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Jan 2026 17:27:23 -0500    

Previously, the CheckXidAlive check was performed within the table_scan*next*  
functions. This caused the check to be executed for every fetched tuple, an  
unnecessary overhead.  
  
To fix, move the check to table_beginscan* so it is performed once per scan  
rather than once per row.  
  
Note: table_tuple_fetch_row_version() does not use a scan descriptor;  
therefore, the CheckXidAlive check is retained in that function. The overhead  
is unlikely to be relevant for the existing callers.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Suggested-by: Andres Freund <andres@anarazel.de>  
Suggested-by: Amit Kapila <akapila@postgresql.org>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/tlpltqm5jjwj7mp66dtebwwhppe4ri36vdypux2zoczrc2i3mp%40dhv4v4nikyfg  

commit   : 333f586372aae764b7ad7e2c975b14fd431ce819    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Jan 2026 16:49:01 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 29 Jan 2026 16:49:01 -0500    

In fcb9c977aa5 I included an assertion in BufferLockConditional() to detect if  
a conditional lock acquisition is done on a buffer that we already have  
locked. The assertion was added in the course of adding other assertions.  
Unfortunately I failed to realize that some of our code relies on such lock  
acquisitions to silently fail. E.g. spgist and nbtree may try to conditionally  
lock an already locked buffer when acquiring a empty buffer.  
  
LWLockAcquireConditional(), which was previously used to implement  
ConditionalLockBuffer(), does not have such an assert.  
  
Instead of just removing the assert, and relying on the lock acquisition to  
fail due to the buffer already locked, this commit changes the behaviour of  
conditional content lock acquisition to fail if the current backend has any  
pre-existing lock on the buffer, even if the lock modes would not  
conflict. The reason for that is that we currently do not have space to track  
multiple lock acquisitions on a single buffer. Allowing multiple locks on the  
same buffer by a backend also seems likely to lead to bugs.  
  
There is only one non-self-exclusive conditional content lock acquisition, in  
GetVictimBuffer(), but it only is used if the target buffer is not pinned and  
thus can't already be locked by the current backend.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/90bd2cbb-49ce-4092-9f61-5ac2ab782c94@gmail.com  

commit   : bd9dfac8b121e67d7dd4a9bfecb1474fe6811927    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Jan 2026 16:16:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Jan 2026 16:16:36 -0500    

Commit 6ceef9408 was still one brick shy of a load, because it caused  
any usage at all of PGIOAlignedBlock or PGAlignedXLogBlock to fail  
under older g++.  Notably, this broke "headerscheck --cplusplus".  
We can permit references to these structs as abstract structs though;  
only actual declaration of such a variable needs to be forbidden.  
  
Discussion: https://www.postgresql.org/message-id/3119480.1769189606@sss.pgh.pa.us  

commit   : de90bb7db1f8c7ab1289f82f877a6e18f7b3d468    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 29 Jan 2026 10:14:55 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 29 Jan 2026 10:14:55 -0800    

The leaks were hard to reach in practice and the impact was low.  
  
The callers provide a buffer the same number of bytes as the source  
string (plus one for NUL terminator) as a starting size, and libc  
never increases the number of characters. But, if the byte length of  
one of the converted characters is larger, then it might need a larger  
destination buffer. Previously, in that case, the working buffers  
would be leaked.  
  
Even in that case, the call typically happens within a context that  
will soon be reset. Regardless, it's worth fixing to avoid such  
assumptions, and the fix is simple so it's worth backporting.  
  
Discussion: https://postgr.es/m/e2b7a0a88aaadded7e2d19f42d5ab03c9e182ad8.camel@j-davis.com  
Backpatch-through: 18  

commit   : ec317440716487753bafa4c0f8adae53e2c32446    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 29 Jan 2026 18:37:09 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 29 Jan 2026 18:37:09 +0100    

Use the proper constant InvalidXLogRecPtr instead of literal 0 when  
assigning XLogRecPtr variables and struct fields.  
  
This improves code clarity by making it explicit that these are  
invalid LSN values rather than ambiguous zero literals.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aRtd2dw8FO1nNX7k@ip-10-97-1-34.eu-west-3.compute.internal  

commit   : 71c1136989b363004357efb54c87b4192749a6a0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 29 Jan 2026 08:04:23 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 29 Jan 2026 08:04:23 -0500    

cost_tidrangescan() was setting the disabled_nodes value correctly,  
and then immediately resetting it to zero, due to poor code editing on  
my part.  
  
materialized_finished_plan correctly set matpath.parent to  
zero, but forgot to also set matpath.parallel_workers = 0, causing  
an access to uninitialized memory in cost_material. (This shouldn't  
result in any real problem, but it makes valgrind unhappy.)  
  
reparameterize_path was dereferencing a variable before verifying that  
it was not NULL.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us> (issue #1)  
Reported-by: Michael Paquier <michael@paquier.xyz> (issue #1)  
Diagnosed-by: Lukas Fittl <lukas@fittl.com> (issue #1)  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com> (issue #2)  
Reported-by: Richard Guo <guofenglinux@gmail.com> (issue #3)  
Discussion: http://postgr.es/m/CAN4CZFPvwjNJEZ_JT9Y67yR7C=KMNa=LNefOB8ZY7TKDcmAXOA@mail.gmail.com  
Discussion: http://postgr.es/m/aXrnPgrq6Gggb5TG@paquier.xyz  

commit   : 20a8f783e15c503125c2ed0ae890510879f62801    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 29 Jan 2026 09:47:09 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 29 Jan 2026 09:47:09 +0200    

Move WaitLSNWakeup() immediately after ApplyWalRecord() so waiters are  
signaled even when recoveryStopsAfter() breaks out for pause/promotion  
targets.  
  
Discussion: https://postgr.es/m/9533608f-f289-44bd-b881-9e5a73203c5b%40iki.fi  
Discussion: https://postgr.es/m/CABPTF7Wdq6KbvC3EhLX3Pz%3DODCCPEX7qVQ%2BE%3DcokkB91an2E-A%40mail.gmail.com  
Reported-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Author: Xuneng Zhou <xunengzhou@gmail.com>  

commit   : 4b77282f250103f2ecd54b9f45421c742006317b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 16:20:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 16:20:45 +0900    

In the psql prompt, %P prompt shows the current pipeline status.  Unlike  
most of the other options, its status was showing up in the output  
generated even if psql was not connected to a database.  This was  
confusing, because without a connection a pipeline status makes no  
sense.  
  
Like the other options, %P is updated so as its data is now hidden  
without an active connection.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/86EF76B5-6E62-404D-B9EC-66F4714D7D5F@gmail.com  
Backpatch-through: 18  

commit   : 740a1494f4bfb470b16e5b70c79fae473b1a655d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 14:57:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 14:57:47 +0900    

These have been fat-fingered in 0e80f3f88dea and 302879bd68d1.  The  
error message for ndistinct had an incorrect grammar, while the one for  
dependencies had finished with a period (incorrect based on the project  
guidelines).  
  
Discussion: https://postgr.es/m/aXrsjZQbVuB6236u@paquier.xyz  

commit   : fc365e4fccc46d2991ab9614198aa6d71b3838d2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 13:22:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 13:22:07 +0900    

The test added in this commit copies the data of an ANALYZE run on one  
relation to a secondary relation with the same attribute definitions and  
extended statistics objects.  Once the clone is done, the target and  
origin should have the same extended statistics information, with no  
differences.  
  
This test would have been able to catch e3094679b983, for example, as we  
expect the full range of statistics to be copied over, with no  
differences generated between the results of an ANALYZE and the data  
copied to the cloned relation.  
  
Note that this new test should remain at the bottom of stats_import.sql,  
so as any additions in the main relation and its clone are automatically  
covered when copying their statistics, so as it would work as a sanity  
check in the future.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com  

commit   : 0b7beec42ae2924f94410bded81f75f6f4eadd34    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 12:38:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 12:38:10 +0900    

The restore of extended statistics has some paths dedicated to  
multirange types and expressions for all the stats kinds supported, and  
we did not have coverage for the case where an extended stats object  
uses a multirange attribute with or without an expression.  
  
Extracted from a larger patch by the same author, with a couple of  
tweaks from me regarding the format of the output generated, to make it  
more readable to the eye.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com  

commit   : 3a98f989e8e596efb0db942ead90f64800136fac    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 29 Jan 2026 03:22:02 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 29 Jan 2026 03:22:02 +0000    

The test added in commit 851f6649cc uses a backup taken from a node  
created by the previous test to perform standby related checks. On  
Windows, however, the standby failed to start with the following error:  
FATAL:  could not rename file "backup_label" to "backup_label.old": Permission denied  
  
This occurred because some background sessions from the earlier test were  
still active. These leftover processes continued accessing the parent  
directory of the backup_label file, likely preventing the rename and  
causing the failure. Ensuring that these sessions are cleanly terminated  
resolves the issue in local testing.  
  
Additionally, the has_restoring => 1 option has been removed, as it was  
not required by the new test.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Backpatch-through: 17  
Discussion: https://postgr.es/m/CA+TgmobdVhO0ckZfsBZ0wqDO4qHVCwZZx8sf=EinafvUam-dsQ@mail.gmail.com  

commit   : efbebb4e85872b1c4d6bc19c4550e67850b83aab    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 12:14:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 12:14:08 +0900    

This commit adds support for the restore of extended statistics of the  
kind "mcv", aka most-common values.  
  
This format is different from n_distinct and dependencies stat types in  
that it is the combination of three of the four different arrays from the  
pg_stats_ext view which in turn require three different input parameters  
on pg_restore_extended_statistics().  These are translated into three  
input arguments for the function:  
- "most_common_vals", acting as a leader of the others.  It is a  
2-dimension array, that includes the common values.  
- "most_common_freqs", 1-dimension array of float8[], with a number of  
elements that has to match with "most_common_vals".  
- "most_common_base_freqs", 1-dimension array of float8[], with a number  
of elements that has to match with "most_common_vals".  
  
All three arrays are required to achieve the restore of this type of  
extended statistics (if "most_common_vals" happens to be NULL in the  
catalogs, the rest is NULL by design).  
  
Note that "most_common_val_nulls" is not required in input, its data is  
rebuilt from the decomposition of the "most_common_vals" array based on  
its text[] representation.  The initial versions of the patch provided  
this option in input, but we do not require it and it simplifies a lot  
the result.  
  
Support in pg_dump is added down to v13 which is where the support for  
this type of extended statistics has been added, when --statistics is  
used.  This means that upgrade and dumps can restore extended statistics  
data transparently, like "dependencies", "ndistinct", attribute and  
relation statistics.  For MCV, the values are directly queried from the  
relevant catalogs.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Co-authored-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com  

commit   : e09e5ad69acab315d2fd5c87626de1bdc0482480    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 11:59:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 11:59:43 +0900    

Issue noticed while playing this area of the tests for a different  
patch.  

commit   : ef1c8652065501503ed328249023509798a80df3    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 28 Jan 2026 15:56:48 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 28 Jan 2026 15:56:48 -0600    

commit   : 8f1e2dfe033e9a3236265c3b9f61bd226f4a8f54    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 28 Jan 2026 12:26:22 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 28 Jan 2026 12:26:22 -0800    

This commit moves the separate global variables for replication origin  
state into a single ReplOriginXactState struct. This groups logically  
related variables, which improves code readability and simplifies  
state management (e.g., resetting the state) by handling them as a  
unit.  
  
Author: Chao Li <lic@highgo.com>  
Suggested-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/CAEoWx2=pYvfRthXHTzSrOsf5_FfyY4zJyK4zV2v4W=yjUij1cA@mail.gmail.com  

commit   : 227eb4eea20575d9ef0aac0bdae7b6c2ba261f34    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 28 Jan 2026 11:45:26 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 28 Jan 2026 11:45:26 -0800    

Factor out common logic for clearing replorigin_session_* variables  
into a dedicated helper function, replorigin_xact_clear().  
  
This removes duplicated assignments of these variables across multiple  
call sites, and makes the intended scope of each reset explicit.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAEoWx2=pYvfRthXHTzSrOsf5_FfyY4zJyK4zV2v4W=yjUij1cA@mail.gmail.com  

commit   : 1fdbca159e0055fefc0b391ec09520d0b3bd9248    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 28 Jan 2026 11:03:29 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 28 Jan 2026 11:03:29 -0800    

The replication origin code was using inconsistent naming  
conventions. Functions were typically prefixed with 'replorigin',  
while typedefs and constants used "RepOrigin".  
  
This commit unifies the naming convention by renaming RepOriginId to  
ReplOriginId.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoBDgm3hDqUZ+nqu=ViHmkCnJBuJyaxG_yvv27BAi2zBmQ@mail.gmail.com  

commit   : 4020b370f214315b8c10430301898ac21658143f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Jan 2026 11:28:34 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Jan 2026 11:28:34 -0500    

Each RelOptInfo now has a pgs_mask member which is a mask of acceptable  
strategies. For most rels, this is populated from PlannerGlobal's  
default_pgs_mask, which is computed from the values of the enable_*  
GUCs at the start of planning.  
  
For baserels, get_relation_info_hook can be used to adjust pgs_mask for  
each new RelOptInfo, at least for rels of type RTE_RELATION. Adjusting  
pgs_mask is less useful for other types of rels, but if it proves to  
be necessary, we can revisit the way this hook works or add a new one.  
  
For joinrels, two new hooks are added. joinrel_setup_hook is called each  
time a joinrel is created, and one thing that can be done from that hook  
is to manipulate pgs_mask for the new joinrel. join_path_setup_hook is  
called each time we're about to add paths to a joinrel by considering  
some particular combination of an outer rel, an inner rel, and a join  
type. It can modify the pgs_mask propagated into JoinPathExtraData to  
restrict strategy choice for that particular combination of rels.  
  
To make joinrel_setup_hook work as intended, the existing calls to  
build_joinrel_partition_info are moved later in the calling functions;  
this is because that function checks whether the rel's pgs_mask includes  
PGS_CONSIDER_PARTITIONWISE, so we want it to only be called after  
plugins have had a chance to alter pgs_mask.  
  
Upper rels currently inherit pgs_mask from the input relation. It's  
unclear that this is the most useful behavior, but at the moment there  
are no hooks to allow the mask to be set in any other way.  
  
Reviewed-by: Lukas Fittl <lukas@fittl.com>  
Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Reviewed-by: Greg Burd <greg@burd.me>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Haibo Yan <tristan.yim@gmail.com>  
Discussion: http://postgr.es/m/CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com  

commit   : e6d6e32f4240bb967460aabdd2db51181cff242f    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 28 Jan 2026 14:38:53 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 28 Jan 2026 14:38:53 +0100    

Commit 90eae926a fixed ON CONFLICT handling during REINDEX CONCURRENTLY  
on partitioned tables by treating unparented indexes as potential  
arbiters.  However, there's a remaining race condition: when pg_inherits  
records are swapped between consecutive calls to get_partition_ancestors(),  
two different child indexes can appear to have the same parent, causing  
duplicate entries in the arbiter list and triggering "invalid arbiter  
index list" errors.  
  
Note that this is not a new problem introduced by 90eae926a.  The same  
error could occur before that commit in a slightly different scenario:  
an index is selected during planning, then index_concurrently_swap()  
commits, and a subsequent call to get_partition_ancestors() uses a new  
catalog snapshot that sees zero ancestors for that index.  
  
Fix by tracking which parent indexes have already been processed.  If a  
subsequent call to get_partition_ancestors() returns a parent we've  
already seen, treat that index as unparented instead, allowing it to be  
matched via IsIndexCompatibleAsArbiter() like other concurrent reindex  
scenarios.  
  
Author: Mihail Nikalayeu <mihailnikalayeu@gmail.com>  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/e5a8c1df-04e5-4343-85ef-5df2a7e3d90c@gmail.com  

commit   : e3094679b9835fed2ea5c7d7877e8ac8e7554d33    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Jan 2026 11:48:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Jan 2026 11:48:45 +0900    

This commit fixes an issue with the restore of ndistinct and  
dependencies statistics, causing the operation to fail when any of these  
kinds included expressions.  
  
In extended statistics, expressions use strictly negative attribute  
numbers, decremented from -1.  For example, let's imagine an object  
defined as follows:  
CREATE STATISTICS stats_obj (dependencies) ON lower(name), upper(name)  
  FROM tab_obj;  
  
This object would generate dependencies stats using -1 and -2 as  
attribute numbers, like that:  
[{"attributes": [-1], "dependency": -2, "degree": 1.000000},  
 {"attributes": [-2], "dependency": -1, "degree": 1.000000}]  
  
However, pg_restore_extended_stats() forgot to account for the number of  
expressions defined in an extended statistics object.  This would cause  
the validation step of ndistinct and dependencies data to fail,  
preventing a restore of their stats even if the input is valid.  
  
This issue has come up due to an incorrect split of the patch set.  Some  
tests are included to cover this behavior.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aXl4bMfSTQUxM_yy@paquier.xyz  

commit   : f9562b95c6e8a66b4cd081f09cc600bf7a364c46    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Jan 2026 08:37:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Jan 2026 08:37:46 +0900    

Commit 302879bd68d115 has added the ability to restore extended stats of  
the type "dependencies", but it has forgotten the addition of a test to  
verify that the value restored was actually set.  
  
This test is the pg_dependencies equivalent of the test added for  
pg_ndistinct in 0e80f3f88dea.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Discussion: https://postgr.es/m/CADkLM=dZr_Ut3jKw94_BisyyDtNZPRJWeOALXVzcJz=ZFTAhvQ@mail.gmail.com  

commit   : c6a10a89feab903b03e2eb664bd6e931b28416a2    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 27 Jan 2026 11:56:44 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 27 Jan 2026 11:56:44 -0800    

The oauth_validator tests missed the lessons of c89525d57 et al, so  
certain combinations of command-line build order and `meson test`  
options can result in  
  
    Command 'oauth_hook_client' not found in [...] at src/test/perl/PostgreSQL/Test/Utils.pm line 427.  
  
Add the missing dependency on the test executable. This fixes, for  
example,  
  
    $ ninja clean && ninja meson-test-prereq && PG_TEST_EXTRA=oauth meson test --no-rebuild  
  
Reported-by: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>  
Author: Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>  
Discussion: https://postgr.es/m/6e8f4f7c23faf77c4b6564c4b7dc5d3de64aa491.camel@gmail.com  
Discussion: https://postgr.es/m/qh4c5tvkgjef7jikjig56rclbcdrrotngnwpycukd2n3k25zi2%4044hxxvtwmgum  
Backpatch-through: 18  

commit   : 9a446d0256dc8f4afb4dba97734b46447c08d918    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 27 Jan 2026 08:31:15 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 27 Jan 2026 08:31:15 -0500    

It's better style to pass the value around to just the places that  
need it. This makes it easier to determine whether the value is  
always properly initialized before use.  
  
Reviewed-by: Amul Sul <sulamul@gmail.com>  
Discussion: http://postgr.es/m/CAAJ_b94+wObPn-z1VECipnSFhjMJ+R2cpTmKVYLjyQuVn+B5QA@mail.gmail.com  

commit   : 851f6649cc18c4b482fa2b6afddb65b35d035370    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Jan 2026 05:06:29 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Jan 2026 05:06:29 +0000    

A race condition could cause a newly synced replication slot to become  
invalidated between its initial sync and the checkpoint.  
  
When syncing a replication slot to a standby, the slot's initial  
restart_lsn is taken from the publisher's remote_restart_lsn. Because slot  
sync happens asynchronously, this value can lag behind the standby's  
current redo pointer. Without any interlocking between WAL reservation and  
checkpoints, a checkpoint may remove WAL required by the newly synced  
slot, causing the slot to be invalidated.  
  
To fix this, we acquire ReplicationSlotAllocationLock before reserving WAL  
for a newly synced slot, similar to commit 006dd4b2e5. This ensures that  
if WAL reservation happens first, the checkpoint process must wait for  
slotsync to update the slot's restart_lsn before it computes the minimum  
required LSN.  
  
However, unlike in ReplicationSlotReserveWal(), this lock alone cannot  
protect a newly synced slot if a checkpoint has already run  
CheckPointReplicationSlots() before slotsync updates the slot. In such  
cases, the remote restart_lsn may be stale and earlier than the current  
redo pointer. To prevent relying on an outdated LSN, we use the oldest  
WAL location available if it is greater than the remote restart_lsn.  
  
This ensures that newly synced slots always start with a safe, non-stale  
restart_lsn and are not invalidated by concurrent checkpoints.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Vitaly Davydov <v.davydov@postgrespro.ru>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Backpatch-through: 17  
Discussion: https://postgr.es/m/TY4PR01MB16907E744589B1AB2EE89A31F94D7A%40TY4PR01MB16907.jpnprd01.prod.outlook.com  

commit   : c32fb29e979db4a7b92adb29007725eeacf91f64    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Jan 2026 13:42:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Jan 2026 13:42:32 +0900    

This commit integrates the new pg_restore_extended_stats() function into  
pg_dump, so as the data of extended statistics is detected and included  
in dumps when the --statistics switch is specified.  Currently, the same  
extended stats kinds as the ones supported by the SQL function can be  
dumped: "n_distinct" and "dependencies".  
  
The extended statistics data can be dumped down to PostgreSQL 10, with  
the following changes depending on the backend version dealt with:  
- In v19 and newer versions, the format of pg_ndistinct and  
pg_dependencies has changed, catalogs can be directly queried.  
- In v18 and older versions, the format is translated to the new format  
supported by the backend.  
- In v14 and older versions, inherited extended statistics are not  
supported.  
- In v11 and older versions, the data for ndistinct and dependencies  
was stored in pg_statistic_ext.  These have been moved to pg_stats_ext  
in v12.  
- Extended Statistics have been introduced in v10, no support is needed  
for versions older than that.  
  
The extended statistics data is dumped if it can be found in the  
catalogs.  If the catalogs are empty, then no restore of the stats data  
is attempted.  
  
Author: Corey Huinker <corey.huinker@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CADkLM=dpz3KFnqP-dgJ-zvRvtjsa8UZv8wDAQdqho=qN3kX0Zg@mail.gmail.com