PostgreSQL 19.0 (upcoming) commit log

commit   : 64840e46243a5f672b9e2fcb8d93c63daec4bc9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2025 18:50:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2025 18:50:13 -0400    

getid() and putid(), which parse and deparse role names within ACL  
input/output, applied isalnum() to see if a character within a role  
name requires quoting.  They did this even for non-ASCII characters,  
which is problematic because the results would depend on encoding,  
locale, and perhaps even platform.  So it's possible that putid()  
could elect not to quote some string that, later in some other  
environment, getid() will decide is not a valid identifier, causing  
dump/reload or similar failures.  
  
To fix this in a way that won't risk interoperability problems  
with unpatched versions, make getid() treat any non-ASCII as a  
legitimate identifier character (hence not requiring quotes),  
while making putid() treat any non-ASCII as requiring quoting.  
We could remove the resulting excess quoting once we feel that  
no unpatched servers remain in the wild, but that'll be years.  
  
A lesser problem is that getid() did the wrong thing with an input  
consisting of just two double quotes ("").  That has to represent an  
empty string, but getid() read it as a single double quote instead.  
The case cannot arise in the normal course of events, since we don't  
allow empty-string role names.  But let's fix it while we're here.  
  
Although we've not heard field reports of problems with non-ASCII  
role names, there's clearly a hazard there, so back-patch to all  
supported versions.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3792884.1751492172@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 990571a08b66c76be85b077ddcba419fd4524952    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 11 Jul 2025 10:06:41 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 11 Jul 2025 10:06:41 -0700    

Commit b0635bfda split off the CPPFLAGS/LDFLAGS/LDLIBS for libcurl into  
their own separate Makefile variables, but I neglected to move the  
existing AC_CHECKs for Curl into a place where they would make use of  
those variables. They instead tested the system libcurl, which 1) is  
unhelpful if a different Curl is being used for the build and 2) will  
fail the build entirely if no system libcurl exists. Correct the order  
of operations here.  
  
Reported-by: Ivan Kush <ivan.kush@tantorlabs.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Ivan Kush <ivan.kush@tantorlabs.com>  
Discussion: https://postgr.es/m/8a611028-51a1-408c-b592-832e2e6e1fc9%40tantorlabs.com  
Backpatch-through: 18  

commit   : 8d33fbacbac93ed70757ea47cd8a4b4fae61528a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    

This option, which is disabled by default, can be used to request  
the checkpoint also flush dirty buffers of unlogged relations.  As  
with the MODE option, the server may consolidate the options for  
concurrently requested checkpoints.  For example, if one session  
uses (FLUSH_UNLOGGED FALSE) and another uses (FLUSH_UNLOGGED TRUE),  
the server may perform one checkpoint with FLUSH_UNLOGGED enabled.  
  
Author: Christoph Berg <myon@debian.org>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/aDnaKTEf-0dLiEfz%40msg.df7cb.de  

commit   : 2f698d7f4b7b4c49c3649b2fcc063eb66f9d2e6c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    

This option may be set to FAST (the default) to request the  
checkpoint be completed as fast as possible, or SPREAD to request  
the checkpoint be spread over a longer interval (based on the  
checkpoint-related configuration parameters).  Note that the server  
may consolidate the options for concurrently requested checkpoints.  
For example, if one session requests a "fast" checkpoint and  
another requests a "spread" checkpoint, the server may perform one  
"fast" checkpoint.  
  
Author: Christoph Berg <myon@debian.org>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Discussion: https://postgr.es/m/aDnaKTEf-0dLiEfz%40msg.df7cb.de  

commit   : a4f126516e688736bfed332b44a0c221b8dc118a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    

This commit adds the boilerplate code for supporting a list of  
options in CHECKPOINT commands.  No actual options are supported  
yet, but follow-up commits will add support for MODE and  
FLUSH_UNLOGGED.  While at it, this commit refactors the code for  
executing CHECKPOINT commands to its own function since it's about  
to become significantly larger.  
  
Author: Christoph Berg <myon@debian.org>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://postgr.es/m/aDnaKTEf-0dLiEfz%40msg.df7cb.de  

commit   : bb938e2c3c7a955090f8b68b5bf75d064f6a36a0    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    

The new name more accurately reflects the effects of this flag on a  
requested checkpoint.  Checkpoint-related log messages (i.e., those  
controlled by the log_checkpoints configuration parameter) will now  
say "fast" instead of "immediate", too.  Likewise, references to  
"immediate" checkpoints in the documentation have been updated to  
say "fast".  This is preparatory work for a follow-up commit that  
will add a MODE option to the CHECKPOINT command.  
  
Author: Christoph Berg <myon@debian.org>  
Discussion: https://postgr.es/m/aDnaKTEf-0dLiEfz%40msg.df7cb.de  

commit   : cd8324cc89a9f95bef9593b11507ebf2b79de72a    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 11 Jul 2025 11:51:25 -0500    

The new name more accurately relects the effects of this flag on a  
requested checkpoint.  Checkpoint-related log messages (i.e., those  
controlled by the log_checkpoints configuration parameter) will now  
say "flush-unlogged" instead of "flush-all", too.  This is  
preparatory work for a follow-up commit that will add a  
FLUSH_UNLOGGED option to the CHECKPOINT command.  
  
Author: Christoph Berg <myon@debian.org>  
Discussion: https://postgr.es/m/aDnaKTEf-0dLiEfz%40msg.df7cb.de  

commit   : f25792c541e559070d8e816f82cce01eb4f55ab8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2025 12:49:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2025 12:49:07 -0400    

We already forced LC_MESSAGES to C in order to get consistent  
message output, but that isn't enough to stabilize messages  
that include %f or similar formatting.  
  
I'm a bit surprised that this hasn't come up before.  Perhaps  
we ought to back-patch this change, but I'll refrain for now.  
  
Reported-by: Bernd Helmle <mailings@oopsware.de>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/6f024eaa7885eddf5e0eb4ba1d095fbc7146519b.camel@oopsware.de  

commit   : 72e6c08fea7cf59f5166e138aab927ad87570aa4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Jul 2025 10:46:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 11 Jul 2025 10:46:43 +0530    

Previously, the check_hook functions for max_slot_wal_keep_size and  
idle_replication_slot_timeout would incorrectly raise an ERROR for values  
set in postgresql.conf during upgrade, even though those values were not  
actively used in the upgrade process.  
  
To prevent logical slot invalidation during upgrade, we used to set  
special values for these GUCs. Now, instead of relying on those values, we  
directly prevent WAL removal and logical slot invalidation caused by  
max_slot_wal_keep_size and idle_replication_slot_timeout.  
  
Note: PostgreSQL 17 does not include the idle_replication_slot_timeout  
GUC, so related changes were not backported.  
  
BUG #18979  
Reported-by: jorsol <jorsol@gmail.com>  
Author: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed by: vignesh C <vignesh21@gmail.com>  
Reviewed by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Backpatch-through: 17, where it was introduced  
Discussion: https://postgr.es/m/219561.1751826409@sss.pgh.pa.us  
Discussion: https://postgr.es/m/18979-a1b7fdbb7cd181c6@postgresql.org  

commit   : 4cff01c4a3472ecd2a53f957f13ab20a2970db4c    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 11 Jul 2025 10:34:57 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Fri, 11 Jul 2025 10:34:57 +0900    

In the description of StartupMessage, the protocol version was left  
3.0. Instead of just updating it, this commit removes the hard coded  
protocol version and shows the numbers as an example. This makes that  
the part of the doc does not need to be updated when the version is  
changed in the future.  
  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Tatsuo Ishii <ishii@postgresql.org>  
Reviewed-by: Aleksander Alekseev <aleksander@timescale.com>  
Discussion: https://postgr.es/m/20250626.155608.568829483879866256.ishii%40postgresql.org  

commit   : 110e6dcaa6595cf71be00808e3df0087d1d2b208    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Jul 2025 08:44:32 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Jul 2025 08:44:32 +0900    

This commit updates the documentation to clarify that "idle" in  
idle_replication_slot_timeout means the replication slot is inactive,  
that is, not currently used by any replication connection.  
  
Without this clarification, "idle" could be misinterpreted to mean  
that the slot is not advancing or that no data is being streamed,  
even if a connection exists.  
  
Back-patch to v18 where idle_replication_slot_timeout was added.  
  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Reviewed-by: Gunnar Morling <gunnar.morling@googlemail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com  
Backpatch-through: 18  

commit   : 05dedf43d380edc98546c381e76a9d907fd19bed    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Jul 2025 08:39:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Jul 2025 08:39:24 +0900    

Previously, the idle_replication_slot_timeout parameter used minutes  
as its unit, based on the assumption that values would typically exceed  
one minute in production environments. However, this caused unexpected  
behavior: specifying a value below 30 seconds would round down to 0,  
effectively disabling the timeout. This could be surprising to users.  
  
To allow finer-grained control and avoid such confusion, this commit changes  
the unit of idle_replication_slot_timeout to seconds. Larger values can  
still be specified easily using standard time suffixes, for example,  
'24h' for 24 hours.  
  
Back-patch to v18 where idle_replication_slot_timeout was added.  
  
Reported-by: Gunnar Morling <gunnar.morling@googlemail.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CADGJaX_0+FTguWpNSpgVWYQP_7MhoO0D8=cp4XozSQgaZ40Odw@mail.gmail.com  
Backpatch-through: 18  

commit   : a6c0bf93031dac8701b8d6c1093230dc5caf190d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 10 Jul 2025 23:26:51 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 10 Jul 2025 23:26:51 +0200    

When sslkeylogfile has been set but the file fails to open in an  
otherwise successful connection, the log entry added to the conn  
object is never printed.  Instead print the error on stderr for  
increased visibility.  This is a debugging tool so using stderr  
for logging is appropriate.  Also while there, remove the umask  
call in the callback as it's not useful.  
  
Issues noted by Peter Eisentraut in post-commit review, backpatch  
down to 18 when support for sslkeylogfile was added  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/70450bee-cfaa-48ce-8980-fc7efcfebb03@eisentraut.org  
Backpatch-through: 18  

commit   : fb6c860bbd1f798dc637c8aa8972570b84f01ad2    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 10 Jul 2025 15:52:41 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 10 Jul 2025 15:52:41 -0500    

Commit a45c78e328 moved large object metadata from SECTION_PRE_DATA  
to SECTION_DATA but neglected to move PRIO_LARGE_OBJECT in  
dbObjectTypePriorities accordingly.  While this hasn't produced any  
known live bugs, it causes problems for a proposed patch that  
optimizes upgrades with many large objects.  Fixing the priority  
might also make the topological sort step marginally faster by  
reducing the number of ordering violations that have to be fixed.  
  
Reviewed-by: Nitin Motiani <nitinmotiani@google.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aBkQLSkx1zUJ-LwJ%40nathan  
Discussion: https://postgr.es/m/aG_5DBCjdDX6KAoD%40nathan  
Backpatch-through: 17  

commit   : b41c4308460500f2888aff9f844458915cae1798    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Jul 2025 12:23:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Jul 2025 12:23:04 +0900    

During the development cycle of v18, btree_gist has been bumped once to  
1.8 for the addition of translate_cmptype support functions (originally  
7406ab623fee, renamed in 32edf732e8dc).  1.9 has added sortsupport  
functions (e4309f73f698).  
  
There is no need for two version bumps in a module for a single major  
release of PostgreSQL.  This commit unifies both upgrades to a single  
SQL script, downgrading btree_gist to 1.8.  
  
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/13c61807-f702-4afe-9a8d-795e2fd40923@illuminatedcomputing.com  
Backpatch-through: 18  

