PostgreSQL 18.2 commit log

commit   : 5a461dc4dbf72a1ec281394a76eb36d68cbdd935    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 16:49:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 16:49:49 -0500    

commit   : 30d2603f5c340133ca03e098fcaa9c242843d5e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 14:01:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 14:01:20 -0500    

Security: CVE-2026-2003, CVE-2026-2004, CVE-2026-2005, CVE-2026-2006, CVE-2026-2007  

commit   : 4543b02af3d3077b8505d533dc51bd51fa47b34a    
  
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   : b69af3dda26104b54d4e728c6946edcc79a8ac61    
  
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   : 66ddac6982c6dc0369dc7b2d251f4d210d704a57    
  
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   : 3b6588cd902faa967f61f539f057f9b7643cf6a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 09:57:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Feb 2026 09:57:44 -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   : b427091947e59788289e80f0ff4279cb7d32dab1    
  
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   : b0f5d25bc3679afaed69d367c72efd387c763d04    
  
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   : 7b5fc85bef8a3baa530ec98f89376f9d4b7de83c    
  
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   : efef05ba995fb2f553c146acb5c33828cc4f898a    
  
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   : df0852fe037246289cc00b4d36da6c1f25ff5844    
  
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   : e0965fb1a8550716db08e2183560be3546851647    
  
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   : 18548681da38b2376d0c071d568b9d0c1f8b6ad2    
  
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   : 209f387b81660e478eea147db9130af1d1c861f2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Feb 2026 08:01:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Feb 2026 08:01:05 +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   : 5944beb7398d76f746c9bb32dbca41bd05419925    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Feb 2026 13:00:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Feb 2026 13:00:40 -0500    

commit   : 731e03272e30ac548d310767a39ab92350da077b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Feb 2026 15:07:02 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Feb 2026 15:07:02 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: bdee668bac7ab3256b6f922c0b6fb663a3b03e16  

commit   : 5eac1d68fc0c51abebafd518f77d1172e191c805    
  
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   : cff2ef9845d6d26c99036c8331b705144186690f    
  
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   : 3c3b34bbee41e8bb1f71e4360d444daa50ea86b1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 7 Feb 2026 10:56:04 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 7 Feb 2026 10:56:04 +1300    

It's not really an ABI break if you change the layout/size of an object  
with incomplete type, as commit f94e9141 did, so advance the ABI  
compliance reference commit in 16-18 to satisfy build farm animal crake.  
  
Backpatch-through: 16-18  
Discussion: https://www.postgresql.org/message-id/1871492.1770409863%40sss.pgh.pa.us  

commit   : c6881f792281d1abeba9acf3fe7972da091f2bbd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Feb 2026 13:06:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Feb 2026 13:06:16 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : e679d0f0b6729d0e97510dd4ab6a793700d6d66a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 19:57:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 19:57:26 +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   : acfa422c3c1f3a6001a109699cae06236efd1aa4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 15:38:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Feb 2026 15:38:21 +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   : 33e3de6d77e87d6c3c6f8f878dd8de42d37c3b8f    
  
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   : 441de639ee2360016be388350abff3afcea76b7a    
  
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   : 8eb17e82fc1d12b2e897b0c053c7c5c003940833    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Feb 2026 00:46:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Feb 2026 00:46:09 +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   : b5e1cd2fdca1ad48982e376c0d22f468e862933c    
  
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   : 2ca4464b6992508a6be201ff8f10847e64e2291d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Feb 2026 16:38:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Feb 2026 16:38:10 +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   : a0f98b27557257f3c50574d381af19897f2de376    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 3 Feb 2026 15:33:08 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 3 Feb 2026 15:33:08 +0100    

Commit 492a69e14070 anticipated this change:  
  
  [C] 'function bool AdjustNotNullInheritance(Oid, AttrNumber, bool, bool, bool)' has some sub-type changes:  
    parameter 6 of type 'bool' was added  
    parameter 3 of type 'bool' changed:  
      entity changed from 'bool' to 'const char*'  
      type size changed from 1 to 8 (in bytes)  
  
Discussion: https://postgr.es/m/19351-8f1c523ead498545%40postgresql.org  
Backpatch-through: 18 only  

commit   : 492a69e1407029f8c673484f44aa719a63323d77    
  
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   : 719aa13b58576dd4428bd3a31496aac8572d8640    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Feb 2026 11:25:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Feb 2026 11:25:14 +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   : ab61f00874e5e27ec04a787505f45d797421b475    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 10:21:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 10:21:07 +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   : d5a4856ffe1815774ba4dc46a6fa453e856f72a3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 08:02:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Feb 2026 08:02:59 +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   : 92b3cc5a28f1557f9f6c59dc6a30868381692ec1    
  
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   : fff87cb50dbd702240c7662feacada4d4eca827b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 30 Jan 2026 08:48:25 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 30 Jan 2026 08:48:25 +0000    

As noted in the commit message for b4307ae2e54, the change to the  
TransitionCaptureState structure is nominally an ABI break, but it is  
not expected to affect any third-party code. Therefore, add it to the  
.abi-compliance-history file.  
  
Discussion: https://postgr.es/m/19380-4e293be2b4007248%40postgresql.org  
Backpatch-through: 15-18  

commit   : 09d8c351744d3fdc7e1f72ab3a3b08b25e0c36f1    
  
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   : d42735b1e8c8c6454a07b709e4ff7ccae4ad58c6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 16:20:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jan 2026 16:20:50 +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   : 1c60f7236368ececfd9dc949251c28cebadfbe77    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 29 Jan 2026 03:05:12 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 29 Jan 2026 03:05:12 +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   : 444826b6dc17c9102d3114e670adb8a4119ab2a2    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 27 Jan 2026 11:58:26 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Tue, 27 Jan 2026 11:58:26 -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   : 8993bf0991d876c878fe3739d6d4e200a1e122f3    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 27 Jan 2026 08:16:07 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 27 Jan 2026 08:16:07 -0800    

Commit 7f007e4a04 in master depends on 1476028225, but the latter was  
not backported. Therefore 806555e300 (the backport of commit  
7f007e4a04) incorrectly used pg_strfold() in a locale where  
ctype_is_c.  
  
The fix is to simply have the callers check for ctype_is_c.  
  
Because 7f007e4a04 was only backported to version 18, and because the  
commit in master is fine, this fix only exists in version 18.  
  
Reported-by: Александр Кожемякин <a.kozhemyakin@postgrespro.ru>  
Discussion: https://postgr.es/m/456f7143-51ea-4342-b4a1-85f0d9b6c79f@postgrespro.ru  

commit   : 919c9fa13cd0684b437a88719d670a9bf6dd0dc8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Jan 2026 05:45:25 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 27 Jan 2026 05:45:25 +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   : 3a8b6e56cdbca12723a58f4ea13e39ac0611a59b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 27 Jan 2026 00:26:36 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 27 Jan 2026 00:26:36 +0100    

Backpatch-through: 18  

commit   : 9796c4f5607be5807f2d2ba9bca1bc87af198db3    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jan 2026 22:20:18 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jan 2026 22:20:18 +0100    

We've assumed that touching the memory is sufficient for a page to be  
located on one of the NUMA nodes. But a page may be moved to a swap  
after we touch it, due to memory pressure.  
  
We touch the memory before querying the status, but there is no  
guarantee it won't be moved to the swap in the meantime. The touching  
happens only on the first call, so later calls are more likely to be  
affected. And the batching increases the window too.  
  
It's up to the kernel if/when pages get moved to swap. We have to accept  
ENOENT (-2) as a valid result, and handle it without failing. This patch  
simply treats it as an unknown node, and returns NULL in the two  
affected views (pg_shmem_allocations_numa and pg_buffercache_numa).  
  
Hugepages cannot be swapped out, so this affects only regular pages.  
  
Reported by Christoph Berg, investigation and fix by me. Backpatch to  
18, where the two views were introduced.  
  
Reported-by: Christoph Berg <myon@debian.org>  
Discussion: 18  
Backpatch-through: https://postgr.es/m/aTq5Gt_n-oS_QSpL@msg.df7cb.de  

commit   : 32593394ee439703db558fc4be83de2cb249ded8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jan 2026 18:54:12 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jan 2026 18:54:12 +0100    

Modify two places creating GIN indexes in regression tests, so that the  
build is parallel. This provides a basic test coverage, even if the  
amounts of data are fairly small.  
  
Reported-by: Kirill Reshke <reshkekirill@gmail.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CALdSSPjUprTj+vYp1tRKWkcLYzdy=N=O4Cn4y_HoxNSqQwBttg@mail.gmail.com  

commit   : eee71a66cc860771837ed645a8dcf0ccffd735c6    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jan 2026 18:52:16 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jan 2026 18:52:16 +0100    

When building a tuplesort during parallel GIN builds, the function  
incorrectly looked up the default B-Tree operator, not the function  
associated with the GIN opclass (through GIN_COMPARE_PROC).  
  
Fixed by using the same logic as initGinState(), and the other place  
in parallel GIN builds.  
  
This could cause two types of issues. First, a data type might not have  
a B-Tree opclass, in which case the PrepareSortSupportFromOrderingOp()  
fails with an ERROR. Second, a data type might have both B-Tree and GIN  
opclasses, defining order/equality in different ways. This could lead to  
logical corruption in the index.  
  
Backpatch to 18, where parallel GIN builds were introduced.  
  
Discussion: https://postgr.es/m/73a28b94-43d5-4f77-b26e-0d642f6de777@iki.fi  
Reported-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Backpatch-through: 18  

commit   : 7903377d9de2f056fd66adc1892cc0771bd2d131    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 26 Jan 2026 12:43:52 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 26 Jan 2026 12:43:52 -0500    

Buildfarm member fairywren hit the Windows limitation on the length of a  
file path. While there may be other things we should also do to prevent  
this from happening, it's certainly the case that the length of this  
test file name is much longer than others in the same directory, so make  
it shorter.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: http://postgr.es/m/274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com  
Backpatch-through: 17  

commit   : ccde5be6869c13ad88259d300c684900d7c1eb8c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 26 Jan 2026 23:46:23 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 26 Jan 2026 23:46:23 +1300    

ed1a88dda made it so WindowClauses can be merged when all window  
functions belonging to the WindowClause can equally well use some  
other WindowClause without any behavioral changes.  When that  
optimization applies, the WindowFunc's "winref" gets adjusted to  
reference the new WindowClause.  
  
That commit does not work well with the deduplication logic in  
find_window_functions(), which only added the WindowFunc to the list  
when there wasn't already an identical WindowFunc in the list.  That  
deduplication logic meant that the duplicate WindowFunc wouldn't get the  
"winref" changed when optimize_window_clauses() was able to swap the  
WindowFunc to another WindowClause.  This could lead to the following  
error in the unlikely event that the deduplication code did something and  
the duplicate WindowFunc happened to be moved into another WindowClause.  
  
ERROR:  WindowFunc with winref 2 assigned to WindowAgg with winref 1  
  
As it turns out, the deduplication logic in find_window_functions() is  
pretty bogus.  It might have done something when added, as that code  
predates b8d7f053c, which changed how projections work.  As it turns  
out, at least now we *will* evaluate the duplicate WindowFuncs.  All  
that the deduplication code seems to do today is assist in  
underestimating the WindowAggPath costs due to not counting the  
evaluation costs of duplicate WindowFuncs.  
  
Ideally the fix would be to remove the deduplication code, but that  
could result in changes to the plan costs, as duplicate WindowFuncs  
would then be costed.  Instead, let's play it safe and shift the  
deduplication code so it runs after the other processing in  
optimize_window_clauses().  
  
Backpatch only as far as v16 as there doesn't seem to be any other harm  
done by the WindowFunc deduplication code before then.  This issue was  
fixed in master by 7027dd499.  
  
Reported-by: Meng Zhang <mza117jc@gmail.com>  
Author: Meng Zhang <mza117jc@gmail.com>  
Author: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAErYLFAuxmW0UVdgrz7iiuNrxGQnFK_OP9hBD5CUzRgjrVrz=Q@mail.gmail.com  
Backpatch-through: 16  

commit   : c6ce4dcf9d3b7a8a89aca386124c473f98fc329e    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 24 Jan 2026 11:30:48 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 24 Jan 2026 11:30:48 +0000    

When executing a data-modifying CTE query containing MERGE and some  
other DML operation on a table with statement-level AFTER triggers,  
the transition tables passed to the triggers would fail to include the  
rows affected by the MERGE.  
  
The reason is that, when initializing a ModifyTable node for MERGE,  
MakeTransitionCaptureState() would create a TransitionCaptureState  
structure with a single "tcs_private" field pointing to an  
AfterTriggersTableData structure with cmdType == CMD_MERGE. Tuples  
captured there would then not be included in the sets of tuples  
captured when executing INSERT/UPDATE/DELETE ModifyTable nodes in the  
same query.  
  
Since there are no MERGE triggers, we should only create  
AfterTriggersTableData structures for INSERT/UPDATE/DELETE. Individual  
MERGE actions should then use those, thereby sharing the same capture  
tuplestores as any other DML commands executed in the same query.  
  
This requires changing the TransitionCaptureState structure, replacing  
"tcs_private" with 3 separate pointers to AfterTriggersTableData  
structures, one for each of INSERT, UPDATE, and DELETE. Nominally,  
this is an ABI break to a public structure in commands/trigger.h.  
However, since this is a private field pointing to an opaque data  
structure, the only way to create a valid TransitionCaptureState is by  
calling MakeTransitionCaptureState(), and no extensions appear to be  
doing that anyway, so it seems safe for back-patching.  
  
Backpatch to v15, where MERGE was introduced.  
  
Bug: #19380  
Reported-by: Daniel Woelfel <dwwoelfel@gmail.com>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19380-4e293be2b4007248%40postgresql.org  
Backpatch-through: 15  

commit   : 9f4b7bfc5eb6b3068f35ef5b879d3d8725f5f167    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 23 Jan 2026 10:20:51 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 23 Jan 2026 10:20:51 +0900    

ExecInitModifyTable() unconditionally required a ctid junk column even  
when the target was a partitioned table. This led to spurious "could  
not find junk ctid column" errors when all children were excluded and  
only the dummy root result relation remained.  
  
A partitioned table only appears in the result relations list when all  
leaf partitions have been pruned, leaving the dummy root as the sole  
entry. Assert this invariant (nrels == 1) and skip the ctid requirement.  
Also adjust ExecModifyTable() to tolerate invalid ri_RowIdAttNo for  
partitioned tables, which is safe since no rows will be processed in  
this case.  
  
Bug: #19099  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19099-e05dcfa022fe553d%40postgresql.org  
Backpatch-through: 14  

commit   : 9f7c803c91584fb6e4b45dc87de44bac370477a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Jan 2026 18:35:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Jan 2026 18:35:31 -0500    

Commit f16241bef mistakenly supposed that INSERT...ON CONFLICT DO  
UPDATE rejects partitioned target tables.  (This may have been  
accurate when the patch was written, but it was already obsolete  
when committed.)  Hence, there's an assertion that we can't see  
ItemPointerIndicatesMovedPartitions() in that path, but the assertion  
is triggerable.  
  
Some other places throw error if they see a moved-across-partitions  
tuple, but there seems no need for that here, because if we just retry  
then we get the same behavior as in the update-within-partition case,  
as demonstrated by the new isolation test.  So fix by deleting the  
faulty Assert.  (The fact that this is the fix doubtless explains  
why we've heard no field complaints: the behavior of a non-assert  
build is fine.)  
  
The TM_Deleted case contains a cargo-culted copy of the same Assert,  
which I also deleted to avoid confusion, although I believe that one  
is actually not triggerable.  
  
Per our code coverage report, neither the TM_Updated nor the  
TM_Deleted case were reached at all by existing tests, so this  
patch adds tests for both.  
  
Reported-by: Dmitry Koval <d.koval@postgrespro.ru>  
Author: Joseph Koshakow <koshy44@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/f5fffe4b-11b2-4557-a864-3587ff9b4c36@postgrespro.ru  
Backpatch-through: 14  

commit   : a3bbd60b94cfbc2fa91f0cc5b94c2105b176b303    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Jan 2026 16:35:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Jan 2026 16:35:40 +0900    

All the other SQL functions reconstructing definitions or commands are  
listed in the documentation, except this one.  
  
Oversight in 1848b73d4576.  
  
Author: Todd Liebenschutz-Jones <todd.liebenschutz-jones@starlingbank.com>  
Discussion: https://postgr.es/m/CAGTRfaD6uRQ9iutASDzc_iDoS25sQTLWgXTtR3ta63uwTxq6bA@mail.gmail.com  
Backpatch-through: 14  

commit   : f1c6b153cabdc9ea33c3396f13e1cee92836df75    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jan 2026 15:43:13 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jan 2026 15:43:13 +1300    

With LLVM >= 17, transform passes are provided as a string to  
LLVMRunPasses. Only two strings were used: "default<O3>" and  
"default<O0>,mem2reg".  
  
With previous LLVM versions, an additional inline pass was added when  
JIT inlining was enabled without optimization. With LLVM >= 17, the code  
would go through llvm_inline, prepare the functions for inlining, but  
the generated bitcode would be the same due to the missing inline pass.  
  
This patch restores the previous behavior by adding an inline pass when  
inlining is enabled but no optimization is done.  
  
This fixes an oversight introduced by 76200e5e when support for LLVM 17  
was added.  
  
Backpatch-through: 14  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Pierre Ducroquet <p.psql@pinaraf.info>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://postgr.es/m/CAO6_XqrNjJnbn15ctPv7o4yEAT9fWa-dK15RSyun6QNw9YDtKg%40mail.gmail.com  

commit   : 3c83a2a0ace90a83249a51925706395c76a85bdf    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 21 Jan 2026 18:55:43 +0100    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 21 Jan 2026 18:55:43 +0100    

We were using SnapshotAny to do some index checks, but that's wrong and  
causes spurious errors when used on indexes created by CREATE INDEX  
CONCURRENTLY.  Fix it to use an MVCC snapshot, and add a test for it.  
  
Backpatch of 6bd469d26aca to branches 14-16.  I previously misidentified  
the bug's origin: it came in with commit 7f563c09f890 (pg11-era, not  
5ae2087202af as claimed previously), so all live branches are affected.  
  
Also take the opportunity to fix some comments that we failed to update  
in the original commits and apply pgperltidy.  In branch 14, remove the  
unnecessary test plan specification (which would have need to have been  
changed anyway; c.f. commit 549ec201d613.)  
  
Diagnosed-by: Donghang Lin <donghanglin@gmail.com>  
Author: Mihail Nikalayeu <mihailnikalayeu@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Backpatch-through: 17  
Discussion: https://postgr.es/m/CANtu0ojmVd27fEhfpST7RG2KZvwkX=dMyKUqg0KM87FkOSdz8Q@mail.gmail.com  

commit   : 85aedc67e9674b7fdbf7627bbb54ed5b741880c5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 Jan 2026 22:59:10 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 Jan 2026 22:59:10 -0500    

This reverts d8aa21b74ff, which was added for the PG 18 release notes,  
and adjusts the PG 18 release notes for this change.  This is necessary  
since the "xreflabel" affected other references to these chapters.  
  
Reported-by: Robert Treat  
  
Author: Robert Treat  
  
Discussion: https://postgr.es/m/CABV9wwNEZDdp5QtrW5ut0H+MOf6U1PvrqBqmgSTgcixqk+Q73A@mail.gmail.com  
  
Backpatch-through: 18  

commit   : 3304e97b1b73e0ca7b14bbd8ed17162b3cb056ec    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jan 2026 08:11:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jan 2026 08:11:16 +0900    

When IN/ANY clauses contain both constants and variable expressions, the  
optimizer transforms them into separate structures: constants become  
an array expression while variables become individual OR conditions.  
  
This transformation was creating an overlap with the token locations,  
causing pg_stat_statements query normalization to crash because it  
could not calculate the amount of bytes remaining to write for the  
normalized query.  
  
This commit disables squashing for mixed IN list expressions when  
constructing a scalar array op, by setting list_start and list_end  
to -1 when both variables and non-variables are present.  Some  
regression tests are added to PGSS to verify these patterns.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0ts9qiONnHjjHxPxtePs22GBo4d3jZ_s2BQC59AN7XbAA@mail.gmail.com  
Backpatch-through: 18  

commit   : c80b0c9d63b25a1e7fc751a4cf66a6510ffafbb8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 19 Jan 2026 12:02:08 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 19 Jan 2026 12:02:08 -0500    

When faced with a relation containing more than 1 physical segment  
(i.e. >1GB, with normal settings), the previous code could compute a  
truncation block length greater than RELSEG_SIZE, which could lead to  
restore failures of this form:  
  
file "%s" has truncation block length %u in excess of segment size %u  
  
The fix is simply to clamp the maximum computed truncation_block_length  
to RELSEG_SiZE. I have also added some comments to clarify the logic.  
  
The test case was written by Oleg Tkachenko, but I have rewritten its  
comments.  
  
Reported-by: Oleg Tkachenko <oatkachenko@gmail.com>  
Diagnosed-by: Oleg Tkachenko <oatkachenko@gmail.com>  
Co-authored-by: Robert Haas <rhaas@postgresql.org>  
Co-authored-by: Oleg Tkachenko <oatkachenko@gmail.com>  
Reviewed-by: Amul Sul <sulamul@gmail.com>  
Backpatch-through: 17  
Discussion: http://postgr.es/m/00FEFC88-EA1D-4271-B38F-EB741733A84A@gmail.com  

commit   : 7650eabb662f2f3708042c0b713c46aa042db94f    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 19 Jan 2026 11:13:23 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 19 Jan 2026 11:13:23 +0900    

When checking a subquery's output expressions to see if it's safe to  
push down an upper-level qual, check_output_expressions() previously  
treated grouping Vars as opaque Vars.  This implicitly assumed they  
were stable and scalar.  
  
However, a grouping Var's underlying expression corresponds to the  
grouping clause, which may be volatile or set-returning.  If an  
upper-level qual references such an output column, pushing it down  
into the subquery is unsafe.  This can cause strange results due to  
multiple evaluation of a volatile function, or introduce SRFs into  
the subquery's WHERE/HAVING quals.  
  
This patch teaches check_output_expressions() to look through grouping  
Vars to their underlying expressions.  This ensures that any  
volatility or set-returning properties in the grouping clause are  
detected, preventing the unsafe pushdown.  
  