commit   : 4eca711bc991954613261b7a314b1e8f5963815c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Jul 2025 10:01:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 10 Jul 2025 10:01:10 +0900    

This function can be used to retrieve the information about all the  
injection points attached to a cluster, providing coverage for  
InjectionPointList() introduced in 7b2eb72b1b8c.  
  
The original proposal turned around a system function, but that would  
not be backpatchable to stable branches.  It was also a bit weird to  
have a system function that fails depending on if the build allows  
injection points or not.  
  
Reviewed-by: Aleksander Alekseev <aleksander@timescale.com>  
Reviewed-by: Rahila Syed <rahilasyed90@gmail.com>  
Discussion: https://postgr.es/m/Z_xYkA21KyLEHvWR@paquier.xyz  

commit   : 48a23f6eae710d2c5c29f38e66d76e7919117e4d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Jul 2025 18:38:05 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Jul 2025 18:38:05 -0400    

The warning, visible when building with -O3 and a recent-ish gcc, is due to  
gcc not realizing that found is a byvalue type and therefore will never be  
interpreted as a varlena type.  
  
Discussion: https://postgr.es/m/3prdb6hkep3duglhsujrn52bkvnlkvhc54fzvph2emrsm4vodl@77yy6j4hkemb  
Discussion: https://postgr.es/m/20230316172818.x6375uvheom3ibt2%40awork3.anarazel.de  
Discussion: https://postgr.es/m/20240207203138.sknifhlppdtgtxnk%40awork3.anarazel.de  

commit   : d65eb5b1b84e9104144b6b07b526bc73e819d6d7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Jul 2025 18:38:05 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Jul 2025 18:38:05 -0400    

This macro can be used to avoid compiler warnings, particularly when using -O3  
and not using assertions, and to get the compiler to generate better code.  
  
A subsequent commit introduces a first user.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/3prdb6hkep3duglhsujrn52bkvnlkvhc54fzvph2emrsm4vodl@77yy6j4hkemb  
Discussion: https://postgr.es/m/20230316172818.x6375uvheom3ibt2%40awork3.anarazel.de  
Discussion: https://postgr.es/m/20240207203138.sknifhlppdtgtxnk%40awork3.anarazel.de  

commit   : 4df477153a6b9339acafbf4162fd8fa3f33e89d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Jul 2025 14:21:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Jul 2025 14:21:00 -0400    

Since b0635bfda, libpq uses dlopen() and related functions.  On some  
platforms these are not supplied by libc, but by a separate library  
libdl, in which case we need to make sure that that dependency is  
known to the linker.  Meson seems to take care of that automatically,  
but the Makefile didn't cater for it.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/1328170.1752082586@sss.pgh.pa.us  
Backpatch-through: 18  

commit   : 53cd0b71ee2e99c611a38ce58636a04d5dde4cc1    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 9 Jul 2025 08:45:34 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Wed, 9 Jul 2025 08:45:34 -0700    

These are libc-specific functions, so should require a locale_t rather  
than a pg_locale_t (which could use another provider).  
  
Discussion: https://postgr.es/m/a8666c391dfcabe79868d95f7160eac533ace718.camel%40j-davis.com  

commit   : 9dcc7641444f6a99269b446ee3a45a080b6ceea3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Jul 2025 11:26:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Jul 2025 11:26:53 -0400    

Increase the size of the "direct" histogram to 10K elements,  
so that we can precisely track loop times up to 10 microseconds.  
(Going further than that seems pretty uninteresting, even for  
very old and slow machines.)  
  
Relabel "Per loop time" as "Average loop time" for clarity.  
  
Pre-zero the histogram arrays to make sure that they are loaded  
into processor cache and any copy-on-write overhead has happened  
before we enter the timing loop.  Also use unlikely() to keep  
the compiler from thinking that the clock-went-backwards case  
is part of the hot loop.  Neither of these hacks made a lot of  
difference on my own machine, but they seem like they might help  
on some platforms.  
  
Discussion: https://postgr.es/m/be0339cc-1ae1-4892-9445-8e6d8995a44d@eisentraut.org  

commit   : 167ed8082f40ee1f3f4cd18cf02bd6d17df57dab    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 9 Jul 2025 09:17:56 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 9 Jul 2025 09:17:56 -0500    

This commit adds a new system view that provides information about  
entries in the dynamic shared memory (DSM) registry.  Specifically,  
it returns the name, type, and size of each entry.  Note that since  
we cannot discover the size of dynamic shared memory areas (DSAs)  
and hash tables backed by DSAs (dshashes) without first attaching  
to them, the size column is left as NULL for those.  
  
Bumps catversion.  
  
Author: Florents Tselai <florents.tselai@gmail.com>  
Reviewed-by: Sungwoo Chang <swchangdev@gmail.com>  
Discussion: https://postgr.es/m/4D445D3E-81C5-4135-95BB-D414204A0AB4%40gmail.com  

commit   : f5a987c0e5f6bbf0cc0420228dc57e7aae4d7e8f    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:34 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 9 Jul 2025 05:45:34 -0700    

Commit c273d9d8ce4 reworked tab-completion of COPY and \copy in psql  
and added support for completing options within WITH clauses. However,  
the same COPY options were suggested for both COPY TO and COPY FROM  
commands, even though some options are only valid for one or the  
other.  
  
This commit separates the COPY options for COPY FROM and COPY TO  
commands to provide more accurate auto-completion suggestions.  
  
Back-patch to v14 where tab-completion for COPY and \copy options  
within WITH clauses was first supported.  
  
Author: Atsushi Torikoshi <torikoshia@oss.nttdata.com>  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/079e7a2c801f252ae8d522b772790ed7@oss.nttdata.com  
Backpatch-through: 14  

commit   : 86c539c5af14f42ee274c03b5eeb3c97ee5b1ec1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 9 Jul 2025 20:33:50 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 9 Jul 2025 20:33:50 +0900    

This commit enhances psql's tab completion to support TO/FROM  
after "GRANT/REVOKE ... ON LARGE OBJECT ...". Additionally,  
since "ALTER DEFAULT PRIVILEGES" now supports large objects,  
tab completion is also updated for "GRANT/REVOKE ... ON LARGE OBJECTS"  
with TO/FROM.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/ade0ab29-777f-47f6-9d0d-1af67728a86e@oss.nttdata.com  

commit   : ed26c4e25a444fcdd8a9120d4fe4b5a08d2b262b    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 9 Jul 2025 14:20:22 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 9 Jul 2025 14:20:22 +0700    

The cpluspluscheck script wraps our headers in `extern "C"`. This  
disables name mangling, which is necessary for the C++ templates  
in system ICU headers. cpluspluscheck thus fails when the build is  
configured with ICU (the default). CI worked around this by disabling  
ICU, but let's make it work so others can run the script.  
  
We can specify we only want the C APIs by defining U_SHOW_CPLUSPLUS_API  
to be 0 in pg_locale.h. Extensions that want the C++ APIs can include  
ICU headers separately before including PostgreSQL headers.  
  
ICU documentation:  
https://github.com/unicode-org/icu/blob/main/docs/processes/release/tasks/healthy-code.md#test-icu4c-headers  
  
Suggested-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20220323002024.f2g6tivduzrktgfa%40alap3.anarazel.de  
Discussion: https://postgr.es/m/CANWCAZbgiaz1_0-F4SD%2B%3D-e9onwAnQdBGJbhg94EqUu4Gb7WyA%40mail.gmail.com  

commit   : df286a5b830ae8cc8aac4bd6c999ea4991f0b092    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jul 2025 15:46:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jul 2025 15:46:31 +0900    

This test corresponds to the case of a "service" defined in a service  
file, that libpq is not able to support in parseServiceFile().  
  
This has come up during the review of a patch to add more features in  
this area, useful on its own.  Piece extracted from a larger patch by  
the same author.  
  
Author: Ryo Kanbayashi <kanbayashi.dev@gmail.com>  
Discussion: https://postgr.es/m/Zz2AE7NKKLIZTtEh@paquier.xyz  

commit   : 24f608625f9ab5632897d21e0dc27ebfea5d3661    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 9 Jul 2025 09:44:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 9 Jul 2025 09:44:27 +0530    

Clarified that the failover steps apply to a specific PostgreSQL subscriber  
and added guidance for verifying replication slot synchronization during  
planned failover. Additionally, corrected the standby query to avoid false  
positives by checking invalidation_reason IS NULL instead of conflicting.  
  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Author: Shveta Malik <shveta.malik@gmail.com>  
Backpatch-through: 17, where it was introduced  
Discussion: https://www.postgresql.org/message-id/CAExHW5uiZ-fF159=jwBwPMbjZeZDtmcTbN+hd4mrURLCg2uzJg@mail.gmail.com  

commit   : fef6da9e9c8790fa915942af2ada190c33fcf98c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jul 2025 12:46:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jul 2025 12:46:13 +0900    

This routine has been introduced as a shortcut to be able to retrieve a  
service name from an active connection, for psql.  Per discussion, and  
as it is only used by psql, let's remove it to not clutter the libpq API  
more than necessary.  
  
The logic in psql is replaced by lookups of PQconninfoOption for the  
active connection, instead, updated each time the variables are synced  
by psql, the prompt shortcut relying on the variable synced.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20250706161319.c1.nmisch@google.com  
Backpatch-through: 18  

commit   : 93001888d85c21a5b9ab1fe8dabfecb673fc007c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 17:00:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 17:00:34 -0400    

What we want in these places is "xmlChar *volatile ptr",  
not "volatile xmlChar *ptr".  The former means that the  
pointer variable itself needs to be treated as volatile,  
while the latter says that what it points to is volatile.  
Since the point here is to ensure that the pointer variables  
don't go crazy after a longjmp, it's the former semantics  
that we need.  The misplacement of "volatile" also led  
to needing to cast away volatile in some places.  
  
Also fix a number of places where variables that are assigned to  
within a PG_TRY and then used after it were not initialized or  
not marked as volatile.  (A few buildfarm members were issuing  
"may be used uninitialized" warnings about some of these variables,  
which is what drew my attention to this area.)  In most cases  
these variables were being set as the last step within the PG_TRY  
block, which might mean that we could get away without the "volatile"  
marking.  But doing that seems unsafe and is definitely not per our  
coding conventions.  
  
These problems seem to have come in with 732061150, so no need  
for back-patch.  

commit   : e03c95287764158941d317972a332565729b6af2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 12:50:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 12:50:19 -0400    

xmltotext_with_options() did not consider the possibility that  
pg_xml_init() could fail --- most likely due to OOM.  If that  
happened, the already-parsed xmlDoc structure would be leaked.  
Oversight in commit 483bdb2af.  
  
Bug: #18981  
Author: Dmitry Kovalenko <d.kovalenko@postgrespro.ru>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18981-9bc3c80f107ae925@postgresql.org  
Backpatch-through: 16  

commit   : aa39b4e35ac65d4c1672ba2a29707008a754ddf5    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 8 Jul 2025 18:37:55 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 8 Jul 2025 18:37:55 +0200    

Also, revert Unicode linestyle to ASCII.  
  
Reported-by: Japin Li <japinli@hotmail.com>  
Discussion: https://postgr.es/m/ME0P300MB04453A39931F95805C4205A8B64FA@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : 0b096e379e6f9bd49d38020d880a7da337e570ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 11:23:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2025 11:23:15 -0400    

Most of our platforms have better-than-microsecond timing resolution,  
so the original definition of this program is getting less and less  
useful.  Make it report nanoseconds not microseconds.  Also, add a  
second output table that reports the exact observed timing durations,  
up to a limit of 1024 ns; and be sure to report the largest observed  
duration.  
  
The documentation for this program included a lot of system-specific  
details that now seem largely obsolete.  Move all that text to the  
PG wiki, where perhaps it will be easier to maintain and update.  
  