We do not need to recursively examine the Vars contained in these  
underlying expressions.  Even if they reference outputs from  
lower-level subqueries (at any depth), those references are guaranteed  
not to expand to volatile or set-returning functions, because  
subqueries containing such functions in their targetlists are never  
pulled up.  
  
Backpatch to v18, where this issue was introduced.  
  
Reported-by: Eric Ridge <eebbrr@gmail.com>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/7900964C-F99E-481E-BEE5-4338774CEB9F@gmail.com  
Backpatch-through: 18  

commit   : 6574bee6459e73c42816ac7ec16e6b6b6197000c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Jan 2026 14:54:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Jan 2026 14:54:33 -0500    

This is pretty pro-forma for our purposes, as the only change  
is a historical correction for pre-1976 DST laws in  
Baja California.  (Upstream made this release mostly to update  
their leap-second data, which we don't use.)  But with minor  
releases coming up, we should be up-to-date.  
  
Backpatch-through: 14  

commit   : 69ee81932a161768833264e6db5523a8412952f2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 18 Jan 2026 17:24:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 18 Jan 2026 17:24:58 +0900    

The code adding the WAL information included in a backup manifest is  
cross-checked with the contents of the timeline history file of the end  
timeline.  A check based on the end timeline, when it fails, reported  
the value of the start timeline in the error message.  This error is  
fixed to show the correct timeline number in the report.  
  
This error report would be confusing for users if seen, because it would  
provide an incorrect information, so backpatch all the way down.  
  
Oversight in 0d8c9c1210c4.  
  
Author: Man Zeng <zengman@halodbtech.com>  
Discussion: https://postgr.es/m/tencent_0F2949C4594556F672CF4658@qq.com  
Backpatch-through: 14  

commit   : 9b6714ed9a1ab18af9cbfff8dd0f52cf99a1557e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 Jan 2026 14:42:22 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 Jan 2026 14:42:22 +0200    

The function is part of the injection_points test module and only used  
in tests. None of the current tests call it with a NULL argument, but  
it is supposed to work.  
  
Backpatch-through: 17  

commit   : f335457e8adb32ce2e506e0d2b62c7f6f4bb98d1    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 16 Jan 2026 14:53:32 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 16 Jan 2026 14:53:32 +0900    

Commit cbc127917e introduced tracking of unpruned relids to skip  
processing of pruned partitions. PlannedStmt.unprunableRelids is  
computed as the difference between PlannerGlobal.allRelids and  
prunableRelids, but allRelids only contains RTE_RELATION entries.  
This means non-relation RTEs (VALUES, subqueries, CTEs, etc.) are  
never included in unprunableRelids, and consequently not in  
es_unpruned_relids at runtime.  
  
As a result, rowmarks attached to non-relation RTEs were incorrectly  
skipped during executor initialization. This affects any DML statement  
that has rowmarks on such RTEs, including MERGE with a VALUES or  
subquery source, and UPDATE/DELETE with joins against subqueries or  
CTEs. When a concurrent update triggers an EPQ recheck, the missing  
rowmark leads to incorrect results.  
  
Fix by restricting the es_unpruned_relids membership check to  
RTE_RELATION entries only, since partition pruning only applies to  
actual relations. Rowmarks for other RTE kinds are now always  
processed.  
  
Bug: #19355  
Reported-by: Bihua Wang <wangbihua.cn@gmail.com>  
Diagnosed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Diagnosed-by: Tender Wang <tndrwang@gmail.com>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/19355-57d7d52ea4980dc6@postgresql.org  
Backpatch-through: 18  

commit   : 1943ceb38842ada55f13630f989c78184e82a397    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 16 Jan 2026 13:01:52 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 16 Jan 2026 13:01:52 +0900    

If a FATAL error occurs while holding a lock in a DSM segment (such  
as a dshash lock) and the process is not in a transaction, a  
segmentation fault can occur during process exit.  
  
The problem sequence is:  
  
 1. Process acquires a lock in a DSM segment (e.g., via dshash)  
 2. FATAL error occurs outside transaction context  
 3. proc_exit() begins, calling before_shmem_exit callbacks  
 4. dsm_backend_shutdown() detaches all DSM segments  
 5. Later, on_shmem_exit callbacks run  
 6. ProcKill() calls LWLockReleaseAll()  
 7. Segfault: the lock being released is in unmapped memory  
  
This only manifests outside transaction contexts because  
AbortTransaction() calls LWLockReleaseAll() during transaction  
abort, releasing locks before DSM cleanup. Background workers and  
other non-transactional code paths are vulnerable.  
  
Fix by calling LWLockReleaseAll() unconditionally at the start of  
shmem_exit(), before any callbacks run. Releasing locks before  
callbacks prevents the segfault - locks must be released before  
dsm_backend_shutdown() detaches their memory. This is safe because  
after an error, held locks are protecting potentially inconsistent  
data anyway, and callbacks can acquire fresh locks if needed.  
  
Also add a comment noting that LWLockReleaseAll() must be safe to  
call before LWLock initialization (which it is, since  
num_held_lwlocks will be 0), plus an Assert for the post-condition.  
  
This fix aligns with the original design intent from commit  
001a573a2, which noted that backends must clean up shared memory  
state (including releasing lwlocks) before unmapping dynamic shared  
memory segments.  
  
Reported-by: Rahila Syed <rahilasyed90@gmail.com>  
Author: Rahila Syed <rahilasyed90@gmail.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAH2L28uSvyiosL+kaic9249jRVoQiQF6JOnaCitKFq=xiFzX3g@mail.gmail.com  
Backpatch-through: 14  

commit   : a80811e592a3f6851e113fbdf5fe21e677391bb9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Jan 2026 14:54:16 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Jan 2026 14:54:16 -0500    

Per buildfarm member koel.  
  
Backpatch-through: 18  

commit   : 9ed411e084b7e25885d761a15e3a54818cf856a9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Jan 2026 20:57:12 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Jan 2026 20:57:12 +0200    

On restart, a replica can fail with an error like 'unexpected data  
beyond EOF in block 200 of relation T/D/R'. These are the steps to  
reproduce it:  
  
- A relation has a size of 400 blocks.  
  - Blocks 201 to 400 are empty.  
  - Block 200 has two rows.  
  - Blocks 100 to 199 are empty.  
- A restartpoint is done  
- Vacuum truncates the relation to 200 blocks  
- A FPW deletes a row in block 200  
- A checkpoint is done  
- A FPW deletes the last row in block 200  
- Vacuum truncates the relation to 100 blocks  
- The replica restarts  
  
When the replica restarts:  
  
- The relation on disk starts at 100 blocks, because all the  
  truncations were applied before restart.  
- The first truncate to 200 blocks is replayed. It silently fails, but  
  it will still (incorrectly!) update the cache size to 200 blocks  
- The first FPW on block 200 is applied. XLogReadBufferForRead relies  
  on the cached size and incorrectly assumes that the page already  
  exists in the file, and thus won't extend the relation.  
- The online checkpoint record is replayed, calling smgrdestroyall  
  which causes the cached size to be discarded  
- The second FPW on block 200 is applied. This time, the detected size  
  is 100 blocks, an extend is attempted. However, the block 200 is  
  already present in the buffer cache due to the first FPW. This  
  triggers the 'unexpected data beyond EOF'.  
  
To fix, update the cached size in SmgrRelation with the current size  
rather than the requested new size, when the requested new size is  
greater.  
  
Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>  
Discussion: https://www.postgresql.org/message-id/CAO6_Xqrv-snNJNhbj1KjQmWiWHX3nYGDgAc=vxaZP3qc4g1Siw@mail.gmail.com  
Backpatch-through: 14  

commit   : 7f1b3a4cea563d791d8a83e5c482f1ed8306ee6a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Jan 2026 10:17:51 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 15 Jan 2026 10:17:51 -0500    

We called io_uring_cqe_seen(..., cqe) before reading cqe->res. That allows the  
completion to be reused, which in turn could lead to cqe->res being  
overwritten. The window for that is very narrow and the likelihood of it  
happening is very low, as we should never actually utilize all CQEs, but the  
consequences would be bad.  
  
This bug was reported to me privately.  
  
Backpatch-through: 18  
Discussion: https://postgr.es/m/bwo3e5lj2dgi2wzq4yvbyzu7nmwueczvvzioqsqo6azu6lm5oy@pbx75g2ach3p  

commit   : 09532a78b8c6b49b5176bc1cd4671c571520a8c8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Jan 2026 16:48:45 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Jan 2026 16:48:45 +0200    

If a multixid with zero offset is left behind after a crash, and that  
multixid later becomes the oldest multixid, truncation might try to  
look up its offset and read the zero value. In the worst case, we  
might incorrectly use the zero offset to truncate valid SLRU segments  
that are still needed. I'm not sure if that can happen in practice, or  
if there are some other lower-level safeguards or incidental reasons  
that prevent the caller from passing an unwritten multixid as the  
oldest multi. But better safe than sorry, so let's add an explicit  
check for it.  
  
In stable branches, we should perhaps do the same check for  
'oldestOffset', i.e. the offset of the old oldest multixid (in master,  
'oldestOffset' is gone). But if the old oldest multixid has an invalid  
offset, the damage has been done already, and we would never advance  
past that point. It's not clear what we should do in that case. The  
check that this commit adds will prevent such an multixid with invalid  
offset from becoming the oldest multixid in the first place, which  
seems enough for now.  
  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: Discussion: https://www.postgresql.org/message-id/000301b2-5b81-4938-bdac-90f6eb660843@iki.fi  
Backpatch-through: 14  

commit   : 64893323925322d2236aaac111343768cf7dafa0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jan 2026 16:02:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jan 2026 16:02:33 +0900    

The test 002_save_fullpage.pl, checking --save-fullpage fails with  
wal_consistency_checking enabled, due to the fact that the block saved  
in the file has the same LSN as the LSN used in the file name.  The test  
required that the block LSN is stritly lower than file LSN.  This commit  
relaxes the check a bit, by allowing the LSNs to match.  
  
While on it, the test name is reworded to include some information about  
the file and block LSNs, which is useful for debugging.  
  
Author: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/4226AED7-E38F-419B-AAED-9BC853FB55DE@yandex-team.ru  
Backpatch-through: 16  

commit   : 9c3caad0264011490134816b2264de7f20b2eb99    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jan 2026 08:44:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jan 2026 08:44:52 +0900    

RangeTblEntry.groupexprs was marked with the node attribute  
query_jumble_ignore, causing a list of GROUP BY expressions to be  
ignored during the query jumbling.  For example, these two queries could  
be grouped together within the same query ID:  
SELECT count(*) FROM t GROUP BY a;  
SELECT count(*) FROM t GROUP BY b;  
  
However, as such queries use different GROUP BY clauses, they should be  
split across multiple entries.  
  
This fixes an oversight in 247dea89f761, that has introduced an RTE for  
GROUP BY clauses.  Query IDs are documented as being stable across minor  
releases, but as this is a regression new to v18 and that we are still  
early in its support cycle, a backpatch is exceptionally done as this  
has broken a behavior that exists since query jumbling is supported in  
core, since its introduction in pg_stat_statements.  
  
The tests of pg_stat_statements are expanded to cover this area, with  
patterns involving GROUP BY and GROUPING clauses.  
  
Author: Jian He <jian.universality@gmail.com>  
Discussion: https://postgr.es/m/CACJufxEy2W+tCqC7XuJ94r3ivWsM=onKJp94kRFx3hoARjBeFQ@mail.gmail.com  
Backpatch-through: 18  

commit   : 6920fc34531449a5e19f8e81f884f9f1de032b42    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 13 Jan 2026 22:54:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 13 Jan 2026 22:54:45 +0900    

Commit 9f8377f7a introduced the DEFAULT option for file_fdw but did not  
update the documentation. This commit adds the missing description of  
the DEFAULT option to the file_fdw documentation.  
  
Backpatch to v16, where the DEFAULT option was introduced.  
  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAOzEurT_PE7QEh5xAdb7Cja84Rur5qPv2Fzt3Tuqi=NU0WJsbg@mail.gmail.com  
Backpatch-through: 16  

commit   : 56e1f501010fc79fd1d11df6fd04eec463d40319    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 11 Jan 2026 13:52:50 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Sun, 11 Jan 2026 13:52:50 -0600    

Oversight in commit 7a485bd641.  Per Coverity.  
  
Backpatch-through: 18  

commit   : d2c6ff7c525bc6d67109021ad28faeb795fa2878    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 9 Jan 2026 10:02:56 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 9 Jan 2026 10:02:56 -0800    

Reword publish_via_partition_root's opening paragraph. Describe its  
behavior more clearly, and directly state that its default is false.  
  
Per complaint by Peter Smith; final text of the patch made in  
collaboration with Chao Li.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Author: Peter Smith <peter.b.smith@fujitsu.com>  
Reported-by: Peter Smith <peter.b.smith@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CAHut%2BPu7SpK%2BctOYoqYR3V4w5LKc9sCs6c_qotk9uTQJQ4zp6g%40mail.gmail.com  
Backpatch-through: 14  

commit   : 39d55557661f6d2fc0b5781b3f40390ca4febdad    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 9 Jan 2026 10:12:54 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 9 Jan 2026 10:12:54 -0600    

Since commit bd15b7db48, pg_dump uses pg_get_sequence_data() (née  
pg_sequence_read_tuple()) to gather all sequence data in a single  
query as opposed to a query per sequence.  Two related bugs have  
been identified:  
  
* If the user lacks appropriate privileges on the sequence, pg_dump  
generates a setval() command with garbage values instead of  
failing as expected.  
  
* pg_dump can fail due to a concurrently dropped sequence, even if  
the dropped sequence's data isn't part of the dump.  
  
This commit fixes the above issues by 1) teaching  
pg_get_sequence_data() to return nulls instead of erroring for a  
missing sequence and 2) teaching pg_dump to fail if it tries to  
dump the data of a sequence for which pg_get_sequence_data()  
returned nulls.  Note that pg_dump may still fail due to a  
concurrently dropped sequence, but it should now only do so when  
the sequence data is part of the dump.  This matches the behavior  
before commit bd15b7db48.  
  
Bug: #19365  
Reported-by: Paveł Tyślacki <pavel.tyslacki@gmail.com>  
Suggested-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19365-6245240d8b926327%40postgresql.org  
Discussion: https://postgr.es/m/2885944.1767029161%40sss.pgh.pa.us  
Backpatch-through: 18  

commit   : c35e5dd9ae972393338b81a2427ab4e587f18534    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jan 2026 11:02:59 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jan 2026 11:02:59 +1300    

When creating a partition for a RANGE partitioned table, the reporting  
of errors relating to converting the specified range values into  
constant values for the partition key's type could display the name of a  
previous partition key column when an earlier range was specified as  
MINVALUE or MAXVALUE.  
  
This was caused by the code not correctly incrementing the index that  
tracks which partition key the foreach loop was working on after  
processing MINVALUE/MAXVALUE ranges.  
  
Fix by using foreach_current_index() to ensure the index variable is  
always set to the List element being worked on.  
  
Author: myzhen <zhenmingyang@yeah.net>  
Reviewed-by: zhibin wang <killerwzb@gmail.com>  
Discussion: https://postgr.es/m/273cab52.978.19b96fc75e7.Coremail.zhenmingyang@yeah.net  
Backpatch-through: 14  

commit   : 6c99c715ddb338e169c2ffd2a4cf754fa510cccb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Jan 2026 12:53:05 -0500    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 7 Jan 2026 12:53:05 -0500    

Fix comments that incorrectly described transformations performed by the  
"Avoid extra index searches through preprocessing" mechanism introduced  
by commit b3f1a13f.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-By: Chao Li <li.evan.chao@gmail.com>  
Reviewed-By: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/20251230190145.c3c88c5eb0f88b136adda92f@sraoss.co.jp  
Backpatch-through: 18  

commit   : f9125ca3db513f94907ef21ecc2665643bc7e5cf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Jan 2026 15:47:02 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 7 Jan 2026 15:47:02 +0100    

Reported-by: Xueyu Gao <gaoxueyu_hope@163.com>  
Discussion: https://www.postgresql.org/message-id/42b5c99a.856d.19b73d858e2.Coremail.gaoxueyu_hope%40163.com  

commit   : 77ade60a0a3a55ce5e591cd02616fe08a0acc806    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 7 Jan 2026 16:02:19 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 7 Jan 2026 16:02:19 +0700    

Commit c7eab0e97 changed the default password_encryption setting to  
'scram-sha-256', so update the example for creating a user with an  
assigned password.  
  
In addition, commit 08951a7c9 added new options that in turn pass  
default tokens NOBYPASSRLS and NOREPLICATION to the CREATE ROLE  
command, so fix this omission as well for v16 and later.  
  
Reported-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://postgr.es/m/cff1ea60-c67d-4320-9e33-094637c2c4fb%40iki.fi  
Backpatch-through: 14  

commit   : cdcab17e7e5deb3fa843214ca1215023735b45cb    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 7 Jan 2026 11:55:01 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 7 Jan 2026 11:55:01 +0700    

Followup to 44f49511b.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>  
Discussion: https://postgr.es/m/CAHGQGwH_UfN96vcvLGA%3DYro%2Bo6qCn0nEgEGoviwzEiLTHtt2Pw%40mail.gmail.com  
Backpatch-through: 18  

commit   : bdc5dedfcaa57ddeef115252283019d79083d8a2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 6 Jan 2026 19:51:19 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 6 Jan 2026 19:51:19 -0500    

In a7f107df2 I changed subplan param evaluation to happen within the  
containing expression. As part of that, ExecInitSubPlanExpr() was changed to  
evaluate parameters via a new EEOP_PARAM_SET expression step. These parameters  
were temporarily stored into ExprState->resvalue/resnull, with some reasoning  
why that would be fine. Unfortunately, that analysis was wrong -  
ExecInitSubscriptionRef() evaluates the input array into "resv"/"resnull",  
which will often point to ExprState->resvalue/resnull. This means that the  
EEOP_PARAM_SET, if inside an array subscript, would overwrite the input array  
to array subscript.  
  
The fix is fairly simple - instead of evaluating into  
ExprState->resvalue/resnull, store the temporary result of the subplan in the  
subplan's return value.  
  
Bug: #19370  
Reported-by: Zepeng Zhang <redraiment@gmail.com>  
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Diagnosed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/19370-7fb7a5854b7618f1@postgresql.org  
Backpatch-through: 18  

commit   : aa40615cc99211db70429ebbc4c8a1549dcc06ae    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Jan 2026 04:48:49 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 6 Jan 2026 04:48:49 +0000    

Since commit 1462aad2e4, which introduced the ability to modify the  
two_phase property of a slot, the comments above ReplicationSlotCreate  
have become outdated. We have now added a cautionary note in the comments  
above ReplicationSlotAlter explaining when it is safe to modify the  
two_phase property of a slot.  
  
Author: Daniil Davydov <3danissimo@gmail.com>  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/CAJDiXggZXQZ7bD0QcTizDt6us9aX6ZKK4dWxzgb5x3+TsVHjqQ@mail.gmail.com  

commit   : bea57a6b430c988d628582dd88e27281ccbae796    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jan 2026 17:29:44 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jan 2026 17:29:44 +1300    

When processing the "publish" options of an ALTER PUBLICATION command,  
we call SplitIdentifierString() to split the options into a List of  
strings.  Since SplitIdentifierString() modifies the delimiter  
character and puts NULs in their place, this would overwrite the memory  
of the AlterPublicationStmt.  Later in AlterPublicationOptions(), the  
modified AlterPublicationStmt is copied for event triggers, which would  
result in the event trigger only seeing the first "publish" option  
rather than all options that were specified in the command.  
  
To fix this, make a copy of the string before passing to  
SplitIdentifierString().  
  
Here we also adjust a similar case in the pgoutput plugin.  There's no  
known issues caused by SplitIdentifierString() here, so this is being  
done out of paranoia.  
  
Thanks to Henson Choi for putting together an example case showing the  
ALTER PUBLICATION issue.  
  
Author: sunil s <sunilfeb26@gmail.com>  
Reviewed-by: Henson Choi <assam258@gmail.com>  
Reviewed-by: zengman <zengman@halodbtech.com>  
Backpatch-through: 14  

commit   : 6ec5968151252b6c01f1150f668fa9331db1313e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Jan 2026 11:57:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Jan 2026 11:57:12 +0900    

Commit d926462d819 restored the behavior of passing GUC settings from  
the CONNECTION string to the publisher's walsender, allowing per-connection  
configuration.  
  
This commit adds a TAP test to verify that behavior works correctly.  
  
Since commit d926462d819 was recently applied and backpatched to v15,  
this follow-up commit is also backpatched accordingly.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com  
Backpatch-through: 15  

commit   : 797fc5d1b38dd46f46d8482bfe762f5d5ca6a001    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Jan 2026 11:52:22 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Jan 2026 11:52:22 +0900    

Prior to v15, GUC settings supplied in the CONNECTION clause of  
CREATE SUBSCRIPTION were correctly passed through to  
the publisher's walsender. For example:  
  
        CREATE SUBSCRIPTION mysub  
            CONNECTION 'options=''-c wal_sender_timeout=1000'''  
            PUBLICATION ...  
  
would cause wal_sender_timeout to take effect on the publisher's walsender.  
  
However, commit f3d4019da5d changed the way logical replication  
connections are established, forcing the publisher's relevant  
GUC settings (datestyle, intervalstyle, extra_float_digits) to  
override those provided in the CONNECTION string. As a result,  
from v15 through v18, GUC settings in the CONNECTION string were  
always ignored.  
  
This regression prevented per-connection tuning of logical replication.  
For example, using a shorter timeout for walsender connecting  
to a nearby subscriber and a longer one for walsender connecting  
to a remote subscriber.  
  
This commit restores the intended behavior by ensuring that  
GUC settings in the CONNECTION string are again passed through  
and applied by the walsender, allowing per-connection configuration.  
  
Backpatch to v15, where the regression was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Chao Li <lic@highgo.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com  
Backpatch-through: 15  

commit   : 9ba5d40e9037ae24c2f4f9a5f3d08a619e1185d6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jan 2026 15:16:56 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 6 Jan 2026 15:16:56 +1300    