Also, improve the TAP test so that it actually runs a short standard  
run, allowing most of the code to be exercised; its coverage before  
was abysmal.  
  
Author: Hannu Krosing <hannuk@google.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/be0339cc-1ae1-4892-9445-8e6d8995a44d@eisentraut.org  

commit   : a27893df45ec5d8c657899202e9cf0b9a816fe2f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jul 2025 13:48:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jul 2025 13:48:49 +0900    

Per buildfarm member culicidae, the query checking for stats reported by  
the WAL summarizer related to WAL reads is proving to be unstable.  
  
Instead of a one-time query, this commit replaces the logic with a  
polling query checking for the WAL read stats, making the test more  
reliable on machines that could be slow with the stats reports.  
  
This test has been introduced in f4694e0f35b2, so backpatch down to v18.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/f35ba3db-fca7-4693-bc35-6db64488e4b1@gmail.com  
Backpatch-through: 18  

commit   : f54af9f2679d5987b4680e742ac9bd585260e620    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Jul 2025 21:03:16 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Jul 2025 21:03:16 -0400    

By default io_uring creates a shared memory mapping for each io_uring  
instance, leading to a large number of memory mappings. Unfortunately a large  
number of memory mappings slows things down, backend exit is particularly  
affected.  To address that, newer kernels (6.5) support using user-provided  
memory for the memory. By putting the relevant memory into shared memory we  
don't need any additional mappings.  
  
On a system with a new enough kernel and liburing, there is no discernible  
overhead when doing a pgbench -S -C anymore.  
  
Reported-by: MARK CALLAGHAN <mdcallag@gmail.com>  
Reviewed-by: "Burd, Greg" <greg@burd.me>  
Reviewed-by: Jim Nasby <jnasby@upgrade.com>  
Discussion: https://postgr.es/m/CAFbpF8OA44_UG+RYJcWH9WjF7E3GA6gka3gvH6nsrSnEe9H0NA@mail.gmail.com  
Backpatch-through: 18  

commit   : 55a780e9476a753354a6db887e92125c7886ca6d    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Tue, 8 Jul 2025 10:21:44 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Tue, 8 Jul 2025 10:21:44 +0900    

For an ordered Append or MergeAppend, we need to inject an explicit  
sort into any subpath that is not already well enough ordered.  
Currently, only explicit full sorts are considered; incremental sorts  
are not yet taken into account.  
  
In this patch, for subpaths of an ordered Append or MergeAppend, we  
choose to use explicit incremental sort if it is enabled and there are  
presorted keys.  
  
The rationale is based on the assumption that incremental sort is  
always faster than full sort when there are presorted keys, a premise  
that has been applied in various parts of the code.  In addition, the  
current cost model tends to favor incremental sort as being cheaper  
than full sort in the presence of presorted keys, making it reasonable  
not to consider full sort in such cases.  
  
No backpatch as this could result in plan changes.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Andrei Lepikhov <lepihov@gmail.com>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs4_V7a2enTR+T3pOY_YZ-FU8ZsFYym2swOz4jNMqmSgyuw@mail.gmail.com  

commit   : 7376e6085468054328a66e8c10c007bdaaf88f91    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 7 Jul 2025 13:41:55 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Mon, 7 Jul 2025 13:41:55 -0700    

In b0635bfda, I added an early header check to the Meson OAuth support,  
which was intended to duplicate the later checks for  
HAVE_SYS_[EVENT|EPOLL]_H. However, I implemented the new test via  
check_header() -- which tries to compile -- rather than has_header(),  
which just looks for the file's existence.  
  
The distinction matters on OpenBSD, where <sys/event.h> can't be  
compiled without including prerequisite headers, so -Dlibcurl=enabled  
failed on that platform. Switch to has_header() to fix this.  
  
Note that reviewers expressed concern about the difference between our  
Autoconf feature tests (which compile headers) and our Meson feature  
tests (which do not). I'm not opposed to aligning the two, but I want to  
avoid making bigger changes as part of this fix.  
  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/flat/CAOYmi+kdR218ke2zu74oTJvzYJcqV1MN5=mGAPqZQuc79HMSVA@mail.gmail.com  
Backpatch-through: 18  

commit   : 3adcf9fbd8ba9c07edb3ef5168a259fb12e6e3a6    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 7 Jul 2025 22:38:12 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 7 Jul 2025 22:38:12 +0200    

Commit 2633dae2e487 added some zero padding to various LSNs output  
routines so that the low word is always 8 hex digits long, for easy  
human consumption.  This included the pg_lsn datatype, which breaks the  
pg_upgrade test when it compares the pg_dump output of an older version.  
Silence this problem by setting the pg_lsn columns to NULL before the  
upgrade.  
  
Discussion: https://postgr.es/m/202507071504.xm2r26u7lmzr@alvherre.pgsql  

commit   : 87b05fdc73e84d6b0bf0e03efad95c99c203cd1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jul 2025 14:33:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jul 2025 14:33:20 -0400    

pl/pgsql's notion of an "expression" is very broad, encompassing  
any SQL SELECT query that returns a single column and no more than  
one row.  So there are cases, for example evaluation of an aggregate  
function, where the query involves significant work and it'd be useful  
to run it with parallel workers.  This used to be possible, but  
commits 3eea7a0c9 et al unintentionally disabled it.  
  
The simplest fix is to make exec_eval_expr() pass maxtuples = 0  
rather than 2 to exec_run_select().  This avoids the new rule that  
we will never use parallelism when a nonzero "count" limit is passed  
to ExecutorRun().  (Note that the pre-3eea7a0c9 behavior was indeed  
unsafe, so reverting that rule is not in the cards.)  The reason  
for passing 2 before was that exec_eval_expr() will throw an error  
if it gets more than one returned row, so we figured that as soon  
as we have two rows we know that will happen and we might as well  
stop running the query.  That choice was cost-free when it was made;  
but disabling parallelism is far from cost-free, so now passing 2  
amounts to optimizing a failure case at the expense of useful cases.  
An expression query that can return more than one row is certainly  
broken.  People might now need to wait a bit longer to discover such  
breakage; but hopefully few will use enormously expensive cases as  
their first test of new pl/pgsql logic.  
  
Author: Dipesh Dhameliya <dipeshdhameliya125@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CABgZEgdfbnq9t6xXJnmXbChNTcWFjeM_6nuig41tm327gYi2ig@mail.gmail.com  
Backpatch-through: 13  

commit   : c61678551699610d658edb0ae838d2541688caba    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 7 Jul 2025 16:49:19 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 7 Jul 2025 16:49:19 +0200    

Functions to bootstrap and zero pages in various SLRU callers were  
fairly duplicative.  We can slash almost two hundred lines with a couple  
of simple helpers:  
  
 - SimpleLruZeroAndWritePage: Does the equivalent of SimpleLruZeroPage  
   followed by flushing the page to disk  
 - XLogSimpleInsertInt64: Does a XLogBeginInsert followed by XLogInsert  
   of a trivial record whose data is just an int64.  
  
Author: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>  
Reviewed by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed by: Aleksander Alekseev <aleksander@timescale.com>  
Discussion: https://www.postgresql.org/message-id/flat/97820ce8-a1cd-407f-a02b-47368fadb14b%40tantorlabs.com  

commit   : 2633dae2e4876a9b7cb90ba025e930a553e5107f    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 7 Jul 2025 13:57:43 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 7 Jul 2025 13:57:43 +0200    

This commit standardizes the output format for LSNs to ensure consistent  
representation across various tools and messages.  Previously, LSNs were  
inconsistently printed as `%X/%X` in some contexts, while others used  
zero-padding.  This often led to confusion when comparing.  
  
To address this, the LSN format is now uniformly set to `%X/%08X`,  
ensuring the lower 32-bit part is always zero-padded to eight  
hexadecimal digits.  
  
Author: Japin Li <japinli@hotmail.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/ME0P300MB0445CA53CA0E4B8C1879AF84B641A@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : 62a17a92833d1eaa60d8ea372663290942a1e8eb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 12:50:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 12:50:40 +0900    

This refactoring is a follow-up of the work done in 5a1dfde8334b, that  
has switched 2PC file names to use FullTransactionIds when written on  
disk.  This will help with the integration of a follow-up solution  
related to the handling of two-phase files during recovery, to address  
older defects while reading these from disk after a crash.  
  
This change is useful in itself as it reduces the need to build the  
file names from epoch numbers and TransactionIds, because we can use  
directly FullTransactionIds from which the 2PC file names are guessed.  
So this avoids a lot of back-and-forth between the FullTransactionIds  
retrieved from the file names and how these are passed around in the  
internal 2PC logic.  
  
Note that the core of the change is the use of a FullTransactionId  
instead of a TransactionId in GlobalTransactionData, that tracks 2PC  
file information in shared memory.  The change in TwoPhaseCallback makes  
this commit unfit for stable branches.  
  
Noah has contributed a good chunk of this patch.  I have spent some time  
on it as well while working on the issues with two-phase state files and  
recovery.  
  
Author: Noah Misch <noah@leadboat.com>  
Co-Authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/Z5sd5O9JO7NYNK-C@paquier.xyz  
Discussion: https://postgr.es/m/20250116205254.65.nmisch@google.com  

commit   : 8aa54aa7eefbf738999ae855d9192bc57756201e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:53:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jul 2025 08:53:57 +0900    

libxml2 has deprecated the members of xmlBuffer, and it is recommended  
to access them with dedicated routines.  We have only one case in the  
tree where this shows an impact: xml2/xpath.c where "content" was  
getting directly accessed.  The rest of the code looked fine, checking  
the PostgreSQL code with libxml2 close to the top of its "2.14" branch.  
  
xmlBufferContent() exists since year 2000 based on a check of the  
upstream libxml2 tree, so let's switch to it.  
  
Like 400928b83bd2, backpatch all the way down as this can have an impact  
on all the branches already released once newer versions of libxml2 get  
more popular.  
  
Reported-by: Walid Ibrahim <walidib@amazon.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aGdSdcR4QTjEHX6s@paquier.xyz  
Backpatch-through: 13  

commit   : 21c9756db6458f859e6579a6754c78154321cb39    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 6 Jul 2025 17:15:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Sun, 6 Jul 2025 17:15:00 +0900    

When estimating the cost/size of a pre-sorted path for a given upper  
relation using local stats, this function dereferences the passed-in  
PgFdwPathExtraData pointer without checking that it is not NULL.  But  
that is not a bug as the pointer is guaranteed to be non-NULL in that  
case; to avoid confusion, add an Assert to ensure that it is not NULL  
before dereferencing it.  
  
Reported-by: Ranier Vilela <ranier.vf@gmail.com>  
Author: Etsuro Fujita <etsuro.fujita@gmail.com>  
Reviewed-by: Ranier Vilela <ranier.vf@gmail.com>  
Discussion: https://postgr.es/m/CAEudQArgiALbV1akQpeZOgim7XP05n%3DbDP1%3DTcOYLA43nRX_vA%40mail.gmail.com  

commit   : 144ad723a4484927266a316d1c9550d56745ff67    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 21:30:05 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 21:30:05 +0200    

That was invented in 9.5, and pg_upgrade claims to support back to 9.0.  
But we don't need that with a simple query change, tested by Tom Lane.  
  
Discussion: https://postgr.es/m/202507041645.afjl5rssvrgu@alvherre.pgsql  

commit   : 90a85fce5e9b9ea63ec7e1b3001e0f39d4c8b7d4    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 18:31:35 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 18:31:35 +0200    

Minor oversight in 347758b12063  