The comment claimed *strat got set to InvalidStrategy when the function  
lookup fails.  This isn't true; an ERROR is raised when that happens.  
  
Author: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://postgr.es/m/CA+renyXOrjLacP_nhqEQUf2W+ZCoY2q5kpQCfG05vQVYzr8b9w@mail.gmail.com  
Backpatch-through: 18  

commit   : b86c2b712b503cdcdf7f801ffd0ef97066204504    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Jan 2026 11:00:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 6 Jan 2026 11:00:54 +0900    

Update pg_rewind documentation to reflect the change that data checksums are  
now enabled by default during initdb.  
  
Backpatch to v18, where data checksums were changed to be enabled by default.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/TY4PR01MB16907D62F3A0A377B30FDBEA794B2A@TY4PR01MB16907.jpnprd01.prod.outlook.com  
Backpatch-through: 18  

commit   : eda0e9383dc1c8ca1d50d358352af06778838447    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jan 2026 13:09:03 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Jan 2026 13:09:03 -0500    

Previously the ulimit -p 256 was needed to increase the limit on  
openbsd. However, sometimes the limit actually was too low, causing  
  "could not fork new process for connection: Resource temporarily unavailable"  
errors.  Most commonly on netbsd, but also on openbsd.  
  
The ulimit on openbsd couldn't trivially be increased with ulimit, because of  
hitting the hard limit.  
  
Instead of increasing the limit in the CI script, the CI image generation now  
increases the limits: https://github.com/anarazel/pg-vm-images/pull/129  
  
Backpatch-through: 18  

commit   : b63302d900767cd0fdcb13c9cc53b538f4c04b78    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 5 Jan 2026 11:33:35 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 5 Jan 2026 11:33:35 +0200    

'lineindex' is 0-based, as mentioned in the comments.  
  
Backpatch to v18 where the assertion was added.  
  
Author: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://www.postgresql.org/message-id/tencent_A84F3C810365BB9BD08442955AE494141907@qq.com  
Backpatch-through: 18  

commit   : 789016be8ef015f65e9f76e5a58945b7b93f17b7    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jan 2026 21:13:10 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jan 2026 21:13:10 +1300    

Author: Daisuke Higuchi <higuchi.daisuke11@gmail.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/CAEVT6c-yWYstu76YZ7VOxmij2XA8vrOEvens08QLmKHTDjEPBw@mail.gmail.com  
Backpatch-through: 14  

commit   : 07c1c6ec51a4474c22abbee731cfc8111fc09a43    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jan 2026 20:33:14 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jan 2026 20:33:14 +1300    

This fixes a poorly written integer comparison function which was  
performing subtraction in an attempt to return a negative value when  
a < b and a positive value when a > b, and 0 when the values were equal.  
Unfortunately that didn't always work correctly due to two's complement  
having the INT_MIN 1 further from zero than INT_MAX.  This could result  
in an overflow and cause the comparison function to return an incorrect  
result, which would result in the binary search failing to find the  
value being searched for.  
  
This could cause poor selectivity estimates when the statistics stored  
the value of INT_MAX (2147483647) and the value being searched for was  
large enough to result in the binary search doing a comparison with that  
INT_MAX value.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAEoWx2ng1Ot5LoKbVU-Dh---dFTUZWJRH8wv2chBu29fnNDMaQ@mail.gmail.com  
Backpatch-through: 14  

commit   : aa4b5ebc7640f60905cd4c71db45674e5941b611    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Jan 2026 13:24:10 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Jan 2026 13:24:10 -0500    

Backpatch-through: 14  

commit   : 640772c6df2bdb3e2b905b03ac199ae46e29cda3    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 31 Dec 2025 11:18:17 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 31 Dec 2025 11:18:17 -0800    

Commit f54af9f2679d added a check for  
io_uring_queue_init_mem(). However, it used the macro name  
HAVE_LIBURING_QUEUE_INIT_MEM in both meson.build and the C code, while  
the Autotools build script defined HAVE_IO_URING_QUEUE_INIT_MEM. As a  
result, the optimization was never enabled in builds configured with  
Autotools, as the C code checked for the wrong macro name.  
  
This commit changes the macro name to HAVE_IO_URING_QUEUE_INIT_MEM in  
meson.build and the C code. This matches the actual function  
name (io_uring_queue_init_mem), following the standard HAVE_<FUNCTION>  
convention.  
  
Backpatch to 18, where the macro was introduced.  
  
Bug: #19368  
Reported-by: Evan Si <evsi@amazon.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19368-016d79a7f3a1c599@postgresql.org  
Backpatch-through: 18  

commit   : 6377b17257c69c6c87b9aa1da3fac62bd91345eb    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 31 Dec 2025 13:24:17 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 31 Dec 2025 13:24:17 +1300    

jit_profiling_support=true captures profile data for Linux perf.  On  
other platforms, LLVMCreatePerfJITEventListener() returns NULL and the  
attempt to register the listener would crash.  
  
Fix by ignoring the setting in that case.  The documentation already  
says that it only has an effect if perf support is present, and we  
already did the same for older LLVM versions that lacked support.  
  
No field reports, unsurprisingly for an obscure developer-oriented  
setting.  Noticed in passing while working on commit 1a28b4b4.  
  
Backpatch-through: 14  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKGJgB6gvrdDohgwLfCwzVQm%3DVMtb9m0vzQn%3DCwWn-kwG9w%40mail.gmail.com  

commit   : fd7c86cfaf139c57a8e0dcf68fe37dd6086f758f    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 30 Dec 2025 10:56:28 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 30 Dec 2025 10:56:28 -0800    

Previously, ReplicationSlotsComputeRequiredXmin() computed the oldest  
xmin across all slots without holding ProcArrayLock (when  
already_locked is false), acquiring the lock just before updating the  
replication slot xmin.  
  
This could lead to a race condition: if a backend created a new slot  
and updates the global replication slot xmin, another backend  
concurrently running ReplicationSlotsComputeRequiredXmin() could  
overwrite that update with an invalid or stale value. This happens  
because the concurrent backend might have computed the aggregate xmin  
before the new slot was accounted for, but applied the update after  
the new slot had already updated the global value.  
  
In the reported failure, a walsender for an apply worker computed  
InvalidTransactionId as the oldest xmin and overwrote a valid  
replication slot xmin value computed by a walsender for a tablesync  
worker. Consequently, the tablesync worker computed a transaction ID  
via GetOldestSafeDecodingTransactionId() effectively without  
considering the replication slot xmin. This led to the error "cannot  
build an initial slot snapshot as oldest safe xid %u follows  
snapshot's xmin %u", which was an assertion failure prior to commit  
240e0dbacd3.  
  
To fix this, we acquire ReplicationSlotControlLock in exclusive mode  
during slot creation to perform the initial update of the slot  
xmin. In ReplicationSlotsComputeRequiredXmin(), we hold  
ReplicationSlotControlLock in shared mode until the global slot xmin  
is updated in ProcArraySetReplicationSlotXmin(). This prevents  
concurrent computations and updates of the global xmin by other  
backends during the initial slot xmin update process, while still  
permitting concurrent calls to ReplicationSlotsComputeRequiredXmin().  
  
Backpatch to all supported versions.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Pradeep Kumar <spradeepkumar29@gmail.com>  
Reviewed-by: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAA4eK1L8wYcyTPxNzPGkhuO52WBGoOZbT0A73Le=ZUWYAYmdfw@mail.gmail.com  
Backpatch-through: 14  

commit   : c5e1281fd893ea8c86cd17cec402dc684b05167c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 30 Dec 2025 14:11:37 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 30 Dec 2025 14:11:37 +1300    

REL_18_STABLE and master have commit ee485912, so they always use the  
newer LLVM opaque pointer functions.  Drop -Wno-deprecated-declarations  
(commit a56e7b660) for code under jit/llvm in those branches, to catch  
any new deprecation warnings that arrive in future version of LLVM.  
  
Older branches continued to use functions marked deprecated in LLVM 14  
and 15 (ie switched to the newer functions only for LLVM 16+), as a  
precaution against unforeseen compatibility problems with bitcode  
already shipped.  In those branches, the comment about warning  
suppression is updated to explain that situation better.  In theory we  
could suppress warnings only for LLVM 14 and 15 specifically, but that  
isn't done here.  
  
Backpatch-through: 14  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1407185.1766682319%40sss.pgh.pa.us  

commit   : 4da5c33a3a046fc81a6b490568801c5739286936    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Dec 2025 15:22:16 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Dec 2025 15:22:16 +1300    

Mkvcbuild.pm scrapes Makefile contents, but couldn't understand the  
change made by commit bec2a0aa.  Revealed by BF animal hamerkop in  
branch REL_16_STABLE.  
  
1.  It used += instead of =, which didn't match the pattern that  
Mkvcbuild.pm looks for.  Drop the +.  
  
2.  Mkvcbuild.pm doesn't link PROGRAM executables with libpgport.  Apply  
a local workaround to REL_16_STABLE only (later branches dropped  
Mkvcbuild.pm).  
  
Backpatch-through: 16  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/175163.1766357334%40sss.pgh.pa.us  

commit   : 7e9f852a79fe19d4d0f18aabc32a620797fb676e    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Dec 2025 11:40:45 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Dec 2025 11:40:45 +0900    

When looking up statistical data about an expression, we failed to  
look through PlaceHolderVar nodes, treating them as opaque.  This  
could prevent us from matching an expression to base columns, index  
expressions, or extended statistics, as examine_variable() relies on  
strict structural matching.  
  
As a result, queries involving PlaceHolderVar nodes often fell back to  
default selectivity estimates, potentially leading to poor plan  
choices.  
  
This patch updates examine_variable() to strip PlaceHolderVars before  
analysis.  This is safe during estimation because PlaceHolderVars are  
transparent for the purpose of statistics lookup: they do not alter  
the value distribution of the underlying expression.  
  
To minimize performance overhead on this hot path, a lightweight  
walker first checks for the presence of PlaceHolderVars.  The more  
expensive mutator is invoked only when necessary.  
  
There is one ensuing plan change in the regression tests, which is  
expected and demonstrates the fix: the rowcount estimate becomes much  
more accurate with this patch.  
  
Back-patch to v18.  Although this issue exists before that, changes in  
this version made it common enough to notice.  Given the lack of field  
reports for older versions, I am not back-patching further.  
  
Reported-by: Haowu Ge <gehaowu@bitmoe.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/62af586c-c270-44f3-9c5e-02c81d537e3d.gehaowu@bitmoe.com  
Backpatch-through: 18  

commit   : b4cf7442058f0b0f525b5df36f4bbfc73a97ed0c    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Dec 2025 11:38:49 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Mon, 29 Dec 2025 11:38:49 +0900    

When pulling up a subquery, we may need to wrap its targetlist items  
in PlaceHolderVars to enforce separate identity or as a result of  
outer joins.  However, this causes any upper-level WHERE clauses  
referencing these outputs to contain PlaceHolderVars, which prevents  
indxpath.c from recognizing that they could be matched to index  
columns or index expressions, potentially affecting the planner's  
ability to use indexes.  
  
To fix, explicitly strip PlaceHolderVars from index operands.  A  
PlaceHolderVar appearing in a relation-scan-level expression is  
effectively a no-op.  Nevertheless, to play it safe, we strip only  
PlaceHolderVars that are not marked nullable.  
  