commit   : f295494d338c452617f966d4d1f13a726cd72661    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 18:05:43 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 4 Jul 2025 18:05:43 +0200    

With tables defined like this,  
  CREATE TABLE ip (id int PRIMARY KEY);  
  CREATE TABLE ic (id int) INHERITS (ip);  
  ALTER TABLE ic ALTER id DROP NOT NULL;  
  
pg_upgrade fails during the schema restore phase due to this error:  
  ERROR: column "id" in child table must be marked NOT NULL  
  
This can only be fixed by marking the child column as NOT NULL before  
the upgrade, which could take an arbitrary amount of time (because ic's  
data must be scanned).  Have pg_upgrade's check mode warn if that  
condition is found, so that users know what to adjust before running the  
upgrade for real.  
  
Author: Ali Akbar <the.apaan@gmail.com>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CACQjQLoMsE+1pyLe98pi0KvPG2jQQ94LWJ+PTiLgVRK4B=i_jg@mail.gmail.com  

commit   : d64d68fddf9802dea4cc5be8a491937c3aefefa0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Jul 2025 23:25:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Jul 2025 23:25:40 +0900    

Commit d70b17636dd introduced the IndexCheckableCallback typedef for  
a callback function, but it was never used. This commit removes  
the unused typedef to clean up dead code.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/e1ea4e14-3b21-4e01-a5f2-0686883265df@oss.nttdata.com  

commit   : 5a6c39b6df3313e5c2d3aed714a56f5a5c6be3f2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:09:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jul 2025 15:09:24 +0900    

Attempting to use commit timestamps during bootstrapping leads to an  
assertion failure, that can be reached for example with an initdb -c  
that enables track_commit_timestamp.  It makes little sense to register  
a commit timestamp for a BootstrapTransactionId, so let's disable the  
activation of the module in this case.  
  
This problem has been independently reported once by each author of this  
commit.  Each author has proposed basically the same patch, relying on  
IsBootstrapProcessingMode() to skip the use of commit_ts during  
bootstrap.  The test addition is a suggestion by me, and is applied down  
to v16.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Author: Andy Fan <zhihuifan1213@163.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/OSCPR01MB14966FF9E4C4145F37B937E52F5102@OSCPR01MB14966.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/87plejmnpy.fsf@163.com  
Backpatch-through: 13  

commit   : 78ebda66bf2683d42b853660757aaf16268ee3b7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Jul 2025 09:03:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 4 Jul 2025 09:03:58 +0900    

Previously, truncating a temporary relation required scanning the entire  
local buffer pool once per relation fork to invalidate buffers. This could  
be slow, especially with a large local buffers, as the scan was repeated  
multiple times.  
  
A similar issue with regular tables (shared buffers) was addressed in  
commit 6d05086c0a7 by scanning the buffer pool only once for all forks.  
  
This commit applies the same optimization to temporary relations,  
improving truncation performance.  
  
Author: Daniil Davydov <3danissimo@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>  
Reviewed-by: Maxim Orlov <orlovmg@gmail.com>  
Discussion: https://postgr.es/m/CAJDiXggNqsJOH7C5co4jA8nDk8vw-=sokyh5s1_TENWnC6Ofcg@mail.gmail.com  

commit   : 931766aaec58b2ce09c82203456877e0b05e1271    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 17:39:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 17:39:53 -0400    

If, after removal of useless null-constant arguments, a CoalesceExpr  
has exactly one remaining argument, we can just take that argument as  
the result, without bothering to wrap a new CoalesceExpr around it.  
This isn't likely to produce any great improvement in runtime per se,  
but it can lead to better plans since the planner no longer has to  
treat the expression as non-strict.  
  
However, there were a few regression test cases that intentionally  
wrote COALESCE(x) as a shorthand way of creating a non-strict  
subexpression.  To avoid ruining the intent of those tests, write  
COALESCE(x,x) instead.  (If anyone ever proposes de-duplicating  
COALESCE arguments, we'll need another iteration of this arms race.  
But it seems pretty unlikely that such an optimization would be  
worthwhile.)  
  
Author: Maksim Milyutin <maksim.milyutin@tantorlabs.ru>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/8e8573c3-1411-448d-877e-53258b7b2be0@tantorlabs.ru  

commit   : fc896821c4448038c5cc678c1aff7349ee850b23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 16:30:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 16:30:38 -0400    

Using the just-added infrastructure, extend btree_gin to support  
cross-type operators in its other opclasses.  All of the cross-type  
comparison operators supported by the core btree opclasses for  
these datatypes are now available for btree_gin indexes as well.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Discussion: https://postgr.es/m/262624.1738460652@sss.pgh.pa.us  

commit   : e2b64fcef35f70f96fa92db56fbfa9ac2da136c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 16:24:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 16:24:31 -0400    

Extend the infrastructure in btree_gin.c to permit cross-type  
operators, and add the code to support them for the int2, int4,  
and int8 opclasses.  (To keep this patch digestible, I left  
the other datatypes for a separate patch.)  This improves the  
usability of btree_gin indexes by allowing them to support the  
same set of queries that a regular btree index does.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Discussion: https://postgr.es/m/262624.1738460652@sss.pgh.pa.us  

commit   : 0059bbe1ecaa5f7f19a8b3aae059f352c02e1d88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 16:17:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 16:17:08 -0400    

Previous commits invented timestamp2timestamptz_opt_overflow,  
date2timestamp_opt_overflow, and date2timestamptz_opt_overflow  
functions to perform non-error-throwing conversions between  
datetime types.  This patch completes the set by adding  
timestamp2date_opt_overflow, timestamptz2date_opt_overflow,  
and timestamptz2timestamp_opt_overflow.  
  
In addition, adjust timestamp2timestamptz_opt_overflow so that it  
doesn't throw error if timestamp2tm fails, but treats that as an  
overflow case.  The situation probably can't arise except with an  
invalid timestamp value, and I can't think of a way that that would  
happen except data corruption.  However, it's pretty silly to have a  
function whose entire reason for existence is to not throw errors for  
out-of-range inputs nonetheless throw an error for out-of-range input.  
  
The new APIs are not used in this patch, but will be needed in  
upcoming btree_gin changes.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Discussion: https://postgr.es/m/262624.1738460652@sss.pgh.pa.us  

commit   : a10f21e6ce549705f194b8fdb28e685403e7579d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 13:46:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2025 13:46:07 -0400    

Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup  
contains three calls to ATPostAlterTypeParse, and the other two  
also need protection against passing a relid that we don't yet  
have lock on.  Add similar logic to those code paths, and add  
some test cases demonstrating the need for it.  
  
In v18 and master, the test cases demonstrate that there's a  
behavioral discrepancy between stored generated columns and virtual  
generated columns: we disallow changing the expression of a stored  
column if it's used in any composite-type columns, but not that of  
a virtual column.  Since the expression isn't actually relevant to  
either sort of composite-type usage, this prohibition seems  
unnecessary; but changing it is a matter for separate discussion.  
For now we are just documenting the existing behavior.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Author: jian he <jian.universality@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tNsv9pWU9g@mail.gmail.com  
Backpatch-through: 13  

commit   : a604affaded028b6bfba024127931289c2b756c2    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 16:54:36 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 16:54:36 +0200    

The command is: ALTER TABLE x ADD [CONSTRAINT y] NOT NULL z  
  
This syntax was added in 18, but I got pushback for getting commit  
dbf42b84ac7b in 18 (also tab-completion for new syntax) after the  
feature freeze, so I'll put this in master only for now.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Discussion: https://postgr.es/m/d4f14c6b-086b-463c-b15f-01c7c9728eab@oss.nttdata.com  
Discussion: https://postgr.es/m/202505111448.bwbfomrymq4b@alvherre.pgsql  

commit   : c84698ceaea8a08b1d11d527ce9530a98b156799    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 23:39:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 23:39:45 +0900    

Commit 08aa89b3262 removed the COMMIT_TS_SETTS WAL record,  
leaving xl_commit_ts_set and SizeOfCommitTsSet unused. However,  
it missed removing these definitions. This commit cleans up  
the leftover code.  
  
Since this is a cleanup rather than a bug fix, it is applied only to  
the master branch.  
  
Author: Andy Fan <zhihuifan1213@163.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/87ecuzmkqf.fsf@163.com  

commit   : 81a2625eb2e4608ba6ca41b2bf548dce8d81ced7    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 16:23:22 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 16:23:22 +0200    

I messed this up in commit 87251e114967.  
  
Per buildfarm member alabio, via Daniel Gustafsson.  
  
Discussion: https://postgr.es/m/B94D82D1-7AF4-4412-AC02-82EAA6154957@yesql.se  

commit   : ff3007c66dc6213fcdaea9a996865bbd943e3e82    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 23:07:23 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 23:07:23 +0900    

The documentation for pg_replication_slots previously mentioned only  
max_slot_wal_keep_size as a condition under which the wal_status column  
could show unreserved or lost. However, since commit be87200,  
replication slots can also be invalidated due to horizon or wal_level,  
and since commit ac0e33136ab, idle_replication_slot_timeout can also  
trigger this state.  
  
This commit updates the description of the wal_status column to  
reflect that max_slot_wal_keep_size is not the only cause of the lost state.  
  
Back-patched to v16, where the additional invalidation cases were introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com  
Backpatch-through: 16  

commit   : 647cffd2f3210818f3882a1ea40cfbe0a4ea8fd7    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 11:46:12 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 11:46:12 +0200    

This was previously harmless, but now that we create pg_constraint rows  
for those, duplicates are not welcome anymore.  
  
Backpatch to 18.  
  
Co-authored-by: jian he <jian.universality@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CACJufxFSC0mcQ82bSk58sO-WJY4P-o4N6RD2M0D=DD_u_6EzdQ@mail.gmail.com  

commit   : 87251e114967d668c8f90ed9fb8c8a8834c2d288    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 11:25:39 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 3 Jul 2025 11:25:39 +0200    

If certain constraint characteristic clauses (NO INHERIT, NOT VALID, NOT  
ENFORCED) are given to CREATE CONSTRAINT TRIGGER, the resulting error  
message is  
  ERROR:  TRIGGER constraints cannot be marked NO INHERIT  
which is a bit silly, because these aren't "constraints of type  
TRIGGER".  Hardcode a better error message to prevent it.  This is a  
cosmetic fix for quite a fringe problem with no known complaints from  
users, so no backpatch.  
  
While at it, silently accept ENFORCED if given.  
  
Author: Amul Sul <sulamul@gmail.com>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAAJ_b97hd-jMTS7AjgU6TDBCzDx_KyuKxG+K-DtYmOieg+giyQ@mail.gmail.com  
Discussion: https://postgr.es/m/CACJufxHSp2puxP=q8ZtUGL1F+heapnzqFBZy5ZNGUjUgwjBqTQ@mail.gmail.com  

commit   : 8ec04c8577a1aa3aac4b77b2747dde30c8f9c8c6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jul 2025 16:34:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jul 2025 16:34:28 +0900    

AlterDomainStmt.subtype used characters for its subtypes of commands,  
SET|DROP DEFAULT|NOT NULL and ADD|DROP|VALIDATE CONSTRAINT, which were  
hardcoded in a couple of places of the code.  The code is improved by  
using an enum instead, with the same character values as the original  
code.  
  
Note that the field was documented in parsenodes.h and that it forgot to  
mention 'V' (VALIDATE CONSTRAINT).  
  
Author: Quan Zongliang <quanzongliang@yeah.net>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/41ff310b-16bd-44b9-a3ef-97e20f14b709@yeah.net  

commit   : 170673a22f28bd6a1d3fa56e23cd74dcbcb60c17    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 16:03:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 16:03:19 +0900    

The documentation previously stated that the wal_status column is NULL  
if restart_lsn is NULL in the pg_replication_slots view. This is incorrect,  
and wal_status can be "lost" even when restart_lsn is NULL.  
  
This commit removes the incorrect description.  
  
Back-patched to all supported versions.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>  
Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701d89@oss.nttdata.com  
Backpatch-through: 13  

commit   : bc2f348e87c02de63647dbe290d64ff088880dbe    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 15:27:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Jul 2025 15:27:26 +0900    

The COPY FROM command now accepts a non-negative integer for the HEADER option,  
allowing multiple header lines to be skipped. This is useful when the input  
contains multi-line headers that should be ignored during data import.  
  
Author: Shinya Kato <shinya11.kato@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/CAOzEurRPxfzbxqeOPF_AGnAUOYf=Wk0we+1LQomPNUNtyZGBZw@mail.gmail.com  

commit   : fd7d7b719137b5c427681a50c0a0ac2d745b68bd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jul 2025 11:14:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jul 2025 11:14:20 +0900    

Currently check_recovery_target_timeline() converts any value that is  
not "current", "latest", or a valid integer to 0.  So, for example, the  
following configuration added to postgresql.conf followed by a startup:  
recovery_target_timeline = 'bogus'  
recovery_target_timeline = '9999999999'  
  
...  results in the following error patterns:  
FATAL:  22023: recovery target timeline 0 does not exist  
FATAL:  22023: recovery target timeline 1410065407 does not exist  
  
This is confusing, because the server does not reflect the intention of  
the user, and just reports incorrect data unrelated to the GUC.  
  
The origin of the problem is that we do not perform a range check in the  
GUC value passed-in for recovery_target_timeline.  This commit improves  
the situation by using strtou64() and by providing stricter range  
checks.  Some test cases are added for the cases of an incorrect, an  
upper-bound and a lower-bound timeline value, checking the sanity of the  
reports based on the contents of the server logs.  
  
Author: David Steele <david@pgmasters.net>  
Discussion: https://postgr.es/m/e5d472c7-e9be-4710-8dc4-ebe721b62cea@pgbackrest.org  

commit   : 0da29e4cb161f78a5ef534b3fb4467756a422e25    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 3 Jul 2025 10:57:26 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 3 Jul 2025 10:57:26 +0900    

Currently, we do not support Memoize for SEMI and ANTI joins because  
nested loop SEMI/ANTI joins do not scan the inner relation to  
completion, which prevents Memoize from marking the cache entry as  
complete.  One might argue that we could mark the cache entry as  
complete after fetching the first inner tuple, but that would not be  
safe: if the first inner tuple and the current outer tuple do not  
satisfy the join clauses, a second inner tuple matching the parameters  
would find the cache entry already marked as complete.  
  
However, if the inner side is provably unique, this issue doesn't  
arise, since there would be no second matching tuple.  That said, this  
doesn't help in the case of SEMI joins, because a SEMI join with a  
provably unique inner side would already have been reduced to an inner  
join by reduce_unique_semijoins.  
  
Therefore, in this patch, we check whether the inner relation is  
provably unique for ANTI joins and enable the use of Memoize in such  
cases.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com>  
Reviewed-by: Andrei Lepikhov <lepihov@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs48FdLiMNrmJL-g6mDvoQVt0yNyJAqMkv4e2Pk-5GKCZLA@mail.gmail.com  

commit   : 7b2eb72b1b8ce4279e42848a3978e781ae239355    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jul 2025 08:41:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jul 2025 08:41:25 +0900    

This routine has come as a useful piece to be able to know the list of  
injection points currently attached in a system.  One area would be to  
use it in a set-returning function, or just let out-of-core code play  
with it.  
  
This hides the internals of the shared memory array lookup holding the  
information about the injection points (point name, library and function  
name), allocating the result in a palloc'd List consumable by the  
caller.  
  
Reviewed-by: Jeff Davis <pgsql@j-davis.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Rahila Syed <rahilasyed90@gmail.com>  
Discussion: https://postgr.es/m/Z_xYkA21KyLEHvWR@paquier.xyz  
Discussion: https://postgr.es/m/aBG2rPwl3GE7m1-Q@paquier.xyz  

commit   : fe05430ace8e0b3c945cf581564458a5983a07b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2025 15:47:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2025 15:47:59 -0400    

PQcancelCreate failed to copy struct pg_conn_host's "type" field,  
instead leaving it zero (a/k/a CHT_HOST_NAME).  This seemingly  
has no great ill effects if it should have been CHT_UNIX_SOCKET  
instead, but if it should have been CHT_HOST_ADDRESS then a  
null-pointer dereference will occur when the cancelConn is used.  
  
Bug: #18974  
Reported-by: Maxim Boguk <maxim.boguk@gmail.com>  
Author: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18974-575f02b2168b36b3@postgresql.org  
Backpatch-through: 17  

commit   : 0c2b7174c362d3092eb7eabf0117a8d47c64ce0e    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Jul 2025 13:26:33 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Jul 2025 13:26:33 -0500    

In commit fe07100e82, I renamed a couple of functions in  
test_dsm_registry to make it clear what they are testing.  However,  
the buildfarm's cross-version upgrade tests run pg_upgrade with the  
test modules installed, so this caused errors like:  
  
    ERROR:  could not find function "get_val_in_shmem" in file ".../test_dsm_registry.so"  
  
To fix, revert those renames.  I could probably get away with only  
un-renaming the C symbols, but I figured I'd avoid introducing  
function name mismatches.  Also, AFAICT the buildfarm's  
cross-version upgrade tests do not run the test module tests  
post-upgrade, else we'll need to properly version the extension.  
  
Per buildfarm member crake.  
  
Discussion: https://postgr.es/m/aGVuYUNW23tStUYs%40nathan  

commit   : bb109382ef403a4827caacf2978e82f46593600c    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Jul 2025 12:32:19 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Jul 2025 12:32:19 -0500    

A few places were open-coding it instead of using this handy macro.  
  
Author: Junwang Zhao <zhjwpku@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/CAEG8a3LjTGJcOcxQx-SUOGoxstG4XuCWLH0ATJKKt_aBTE5K8w%40mail.gmail.com  

commit   : fe07100e82b096d3c848cace790d4b4daf0c4131    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Jul 2025 11:50:52 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Wed, 2 Jul 2025 11:50:52 -0500    

Presently, the dynamic shared memory (DSM) registry only provides  
GetNamedDSMSegment(), which allocates a fixed-size segment.  To use  
the DSM registry for more sophisticated things like dynamic shared  
memory areas (DSAs) or a hash table backed by a DSA (dshash), users  
need to create a DSM segment that stores various handles and LWLock  
tranche IDs and to write fairly complicated initialization code.  
Furthermore, there is likely little variation in this  
initialization code between libraries.  
  
This commit introduces functions that simplify allocating a DSA or  
dshash within the DSM registry.  These functions are very similar  
to GetNamedDSMSegment().  Notable differences include the lack of  
an initialization callback parameter and the prohibition of calling  
the functions more than once for a given entry in each backend  
(which should be trivially avoidable in most circumstances).  While  
at it, this commit bumps the maximum DSM registry entry name length  
from 63 bytes to 127 bytes.  
  
Also note that even though one could presumably detach/destroy the  
DSAs and dshashes created in the registry, such use-cases are not  
yet well-supported, if for no other reason than the associated DSM  
registry entries cannot be removed.  Adding such support is left as  
a future exercise.  
  
The test_dsm_registry test module contains tests for the new  
functions and also serves as a complete usage example.  
  
Reviewed-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Florents Tselai <florents.tselai@gmail.com>  
Reviewed-by: Rahila Syed <rahilasyed90@gmail.com>  
Discussion: https://postgr.es/m/aEC8HGy2tRQjZg_8%40nathan  

commit   : 9ca30a0b04d751c58d4efa0a2b3073cb285b1bd2    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 2 Jul 2025 12:36:35 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 2 Jul 2025 12:36:35 -0400    

Restore nbtree preprocessing comments describing how we mark nbtree row  
compare members required to how they were prior to 2016 bugfix commit  
a298a1e0.  
  
Oversight in commit bd3f59fd, which made nbtree preprocessing revert to  
the original 2006 rules, but neglected to revert these comments.  
  
Backpatch-through: 18  

commit   : 7374b3a53635cb031b4d1bedfd80531409f54693    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2025 11:34:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2025 11:34:40 -0400    

The array-based variant of width_bucket() has always accepted NaN  
inputs, treating them as equal but larger than any non-NaN,  
as we do in ordinary comparisons.  But up to now, the four-argument  
variants threw errors for a NaN operand.  This is inconsistent  
and unnecessary, since we can perfectly well regard NaN as falling  
after the last bucket.  
  
We do still throw error for NaN or infinity histogram-bound inputs,  
since there's no way to compute sensible bucket boundaries.  
  
Arguably this is a bug fix, but given the lack of field complaints  
I'm content to fix it in master.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/2822872.1750540911@sss.pgh.pa.us  

commit   : c989affb527d330898e92e6223e2218e702176ed    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 2 Jul 2025 17:02:27 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 2 Jul 2025 17:02:27 +0200    

Trying to alter a constraint so that it becomes NOT VALID results in an  
error that assumes the constraint is a foreign key.  This is potentially  
wrong, so give a more generic error message.  
  
While at it, give CREATE CONSTRAINT TRIGGER a better error message as  
well.  
  
Co-authored-by: jian he <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Co-authored-by: Amul Sul <sulamul@gmail.com>  
Discussion: https://postgr.es/m/CACJufxHSp2puxP=q8ZtUGL1F+heapnzqFBZy5ZNGUjUgwjBqTQ@mail.gmail.com  

commit   : bd3f59fdb71721921bb0aca7e16d483f72e95779    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 2 Jul 2025 09:48:15 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 2 Jul 2025 09:48:15 -0400    

Recent nbtree bugfix commit 5f4d98d4 added a special case to the code  
that sets up a page-level prefix of keys that are definitely satisfied  
by every tuple on the page: whenever _bt_set_startikey reached a row  
compare key, we'd refuse to apply the pstate.forcenonrequired behavior  
in scans where that usually happens (scans with a higher-order array  
key).  That hack made the scan avoid essentially the same infinite  
cycling behavior that also affected nbtree scans with redundant keys  
(keys that preprocessing could not eliminate) prior to commit f09816a0.  
There are now serious doubts about this row compare workaround.  
  
Testing has shown that a scan with a row compare key and an array key  
could still read the same leaf page twice (without the scan's direction  
changing), which isn't supposed to be possible following the SAOP  
enhancements added by Postgres 17 commit 5bf748b8.  Also, we still  
allowed a required row compare key to be used with forcenonrequired mode  
when its header key happened to be beyond the pstate.ikey set by  
_bt_set_startikey, which was complicated and brittle.  
  
The underlying problem was that row compares had inconsistent rules  
around how scans start (which keys can be used for initial positioning  
purposes) and how scans end (which keys can set continuescan=false).  
Quals with redundant keys that could not be eliminated by preprocessing  
also had that same quality to them prior to today's bugfix f09816a0.  It  
now seems prudent to bring row compare keys in line with the new charter  
for required keys, by making the start and end rules symmetric.  
  
This commit fixes two points of disagreement between _bt_first and  
_bt_check_rowcompare.  Firstly, _bt_check_rowcompare was capable of  
ending the scan at the point where it needed to compare an ISNULL-marked  
row compare member that came immediately after a required row compare  
member.  _bt_first now has symmetric handling for NULL row compares.  
Secondly, _bt_first had its own ideas about which keys were safe to use  
for initial positioning purposes.  It could use fewer or more keys than  
_bt_check_rowcompare.  _bt_first now uses the same requiredness markings  
as _bt_check_rowcompare for this.  
  