The stripping is performed recursively to handle cases where  
PlaceHolderVars are nested or interleaved with other node types.  To  
minimize performance impact, we first use a lightweight walker to  
check for the presence of strippable PlaceHolderVars.  The expensive  
mutator is invoked only if a candidate is found, avoiding unnecessary  
memory allocation and tree copying in the common case where no  
PlaceHolderVars are present.  
  
Back-patch to v18.  Although this issue exists before that, changes in  
this version made it common enough to notice.  Given the lack of field  
reports for older versions, I am not back-patching further.  
  
Reported-by: Haowu Ge <gehaowu@bitmoe.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://postgr.es/m/62af586c-c270-44f3-9c5e-02c81d537e3d.gehaowu@bitmoe.com  
Backpatch-through: 18  

commit   : 61c78e1f494cc737807c9fa7f1de0d8c39b53428    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 27 Dec 2025 23:05:48 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 27 Dec 2025 23:05:48 +0100    

The variable_is_guc_list_quote function need to know about all  
GUC_QUOTE variables, this adds oauth_validator_libraries which  
was missing.  Backpatch to v18 where OAuth was introduced.  
  
Author: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/tencent_03D4D2A5C0C8DCE0CD1DB4D945858E15420A@qq.com  
Backpatch-through: 18  

commit   : 06907e864733ed02056e510c3f405414335bcae3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Dec 2025 17:23:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Dec 2025 17:23:51 +0900    

pg_stat_get_backend_activity() calls pgstat_clip_activity() to ensure  
that the reported query string is correctly truncated when it finishes  
with an incomplete multi-byte sequence.  However, the result returned by  
the function was not what pgstat_clip_activity() generated, but the  
non-truncated, original, contents from PgBackendStatus.st_activity_raw.  
  
Oversight in 54b6cd589ac2, so backpatch all the way down.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAEoWx2mDzwc48q2EK9tSXS6iJMJ35wvxNQnHX+rXjy5VgLvJQw@mail.gmail.com  
Backpatch-through: 14  

commit   : c6d2cd06cb43050fbe5cc1a928bdb9eb0299ca27    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 26 Dec 2025 17:34:17 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 26 Dec 2025 17:34:17 -0500    

Also be more assertive that "ctid" should not be used for long-term  
storage.  
  
Reported-by: Bernice Southey  
  
Discussion: https://postgr.es/m/CAEDh4nyn5swFYuSfcnGAbpQrKOc47Hh_ZyKVSPYJcu2P=51Luw@mail.gmail.com  
  
Backpatch-through: 17  

commit   : 2359c5945c2c8092ef41734221af59dbffce242e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 26 Dec 2025 15:26:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 26 Dec 2025 15:26:02 +0900    

Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Discussion: https://postgr.es/m/d6d6a800f8b503cd78d5f4fa721198e40eec1677.camel@cybertec.at  
Backpatch-through: 14  

commit   : 382ce9cb717f3376174f852e8f4b8c28b1c87020    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 25 Dec 2025 12:12:52 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 25 Dec 2025 12:12:52 +0900    

If there are any SRFs in a PathTarget, we must separate it into  
SRF-computing and SRF-free targets.  This is because the executor can  
only handle SRFs that appear at the top level of the targetlist of a  
ProjectSet plan node.  
  
If we find a subexpression that matches an expression already computed  
in the previous plan level, we should treat it like a Var and should  
not split it again.  setrefs.c will later replace the expression with  
a Var referencing the subplan output.  
  
However, when processing the grouping target for grouping sets, the  
planner can fail to recognize that an expression is already computed  
in the scan/join phase.  The root cause is a mismatch in the  
nullingrels bits.  Expressions in the grouping target carry the  
grouping nulling bit in their nullingrels to indicate that they can be  
nulled by the grouping step.  However, the corresponding expressions  
in the scan/join target do not have these bits.  
  
As a result, the exact match check in list_member() fails, leading the  
planner to incorrectly believe that the expression needs to be  
re-evaluated from its arguments, which are often not available in the  
subplan.  This can lead to planner errors such as "variable not found  
in subplan target list".  
  
To fix, ignore the grouping nulling bit when checking whether an  
expression from the grouping target is available in the pre-grouping  
input target.  This aligns with the matching logic in setrefs.c.  
  
Backpatch to v18, where this issue was introduced.  
  
Bug: #19353  
Reported-by: Marian MULLER REBEYROL <marian.muller@serli.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/19353-aaa179bba986a19b@postgresql.org  
Backpatch-through: 18  

commit   : 4e13769004c8b2a337d24060e15f23684d3df98b    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 24 Dec 2025 13:55:32 -0800    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 24 Dec 2025 13:55:32 -0800    

Commit 8a3e4011 introduced tab completion for the ONLY option of  
VACUUM and ANALYZE, along with some code simplification using  
MatchAnyN. However, it caused a regression in tab completion for  
VACUUM option values. For example, neither ON nor OFF was suggested  
after "VACUUM (VERBOSE". In addition, the ONLY keyword was not  
suggested immediately after a completed option list.  
  
Backpatch to v18.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/20251223021509.19bba68ecbbc70c9f983c2b4@sraoss.co.jp  
Backpatch-through: 18  

commit   : 02a0f385fa980c1eb14947936161123b4848fe9b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Dec 2025 00:27:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 25 Dec 2025 00:27:19 +0900    

The pg_overexplain documentation previously used the <literal> tag for  
some file names, struct names, and commands. Update the markup to  
use the more appropriate tags: <filename>, <structname>, and <command>.  
  
Backpatch to v18, where pg_overexplain was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Shixin Wang <wang-shi-xin@outlook.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwEyYUzz0LjBV_fMcdwU3wgmu0NCoT+JJiozPa8DG6eeog@mail.gmail.com  
Backpatch-through: 18  

commit   : 214c17bd623e1fd80b6ac02bd7c428eb4ab4307d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Dec 2025 10:06:20 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Dec 2025 10:06:20 +0000    

Commit 8e0d32a4a1 fixed an issue by allowing the replication origin to be  
created while marking the table sync state as SUBREL_STATE_DATASYNC.  
Update the comment in check_old_cluster_subscription_state() to accurately  
describe this corrected behavior.  
  
Author: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Backpatch-through: 17, where the code was introduced  
Discussion: https://postgr.es/m/CAA4eK1+KaSf5nV_tWy+SDGV6MnFnKMhdt41jJjSDWm6yCyOcTw@mail.gmail.com  
Discussion: https://postgr.es/m/aUTekQTg4OYnw-Co@paquier.xyz  

commit   : 2f7ffe124a9ba0ddc477fa5643da5e59cc1e4db0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Dec 2025 04:21:43 +0000    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 24 Dec 2025 04:21:43 +0000    

The logical replication parallel apply worker could incorrectly advance  
the origin progress during an error or failed apply. This behavior risks  
transaction loss because such transactions will not be resent by the  
server.  
  
Commit 3f28b2fcac addressed a similar issue for both the apply worker and  
the table sync worker by registering a before_shmem_exit callback to reset  
origin information. This prevents the worker from advancing the origin  
during transaction abortion on shutdown. This patch applies the same fix  
to the parallel apply worker, ensuring consistent behavior across all  
worker types.  
  
As with 3f28b2fcac, we are backpatching through version 16, since parallel  
apply mode was introduced there and the issue only occurs when changes are  
applied before the transaction end record (COMMIT or ABORT) is received.  
  
Author: Hou Zhijie <houzj.fnst@fujitsu.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Backpatch-through: 16  
Discussion: https://postgr.es/m/TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/TYAPR01MB5692FAC23BE40C69DA8ED4AFF5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com  

commit   : 3e3a80f62c09709de899cc7649f1c86c63b78981    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 Dec 2025 13:37:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 Dec 2025 13:37:16 +0200    

After waiting for a concurrent updater to finish, heap_lock_tuple()  
followed the update chain to lock all tuple versions. However, when  
stepping from the initial tuple to the next one, it failed to check  
that the next tuple's XMIN matches the initial tuple's XMAX. That's an  
important check whenever following an update chain, and the recursive  
part that follows the chain did it, but the initial step missed it.  
Without the check, if the updating transaction aborts, the updated  
tuple is vacuumed away and replaced by an unrelated tuple, the  
unrelated tuple might get incorrectly locked.  
  
Author: Jasper Smit <jasper.smit@servicenow.com>  
Discussion: https://www.postgresql.org/message-id/CAOG+RQ74x0q=kgBBQ=mezuvOeZBfSxM1qu_o0V28bwDz3dHxLw@mail.gmail.com  
Backpatch-through: 14  

commit   : 00a851f0c480f4d2c1f8c957f8b53e29ed6113fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Dec 2025 14:06:54 -0500    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Dec 2025 14:06:54 -0500    

commit   : b07c326192d09d996afd761a6224bf74273128a1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Dec 2025 14:32:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Dec 2025 14:32:19 +0900    

Since ce0fdbfe9722, a replication slot and an origin are created by each  
tablesync worker, whose information is stored in both a catalog and  
shared memory (once the origin is set up in the latter case).  The  
transaction where the origin is created is the same as the one that runs  
the initial COPY, with the catalog state of the origin becoming visible  
for other sessions only once the COPY transaction has committed.  The  
catalog state is coupled with a state in shared memory, initialized at  
the same time as the origin created in the catalogs.  Note that the  
transaction doing the initial data sync can take a long time, time that  
depends on the amount of data to transfer from a publication node to its  
subscriber node.  
  
Now, when a DROP SUBSCRIPTION is executed, all its workers are stopped  
with the origins removed.  The removal of each origin relies on a  
catalog lookup.  A worker still running the initial COPY would fail its  
transaction, with the catalog state of the origin rolled back while the  
shared memory state remains around.  The session running the DROP  
SUBSCRIPTION should be in charge of cleaning up the catalog and the  
shared memory state, but as there is no data in the catalogs the shared  
memory state is not removed.  This issue would leave orphaned origin  
data in shared memory, leading to a confusing state as it would still  
show up in pg_replication_origin_status.  Note that this shared memory  
data is sticky, being flushed on disk in replorigin_checkpoint at  
checkpoint.  This prevents other origins from reusing a slot position  
in the shared memory data.  
  
To address this problem, the commit moves the creation of the origin at  
the end of the transaction that precedes the one executing the initial  
COPY, making the origin immediately visible in the catalogs for other  
sessions, giving DROP SUBSCRIPTION a way to know about it.  A different  
solution would have been to clean up the shared memory state using an  
abort callback within the tablesync worker.  The solution of this commit  
is more consistent with the apply worker that creates an origin in a  
short transaction.  
  
A test is added in the subscription test 004_sync.pl, which was able to  
display the problem.  The test fails when this commit is reverted.  
  
Reported-by: Tenglong Gu <brucegu@amazon.com>  
Reported-by: Daisuke Higuchi <higudai@amazon.com>  
Analyzed-by: Michael Paquier <michael@paquier.xyz>  
Author: Hou Zhijie <houzj.fnst@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/aUTekQTg4OYnw-Co@paquier.xyz  
Backpatch-through: 14  

commit   : 283e25a37187b67e9ad88fef59e036140a615389    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 22 Dec 2025 17:56:28 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 22 Dec 2025 17:56:28 +0900    