Now that _bt_first and _bt_check_rowcompare agree on how to start and  
end scans, we can get rid of the forcenonrequired special case, without  
any risk of infinite cycling.  This approach also makes row compare keys  
behave more like regular scalar keys, particularly within _bt_first.  
  
Fixing these inconsistencies necessitates dealing with a related issue  
with the way that row compares were marked required by preprocessing: we  
didn't mark any lower-order row members required following 2016 bugfix  
commit a298a1e0.  That approach was over broad.  The bug in question was  
actually an oversight in how _bt_check_rowcompare dealt with tuple NULL  
values that failed to satisfy a scan key marked required in the opposite  
scan direction (it was a bug in 2011 commits 6980f817 and 882368e8, not  
a bug in 2006 commit 3a0a16cb).  Go back to marking row compare members  
as required using the original 2006 rules, and fix the 2016 bug in a  
more principled way: by limiting use of the "set continuescan=false with  
a key required in the opposite scan direction upon encountering a NULL  
tuple value" optimization to the first/most significant row member key.  
While it isn't safe to use an implied IS NOT NULL qualifier to end the  
scan when it comes from a required lower-order row compare member key,  
it _is_ generally safe for such a required member key to end the scan --  
provided the key is marked required in the _current_ scan direction.  
  
This fixes what was arguably an oversight in either commit 5f4d98d4 or  
commit 8a510275.  It is a direct follow-up to today's commit f09816a0.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Discussion: https://postgr.es/m/CAH2-Wz=pcijHL_mA0_TJ5LiTB28QpQ0cGtT-ccFV=KzuunNDDQ@mail.gmail.com  
Backpatch-through: 18  

commit   : f09816a0a7c138751b76ba3676adb75c94be2ab0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 2 Jul 2025 09:40:49 -0400    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 2 Jul 2025 09:40:49 -0400    

nbtree preprocessing's handling of redundant (and contradictory) keys  
created problems for scans with = arrays.  It was just about possible  
for a scan with an = array key and one or more redundant keys (keys that  
preprocessing could not eliminate due an incomplete opfamily and a  
cross-type key) to get stuck.  Testing has shown that infinite cycling  
where the scan never manages to make forward progress was possible.  
This could happen when the scan's arrays were reset in _bt_readpage's  
forcenonrequired=true path (added by bugfix commit 5f4d98d4) when the  
arrays weren't at least advanced up to the same point that they were in  
at the start of the _bt_readpage call.  Earlier redundant keys prevented  
the finaltup call to _bt_advance_array_keys from reaching lower-order  
keys that needed to be used to sufficiently advance the scan's arrays.  
  
To fix, make preprocessing leave the scan's keys in a state that is as  
close as possible to how it'll usually leave them (in the common case  
where there's no redundant keys that preprocessing failed to eliminate).  
Now nbtree preprocessing _reliably_ leaves behind at most one required  
>/>= key per index column, and at most one required </<= key per index  
column.  Columns that have one or more = keys that are eligible to be  
marked required (based on the traditional rules) prioritize the = keys  
over redundant inequality keys; they'll _reliably_ be left with only one  
of the = keys as the index column's only required key.  
  
Keys that are not marked required (whether due to the new preprocessing  
step running or for some other reason) are relocated to the end of the  
so->keyData[] array as needed.  That way they'll always be evaluated  
after the scan's required keys, and so cannot prevent code in places  
like _bt_advance_array_keys and _bt_first from reaching a required key.  
  
Also teach _bt_first to decide which initial positioning keys to use  
based on the same requiredness markings that have long been used by  
_bt_checkkeys/_bt_advance_array_keys.  This is a necessary condition for  
reliably avoiding infinite cycling.  _bt_advance_array_keys expects to  
be able to reason about what'll happen in the next _bt_first call should  
it start another primitive index scan, by evaluating inequality keys  
that were marked required in the opposite-to-scan scan direction only.  
Now everybody (_bt_first, _bt_checkkeys, and _bt_advance_array_keys)  
will always agree on which exact key will be used on each index column  
to start and/or end the scan (except when row compare keys are involved,  
which have similar problems not addressed by this commit).  
  
An upcoming commit will finish off the work started by this commit by  
harmonizing how _bt_first, _bt_checkkeys, and _bt_advance_array_keys  
apply row compare keys to start and end scans.  
  
This fixes what was arguably an oversight in either commit 5f4d98d4 or  
commit 8a510275.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Discussion: https://postgr.es/m/CAH2-Wz=ds4M+3NXMgwxYxqU8MULaLf696_v5g=9WNmWL2=Uo2A@mail.gmail.com  
Backpatch-through: 18  

commit   : 8eede2c7200fba0eae40a19ca78939fd0dc0ec5b    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 2 Jul 2025 11:42:36 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 2 Jul 2025 11:42:36 +0200    

A words seemed to have gone missing in the leading paragraphs.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Co-authored-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/aGTQYZz9L0bjlzVL@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 18  

commit   : f039c2244110a55e966e8538b6be8bf83458a0fb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Jul 2025 11:14:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Jul 2025 11:14:53 +0200    

The previous minimum was to maintain support for Python 3.5, but we  
now require Python 3.6 anyway (commit 45363fca637), so that reason is  
obsolete.  A small raise to Meson 0.57 allows getting rid of a fair  
amount of version conditionals and silences some future-deprecated  
warnings.  
  
With the version bump, the following deprecation warnings appeared and  
are fixed:  
  
WARNING: Project targets '>=0.57' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead  
WARNING: Project targets '>=0.57' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.  
  
It turns out that meson 0.57.0 and 0.57.1 are buggy for our use, so  
the minimum is actually set to 0.57.2.  This is specific to this  
version series; in the future we won't necessarily need to be this  
precise.  
  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/flat/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org  

commit   : de5aa15209397712dcfdeee2a72977b83374f276    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Jul 2025 09:41:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 2 Jul 2025 09:41:08 +0200    

Use per-field comments for IndexInfo, instead of one big header  
comment listing all the fields.  This makes the relevant comments  
easier to find, and it will also make it less likely that comments are  
not updated when fields are added or removed, as has happened in the  
past.  
  
Author: Japin Li <japinli@hotmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ME0P300MB04453E6C7EA635F0ECF41BFCB6832%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : 3811ca3600a31f999e4709de4a9c64c789992e14    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 1 Jul 2025 23:25:20 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 1 Jul 2025 23:25:20 -0700    

Commit c120550edb86 optimized the vacuuming of relations without  
indexes (a.k.a. one-pass strategy) by directly marking dead item IDs  
as LP_UNUSED. However, the periodic FSM vacuum was still checking if  
dead item IDs had been marked as LP_DEAD when attempting to vacuum the  
FSM every VACUUM_FSM_EVERY_PAGES blocks. This condition was never met  
due to the optimization, resulting in missed FSM vacuum  
opportunities.  
  
This commit modifies the periodic FSM vacuum condition to use the  
number of tuples deleted during HOT pruning. This count includes items  
marked as either LP_UNUSED or LP_REDIRECT, both of which are expected  
to result in new free space to report.  
  
Back-patch to v17 where the vacuum optimization for tables with no  
indexes was introduced.  
  
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoBL8m6B9GSzQfYxVaEgvD7-Kr3AJaS-hJPHC+avm-29zw@mail.gmail.com  
Backpatch-through: 17  

commit   : 9adb58a3ccb5ad28e773684db33ffcb1ebbd5ef1    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 2 Jul 2025 11:51:10 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 2 Jul 2025 11:51:10 +0700    

Commit e2809e3a101 added code to a header which assigns a pointer  
to void to a pointer to unsigned char. This causes build errors for  
extensions written in C++. Fix by adding an explicit cast.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CANWCAZaCq9AHBuhs%3DMx7Gg_0Af9oRU7iAqr0itJCtfmsWwVmnQ%40mail.gmail.com  
Backpatch-through: 18  

commit   : 3369a3b49b0bc0a4205062e45623af297240c8c6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 13:48:36 +0900    

When decompressing some input data, the calculation for the initial  
starting point and the initial size were incorrect, potentially leading  
to failures when decompressing contents with LZ4.  These initialization  
points are fixed in this commit, bringing the logic closer to what  
exists for gzip and zstd.  
  
The contents of the compressed data is clear (for example backups taken  
with LZ4 can still be decompressed with a "lz4" command), only the  
decompression part reading the input data was impacted by this issue.  
  
This code path impacts pg_basebackup and pg_verifybackup, which can use  
the LZ4 decompression routines with an archive streamer, or any tools  
that try to use the archive streamers in src/fe_utils/.  
  
The issue is easier to reproduce with files that have a low-compression  
rate, like ones filled with random data, for a size of at least 512kB,  
but this could happen with anything as long as it is stored in a data  
folder.  Some tests are added based on this idea, with a file filled  
with random bytes grabbed from the backend, written at the root of the  
data folder.  This is proving good enough to reproduce the original  
problem.  
  
Author: Mikhail Gribkov <youzhick@gmail.com>  
Discussion: https://postgr.es/m/CAMEv5_uQS1Hg6KCaEP2JkrTBbZ-nXQhxomWrhYQvbdzR-zy-wA@mail.gmail.com  
Backpatch-through: 15  

commit   : b45242fd30ffa6e1e7f490cc400ecbd966880f41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 09:52:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 09:52:21 +0900    

This commit moves all the routines related to the bytea data type into  
its own new file, called bytea.c, clearing some of the bloat in  
varlena.c.  This includes the routines for:  
- Input, output, receive and send  
- Comparison  
- Casts to integer types  
- bytea-specific functions  
  
The internals of the routines moved here are unchanged, with one  
exception.  This comes with a twist in bytea_string_agg_transfn(), where  
the call to makeStringAggState() is replaced by the internals of this  
routine, still located in varlena.c.  This simplifies the move to the  
new file by not having to expose makeStringAggState().  
  
Author: Aleksander Alekseev <aleksander@timescale.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/CAJ7c6TMPVPJ5DL447zDz5ydctB8OmuviURtSwd=PHCRFEPDEAQ@mail.gmail.com  

commit   : bee23ea4ddc46198c95a4e73a83f453c09e04bf8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 08:39:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Jul 2025 08:39:25 +0900    

Prior to this patch, every FETCH call would generate a unique queryId  
with a different size specified.  Depending on the workloads, this could  
lead to a significant bloat in pg_stat_statements, as repeatedly calling  
a specific cursor would result in a new queryId each time.  For example,  
FETCH 1 c1; and FETCH 2 c1; would produce different queryIds.  
  
This patch improves the situation by normalizing the fetch size, so as  
semantically similar statements generate the same queryId.  As a result,  
statements like the below, which differ syntactically but have the same  
effect, will now share a single queryId:  
FETCH FROM c1  
FETCH NEXT c1  
FETCH 1 c1  
  
In order to do a normalization based on the keyword used in FETCH,  
FetchStmt is tweaked with a new FetchDirectionKeywords.  This matters  
for "howMany", which could be set to a negative value depending on the  
direction, and we want to normalize the queries with enough information  
about the direction keywords provided, including RELATIVE, ABSOLUTE or  
all the ALL variants.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAA5RZ0tA6LbHCg2qSS+KuM850BZC_+ZgHV7Ug6BXw22TNyF+MA@mail.gmail.com  

commit   : 184595836ba37e1d35cb8a4e9298dc0eed763746    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 22:15:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 22:15:26 +0200    

Commit 7a7b3e11e61 added the ii_NullsNotDistinct field, but the  
comment was not updated.  
  