Correct the referenced location of the RangeTblEntry definition  
in the pg_overexplain documentation.  
  
Backpatched to v18, where pg_overexplain was introduced.  
  
Author: Julien Tachoires <julien@tachoires.me>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/20251218092319.tht64ffmcvzqdz7u@poseidon.home.virt  
Backpatch-through: 18  

commit   : a7d06e74d51209702fe0712214aac07f863ec36a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 21 Dec 2025 15:40:07 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 21 Dec 2025 15:40:07 +1300    

An unused variable caused a compiler warning on BF animal fairywren, an  
snprintf() call was redundant, and some buffer sizes were inconsistent.  
Per code review from Tom Lane.  
  
The Makefile's test ifeq ($(PORTNAME), win32) never succeeded due to a  
circularity, so only Meson builds were actually compiling the new test  
code, partially explaining why CI didn't tell us about the warning  
sooner (the other problem being that CompilerWarnings only makes  
world-bin, a problem for another commit).  Simplify.  
  
Backpatch-through: 16, like commit c507ba55  
Author: Bryan Green <dbryan.green@gmail.com>  
Co-authored-by: Thomas Munro <tmunro@gmail.com>  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1086088.1765593851%40sss.pgh.pa.us  

commit   : cf8c8adfe38138930569eeeae7d600cf465ef334    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 19 Dec 2025 15:48:18 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 19 Dec 2025 15:48:18 +0700    

In the wake of commit db6a4a985, remove most use of 'md5' from the  
example configuration file. The only remainder is an example exception  
for a client that doesn't support SCRAM.  
  
Author: Mikael Gustavsson <mikael.gustavsson@smhi.se>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/176595607507.978865.11597773194269211255@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/4ed268473fdb4cf9b0eced6c8019d353@smhi.se  
Backpatch-through: 18  

commit   : b863d8d87fc1fc44962163a335c2ea1e1d345e13    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Dec 2025 12:05:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 19 Dec 2025 12:05:37 +0900    

Previously, if memory context logging was triggered repeatedly and  
rapidly while a previous request was still being processed, it could  
result in recursive calls to ProcessLogMemoryContextInterrupt().  
This could lead to infinite recursion and potentially crash the process.  
  
This commit adds a guard to prevent such recursion.  
If ProcessLogMemoryContextInterrupt() is already in progress and  
logging memory contexts, subsequent calls will exit immediately,  
avoiding unintended recursive calls.  
  
While this scenario is unlikely in practice, it's not impossible.  
This change adds a safety check to prevent such failures.  
  
Back-patch to v14, where memory context logging was introduced.  
  
Reported-by: Robert Haas <robertmhaas@gmail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Atsushi Torikoshi <torikoshia@oss.nttdata.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reviewed-by: Artem Gavrilov <artem.gavrilov@percona.com>  
Discussion: https://postgr.es/m/CA+TgmoZMrv32tbNRrFTvF9iWLnTGqbhYSLVcrHGuwZvCtph0NA@mail.gmail.com  
Backpatch-through: 14  

commit   : 573e679a26649e14742b4a7d19331bf8ced908ae    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 18 Dec 2025 10:23:47 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 18 Dec 2025 10:23:47 -0800    

Commit 0decd5e89db9f5edb9b27351082f0d74aae7a9b6 missed  
DO_SUBSCRIPTION_REL, leading to assertion failures.  In the unlikely use  
case of diffing "pg_dump --binary-upgrade" output, spurious diffs were  
possible.  As part of fixing that, align the DumpableObject naming and  
sort order with DO_PUBLICATION_REL.  The overall effect of this commit  
is to change sort order from (subname, srsubid) to (rel, subname).  
Since DO_SUBSCRIPTION_REL is only for --binary-upgrade, accept that  
larger-than-usual dump order change.  Back-patch to v17, where commit  
9a17be1e244a45a77de25ed2ada246fd34e4557d introduced DO_SUBSCRIPTION_REL.  
  
Reported-by: vignesh C <vignesh21@gmail.com>  
Author: vignesh C <vignesh21@gmail.com>  
Discussion: https://postgr.es/m/CALDaNm2x3rd7C0_HjUpJFbxpAqXgm=QtoKfkEWDVA8h+JFpa_w@mail.gmail.com  
Backpatch-through: 17  

commit   : d77a5f98176ffaf3a537f4683ec87044c21bb98c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Dec 2025 15:08:48 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Dec 2025 15:08:48 +0200    

Operations on unlogged relations should not be WAL-logged. The  
brin_initialize_empty_new_buffer() function didn't get the memo.  
  
The function is only called when a concurrent update to a brin page  
uses up space that we're just about to insert to, which makes it  
pretty hard to hit. If you do manage to hit it, a full-page WAL record  
is erroneously emitted for the unlogged index. If you then crash,  
crash recovery will fail on that record with an error like this:  
  
    FATAL:  could not create file "base/5/32819": File exists  
  
Author: Kirill Reshke <reshkekirill@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CALdSSPhpZXVFnWjwEBNcySx_vXtXHwB2g99gE6rK0uRJm-3GgQ@mail.gmail.com  
Backpatch-through: 14  

commit   : c3df85756ceb0246958ef2b72c04aba51e52de13    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 17 Dec 2025 11:55:04 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 17 Dec 2025 11:55:04 -0800    

Commit e0f373ee4 fixed up races in Cluster::connect_fails when using  
log_like. t/002_client.pl didn't get the memo, though, because it  
doesn't use Test::Cluster to perform its custom hook tests. (This is  
probably not an issue at the moment, since the log check is only done  
after authentication success and not failure, but there's no reason to  
wait for someone to hit it.)  
  
Introduce the fix, based on debug2 logging, to its use of log_check() as  
well, and move the logic into the test() helper so that any additions  
don't need to continually duplicate it.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com  
Backpatch-through: 18  

commit   : 023a3c786b81bf9e0ca023f8e279f03b197b189f    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 17 Dec 2025 11:54:56 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 17 Dec 2025 11:54:56 -0800    