Author: Japin Li <japinli@hotmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ME0P300MB04453E6C7EA635F0ECF41BFCB6832%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : aa268cbaade2e7c87addc2fabc7fc8a43310a440    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 14:30:16 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 14:30:16 -0500    

commit   : 32bcf568cbc32ffc6d9be1b385d0f766720f7ebc    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 14:19:07 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 14:19:07 -0500    

A few places were accessing bh_size directly instead of via these  
handy macros.  
  
Author: Aleksander Alekseev <aleksander@timescale.com>  
Discussion: https://postgr.es/m/CAJ7c6TPQMVL%2B028T4zuw9ZqL5Du9JavOLhBQLkJeK0RznYx_6w%40mail.gmail.com  

commit   : e6115394d40c5d8789b23e5badb2a7679ddd5203    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:54:38 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:54:38 -0500    

Oversight in commit 0ac5ad5134.  
  
Author: Sami Imseih <samimseih@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/20150619215231.GT133018%40postgresql.org  
Discussion: https://postgr.es/m/CAA5RZ0sjQDDwJfMRb%3DZ13nDLuRpF13ME2L_BdGxi0op8RKjmDg%40mail.gmail.com  
Backpatch-through: 13  

commit   : 7a7b3e11e6190e414ccd6ad126bed915e8be16f1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 20:37:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 20:37:24 +0200    

Commit fc0438b4e80 added the ii_WithoutOverlaps field, but the comment  
was not updated.  
  
Author: Japin Li <japinli@hotmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ME0P300MB04453E6C7EA635F0ECF41BFCB6832%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : 9e5fee822846763a9c04a60bd5076d6fe3248faf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 20:12:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 20:12:36 +0200    

Commit 78416235713 removed the ii_OpclassOptions field, but the  
comment was not updated.  
  
Author: Japin Li <japinli@hotmail.com>  
Reviewed-by: Richard Guo <guofenglinux@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ME0P300MB04453E6C7EA635F0ECF41BFCB6832%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM  

commit   : fff0d1edf567c412c9d78cb10e9b67ce78b8e0cb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 18:42:07 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 18:42:07 +0200    

The previous wording was potentially confusing about the impact of the  
OVERRIDING clause on generated columns.  Reword slightly to avoid  
that.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CACJufxFMBe0nPXOQZMLTH4Ry5Gyj4m%2B2Z05mRi9KB4hk8rGt9w%40mail.gmail.com  

commit   : 1fd772d192909a4f0e1ce88ebc72c8c43b81b025    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:40:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:40:35 -0400    

We stopped defining IOV_MAX on non-Windows systems in 75357ab94, on  
the assumption that every non-Windows system defines it in <limits.h>  
as required by X/Open.  GNU Hurd, however, doesn't follow that  
standard either.  Put back the old logic to assume 16 if it's  
not defined.  
  
Author: Michael Banck <mbanck@gmx.net>  
Co-authored-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/6862e8d1.050a0220.194b8d.76fa@mx.google.com  
Discussion: https://postgr.es/m/6846e0c3.df0a0220.39ef9b.c60e@mx.google.com  
Backpatch-through: 16  

commit   : 29213636e6cddcb7b2c877bff8cb9ba470d392db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:08:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2025 12:08:20 -0400    

The existing code assumed that O_RDONLY is defined as 0, but this is  
not required by POSIX and is not true on GNU Hurd.  We can avoid  
the assumption by relying on O_ACCMODE to mask the fcntl() result.  
(Hopefully, all supported platforms define that.)  
  
Author: Michael Banck <mbanck@gmx.net>  
Co-authored-by: Samuel Thibault  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/6862e8d1.050a0220.194b8d.76fa@mx.google.com  
Discussion: https://postgr.es/m/68480868.5d0a0220.1e214d.68a6@mx.google.com  
Backpatch-through: 13  

commit   : 8af0d0ab01b406b8671ff4426acfe9b1d2af30d8    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Jul 2025 07:42:44 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Jul 2025 07:42:44 -0700    

The behavior of pg_locale_t is specified by methods, so a separate  
provider field is no longer necessary.  
  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/2830211e1b6e6a2e26d845780b03e125281ea17b.camel%40j-davis.com  

commit   : 5a38104b364234615c780656a8b2424f96ed9efa    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Jul 2025 07:42:39 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Jul 2025 07:42:39 -0700    

Previously, pattern matching and case mapping behavior branched based  
on the provider. Refactor to use a method table, which is less  
error-prone.  
  
This is also a step toward multiple provider versions, which we may  
want to support in the future.  
  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/2830211e1b6e6a2e26d845780b03e125281ea17b.camel%40j-davis.com  

commit   : d81dcc8d6243054e3bde40c6fb2b2a0be4b19da6    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Jul 2025 07:24:23 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 1 Jul 2025 07:24:23 -0700    

Avoids unnecessary dependence on setlocale(). No behavior change.  
  
This commit reverts e1458f2f1b, which reverted some changes  
unintentionally committed before the branch for 19.  
  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/a8666c391dfcabe79868d95f7160eac533ace718.camel@j-davis.com  
Discussion: https://postgr.es/m/7efaaa645aa5df3771bb47b9c35df27e08f3520e.camel@j-davis.com  

commit   : 9e345415bcd3c4358350b89edfd710469b8bfaf9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 15:20:26 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 15:20:26 +0200    

Broken by commits 7fe2f67c7c9f, 81f287dc923f and bf1119d74a79. Backpatch  
to 18, same as the offending commits.  
  
Backpatch-through: 18  

commit   : bf1119d74a79b68d9c9086e5d32d44fb294a1427    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 12:58:35 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 12:58:35 +0200    

Querying the NUMA status can be quite time consuming, especially with  
large shared buffers. 8cc139bec34a called numa_move_pages() once, for  
all buffers, and we had to wait for the syscall to complete.  
  
But with the chunking, introduced by 7fe2f67c7c to work around a kernel  
bug, we can do CHECK_FOR_INTERRUPTS() after each chunk, allowing users  
to abort the execution.  
  
Reviewed-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aEtDozLmtZddARdB@msg.df7cb.de  
Backpatch-through: 18  

commit   : 81f287dc923f565722f46b18d71969926bc3c64f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 12:32:23 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 12:32:23 +0200    

When querying NUMA status of pages in shared memory, we need to touch  
the memory first to get valid results. This may trigger valgrind  
reports, because some of the memory (e.g. unpinned buffers) may be  
marked as noaccess.  
  
Solved by adding a valgrind suppresion. An alternative would be to  
adjust the access/noaccess status before touching the memory, but that  
seems far too invasive. It would require all those places to have  
detailed knowledge of what the shared memory stores.  
  
The pg_numa_touch_mem_if_required() macro is replaced with a function.  
Macros are invisible to suppressions, so it'd have to suppress reports  
for the caller - e.g. pg_get_shmem_allocations_numa(). So we'd suppress  
reports for the whole function, and that seems to heavy-handed. It might  
easily hide other valid issues.  
  
Reviewed-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aEtDozLmtZddARdB@msg.df7cb.de  
Backpatch-through: 18  

commit   : 953050236ab2640055d79532981f958271a33292    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 12:24:17 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 12:24:17 +0200    

The way it was worded, the %u placeholder could be read as the table  
OID.  Rearrange slightly to avoid the possible confusion.  
  
Reported-by: jian he <jian.universality@gmail.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CACJufxFx-25XQV%2Br23oku7ZnL958P30hyb9cFeYPv6wv7yzCCw%40mail.gmail.com  

commit   : 7fe2f67c7c9f27955df584eb79edd6ec2be7f9e4    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 12:02:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Jul 2025 12:02:31 +0200    

There's a kernel bug in do_pages_stat(), affecting systems combining  
64-bit kernel and 32-bit user space. The function splits the request  
into chunks of 16 pointers, but forgets the pointers are 32-bit when  
advancing to the next chunk. Some of the pointers get skipped, and  
memory after the array is interpreted as pointers. The result is that  
the produced status of memory pages is mostly bogus.  
  
Systems combining 64-bit and 32-bit environments like this might seem  
rare, but that's not the case - all 32-bit Debian packages are built in  
a 32-bit chroot on a system with a 64-bit kernel.  
  
This is a long-standing kernel bug (since 2010), affecting pretty much  
all kernels, so it'll take time until all systems get a fixed kernel.  
Luckily, we can work around the issue by chunking the requests the same  
way do_pages_stat() does, at least on affected systems. We don't know  
what kernel a 32-bit build will run on, so all 32-bit builds use chunks  
of 16 elements (the largest chunk before hitting the issue).  
  
64-bit builds are not affected by this issue, and so could work without  
the chunking. But chunking has other advantages, so we apply chunking  
even for 64-bit builds, with chunks of 1024 elements.  
  
Reported-by: Christoph Berg <myon@debian.org>  
Author: Christoph Berg <myon@debian.org>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/aEtDozLmtZddARdB@msg.df7cb.de  
Context: https://marc.info/?l=linux-mm&m=175077821909222&w=2  
Backpatch-through: 18  

commit   : b5cd0ecd4d4fa89b716785f22e9f009624104d61    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jul 2025 15:17:03 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jul 2025 15:17:03 +0530    

Author: shveta malik <shveta.malik@gmail.com>  
Discussion: https://postgr.es/m/CAJpy0uAyFN9o7vU_ZkZFv5-6ysXDNKNx_fC0gwLLKg=8==E3ow@mail.gmail.com  

commit   : 83389838827b75dbdc9e4c251e2f57b23bfb2cff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 10:19:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 10:19:52 +0200    

There are different capitializations of "TOAST" around the  
documentation and code.  This just changes a few places that were more  
obviously inconsistent with similar phrases elsewhere.  
  
Author: Peter Smith <peter.b.smith@fujitsu.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAHut+PtxXLJFhwJFvx+M=Ux8WGHU85XbT3nDqk-aAUS3E5ANCw@mail.gmail.com  

commit   : 8fd9bb1d9654c59d40613232ad964e9a648e4202    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 09:36:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 1 Jul 2025 09:36:33 +0200    

Switch MSVC to use the conforming preprocessor, using the  
/Zc:preprocessor option.  
  
This allows us to drop the alternative implementation of  
VA_ARGS_NARGS() for the previous "traditional" preprocessor.  
  
This also prepares the way for enabling C11 mode in the future, which  
enables the conforming preprocessor by default.  
  
This now requires Visual Studio 2019.  The installation documentation  
is adjusted accordingly.  
  
Discussion: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a%40eisentraut.org  

commit   : 732061150b004385810e522f8629f5bf91d977b7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jul 2025 15:48:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jul 2025 15:48:32 +0900    

The contrib module xml2/ has always been fuzzy with the cleanup of the  
memory allocated by the calls internal to libxml2, even if there are  
APIs in place giving a lot of control over the error behavior, all  
located in the backend's xml.c.  
  
The code paths fixed in the commit address multiple defects, while  
sanitizing the code:  
- In xpath.c, several allocations are done by libxml2 for  
xpath_workspace, whose memory cleanup could go out of sight as it relied  
on a single TRY/CATCH block done in pgxml_xpath().  workspace->res is  
allocated by libxml2, and may finish by not being freed at all upon a  
failure outside of a TRY area.  This code is refactored so as the  
TRY/CATCH block of pgxml_xpath() is moved one level higher to its  
callers, which are responsible for cleaning up the contents of a  
workspace on failure.  cleanup_workspace() now requires a volatile  
workspace, forcing as a rule that a TRY/CATCH block should be used.  
- Several calls, like xmlStrdup(), xmlXPathNewContext(),  
xmlXPathCtxtCompile(), etc. can return NULL on failures (for most of  
them allocation failures.  These forgot to check for failures, or missed  
that pg_xml_error_occurred() should be called, to check if an error is  
already on the stack.  
- Some memory allocated by libxml2 calls was freed in an incorrect way,  
"resstr" in xslt_process() being one example.  
  
The class of errors fixed here are for problems that are unlikely going  
to happen in practice, so no backpatch is done.  The changes have  
finished by being rather invasive, so it is perhaps not a bad thing to  
be conservative and to keep these changes only on HEAD anyway.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Reported-by: Karavaev Alexey <maralist86@mail.ru>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/18943-2f2a04ab03904598@postgresql.org  

commit   : c67989789cec3953effca4e01dff834abff9116a    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:13:48 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Tue, 1 Jul 2025 13:13:48 +0900    

Commit 19d8e2308bc added enum values with the prefix TU_, but a few  
comments still referred to TUUI_, which was used in development  
versions of the patches committed as 19d8e2308bc.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Discussion: https://postgr.es/m/20250701110216.8ac8a9e4c6f607f1d954f44a@sraoss.co.jp  
Backpatch-through: 16  

commit   : a3df0d43d93789777fd06bb7ffa8cdc1f06d63c3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jul 2025 09:41:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jul 2025 09:41:42 +0900    

backend_xmin used a lower-character 's' instead of the upper-character  
'S' like the other attributes.  This is harmless, but let's be  
consistent.  
  
Issue introduced in dd1a3bccca24.  
  
Author: Daisuke Higuchi <higuchi.daisuke11@gmail.com>  
Discussion: https://postgr.es/m/CAEVT6c8M39cqWje-df39wWr0KWcDgGKd5fMvQo84zvCXKoEL9Q@mail.gmail.com  

commit   : 2e947217474c15c7fd9011d1ab2b0d4657b3eae2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jul 2025 08:57:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Jul 2025 08:57:05 +0900    

This commit fixes some defects in the backend's xml.c, found upon  
inspection of the internals of libxml2:  
- xmlEncodeSpecialChars() can fail on malloc(), returning NULL back to  
the caller.  xmltext() assumed that this could never happen.  Like other  
code paths, a TRY/CATCH block is added there, covering also the fact  
that cstring_to_text_with_len() could fail a memory allocation, where  
the backend would miss to free the buffer allocated by  
xmlEncodeSpecialChars().  
- Some libxml2 routines called in xmlelement() can return NULL, like  
xmlAddChildList() or xmlTextWriterStartElement().  Dedicated errors are  
added for them.  
- xml_xmlnodetoxmltype() missed that xmlXPathCastNodeToString() can fail  
on an allocation failure.  In this case, the call can just be moved to  
the existing TRY/CATCH block.  
  
All these code paths would cause the server to crash.  As this is  
unlikely a problem in practice, no backpatch is done.  Jim and I have  
caught these defects, not sure who has scored the most.  The contrib  
module xml2/ has similar defects, which will be addressed in a separate  
change.  
  
Reported-by: Jim Jones <jim.jones@uni-muenster.de>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Discussion: https://postgr.es/m/aEEingzOta_S_Nu7@paquier.xyz  

commit   : 0836683a8977cac07d8cbdd0462f8a3e7e32565f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jun 2025 17:06:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jun 2025 17:06:39 -0400    

The current code in resolve_column_ref (dating to commits 01f7d2990  
and fe24d7816) believes that not finding a RECFIELD datum is a  
can't-happen case, in consequence of which I didn't spend a whole lot  
of time considering what to do if it did happen.  But it turns out  
that it *can* happen if the would-be field name is a fully-reserved  
PL/pgSQL keyword.  Change the error message to describe that  
situation, and add a test case demonstrating it.  
  
This might need further refinement if anyone can find other ways to  
trigger a failure here; but without an example it's not clear what  
other error to throw.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://postgr.es/m/2185258.1745617445@sss.pgh.pa.us  

commit   : 999f172ded2bae7efbd8bf1dd6f823095395493f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jun 2025 16:59:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jun 2025 16:59:36 -0400    

On close inspection, there does not seem to be a strong reason  
why these should be fully-reserved keywords.  I guess they just  
escaped consideration in previous attempts to minimize PL/pgSQL's  
list of reserved words.  
  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://postgr.es/m/2185258.1745617445@sss.pgh.pa.us  

commit   : bd09f024a1bbdd7a7e2ca944595a9d4b6c90fb83    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 30 Jun 2025 15:38:54 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 30 Jun 2025 15:38:54 -0500    

This provides a convenient way to look up a database's OID.  For  
example, the query  
  
    SELECT * FROM pg_shdepend  
    WHERE dbid = (SELECT oid FROM pg_database  
                  WHERE datname = current_database());  
  
can now be simplified to  
  
    SELECT * FROM pg_shdepend  
    WHERE dbid = current_database()::regdatabase;  
  
Like the regrole type, regdatabase has cluster-wide scope, so we  
disallow regdatabase constants from appearing in stored  
expressions.  
  
Bumps catversion.  
  
Author: Ian Lawrence Barwick <barwick@gmail.com>  
Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com>  
Reviewed-by: Jian He <jian.universality@gmail.com>  
Reviewed-by: Fabrízio de Royes Mello <fabriziomello@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aBpjJhyHpM2LYcG0%40nathan  

commit   : f20a347e1a613cfc9053e7bc3d254608ae968386    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Jun 2025 10:20:14 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Jun 2025 10:20:14 -0400    

Reported-by: Antonin Houska <ah@cybertec.at>  
Author: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/5250.1751266701@localhost  
Backpatch-through: 18, where da7226993fd4 introduced this  

commit   : c3e28e9fd936b83dbb6dfb5003b6221d98f8469c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Jun 2025 09:49:31 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Jun 2025 09:49:31 -0400    

If the method is called in scalar context and we didn't pass in a stderr  
handle, one won't be created. However, some error paths assume that it  
exists, so in this case create a dummy stderr to avoid the resulting  
perl error.  
  
Per gripe from Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru> and  
adapted from his patch.  
  
Discussion: https://postgr.es/m/378eac5de4b8ecb5be7bcdf2db9d2c4d@postgrespro.ru  

commit   : 40a96cd1484fdf3ab57e8cb7b09767ec7a7f73b1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:23:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:23:33 +0200    

Python's subprocess.run docs say that if the env argument is not None,  
it will be used "instead of the default behavior of inheriting the  
current process’ environment".  However, the environment should be  
preserved, only adding FLEX_TMP_DIR to it.  
  
Author: Javier Maestro <jjmaestro@ieee.org>  
Discussion: https://www.postgresql.org/message-id/flat/CABvji06GUpmrTqqiCr6_F9vRL2-JUSVAh8ChgWa6k47FUCvYmA%40mail.gmail.com  

commit   : cc2ac0e6f99e4efc3ae5710010ff35e646990a60    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:00:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 12:00:00 +0200    

Author: Aleksander Alekseev <aleksander@timescale.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAJ7c6TOowVbR-0NEvvDm6a_mag18krR0XJ2FKrc9DHXj7hFRtQ%40mail.gmail.com  

commit   : a6a4641252ed166ba187d7fbe0504ddb5a5f0e33    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:38:18 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:38:18 +0200    

commit   : a4c10de9291291bce3dd2b81bd8b5f0b98649244    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Jun 2025 18:36:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Jun 2025 18:36:24 +0900    

Previously, tab completion for COPY only suggested plain tables  
and partitioned tables, even though materialized views are also  
valid for COPY TO (since commit 534874fac0b), and foreign tables  
are valid for COPY FROM.  
  
This commit enhances tab completion for COPY to also include  
materialized views and foreign tables.  
  
Views with INSTEAD OF INSERT triggers are supported with  
COPY FROM but rarely used, so plain views are intentionally  
excluded from completion.  
  
Author: jian he <jian.universality@gmail.com>  
Co-authored-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Discussion: https://postgr.es/m/CACJufxFxnSkikp+GormAGHcMTX1YH2HRXW1+3dJM9w7yY9hdsg@mail.gmail.com  

commit   : 960135114629bc89da0dd1d839541098c7e6401a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:28:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 11:28:11 +0200    

It was quite hard to guess what leaf_fragmentation meant without looking  
at pgstattuple's code.  This patch aims to give to the user a better  
idea of what it means.  
  
Author: Frédéric Yhuel <frederic.yhuel@dalibo.com>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Benoit Lobréau <benoit.lobreau@dalibo.com>  
Discussion: https://postgr.es/m/bf110561-f774-4957-a890-bb6fab6804e0%40dalibo.com  
Discussion: https://postgr.es/m/4c5dee3a-8381-4e0f-b882-d1bd950e8972@dalibo.com  

commit   : 3431e3e4aa3a33e8411f15e76c284cdd4c54ca28    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:45:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:45:08 +0200    

Run program_XXX tests instead of its own tests.  This ensures  
consistency with the test suites of other programs and enforces common  
policies, such as help line length.  
  
Author: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Discussion: https://www.postgresql.org/message-id/flat/OSCPR01MB14966247015B7E3D8D340D022F56FA@OSCPR01MB14966.jpnprd01.prod.outlook.com  

commit   : 2e640a0fa224e4233220252b360efd33c98b3e90    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:32:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Jun 2025 10:32:26 +0200    

When postfix operators where dropped in 1ed6b8956, the CREATE OPERATOR  
docs were not updated to make the RIGHTARG argument mandatory in the  
grammar.  
  
While at it, make the RIGHTARG docs more concise. Also, the operator  
docs were mentioning "infix" in the introduction, while using "binary"  
everywhere else.  
  
Author: Christoph Berg <myon@debian.org>  
Discussion: https://www.postgresql.org/message-id/flat/aAtpbnQphv4LWAye@msg.df7cb.de  

commit   : c5c4fbb4d482b87c2a6c90337f3b657b2d0002ca    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 30 Jun 2025 10:12:31 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 30 Jun 2025 10:12:31 +0200    

Commit 1546e17f9d0 accidentally misspelled additionally as  
additionaly.  Backpatch to v17 to match where the original  
commit was backpatched.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Backpatch-through: 17  

commit   : 2252fcd4276cfeabae8786ab7c5a421dd674743e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 15:42:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 15:42:50 +0900    

This commit refactors the vacuum routines that rely on VacuumParams,  
adding const markers where necessary to force a new policy in the code.  
This structure should not use a pointer as it may be used across  
multiple relations, and its contents should never be updated.  
vacuum_rel() stands as an exception as it touches the "index_cleanup"  
and "truncate" options.  
  
VacuumParams has been introduced in 0d831389749a, and 661643dedad9 has  
fixed a bug impacting VACUUM operating on multiple relations.  The  
changes done in tableam.h break ABI compatibility, so this commit can  
only happen on HEAD.  
  
Author: Shihao Zhong <zhong950419@gmail.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/CAGRkXqTo+aK=GTy5pSc-9cy8H2F2TJvcrZ-zXEiNJj93np1UUw@mail.gmail.com  

commit   : 5ba00e175a4eaefa4dc38ea14c667bbeb13af305    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 13:56:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Jun 2025 13:56:31 +0900    

log_line_prefix is changed to include "%b", the backend type in the TAP  
test configuration.  %v and %x are removed from the CI configuration,  
with the format around %b changed.  
  
The lack of backend type in postgresql.conf set by Cluster.pm for the  
TAP test configuration was something that has been bugging me, beginning  
the discussion that has led to this change.  The change in the CI has  
come up during the discussion, to become consistent with pg_regress.c,  
%v and %x not being that useful to have.  
  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aC0VaIWAXLgXcHVP@paquier.xyz  

commit   : 2652835d3efa003439ecc23d5fc3cf089c5952a6    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 22:28:10 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 29 Jun 2025 22:28:10 -0400    

Let the hacking begin ...