Copy-paste bug from b0635bfda: libpq-oauth.so was being built with  
libpq_so_c_args, rather than libpq_oauth_so_c_args. (At the moment, the  
two lists are identical, but that won't be true forever.)  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com  
Backpatch-through: 18  

commit   : cc824482a3c0e6957c252730a62e7460d16a91f4    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 17 Dec 2025 11:54:47 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Wed, 17 Dec 2025 11:54:47 -0800    

The definition of PGoauthBearerRequest uses a temporary SOCKTYPE macro  
to hide the difference between Windows and Berkeley socket handles,  
since we don't surface pgsocket in our public API. This macro doesn't  
need to escape the header, because implementers will choose the correct  
socket type based on their platform, so I #undef'd it immediately after  
use.  
  
I didn't namespace that helper, though, so if anyone else needs a  
SOCKTYPE macro, libpq-fe.h will now unhelpfully get rid of it. This  
doesn't seem too far-fetched, given its proximity to existing POSIX  
macro names.  
  
Add a PQ_ prefix to avoid collisions, update and improve the surrounding  
documentation, and backpatch.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com  
Backpatch-through: 18  

commit   : c8098aa411ee72b36879acba95819100b263f726    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 17 Dec 2025 16:23:13 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 17 Dec 2025 16:23:13 +0200    

The test is very sensitive to how backends start and exit, because it  
tests dead-end backends which occur when all the connection slots are  
in use. The test failed occasionally in the CI, when the backend that  
was launched for the raw_connect_works() check lingered for a while,  
and exited only later during the test. When it exited, it released a  
connection slot, when the test expected all the slots to be in use at  
that time.  
  
The 002_connection_limits.pl test had a similar issue: if the backend  
launched for safe_psql() in the test initialization lingers around, it  
uses up a connection slot during the test, messing up the test's  
connection counting. I haven't seen that in the CI, but when I added a  
"sleep(1);" to proc_exit(), the test failed.  
  
To make the tests more robust, restart the server to ensure that the  
lingering backends doesn't interfere with the later test steps.  
  
In the passing, fix a bogus test name.  
  
Report and analysis by Jelte Fennema-Nio, Andres Freund, Thomas Munro.  
  
Discussion: https://www.postgresql.org/message-id/CAGECzQSU2iGuocuP+fmu89hmBmR3tb-TNyYKjCcL2M_zTCkAFw@mail.gmail.com  
Backpatch-through: 18  

commit   : 806555e3000d0b0e0c536c1dc65548128d457d86    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 16 Dec 2025 11:13:17 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 16 Dec 2025 11:13:17 -0800    

Previously, ltree_prefix_eq_ci() used lowercasing with the default  
collation; while ltree_crc32_sz() used tolower() directly. These were  
equivalent only if the default collation provider was libc and the  
encoding was single-byte.  
  
Change both to use casefolding with the default collation.  
  
Backpatch through 18, where the casefolding APIs were introduced. The  
bug exists in earlier versions, but would require some adaptation.  
  
A REINDEX is required for ltree indexes where the database default  
collation is not libc.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Backpatch-through: 18  
Discussion: https://postgr.es/m/450ceb6260cad30d7afdf155d991a9caafee7c0d.camel@j-davis.com  
Discussion: https://postgr.es/m/01fc00fd66f641b9693d4f9f1af0ccf44cbdfbdf.camel@j-davis.com  

commit   : f79e239e0bc6e4d5fe91e1a0e573ecf0715d6c8c    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 16 Dec 2025 10:35:40 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 16 Dec 2025 10:35:40 -0800    

Previously, the API for ltree_strncasecmp() took two inputs but only  
one length (that of the smaller input). It truncated the larger input  
to that length, but that could break a multibyte sequence.  
  
Change the API to be a check for prefix equality (possibly  
case-insensitive) instead, which is all that's needed by the  
callers. Also, provide the lengths of both inputs.  
  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/5f65b85740197ba6249ea507cddf609f84a6188b.camel%40j-davis.com  
Backpatch-through: 14  

commit   : 06b030e8973fa440d5b0d3ce0cd93a6c0a3f72ab    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 16 Dec 2025 10:01:28 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 16 Dec 2025 10:01:28 -0800    

Commit bae8ca82fd00603ebafa0658640d6e4dfe20af92 anticipated this:  
  
  [C] 'function void CacheInvalidateHeapTupleInplace(Relation, HeapTuple, HeapTuple)' has some sub-type changes:  
    parameter 3 of type 'typedef HeapTuple' was removed  
  
Discussion: https://postgr.es/m/CA+renyU+LGLvCqS0=fHit-N1J-2=2_mPK97AQxvcfKm+F-DxJA@mail.gmail.com  
Backpatch-through: 18 only  

commit   : 57df5ab8049782d7b24594ac677783512ffce2bc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Dec 2025 10:40:53 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Dec 2025 10:40:53 -0500    

We already do this in CreateParallelContext, InitializeParallelDSM, and  
LaunchParallelWorkers. I suspect the reason why the matching logic was  
omitted from ReinitializeParallelDSM is that I failed to realize that  
any memory allocation was happening here -- but shm_mq_attach does  
allocate, which could result in a shm_mq_handle being allocated in a  
shorter-lived context than the ParallelContext which points to it.  
  
That could result in a crash if the shorter-lived context is freed  
before the parallel context is destroyed. As far as I am currently  
aware, there is no way to reach a crash using only code that is  
present in core PostgreSQL, but extensions could potentially trip  
over this. Fixing this in the back-branches appears low-risk, so  
back-patch to all supported versions.  
  
Author: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Co-authored-by: Jeevan Chalke <jeevan.chalke@enterprisedb.com>  
Backpatch-through: 14  
Discussion: http://postgr.es/m/CAKZiRmwfVripa3FGo06=5D1EddpsLu9JY2iJOTgbsxUQ339ogQ@mail.gmail.com  

commit   : b30089fde1e9e945f96db9366f5ff5eb4abd3774    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 16 Dec 2025 09:46:53 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 16 Dec 2025 09:46:53 +0100    

Commit 119fc30 moved CompareType to cmptype.h but the mention in  
the docs still refered to primnodes.h  
  
Author: Daisuke Higuchi <higuchi.daisuke11@gmail.com>  
Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAEVT6c8guXe5P=L_Un5NUUzCgEgbHnNcP+Y3TV2WbQh-xjiwqA@mail.gmail.com  
Backpatch-through: 18  

commit   : 68ebdf2b07f6fb2d83f6e6440310fdb4b7377bb3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Dec 2025 13:29:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Dec 2025 13:29:36 +0900    

This commit adds an extra check at the beginning of recovery to ensure  
that the redo record of a checkpoint exists before attempting WAL  
replay, logging a PANIC if the redo record referenced by the checkpoint  
record could not be found.  This is the same level of failure as when a  
checkpoint record is missing.  This check is added when a cluster is  
started without a backup_label, after retrieving its checkpoint record.  
The redo LSN used for the check is retrieved from the checkpoint record  
successfully read.  
  
In the case where a backup_label exists, the startup process already  
fails if the redo record cannot be found after reading a checkpoint  
record at the beginning of recovery.  
  
Previously, the presence of the redo record was not checked.  If the  
redo and checkpoint records were located on different WAL segments, it  
would be possible to miss a entire range of WAL records that should have  
been replayed but were just ignored.  The consequences of missing the  
redo record depend on the version dealt with, these becoming worse the  
older the version used:  
- On HEAD, v18 and v17, recovery fails with a pointer dereference at the  
beginning of the redo loop, as the redo record is expected but cannot be  
found.  These versions are good students, because we detect a failure  
before doing anything, even if the failure is misleading in the shape of  
a segmentation fault, giving no information that the redo record is  
missing.  
- In v16 and v15, problems show at the end of recovery within  
FinishWalRecovery(), the startup process using a buggy LSN to decide  
from where to start writing WAL.  The cluster gets corrupted, still it  
is noisy about it.  
- v14 and older versions are worse: a cluster gets corrupted but it is  
entirely silent about the matter.  The redo record missing causes the  
startup process to skip entirely recovery, because a missing record is  
the same as not redo being required at all.  This leads to data loss, as  
everything is missed between the redo record and the checkpoint record.  
  
Note that I have tested that down to 9.4, reproducing the issue with a  
version of the author's reproducer slightly modified.  The code is wrong  
since at least 9.2, but I did not look at the exact point of origin.  
  
This problem has been found by debugging a cluster where the WAL segment  
including the redo segment was missing due to an operator error, leading  
to a crash, based on an investigation in v15.  
  
Requesting archive recovery with the creation of a recovery.signal or  
a standby.signal even without a backup_label would mitigate the issue:  
if the record cannot be found in pg_wal/, the missing segment can be  
retrieved with a restore_command when checking that the redo record  
exists.  This was already the case without this commit, where recovery  
would re-fetch the WAL segment that includes the redo record.  The check  
introduced by this commit makes the segment to be retrieved earlier to  
make sure that the redo record can be found.  
  
On HEAD, the code will be slightly changed in a follow-up commit to not  
rely on a PANIC, to include a test able to emulate the original problem.  
This is a minimal backpatchable fix, kept separated for clarity.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Analyzed-by: Andres Freund <andres@anarazel.de>  
Author: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Discussion: https://postgr.es/m/20231023232145.cmqe73stvivsmlhs@awork3.anarazel.de  
Discussion: https://postgr.es/m/CAMm1aWaaJi2w49c0RiaDBfhdCL6ztbr9m=daGqiOuVdizYWYaA@mail.gmail.com  
Backpatch-through: 14  

commit   : 7a15cff1f11193467898da1c1fabf06fd2caee04    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 15 Dec 2025 13:30:48 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 15 Dec 2025 13:30:48 -0800    

Now that the prior commits have fixed missing OAuth translations, pull  
the bespoke usage of libpq_gettext() for OAUTHBEARER parsing into  
oauth_json_set_error() itself, and make that a gettext trigger as well,  
to better match what the other sites are doing. Add an _internal()  
variant to handle the existing untranslated case.  
  
Suggested-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/0EEBCAA8-A5AC-4E3B-BABA-0BA7A08C361B%40yesql.se  
Backpatch-through: 18  

commit   : aac25567fec10b7b2cc382654e5586acebec5431    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 15 Dec 2025 13:30:44 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 15 Dec 2025 13:30:44 -0800    

Some error messages are generated when OAuth multiplexer operations fail  
unexpectedly in the client. Álvaro pointed out that these are both  
difficult to translate idiomatically (as they use internal terminology  
heavily) and of dubious translation value to end users (since they're  
going to need to get developer help anyway). The response parsing engine  
has a similar issue.  
  
Remove these from the translation files by introducing internal variants  
of actx_error() and oauth_parse_set_error().  
  
Suggested-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAOYmi%2BkQQ8vpRcoSrA5EQ98Wa3G6jFj1yRHs6mh1V7ohkTC7JA%40mail.gmail.com  
Backpatch-through: 18  

commit   : 169ff4ca930bc2562a1c938244a1b098bb09186b    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 15 Dec 2025 13:30:31 -0800    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 15 Dec 2025 13:30:31 -0800    

Several strings that should have been translated as they passed through  
libpq_gettext were not actually being pulled into the translation files,  
because I hadn't directly wrapped them in one of the GETTEXT_TRIGGERS.  
  
Move the responsibility for calling libpq_gettext() to the code that  
sets actx->errctx. Doing the same in report_type_mismatch() would result  
in double-translation, so mark those strings with gettext_noop()  
instead. And wrap two ternary operands with gettext_noop(), even though  
they're already in one of the triggers, since xgettext sees only the  
first.  
  
Finally, fe-auth-oauth.c was missing from nls.mk, so none of that file  
was being translated at all. Add it now.  
  
Original patch by Zhijie Hou, plus suggested tweaks by Álvaro Herrera  
and small additions by me.  
  
Reported-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Co-authored-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/TY4PR01MB1690746DB91991D1E9A47F57E94CDA%40TY4PR01MB16907.jpnprd01.prod.outlook.com  
Backpatch-through: 18  

commit   : bae8ca82fd00603ebafa0658640d6e4dfe20af92    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 15 Dec 2025 12:19:49 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 15 Dec 2025 12:19:49 -0800    

This removes a never-used CacheInvalidateHeapTupleInplace() parameter.  
It adds README content about inplace update visibility in logical  
decoding.  It rewrites other comments.  
  
Back-patch to v18, where commit 243e9b40f1b2dd09d6e5bf91ebf6e822a2cd3704  
first appeared.  Since this removes a CacheInvalidateHeapTupleInplace()  
parameter, expect a v18 ".abi-compliance-history" edit to follow.  PGXN  
contains no calls to that function.  
  
Reported-by: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Reported-by: Ilyasov Ian <ianilyasov@outlook.com>  
Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: Surya Poondla <s_poondla@apple.com>  
Discussion: https://postgr.es/m/CA+renyU+LGLvCqS0=fHit-N1J-2=2_mPK97AQxvcfKm+F-DxJA@mail.gmail.com  
Backpatch-through: 18  

commit   : 3fbad030a24de28aa9b97e2c5b7e4a419594d4b7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Dec 2025 11:47:04 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 15 Dec 2025 11:47:04 +0200    

Coverity complained that offset cannot be 0 here because there's an  
explicit check for "offset == 0" earlier in the function, but it  
didn't see the possibility that offset could've wrapped around to 0.  
The code is correct, but clarify the comment about it.  
  
The same code exists in backbranches in the server  
GetMultiXactIdMembers() function and in 'master' in the pg_upgrade  
GetOldMultiXactIdSingleMember function. In backbranches Coverity  
didn't complain about it because the check was merely an assertion,  
but change the comment in all supported branches for consistency.  
  
Per Tom Lane's suggestion.  
  
Discussion: https://www.postgresql.org/message-id/1827755.1765752936@sss.pgh.pa.us  

commit   : 580b5c2f397fbb2f74c2661cfe53203ed6acead0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Dec 2025 14:11:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Dec 2025 14:11:25 +0900    

The code over-allocated the memory required for os_page_status, relying  
on uint64 for its element size instead of an int, hence doubling what  
was required.  This could mean quite a lot of memory if dealing with a  
lot of NUMA pages.  
  
Oversight in ba2a3c2302f1.  
  
Author: David Geier <geidav.pg@gmail.com>  
Discussion: https://postgr.es/m/ad0748d4-3080-436e-b0bc-ac8f86a3466a@gmail.com  
Backpatch-through: 18  

commit   : 5b7bbf16db3427522d057c14bd9063ef21dff196    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Dec 2025 10:25:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Dec 2025 10:25:44 +0900    

An array of LLVMBasicBlockRef is allocated with the size used for an  
element being "LLVMBasicBlockRef *" rather than "LLVMBasicBlockRef".  
LLVMBasicBlockRef is a type that refers to a pointer, so this did not  
directly cause a problem because both should have the same size, still  
it is incorrect.  
  
This issue has been spotted while reviewing a different patch, and  
exists since 2a0faed9d702, so backpatch all the way down.  
  
Discussion: https://postgr.es/m/CA+hUKGLngd9cKHtTUuUdEo2eWEgUcZ_EQRbP55MigV2t_zTReg@mail.gmail.com  
Backpatch-through: 14  

commit   : e08f338d0028af6f9f54616df1cb51009504eee3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 10 Dec 2025 19:38:07 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 10 Dec 2025 19:38:07 +0200    

The test seemed to incorrectly think that query_safe() takes an  
argument that describes what the query does, similar to e.g.  
command_ok(). Until commit bd8d9c9bdf the extra arguments were  
harmless and were just ignored, but when commit bd8d9c9bdf introduced  
a new optional argument to query_safe(), the extra arguments started  
clashing with that, causing the test to fail.  
  
Backpatch to v17, that's the oldest branch where the test exists. The  
extra arguments didn't cause any trouble on the older branches, but  
they were clearly bogus anyway.  

commit   : e8dc5810a227d5671c25dc2c7dbe1321093a08a6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 10 Dec 2025 11:43:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 10 Dec 2025 11:43:16 +0200    

These functions took a ResourceOwner argument, but only checked if it  
was NULL, and then used CurrentResourceOwner for the actual work.  
Surely the intention was to use the passed-in resource owner. All  
current callers passed CurrentResourceOwner or NULL, so this has no  
consequences at the moment, but it's an accident waiting to happen for  
future caller and extensions.  
  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAEze2Whnfv8VuRZaohE-Af+GxBA1SNfD_rXfm84Jv-958UCcJA@mail.gmail.com  
Backpatch-through: 17