PostgreSQL 19.0 (upcoming) commit log

commit   : 0b74df66f08f474aa2225553b8d38704ae844797    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 12:37:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 12:37:21 +0900    

This one has been forgotten in 8bf257aebac1.  Per report from buildfarm  
member massasauga.  
  
Backpatch-through: 14  

commit   : a8ee70bd5e0069c5550b0b0c5418638507fa0ed7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 11:44:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 11:44:11 +0900    

read_local_xlog_page_guts has the same race as logical_read_xlog_page:  
RecoveryInProgress() can return true during promotion, impacting the  
availability of the operations doing WAL page reads with this callback.  
  
This problem is similar to eb4e7224a1c6 that has addressed the issue for  
logical replication, impacting more areas of the code where this WAL  
page callback can be used (same narrow window during promotion, same  
availability issue):  
- pg_walinspect.  
- Slot advance (SQL function).  
- Slot creation.  
  
Repack workers (v19~) and 2PC files (since forever) can also use this  
callback, but they are irrelevant as far as I know.  A test is added  
with the SQL lookup functions.  This part relies on injection points,  
and is backpatched down to v18, like the test added for eb4e7224a1c6.  
  
This issue could probably be fixed as well in v14 and v15 for  
pg_walinspect.  However, I also feel that there is a conservative  
argument about consistency here due to the support of logical decoding  
on standbys, so let's limit ourselves to v16 for now.  pg_walinspect is  
used less in the field compared to the two other operations, making  
addressing this problem less attractive in these two older branches.  
  
Reported-by: Xuneng Zhou <xunengzhou@gmail.com>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/7daef094-abf3-4672-bc23-3df4763b16a3%40gmail.com  
Backpatch-through: 16  

commit   : 4113873a5ab0fb83a6f772f455b2842359d5ec50    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 12 Jun 2026 11:05:25 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 12 Jun 2026 11:05:25 +0900    

The FK fast-path batching added in b7b27eb41a5 buffers rows in a  
transaction-lived cache (ri_fastpath_cache) keyed by constraint OID.  
Running user-defined cast and equality functions during a batch flush,  
together with the cache's lifetime and iteration, exposed two defects  
reachable by an unprivileged table owner.  
  
First, on subtransaction abort ri_FastPathSubXactCallback discarded the  
entire cache.  An entry's batch holds rows buffered by the enclosing  
transaction, not just the aborting subxact -- the cache is keyed by  
constraint, so a single entry can mix rows from multiple subxact levels.  
An internal subxact abort during after-trigger firing (e.g. a PL/pgSQL  
BEGIN ... EXCEPTION block) therefore dropped buffered rows of the outer  
transaction without running their FK checks, letting orphan rows commit  
behind a constraint that still reported itself valid.  The discard also  
left relations opened by the batch unclosed, producing "resource was not  
closed" warnings.  
  
Second, ri_FastPathEndBatch flushes by iterating the cache with  
hash_seq_search.  If flush-time user code inserts into a different  
fast-path FK table, a new entry is added to the cache mid-scan; it may  
land in a bucket the scan has already passed and never be reached, and  
ri_FastPathTeardown then destroys the cache without flushing it,  
silently dropping that check.  
  
Cleanly unwinding the cache on subxact abort would require tracking the  
originating subxact of each buffered row, since rows from different  
levels share an entry (the cache is keyed by constraint) and deferred  
constraints cannot be flushed early at a subxact boundary.  Rather than  
add that bookkeeping, confine batching to the top transaction level: in  
RI_FKey_check, when GetCurrentTransactionNestLevel() > 1, use the  
per-row fast path (ri_FastPathCheck) instead of buffering.  Rows checked  
inside a subtransaction are then verified immediately and roll back  
cleanly with their subtransaction, and the cache only ever holds  
top-level rows.  With the cache confined to the top level, a  
subtransaction abort has nothing of its own to discard, so  
ri_FastPathSubXactCallback is removed along with its registration.  
  
For the second defect, add a cache-wide flag (ri_fastpath_flushing) set  
while ri_FastPathEndBatch iterates the cache.  A re-entrant FK check  
arriving while the flag is set takes the per-row path rather than adding  
an entry to the cache being scanned, so no entry can be missed and torn  
down unflushed.  The flag is cleared in a PG_FINALLY so a flush that  
throws (a reported violation or an error from user code) does not leave  
it stuck.  As defensive insurance it is also cleared in  
ri_FastPathXactCallback() at transaction end.  
  
The per-row fast path still bypasses SPI and stays well ahead of the  
pre-19 SPI-based check.  A fuller fix that preserves batching across  
subtransactions -- whether by tracking the originating subxact of each  
buffered row or by per-subxact cache stacks merged into the parent on  
commit -- is left for a future release.  
  
The subtransaction-abort case is covered by a new regression test.  The  
mid-scan cross-table case depends on hash bucket placement and so is not  
reliably reproducible in a portable test, but the flag prevents it by  
construction.  
  
Reported-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reviewed-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/CAM527d9exRCdWrhJOnAxk_vACg7sr_yPoaJp_+uCFY0qP8v=aw@mail.gmail.com  

commit   : 67bd944c0e61baf01eae61fcf54cc96011455ebb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 11:08:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 11:08:33 +0900    

Commit a70bce43fb added instructions on how to recover if PostgreSQL  
refuses to issue new transaction IDs because of imminent wraparound,  
but when describing how to find replication slots that should be dropped,  
it referred to pg_stat_replication where it should have referenced  
pg_replication_slots.  
  
In passing, decorate references to views with <structname> tags.  
  
Backpatch to all supported versions.  
  
Reported-By: Sanjaya Waruna <sanjaya.waruna@gmail.com>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/176767268098.1084085.10345048667224193115@wrigleys.postgresql.org  
Backpatch-through: 14  

commit   : 0e47bb5fbeec64d776d49dee242bac39d4616f8b    
  
author   : Amit Langote <amitlan@postgresql.org>    
date     : Fri, 12 Jun 2026 10:36:45 +0900    
  
committer: Amit Langote <amitlan@postgresql.org>    
date     : Fri, 12 Jun 2026 10:36:45 +0900    

The FK fast-path batching added in b7b27eb41a5 wrote the incoming row  
into the batch array before checking whether the array was full:  
  
    fpentry->batch[fpentry->batch_count] = ExecCopySlotHeapTuple(newslot);  
    fpentry->batch_count++;  
    if (fpentry->batch_count >= RI_FASTPATH_BATCH_SIZE)  
        ri_FastPathBatchFlush(fpentry, fk_rel, riinfo);  
  
batch_count is reset to zero only at the end of ri_FastPathBatchFlush(),  
so it remains at RI_FASTPATH_BATCH_SIZE throughout a full-batch flush.  
A flush runs user-defined cast functions and equality operators; if that  
user code performs DML on the same FK table, ri_FastPathBatchAdd()  
re-enters with batch_count == RI_FASTPATH_BATCH_SIZE and writes one past  
the end of the array, corrupting the adjacent batch_count field.  This  
is reachable by an unprivileged table owner via an implicit cast with a  
PL/pgSQL function and causes a SIGSEGV in assert-enabled builds.  
  
Fix by bounds-checking the write into the batch array so a re-entrant  
add can never write past the end, and by adding a "flushing" flag to  
RI_FastPathEntry that routes re-entrant ri_FastPathBatchAdd() calls on  
a busy entry to the per-row path (ri_FastPathCheck) instead of touching  
the mid-flush batch array.  The flag is set around the probe in  
ri_FastPathBatchFlush() and cleared in a PG_FINALLY, which also resets  
batch_count, so the entry is left empty and reusable if a flush error  
(including a reported FK violation) is caught by a savepoint.  
  
Add regression tests for both the re-entrant flush and reuse of an entry  
after a flush error caught by a savepoint.  
  
Reported-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reviewed-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://postgr.es/m/CAM527d9exRCdWrhJOnAxk_vACg7sr_yPoaJp_+uCFY0qP8v=aw@mail.gmail.com  

commit   : 8bf257aebac12791dc78a599e4f7dc225893d45e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 12 Jun 2026 10:25:45 +0900    

xpath() attempted to call xmlCopyNode() and xmlNodeDump() on a  
XML_NAMESPACE_DECL, finishing with a confusing error:  
=# SELECT xpath('//namespace::foo', '<root xmlns:foo="http://127.0.0.1"/>');  
ERROR:  53200: could not copy node  
CONTEXT:  SQL function "xpath" statement 1  
  
xpath() is changed so as it goes through xmlXPathCastNodeToString()  
instead, that is able to handle namespace nodes.  xml2 uses the same  
solution.  This issue has been discovered while digging into  
9d33a5a804db.  
  
Author: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/aioT7ui_ZJ9RMlfM@paquier.xyz  
Backpatch-through: 14  

commit   : 389bd4c5b93426e6616a0be7cff9cf91179c16e7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 09:35:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 09:35:27 +0900    

When amcheck validates that a B-Tree metapage's allequalimage flag  
matches _bt_allequalimage(), it could fail to report corruption  
unless one of the index key columns used interval_ops. As a result,  
pg_amcheck could silently miss this corruption on other opclasses,  
incorrectly reporting the index as valid.  
  
The mistake was that bt_index_check_callback() kept ereport(ERROR)  
inside the loop that scans key attributes for INTERVAL_BTREE_FAM_OID,  
even though that loop is only needed to decide whether to add  
the interval-specific hint. This commit moves ereport() out of the loop  
so allequalimage mismatches are always reported, while still emitting  
the hint for affected interval indexes.  
  
Back-patch to v18, where d70b17636dd introduced this regression  
while moving the check into bt_index_check_callback().  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/011ACC9C-CB87-4160-ACE7-4ED57AB86E15@gmail.com  
Backpatch-through: 18  

commit   : 44196fd4f378d776c4cd7282256f4d6df03b5734    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 08:32:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2026 08:32:39 +0900    

MD5 authentication warnings are queued during authentication, before  
startup options and role/database settings have been applied. The code  
checked md5_password_warnings at queue time, so settings such as  
ALTER ROLE ... SET md5_password_warnings = off did not suppress the  
warning, even though the established session showed the GUC as off.  
  
Keep the connection-warning infrastructure generic by allowing each  
queued warning to carry an optional filter callback. Evaluate that  
callback when warnings are emitted, after startup options and  
role/database settings have been processed.  
  
Use this for MD5 authentication warnings, while leaving password  
expiration warnings unchanged. Add test coverage for an MD5-authenticated  
role with md5_password_warnings disabled.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/AE46E42D-5966-4D76-9E64-95EAB01B9FB5@gmail.com  

commit   : 99db753c656946bfd1d4ddd3978ebfcee6fb86c0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 11 Jun 2026 15:55:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 11 Jun 2026 15:55:44 -0400    

Since this is trying to add a SharedInvalRelSyncMsg rather than  
a SharedInvalRelcacheMsg, it should use rs rather than rc.  
  
This makes no difference as things stand, because the two structure  
definitions are identical (except for the capitalization of "relid"),  
but it's still a good idea to fix it.  
  
Co-authored-by: Stolpovskikh Danil <d.stolpovskikh@ftdata.ru>  
Co-authored-by: Robert Haas <rhaas@postgresql.org>  
Discussion: http://postgr.es/m/bd6a5735b72b4afe99af49c3c62901d6@localhost.localdomain  

commit   : 3692a622d3fdf8a44af0c0b541a51163ead314f1    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 11 Jun 2026 18:29:36 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 11 Jun 2026 18:29:36 +0200    

In a few places, we were constructing translatable strings consisting of  
elements list by adding one element at a time and separately a comma.  
This is not great from a translation point of view, so rewrite to append  
the comma together with the corresponding element in one go.  
  
Author: Peter Smith <smithpb2250@gmail.com>  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAHut+Pvp7jYcaiZ3pXedXgLcWZWDBLXFUK05JtZpGv3Mj=UOjw@mail.gmail.com  

commit   : 7dd15325952fe85521b1fefea3ad39cf1b46e0c8    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 11 Jun 2026 16:17:58 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 11 Jun 2026 16:17:58 +0200    

transformJsonParseArg() was not careful enough on generation of  
transformed expressions when starting from expressions that are not  
coercible to text but are in the string type category: it failed to  
verify that coerce_to_target_type() succeeds, and returned a NULL  
pointer.  This leads to a later NULL dereference and crash at executor  
time.  
  
This escaped noticed because it cannot happen for built-in types, all of  
which have casts to text.  Only user-created types are potentially  
problematic.  
  
Fix by raising an error when a cast to text doesn't exist.  
  
This mistake came in with commit 6ee30209a6f1.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reported-by: Chi Zhang <798604270@qq.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Backpatch-through: 16  
Discussion: https://postgr.es/m/19491-7aafc221ec63f288@postgresql.org  

commit   : 79c65b9d97fe92ea2792be09479cf4bbea7cefe1    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 11 Jun 2026 12:08:47 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 11 Jun 2026 12:08:47 +0100    

When parsing expressions like (old).colname and (old).* in a RETURNING  
list, the parser would lose track of the intended varreturningtype,  
and therefore return incorrect results.  
  
The root cause was code using GetNSItemByRangeTablePosn() to find a  
namespace item from its rtindex and levelsup, without taking into  
account returningtype, which would return the wrong namespace item.  
Fix by adding a new function GetNSItemByVar() that does take  
returningtype into account.  
  
Backpatch to v18, where support for RETURNING OLD/NEW was added.  
  
Bug: #19516  
Reported-by: Marko Grujic <markoog@gmail.com>  
Author: Marko Grujic <markoog@gmail.com>  
Suggested-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Discussion: https://postgr.es/m/CAOvwyF2cO_5mAt=w=y-dFnaG5UkZ+3H8nSDoKF_iuWZHsU2ARg@mail.gmail.com  
Backpatch-through: 18  

commit   : 0e1f1ed157e90741e12a3715909e1b2d71ff9344    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Jun 2026 12:33:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Jun 2026 12:33:48 +0300    

When printing the upper boundary of a seg interval, seg_out() decided  
whether to emit the certainty indicator ('<', '>' or '~') by testing the  
upper indicator (u_ext) for '<' and '>', but mistakenly tested the lower  
indicator (l_ext) for '~'.  This is a copy-and-paste slip from the  
symmetric code that prints the lower boundary a few lines above.  
  
The consequences for valid input were:  
  
  * A '~' on the upper boundary was dropped on output, e.g.  
    '1.5 .. ~2.5'::seg printed as '1.5 .. 2.5'.  
  
  * When the lower boundary carried '~' but the upper boundary had no  
    indicator, the wrong test matched and sprintf(p, "%c", seg->u_ext)  
    wrote a NUL byte (u_ext == '\0'), which truncated the result string  
    and silently lost the entire upper boundary, e.g.  
    '~6.5 .. 8.5'::seg printed as '~6.5 .. '.  
  
Certainty indicators are documented to be preserved on output (they are  
ignored by the operators, but kept as comments), so this broke the  
input/output round-trip for the affected values.  
  
The bug has existed since seg was added.  It went unnoticed because the  
existing regression tests only exercised certainty indicators on  
single-point segs, which are printed by a different branch of seg_out().  
Add tests that place indicators on both boundaries of an interval.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CAON2xHPYeRRCEVAv8XfE18KsEsEHCiYcJ5fOsoxFuMEfpxF1=g@mail.gmail.com  
Backpatch-through: 14  

commit   : eb4e7224a1c6f0058d708cdfda7326bbf884a871    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 17:28:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 17:28:57 +0900    

During promotion, there is a window where RecoveryInProgress() returns  
true but the WAL segments of the old timeline have already been removed.  
A logical decoding could pick up the old timeline in this window when  
reading a page, failing with the following error:  
ERROR: requested WAL segment ... has already been removed  
  
This issue does not lead to any data correctness issue, as retrying to  
decode the data works in follow-up decoding attempts.  It impacts  
availability, though.  Other WAL page read callbacks have a similar  
issue, this commit takes care of what should be the noisiest code path:  
logical decoding with START_REPLICATION in a WAL sender.  
  
A TAP test, based on an injection point waiting in the startup process  
after the segments have been removed/recycled, is added.  This part is  
backpatched down to v17.  
  
This issue has been causing sporadic failures in the buildfarm, and  
was reproducible manually.  This issue happens since logical decoding on  
standbys exists, down to v16.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/7daef094-abf3-4672-bc23-3df4763b16a3@gmail.com  
Backpatch-through: 16  

commit   : 987440b33a511482232c59a190cc16ae4feff9aa    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 11 Jun 2026 11:17:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 11 Jun 2026 11:17:54 +0530    

The subscription option max_retention_duration accepts an integer value  
representing a timeout in milliseconds, where zero means unlimited  
retention (no timeout).  Negative values have no useful meaning, but were  
silently accepted and stored in the subscription catalog.  
  
A negative value causes should_stop_conflict_info_retention() to always  
return true, because TimestampDifferenceExceeds() treats a negative  
threshold as already exceeded.  This stops dead tuple retention  
immediately rather than honoring the configured timeout.  
  
Fix by rejecting negative values for max_retention_duration during CREATE  
SUBSCRIPTION and ALTER SUBSCRIPTION.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/9232401A-DEEE-49E1-9D11-D14A776DB82B@gmail.com  

commit   : 9d33a5a804db48b254de7a0ad2fde03152f378e3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 14:29:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 11 Jun 2026 14:29:18 +0900    

pgxmlNodeSetToText() passed nodeTab[i]->doc to xmlNodeDump() without  
checking the node type, which could cause a crash as a  
XML_NAMESPACE_DECL maps to a xmlNs struct.  The passed-in code would  
then be dereferenced in xmlNodeDump().  
  
This commit switches the code to render XML_NAMESPACE_DECL nodes with  
xmlXPathCastNodeToString(), like xpath_table().  Some tests are added,  
written by me.  
  
Author: Andrey Chernyy <andrey.cherny@tantorlabs.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20260611031436.5afde3cb@andrnote  
Backpatch-through: 14  

commit   : 9d141466ff087230571e9c9dfd720deb94977253    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jun 2026 17:01:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jun 2026 17:01:45 -0400    

In pursuit of removing a Valgrind-detected leak, I inserted  
"pfree(pq_mq_handle);" into mq_putmessage's recursion-trouble-recovery  
code path, failing to notice that shm_mq_detach would have pfree'd  
that block just before (i.e., this particular code path did not leak).  
So now that was a double pfree.  We didn't notice because the  
recursion scenario isn't exercised in our regression tests, but  
Alexander Lakhin found it via code fuzzing.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/b8b40954-e155-41b3-9af8-ad4f261a1b64@gmail.com  

commit   : e18b0cb7344cb4bd28468f6c0aeeb9b9241d30aa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jun 2026 13:49:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jun 2026 13:49:26 +0900    

GetBufferDescriptor() was called before checking if the buffer is local.  
Such buffers have a negative ID, meaning that we could call  
GetBufferDescriptor() with a wrapped-around uint32 value causing a  
potential out-of-bound access to the BufferDescriptors array.  
  
This is harmless in the existing code for the current uses of  
MarkBufferDirtyHint(), but the author has found a way to make that  
buggy while working on a different patch set, and the order of the  
operations is wrong.  
  
Oversight in 82467f627bd4.  No backpatch is required, as this is new to  
v19.  
  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://postgr.es/m/CAExHW5uzRMYVZsXXS3HXXT0fG_sNrpUhUqwP4NorhaCqH9JDhA@mail.gmail.com  

commit   : b70d5672d0c5d4310965fcbc1c846c9d111a3046    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 10 Jun 2026 12:32:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 10 Jun 2026 12:32:59 +0900    

Commit 257c8231bf9 changed pg_buffercache_pages() to materialize its output  
directly into a tuplestore. As a result, the function ended up trusting  
a caller-supplied RECORD descriptors. That could lead to crashes  
if the supplied row definition did not match the actual returned values,  
for example by passing bool Datums to tuplestore_putvalues() with  
an incompatible descriptor.  
  
Fix this by constructing the correct tuple descriptor for  
pg_buffercache_pages() and assigning it to  
rsinfo->setDesc after InitMaterializedSRF(). This restores the executor's  
tupledesc_match() verification, so incompatible caller-supplied  
row definitions are rejected with an error, as before commit 257c8231bf9.  
  
Bug: #19508  
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Ashutosh Sharma <ashu.coek88@gmail.com>  
Discussion: https://postgr.es/m/19508-e5f188183279219b@postgresql.org  

commit   : bf5206f007732c64f857e6bc214f77b5f31efc6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jun 2026 10:56:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jun 2026 10:56:23 +0900    

These schema qualifications have been missed by 2f094e7a (recent),  
8185bb53 (recent) and 923def9a533a (much older, down to v15).  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Tingchuan Sun <suntingchuan1996@163.com>  
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Discussion: https://postgr.es/m/C809E3C7-2437-486E-B626-0BE5F40BBB6C@gmail.com  

commit   : 93a3e6839bf8d2e0498291335191b57ddf458b48    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 9 Jun 2026 11:19:27 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Tue, 9 Jun 2026 11:19:27 -0700    

EnableLogicalDecoding() sets xlog_logical_info to true, emits a  
procsignal barrier, sets logical_decoding_enabled to true, and then  
writes a WAL record. If the activating backend is interrupted between  
these steps, a PG_ENSURE_ERROR_CLEANUP() callback runs to undo the  
partial activation.  
  
The previous callback asserted that logical_decoding_enabled was still  
false and then cleared xlog_logical_info. Both actions were unsafe  
when a second backend was concurrently activating: the peer backend  
might have already observed xlog_logical_info as true, set  
logical_decoding_enabled to true, and written the activation WAL  
record before our callback fired, causing the first backend to hit the  
assertion failure.  
  
Fix this by having the abort callback call  
RequestDisableLogicalDecoding(), allowing the checkpointer to undo the  
partial activation in the same manner as a normal deactivation. This  
simplifies the logic by unifying the activation abort and deactivation  
paths. While this approach now wakes up the checkpointer when an  
activation is interrupted, this should not be a serious issue in  
practice since such interruptions are rare.  
  
Add a test case to 051_effective_wal_level.pl.  
  
Reported-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/788B5B8A-BC22-48D8-818E-7B00416CF84E@gmail.com  

commit   : cd7b204b2df99516a48a738e662d8512e706b519    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 9 Jun 2026 20:12:55 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 9 Jun 2026 20:12:55 +0200    

Nothing is to be gained from using pgrepack outside of REPACK  
(CONCURRENTLY), and it leads to assertion failures in assertion-enabled  
builds, and to crashes due to bogus memory lifetime in production  
builds.  Reject attempts to do that with a clean error report.  
  
Clean up the nearby code a tad while at it.  The only functional changes  
in that are that the output_writer_private context is allocated and  
partially filled by the pgrepack output plugin; and that ->relid therein  
is now always present (rather than only in assertion-enabled builds).  
Other than that it's just minor code rearrangement and added comments.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>  
Suggested-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Antonin Houska <ah@cybertec.at> (older version)  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com> (older version)  
Discussion: https://postgr.es/m/19500-38a02529a69353a5@postgresql.org  

commit   : 9d8cdcbe0c8aee743e29079bdb2e4b5eeae4c70e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jun 2026 12:55:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jun 2026 12:55:47 +0200    

A view definition with GRAPH_TABLE depends upon the property graph it  
references as well as the properties and labels referenced in it.  We  
recorded the dependency on the property graph, but did not record  
dependency on labels and properties.  This allowed properties or  
labels referenced by a view to be dropped, resulting in a cache lookup  
error when such a view was accessed.  Fix this bug by handling  
GraphPropertyRef and GraphLabelRef in find_expr_references_walker().  
The dependency on the data type of property does not need to be  
recorded separately as it is recorded indirectly via a dependency on  
the property graph property itself.  
  
Note that a property or a label associated with individual elements  
can still be dropped as long as there are other elements that are  
associated with that property or label, since they do not lead to  
dropping the property or the label from the property graph altogether.  
  
Reported-by: Man Zeng <zengman@halodbtech.com>  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/tencent_43D9888041FA4FDE498C7BF1%40qq.com  

commit   : bd4bd30ce6a7f08e95390c3fa068f2bfbe9fcee8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 9 Jun 2026 08:18:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 9 Jun 2026 08:18:41 +0900    

Commit 85c17f6 mistakenly declared a variable storing catalog_xmin as  
XLogRecPtr, even though catalog_xmin is a TransactionId.  
  
This caused no functional issue, but the type was clearly incorrect.  
Therefore, this commit fixes it to use the correct type TransactionId  
instead, and backpatch to v17 where the issue was introduced.  
  
Author: Imran Zaheer <imran.zhir@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CA+UBfa=mNeLt-4BFjEP4tqdDsnq+oMqqPr7fd9Wji2_9YXmQdA@mail.gmail.com  

commit   : 1c77203c15e43d4ae9a8fed67ce89eeeca54af8f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2026 13:10:40 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2026 13:10:40 -0700    

No known problem today, but defend against issues like dbf217c1c7 in  
the future.  
  
Discussion: https://postgr.es/m/d080287d8d2d14c246c86be2e9eb611fb6b27b11.camel@j-davis.com  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Backpatch-through: 17  

commit   : f52c44ce48a61dd99d8ea545a57da95e62b084e4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2026 15:26:47 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2026 15:26:47 -0400    

There previously were a number of issues:  
  
- We'd upload the cache even if we already had a high hit rate. That means we  
  churn through the available cache space very quickly.  
  
  For this we now check if the cache hit ratio is already high, and skip  
  uploading a new cache in that case.  
  
- We'd generate per-branch caches, even if master's already would suffice,  
  because the branch doesn't change much  
  
  This is solved indirectly by the above.  
  
- The cache key allowed prefix matches based on the branch,  
  e.g. master-pending would always use master's branch  
  
  Replace the cache key element separator of - with :, which is not a valid  
  part of a branch name.  
  
- When rebasing a feature branch, we'd start with just that branch's cache,  
  rather than also having the newer cache of master available  
  
  This is solved by downloading by master's and the feature branch's cache,  
  simply overlaying both. That's possible because ccache is content addressed.  
  
- The size of a cache would increase to the max, even though there likely will  
  be no benefit from old cache entries.  
  
  Address this by explicitly evicting old data and also recompressing the  
  cache before uploading it.  
  
In my testing this utilizes the available cache space (10GB for personal  
accounts) much more effectively than before.  
  
The not entirely trivial determination of whether it's worth uploading a cache  
entry is moved to a python script.  I first had it as shell, but that gets  
awkward.  This way it'd also be more viable to use ccache for msvc at some  
point.  
  
The per-job redundancies are a bit annoying. There's a way around that, by  
using composite actions, but I think that might be harder to understand,  
without all that much of an improvement.  
  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Discussion: https://postgr.es/m/7eugqon2ilnaq6yimtq7prtl5wlia43mhpmwlydzlw4u4wonaz@hh2fagz5bjuu  

commit   : 4b1e18b0573b6630feb3d794930be1005016077d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Jun 2026 15:23:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Jun 2026 15:23:48 -0400    

Strings built by this function are not supposed to be subject to  
NLS translation, but commit 6566133c5 missed that memo, so that  
object identities like "membership of role %s in role %s" were  
translated.  

commit   : 9234e333711ef9875a4cef31889e88439421c396    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2026 11:47:53 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 8 Jun 2026 11:47:53 -0700    

Previously, outlen was miscalculated if case_sensitive was false and  
str_tolower() changed the byte length of the string. If outlen was too  
large, pnstrdup() would stop at the NUL terminator, preventing  
overrun. But if outlen was too small, it would cause truncation.  
  
Fix by just removing outlen. It was only used in a single site, which  
could just as well use pstrdup().  
  
Discussion: https://postgre.es/m/1101e1a3afbbabb503317069c40374b82e6f4cac.camel@j-davis.com  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Backpatch-through: 14  

commit   : a0354e29c41a9fb7491b3c7c23f079b1923c045a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 8 Jun 2026 13:42:50 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 8 Jun 2026 13:42:50 -0400    

This reverts commit a0b6ef29a51818a4073a5f390ed10ef6453d5c11, along with  
its follow-up 2e123e3c2bd34f2377212a4e7cfcdbf9e2d9c7ff ("Silence compiler  
warning from older compilers"), which only adjusted code introduced by  
the former.  
  
The change failed with an empty table and an invalid default, and the  
best way to deal with that will involve an addition to the TAM API, so  
it's not ready for relese 19 now.  
  
Discussion: https://postgr.es/m/7033D663-DDB4-4B35-922C-F33DE53B1502@gmail.com  

commit   : fb23cc7e81db181bfb3dcfed6ad0731a3473d4e1    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 8 Jun 2026 19:49:54 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Mon, 8 Jun 2026 19:49:54 +0200    

Commit 0c8e082fba8d changed the time at which MyBackendType is assigned,  
breaking a careful choreography in syslogger to decide when to write  
messages to its own log files.  Fix by flipping a boolean at the  
(approximate) location where previously MyBackendType was set, instead  
of depending on MyBackendType directly.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Euler Taveira <euler@eulerto.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/ahP-JT4ZRPyobnLb@paquier.xyz  

commit   : 7d13b03a2e677b78047cf537e519166dcbafa117    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2026 19:18:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2026 19:18:58 +0200    

ExecForPortionOfLeftovers() assumed that any result relation with  
ri_RootResultRelInfo should reinsert temporal leftovers through the  
root relation.  That is correct for partitioned tables, where tuple  
routing is needed, but it is wrong for plain inheritance.  
  
When UPDATE/DELETE FOR PORTION OF is run on an inheritance parent and  
a child row is split, the leftover rows must be inserted back into the  
child relation.  Reinserting through the parent can lose child-only  
columns and place the leftover rows in the wrong relation.  
  
Fix this by distinguishing partitioned-table routing from plain  
inheritance.  For partitioned tables, keep using the root leftover  
slot and insert through the root relation.  For plain inheritance  
children, use a leftover slot matching the child relation and insert  
directly into the child.  Also keep translating the application-time  
column attno for child relations, so multiple-inheritance cases with  
different attribute numbers are handled correctly.  
  
Added an ExecInitForPortionOf function to set up the ForPortionOfState  
for each child table, which keeps most of these decisions localized  
instead of spread out through ExecForPortionOfLeftovers.  Incidentally  
clarified a comment about the rangetype stored in ForPortionOfState.  
  
Add regression tests for UPDATE and DELETE FOR PORTION OF on  
inheritance children, including a multiple-inheritance case where the  
range column has a different attnum in the parent and child.  
  
Author: jian he <jian.universality@gmail.com>  
Co-authored-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://www.postgresql.org/message-id/flat/4245F94D-84F1-4E05-BF81-C458A6CF9901%40gmail.com  

commit   : 06e94eccfd910225a78f3510700bc89c1d88782f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Jun 2026 11:48:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Jun 2026 11:48:07 -0400    

The operators for array_eq, record_eq, range_eq, and multirange_eq  
are all marked oprcanhash, but there's a pitfall: their hash functions  
can fail at runtime if the contained type(s) are not hashable.  
Therefore, the planner has to check hashability of the contained types  
before deciding it can use hashing in these cases.  Not every place  
had gotten this memo, and noplace at all had considered the issue  
for ranges or multiranges.  In particular we could attempt to use  
hashing for a ScalarArrayOpExpr on a container type when it won't  
actually work, leading to "could not identify a hash function ..."  
runtime failures.  
  
For the most part we should fix this in the lookup functions provided  
by lsyscache.c, to wit get_op_hash_functions and op_hashjoinable.  
But there's a problem: get_op_hash_functions is not passed the input  
data type it would need to check.  We mustn't change the API of that  
exported function in a back-patched fix, and even if we wanted to,  
its call sites in the executor mostly don't have easy access to the  
required data type OID.  Fortunately, the executor call sites don't  
actually need fixing, because it's expected that the planner verified  
hashability before building a plan that requires it.  Therefore,  
leave get_op_hash_functions as-is and invent a wrapper function  
get_op_hash_functions_ext that does the additional checking needed  
in the planner's uses.  
  
We also need to fix hash_ok_operator (extending the fix in 647889667).  
  
While at it, neaten up a couple of places in lookup_type_cache where  
relevant code for multirange cases was written differently from the  
code for other container types.  
  
Note: while this touches pg_operator.dat, it's only to add oid_symbol  
macros.  So there's no on-disk data change and no need for a  
catversion bump.  
  
Reported-by: Andrei Lepikhov <lepihov@gmail.com>  
Author: Andrei Lepikhov <lepihov@gmail.com>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/ed221f95-f09b-4a9c-b05b-e1fed621ec87@gmail.com  
Backpatch-through: 14  

commit   : 1541d91d1ccad2f1ac735574fabbacebf9ecbfa5    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 8 Jun 2026 10:33:52 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Mon, 8 Jun 2026 10:33:52 -0500    

The security team has received a couple of reports about potential  
SQL injection via refint's trigger arguments.  We discussed this  
while preparing CVE-2026-6637 and concluded that forcibly quoting  
these arguments is more likely to break working code than to  
prevent exploits.  Unlike data values, the table/column names come  
from trigger arguments, and there is little reason for a trigger  
author to put hostile inputs into those arguments.  So, let's  
document it accordingly.  
  
Reported-by: Nikolay Samokhvalov <nik@postgres.ai>  
Reported-by: Alex Young <alex000young@gmail.com>  
Reported-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com>  
Suggested-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Christoph Berg <myon@debian.org>  
Reviewed-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com>  
Discussion: https://postgr.es/m/ahXP7z7nsfGPOZ3T%40nathan  
Backpatch-through: 14  

commit   : f58623faa856cfac67f1ff54b951f82f81fa1f59    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 8 Jun 2026 11:03:54 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 8 Jun 2026 11:03:54 +0200    

Fixing incorrect spelling and breaking up a long sentence.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Thom Brown <thom@linux.com>  
Discussion: https://postgr.es/m/CAA-aLv5pZNZbdhPG2Wu0fzyKCjn9TTzN9QZ=JONPyqZQKhBV=g@mail.gmail.com  

commit   : 4484165b0712f09ca369ed497fc6f504b718abac    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 8 Jun 2026 17:07:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 8 Jun 2026 17:07:48 +0900    

Previously, ecpg accepted multiple descriptor header items in GET DESCRIPTOR  
and SET DESCRIPTOR, but generated broken C code when they were used.  
Although the grammar allowed this syntax, the implementation did not actually  
support it.  
  
This commit tightens the ecpg grammar so the header form of GET/SET DESCRIPTOR  
accepts only a single header item, matching the implementation and preventing  
generation of broken C code.  
  
Also update the documentation synopsis accordingly.  
  
Backpatch to all supported versions.  
  
Author: Masashi Kamura <kamura.masashi@fujitsu.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Reviewed-by: Lakshmi G <lakshmigcdac@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/OS9PR01MB13174AD7D1829D0644B6BB90E9447A@OS9PR01MB13174.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : 6ce035ffff444479e63ea6276d56e33cc8b991d9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 8 Jun 2026 12:19:29 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 8 Jun 2026 12:19:29 +0530    

pg_createsubscriber rejected duplicate --publication values while parsing  
command-line options, even when the duplicate names referred to  
publications in different databases. Since publication names are  
database-local objects, the same name is perfectly valid across multiple  
databases.  
  
This restriction was not a practical problem before commit 85ddcc2f4c,  
which added support for reusing pre-existing publications. After that  
change, users who have identically-named publications in multiple  
databases (a common convention) could not use the feature without renaming  
their publications.  
  
The analogous restriction on --subscription names is intentionally kept as  
they are reused as replication slot names, which are cluster-global, so  
allowing duplicate subscription names without additional guards could  
cause a slot-name collision. That work is left for a future release.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Shlok Kyal <shlok.kyal.oss@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>  
Discussion: https://postgr.es/m/B08A7C89-B3DE-4C1D-A671-32AD8BAB7E22@gmail.com  

commit   : b20c952ce70370b22ea7a206d7b674a322397d28    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 15:29:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 15:29:16 +0900    

When called from a parallel worker, this function calls initStringInfo()  
and pq_beginmessage(), causing a StringInfo allocation to happen twice.  
pq_endmessage() frees only the second allocation, with each call leaking  
~1 kB into the per-worker memory context.  This could cause a few  
hundred megabytes worth of memory to pile up until the worker exits (the  
message allocations happen in the parallel worker context), with the  
situation being worse the longer a parallel worker runs.  
  
Oversight in f1889729dd3.  
  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Reviewed-by: Sami Imseih <samimseih@gmail.com>  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Discussion: https://postgr.es/m/CA+fm-RMopta1Dmq8udiU5sp+zwTvhUf4+xfbr3rZDfczH+p-xw@mail.gmail.com  
Backpatch-through: 17  

commit   : a450dd7ad4ff80c65f565f1a2bd24be8ff0bf3e3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2026 07:55:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jun 2026 07:55:01 +0200    

commit   : da51d9154deba7907062206d190dcd5730fe77f2    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 8 Jun 2026 11:26:25 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 8 Jun 2026 11:26:25 +0530    

Author: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CAHut+Pu7Zxm3oU7OyK3FVXRuDO+V6143adGUC6nnSrhqizYqQQ@mail.gmail.com  

commit   : 3d0d6741d810fbab894905b4945f4dc4e827c4ff    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 14:37:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jun 2026 14:37:51 +0900    

When a table's columns are narrower than the record header line, the  
expanded aligned format produced misaligned output because the data  
column width was not adjusted to match the record header width, leading  
to output like:  
+-[ RECORD 1 ]-+  
| a | 10 |  
| b | 20 |  
+---+----+  
  
This commit adjusts the output so as the column width match with the  
header line, giving:  
+-[ RECORD 1 ]-+  
| a | 10       |  
| b | 20       |  
+---+----------+  
  
Author: Pavel Stehule <pavel.stehule@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAFj8pRCzGpsr9zTHbtTd4mGh2YPJqOEgLgt8JLiopuYA9_1xGw@mail.gmail.com  
Backpatch-through: 14  

commit   : 75dcc63dac0ef183774ec22a6557174ee36db601    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 8 Jun 2026 10:59:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 8 Jun 2026 10:59:05 +0530    

In AlterSubscription(), when the SET clause includes both  
retain_dead_tuples and origin options, the origin branch was using  
assignment (=) rather than bitwise-or assignment (|=) when setting  
check_pub_rdt. This meant that if retain_dead_tuples had already set the  
flag to true in the same command, the origin branch would silently  
overwrite it. As a result, the publisher-side retain_dead_tuples check  
could be incorrectly skipped.  
  
Fix by changing the assignment to |= so that the flag accumulates across  
both option branches within the same ALTER SUBSCRIPTION command.  
  
Author: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CAHg+QDfe7WPOhVGKzv83ZB+BmXM88r=KPQn1sa_ZXMMChcNo=A@mail.gmail.com  

commit   : eb77a521996f6b7900dc0dfe6346f7e3c88455bb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 7 Jun 2026 23:27:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 7 Jun 2026 23:27:28 -0400    

Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/aiQPgZtALNqj4npv@alvherre.pgsql  

commit   : 89eafad297a9b01ad77cfc1ab93a433e0af894b0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 6 Jun 2026 16:45:29 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 6 Jun 2026 16:45:29 +1200    

TupleDescFinalize() failed to take into account virtual generated  
columns, which are always stored as NULL in tuples.  TupleDescFinalize()  
didn't check for this, and that could result in attcacheoff being set for  
and beyond virtual generated columns.  Also, the TupleDesc's  
firstNonGuaranteedAttr could also be set incorrectly, which could result  
in the tuple deformation function deforming without checking for NULLs,  
and deforming using incorrectly cached offsets.  
  
This could result in tuples being deformed incorrectly, which could  
result in incorrect results, ERRORs or possibly a crash.  
  
This has been broken since c456e39113.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Reported-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: ChangAo Chen <cca5507@qq.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/A4BC563C-0CA3-4EF3-952A-EA41F9E5BF1E%40gmail.com  

commit   : 193a4ded94741ba9c24509540a5d586c11761e37    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:16:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Jun 2026 08:16:36 +0900    

heap_force_common() declared a boolean array indexed with an  
OffsetNumber for a size of MaxHeapTuplesPerPage.  OffsetNumbers are  
1-based, so an input TID whose offset number equals MaxHeapTuplesPerPage  
wrote one byte past the end of the stack array, crashing the server.  
  
Like heapam_handler.c, this commit changes the array so as it uses a  
0-based index, substracting one from the OffsetNumbers.  
  
Reported-by: Wang Yuelin <violin0613@tju.edu.cn>  
Reviewed-by: Ashutosh Sharma <ashu.coek88@gmail.com>  
Discussion: https://postgr.es/m/20260604002256.40f1fd544@smtp.qiye.163.com  
Backpatch-through: 14  

commit   : 4cb2e2fe0aa8251bef8c2e2351cd5a062c105c0a    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 6 Jun 2026 00:18:30 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 6 Jun 2026 00:18:30 +0200    

Document that OAuth validators can return an authenticated identity  
in the authn_id member.  The server records the identity value before  
checking if the connection is authorized, so it may appear in  
connection-authentication logs (even if the connection later fails  
authorization).  
  
Also remove outdated wording saying that all result parameters are  
ignored when a validator returns false since validators may provide  
error_detail.  
  
Patch by Chao Li with some additional wordsmithing by me.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reported-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/0281836A-F5FF-41A5-9EE1-656C1FAAC6B2@gmail.com  

commit   : 55136e378c6bfc2240043d0edee6f92924e2c9fd    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 5 Jun 2026 22:16:42 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 5 Jun 2026 22:16:42 +0200    

With TLS 1.3 the concept of curves was renamed to groups.  Update  
our wording to use groups instead of curves to make it clear what  
the underlying GUC can support.  
  
This was extracted from a slightly larger patch which also renamed  
variables to match the new terminology.  Given that we are in beta  
this portion was however left as a future excercise.  
  
Author: Evan Si <evsi@amazon.com>  
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>  
Discussion: https://postgr.es/m/23C40DD6-1C47-46FC-A746-8A1D8530AD3E@amazon.com  
Backpatch-through: 18  

commit   : 4ebae546accf6ff0daee2f171f5d6907771b76f6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jun 2026 14:05:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jun 2026 14:05:01 -0400    

commit   : 1fbe2066dcc882321e87fdac43b942b890338f34    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 5 Jun 2026 12:08:05 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Fri, 5 Jun 2026 12:08:05 -0500    

Presently, refint stores plans in a per-backend cache to avoid  
re-preparing in each call.  This has a few problems.  For one,  
check_foreign_key() embeds the new key values in its cascade-UPDATE  
queries, so a cached plan reuses the values from preparation.  
Also, the cache is never invalidated, so it can return stale  
entries that cause other problems.  There may very well be more  
bugs lurking.  
  
We could spend a lot of time trying to address all these problems,  
but this module is primarily intended as sample code, and by all  
indications, it sees minimal use.  Furthermore, there is a growing  
consensus for removing refint in v20.  However, since we'll need to  
support it on the back-branches for a while longer, it probably  
still makes sense to fix some of the more egregious bugs.  
  
Therefore, let's just remove refint's plan cache entirely.  That  
means we'll re-prepare on every call, but that seems quite unlikely  
to bother anyone.  On v17 and older versions, the regression test  
for triggers fails after this change, so I've borrowed pieces of  
commit 8cfbdf8f4d to fix it.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: https://postgr.es/m/CAJTYsWXU%2BfhuzrEd_bnrxyGH3%2Bny8QRQC2QHf3ws6s9iki3c2Q%40mail.gmail.com  
Backpatch-through: 14  

commit   : b45137f315bb49fa4f50ae9cc16fda0a49196610    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jun 2026 11:38:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jun 2026 11:38:34 -0400    

Also remove duplicate psql tab completion authors.  
  
Reported-by: duplicates reported by Yugo Nagata  

commit   : e5e1f6dc795da65d430d59a813643739bed6cadb    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 5 Jun 2026 17:25:56 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 5 Jun 2026 17:25:56 +0200    

The message sent to pg_stat_activity when waiting for transactions to  
end was long enough that it could get truncated when the xid included  
in the string grew large. Fix by rewording to avoid truncation, using  
a similar message in the logical replication code as inspiration.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: ChangAo Chen <cca5507@qq.com>  
Discussion: https://postgr.es/m/tencent_47CA9CE2F91FF4D81D875E162AD69AA4900A@qq.com  

commit   : 4cb2a9863d89b320f37eb1bd76822f6f65e59311    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jun 2026 09:27:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jun 2026 09:27:31 +0200    

When rewriting a GRAPH_TABLE into a subquery,  
replace_property_refs_mutator() bumps levelsup of lateral references  
by one so that they reference outside the subquery.  This works for  
path patterns that result in only one path query.  Patterns that  
produce multiple path queries are rewritten as a UNION of path  
queries.  Since every path query becomes a subquery of the UNION  
statement, the levelsup of lateral references in those path queries  
need an additional bump.  This adjustment was missing resulting in the  
lateral references being interpreted as references in the UNION query  
itself.  This caused different symptoms like a crash in  
create_lateral_join_info() or error "plan should not reference  
subplan's variable".  The symptoms varied depending on the number of  
RangeTblEntries in the UNION statement.  
  
This commit adds the missing adjustment.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Author: Satya Narlapuram <satyanarlapuram@gmail.com>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDfnLzsgjaQ_CiKSpP4JH3MKOiwoawEcCzXa9uYr45yiWw%40mail.gmail.com  

commit   : 72498a86989e3491228ba09be43eab778a3ac943    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jun 2026 08:59:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jun 2026 08:59:05 +0200    

getObjectTypeDescription() and getObjectIdentityParts() do not handle  
objects in pg_propgraph_element_label and pg_propgraph_label_property  
catalogs.  These functions when called for handling DDL that affects  
these objects cause an "unsupported object class" error.  An error is  
reported when these functions are called via pg_identify_object() and  
pg_identify_object_as_address() with objects from the said catalogs.  
  
The objects in these catalogs do not have a (user-given) name but they  
can be manipulated individually through ALTER PROPERTY GRAPH  
sub-commands.  Hence they need to be accessible to the event triggers.  
Handle these catalogs in the respective functions.  
  
Reported-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Author: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>  
Discussion: https://www.postgresql.org/message-id/aej1DkLwhyZWmtxJ@bdtpg  

commit   : 9ec568b3eb6a8e8aad9041078e4c7bfedf293ca8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 14:29:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 14:29:27 +0900    

xslt_process() parses the stylesheet text into an xmlDoc before passing it  
to xsltParseStylesheetDoc().  On success, the returned stylesheet owns  
that document and frees it through xsltFreeStylesheet(), calling  
xmlFreeDoc() at its end.  On failure, libxslt leaves the caller  
responsible for the xmlDoc.  In xml2, this would cause the memory  
allocated for the xmlDoc to pile up across calls of xslt_process() when  
failing to create a sheet.  
  
While on it, I have double-checked the code of xml2 with libxslt, and it  
seems that we are in the clear now, hopefully..  This leak exists for a  
long time.  732061150b0 has made the fix introduced in this commit  
easier to implement.  
  
Author: Andrey Chernyy <andrey.cherny@tantorlabs.com>  
Discussion: https://postgr.es/m/20260605024642.5a1b6518@andrnote  

commit   : 1a5b19e447aa6c2743371dc559f697cf63c7ba82    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 5 Jun 2026 09:51:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 5 Jun 2026 09:51:55 +0900    

The subwalrcvtimeout column was added by commit fb80f38, but the  
column-level privileges on pg_subscription were not updated. As a  
result, non-superusers cannot read the column, unlike the other  
publicly readable pg_subscription columns.  
  
This commit grants SELECT privilege on subwalrcvtimeout to PUBLIC.  
  
Bump catalog version.  
  
Author: Nisha Moond <nisha.moond412@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CABdArM4uA=6nA0BunJwudiEoY1BcWUS_oj_2pkEq_d-YdiBJhw@mail.gmail.com  

commit   : f2ff15e4c37190e677437ecb76f706a05a645c6b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 07:50:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jun 2026 07:50:08 +0900    

The NFC recomposition incorrectly included TBASE as a valid T syllable,  
which is incorrect based on the Unicode specification (TBASE is one  
below the start of the range, range beginning at U+11A8).  
  
This would cause the TBASE to be silently swallowed in the  
normalization, leading to an incorrect result.  
  
A couple of regression tests are added to check more patterns with  
Hangul recomposition and decomposition, on top of a test to check the  
problem with TBASE.  Diego has submitted the code fix, and I have  
written the tests.  
  
Author: Diego Frias <mail@dzfrias.dev>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/B92ED640-7D4A-4505-B09F-3548F58CBB16@dzfrias.dev  
Backpatch-through: 14  

commit   : 4ae3e98c02cf57ba5e1d29e914a3b2e4d15f066f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 5 Jun 2026 00:12:33 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 5 Jun 2026 00:12:33 +0200    

The documentation for bin/pg_checksums refered to online processing only  
in passing, this extends the documentation to list online checksums as as  
alternative as well as providing a link to the new Data Checksums section.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Bruce Momjian <bruce@momjian.us>  
Reported-by: Bruce Momjian <bruce@momjian.us>  
Discussion: https://postgr.es/m/aiHKJWa1k28fFTqf@momjian.us  

commit   : 68c8a365d4dcefd7ec60f7a99a7ab7b557c36357    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 4 Jun 2026 14:55:57 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 4 Jun 2026 14:55:57 -0400    

As mentioned in the earlier commit, cirrus-ci has shut down. Therefore remove  
all files related to running CI via cirrus. Also update comments / code that  
were referencing cirrus-ci.  
  
Discussion: https://postgr.es/m/3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv%40yatlykpribmm  

commit   : 9c126063b19adc53a0ce15ac1ae1a70979e3c12e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 4 Jun 2026 14:55:57 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 4 Jun 2026 14:55:57 -0400    

Cirrus CI, which the project used for CI until now, has shut down on June 1,  
2026. Replace it with GitHub Actions. GitHub Actions was selected because it  
has unlimited runner time for public repositories.  
  
The GitHub Actions based CI currently covers:  
  
- SanityCheck  
- Linux - Autoconf  
- Linux - Meson, (32-bit and 64-bit)  
- macOS - Meson  
- Windows (Visual Studio + Meson and MinGW + Meson)  
- CompilerWarnings  
  
BSD coverage is left for later, as it requires more work.  
  
Note that, for performance reasons, use of address sanitizer was moved to the  
Linux - Meson (64-bit) task.  
  
While Actions workflows in new forks are disabled by default, existing forks  
that pull new changes into the repository will automatically start running  
CI. That may not be desired. There however is no way native to Actions to  
prevent this.  
  
To avoid that, each repository that wants real CI to run needs to explicitly  
opt into doing so, by creating the 'PG_CI_ENABLED' repository variable with  
the value 1.  
  
To make that less confusing, emit a summary whenever we skip running CI, with  
a message explaining how to enable CI.  
  
The remaining cirrus-ci support will be removed in a subsequent commit, to  
make review easier.  
  
Back-branches will be updated later, after being sure that workflow runs  
correctly on master.  
  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Author: Andres Freund <andres@anarazel.de>  
Author: Jelte Fennema-Nio <postgres@jeltef.nl>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Discussion: https://postgr.es/m/3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv%40yatlykpribmm  

commit   : 7598b5383b16a562bd7e7732eda7d783b34f4615    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Jun 2026 12:26:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Jun 2026 12:26:38 -0400    

commit   : ce6bf3cd17d1f96c9c40d2915ef25580fbbc8be7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 12:24:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 12:24:51 -0400    

This commit addresses two related issues:  
  
tsvector_filter() assumed it could print an incorrect weight value  
with %c.  This could result in an invalidly-encoded error message  
if the database encoding is multibyte and the char value has its  
high bit set.  Weight values that are ASCII control characters  
could render illegibly too.  Fix by printing such values in octal  
(\ooo), similarly to how charout() would render them.  
  
tsvector_setweight() and tsvector_setweight_by_filter() reported  
the same unrecognized-weight error condition with elog(), as though  
it were an internal error.  That'd not translate, would produce an  
unwanted XX000 SQLSTATE code, and also reported the bad value as a  
decimal integer which seems unhelpful.  Fix by refactoring so that  
all three functions share one copy of the code that interprets a  
weight argument.  
  
The invalid-encoding aspect seems to me (tgl) to justify  
back-patching.  
  
Author: Ewan Young <kdbase.hack@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAON2xHNaeLAUzRCXL5AmXLcXaSE_gWAVjWQRmLzc_oZ=1_Vf4Q@mail.gmail.com  
Backpatch-through: 14  

commit   : c35f85ac02a1c19dbb40382a8098846ffc3b368b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 11:37:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 11:37:43 -0400    

Like 8f1791c61, this fixes a case of implicitly casting away  
const by not treating the result of strrchr() on a const pointer  
as const.  This was missed at the time because the machines  
reporting those warnings weren't building with --with-llvm.  
  
While here, clean up another infelicity: in the probably-  
impossible case that the input string contains only one dot,  
this function would call pnstrdup() with a length of -1  
and thereby emit a module name equal to the function name.  
It seems to me we should emit modname = NULL instead.  
  
Also remove a useless Assert and two redundant assignments.  
  
Back-patch, as 8f1791c61 was, so that users of back branches  
don't see this warning when building with late-model gcc.  
  
Reported-by: hubert depesz lubaczewski <depesz@depesz.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/aiGNJ89PBqvq2Yyz@depesz.com  
Backpatch-through: 14  

commit   : 4dce650cc1bb48d6a65503f17dff87085728e08b    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 4 Jun 2026 10:16:21 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 4 Jun 2026 10:16:21 -0500    

commit   : bd57abbb1910e51e45761b59985745d094ae9e03    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 4 Jun 2026 10:15:37 -0500    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 4 Jun 2026 10:15:37 -0500    

commit   : e88bd2736f86d66dc75ad8b2f7edd799d20b7d53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 10:37:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2026 10:37:25 -0400    

Various code assumed this was true already, and usually it is.  
However, it emerges that in a "universal" (multi-architecture)  
macOS build, configure will define USE_AVX2_WITH_RUNTIME_CHECK  
if the build host is x86_64, and then the arm64 half of the  
build fails.  
  
Ideally we'd get pg_config.h to define this symbol conditionally  
depending on defined(__x86_64__), but I don't see any way to  
persuade Autoconf to do that.  Instead, clean up the mess by  
#undef'ing it again in c.h for not-x86_64 builds.  
  
For consistency I made c.h also #undef the USE_AVX512... symbols.  
Those are not actively broken, but it seems only happenstance  
that configure's tests for them fail in a universal build.  
Down the road we may have occasion to add more #undef's here.  
  
This problem is new in v19, so no need for back-patch.  
  
Reported-by: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>  
Reported-by: Tobias Bussmann <t.bussmann@gmx.net>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/15574903-87C9-478A-B2D7-CC8F4C275DBB@gmx.net  

commit   : f0aedc7cb0ed82d4cca48332dc0852c767514558    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2026 11:57:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2026 11:57:55 +0200    

Author: jian he <jian.universality@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDcd%3Dt69gLf9yQexO07EJ2mx0Z70NFHo6h94X1EDA%3DhM0g%40mail.gmail.com  

commit   : 7ac030d5b152475275e84e0abe0b3628700fbeda    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2026 11:30:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2026 11:30:41 +0200    

It seems like the SQL standard does require this after all, and it  
makes sense because these columns get changed.  (This is not to be  
confused with *not* requiring INSERT permission to add the temporal  
leftovers.)  
  
Adding the column to RTEPermissionInfo->updatedCols also fixes a  
couple outstanding bugs from other (non-permission) features using  
that bitmapset to detect changes: GENERATED columns and UPDATE OF  
triggers.  This patch includes test cases to exercise those scenarios,  
including on partitioned tables.  
  
Author: Paul A. Jungwirth <pj@illuminatedcomputing.com>  
Reviewed-by: jian he <jian.universality@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDcd%3Dt69gLf9yQexO07EJ2mx0Z70NFHo6h94X1EDA%3DhM0g%40mail.gmail.com  

commit   : 993a7aa0e4af0922ac86d8914e0e78fc38fb0daf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2026 11:12:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jun 2026 11:12:58 +0200    

When we insert temporal leftovers after an UPDATE FOR PORTION OF, we  
must make a new copy of the tuple before each insert.  Otherwise, if  
an insert trigger assigns to attributes of NEW, the second leftover  
sees those changes.  
  
Author: Sergei Patiakin <sergei.patiakin@enterprisedb.com>  
Reviewed-by: Paul A Jungwirth <pj@illuminatedcomputing.com>  
Discussion: https://www.postgresql.org/message-id/flat/CANE55rCqcse_pwXBMWhbj3_7XROb8Dks6%3DOLFmKy3bO3zDsCsg%40mail.gmail.com  

commit   : 90354030b8fceecef9a1908fdefcccf0e02823fb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jun 2026 15:12:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jun 2026 15:12:11 +0900    

When "servicefile" is specified in a connection string but the requested  
service is not found in this file, libpq falls back to a default file,  
pg_service.conf in PGSYSCONFDIR.  The "servicefile" option was missing  
an update in this case, causing an incorrect value to be reported,  
impacting SERVICEFILE in psql, for example.  
  
An extra update of the option is added in this commit, based on the  
actual file where the service name has been found.  A test is added to  
cover this problem.  
  
Oversight in 092f3c63efc6.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/59DD1652-4EB5-449B-8DE3-959F06561A96@gmail.com  

commit   : 378668d50b44afb52688988de6651aa8585f3f5c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Jun 2026 14:21:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Jun 2026 14:21:05 -0400    

Also fix commit message cut/paste mistake, and add "tar" markup.  

commit   : 41ddb9c33eadc7fec0745b86943c87f3a465cd40    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Jun 2026 13:48:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Jun 2026 13:48:02 -0400    

commit   : 298bdd379552148f6043b4595374a7a6fbdd13c3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 3 Jun 2026 11:33:35 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 3 Jun 2026 11:33:35 +0300    

getIndexes() declared indAttNames and nindAttNames in the outer  
per-table loop, so the names collected for an index on expressions  
were carried over to the next plain index in the same table.  
  
This is an internal inconsistency rather than a user-facing bug.  
dumpRelationStats_dumper() only walks indexes that have pg_statistic  
rows, and ANALYZE only creates those for indexes with expressions,  
so the second index in the affected pair is not visited and the stale  
array is never consulted.  
  
Fix by moving the two variables into the inner per-index loop so each  
iteration starts with a clean slate.  
  
Author: Maksim Melnikov <m.melnikov@postgrespro.ru>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Discussion: https://postgr.es/m/be5fc489-587e-421f-bbb8-adb43cfd50f4@postgrespro.ru  
Backpatch-through: 17  

commit   : f2081a7800f1696cb0415bacd655cb41b7b9ca63    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2026 18:44:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2026 18:44:56 +0900    

When releasing an ephemeral replication slot, ReplicationSlotRelease()  
drops the slot via ReplicationSlotDropAcquired().  
  
However, after dropping the slot, ReplicationSlotRelease() continued  
to use its local "slot" pointer, which still referenced the dropped  
slot's former shared-memory entry. It could then update fields such as  
effective_xmin in that entry.  
  
Once an ephemeral slot has been dropped (via ReplicationSlotDropAcquired()),  
its slot array entry can be reused immediately by another backend  
creating a new slot. As a result, those updates could corrupt  
the state of an unrelated replication slot.  
  
Fix by skipping those shared-memory updates for phemeral slots and  
performing them only for non-ephemeral slots, whose shared-memory  
entries remain valid after release.  
  
Backpatch to all supported versions.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Masao Fujii <masao.fujii@gmail.com>  
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>  
Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com>  
Discussion: https://postgr.es/m/TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : eb8e76e130fd8bd42982d597f5a66f08b13380c0    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 3 Jun 2026 09:20:21 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 3 Jun 2026 09:20:21 +0100    

As with corr() and regr_r2(), improve regr_intercept()'s final  
function to cope with overflow/underflow in the final calculation.  
Here, instead of using sqrt(), we use frexp() and ldexp() to recover,  
if an overflow or underflow is detected, so that the multiplication  
and division steps operate on normalised mantissas, and cannot  
overflow or underflow.  
  
As with 6498287696d, and the previous commit improving regr_r2(), this  
is arguably a bug fix, but given the lack of prior complaints, refrain  
from back-patching.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Chengpeng Yan <chengpeng_yan@outlook.com>  
Discussion: https://postgr.es/m/33E01656-BB3B-46E9-A41F-24A01A7C35F4@outlook.com  

commit   : d58ec50e0faae364fa59cdb88eba7e23b55ab583    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 3 Jun 2026 09:01:13 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 3 Jun 2026 09:01:13 +0100    

Commit 6498287696d improved corr()'s final function to cope with  
overflow/underflow in the final calculation, and clamped its result to  
[-1, 1] in case of roundoff error. Improve regr_r2() in a similar way,  
clamping its result to [0, 1].  
  
Arguably this is a bug fix, but given the lack of prior complaints,  
refrain from back-patching, as we did with 6498287696d.  
  
Reported-by: Chengpeng Yan <chengpeng_yan@outlook.com>  
Author: Chengpeng Yan <chengpeng_yan@outlook.com>  
Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/33E01656-BB3B-46E9-A41F-24A01A7C35F4@outlook.com  

commit   : 95b6ec52e684e5de743e5bf4a2303f6cac466682    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2026 16:53:16 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2026 16:53:16 +0900    

Commit 6429e5b77 changed vacuumdb to process partitioned tables when  
--analyze-only or --analyze-in-stages is specified, matching the  
documented behavior of analyzing regular tables, partitioned tables,  
and materialized views.  
  
Later, commit c4067383cb2 accidentally changed this behavior so that  
partitioned tables were processed for --analyze-only, but skipped for  
--analyze-in-stages.  
  
As a result, vacuumdb --analyze-in-stages no longer matched its  
documentation. Partitioned tables were skipped, leaving parent-table  
statistics outdated even though users running vacuumdb  
--analyze-in-stages after pg_upgrade, restore, or bulk loading would  
expect statistics to be rebuilt for the database.  
  
Fix this issue by making --analyze-in-stages process partitioned  
tables again.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/EDFF0AFB-050F-4FBF-8D4F-B44DC454D957@gmail.com  

commit   : 273a3c77615e793089b2f41b666b6fcaa970a0c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 12:47:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 12:47:22 +0900    

The code failed to initialize the second isnull argument passed to  
FunctionCallInvoke().  This is harmless for existing in-core extended  
hash support functions, since FunctionCallInvoke() does not use the  
value (note that all the in-core extended hash functions are strict),  
examining only the argument values.  However, extension-provided  
extended hash functions could be affected if they inspect  
PG_ARGISNULL(1).  
  
Oversight in 01e658fa74cb.  
  
Author: Man Zeng <zengman@halodbtech.com>  
Discussion: https://postgr.es/m/tencent_7818173C01E01836109848C3@qq.com  
Backpatch-through: 14  

commit   : ffeda04259bb0b78e901c61e4b9d0ad86e786f4f    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Jun 2026 10:12:40 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Jun 2026 10:12:40 +0900    

Eager aggregation pushes a partial aggregate down to a base or join  
relation, to be finalized after that relation is joined with the rest  
of the query.  eager_aggregation_possible_for_relation() already  
refuses to do this for a relation on the nullable side of an outer  
join, but it failed to also refuse it for a relation on the inner side  
of a semijoin or antijoin.  
  
Such a join does not emit its inner rows, so a partial aggregate  
computed on the inner side does not survive the join and cannot be  
combined by the final aggregation.  This can happen only for an  
aggregate that references no table column, such as count(*): it is  
considered computable on any relation, including the inner one,  
whereas an aggregate that references a column is anchored to the outer  
side and never reaches the inner relation.  
  
The existing outer-join check did not catch this because it consults  
nulling_relids, which only tracks joins that null-extend their inner  
side.  Semijoins and antijoins formed from EXISTS, IN, NOT EXISTS, or  
NOT IN sublinks do not null-extend and carry no ojrelid, so they are  
invisible to that check.  
  
Fix by additionally rejecting any relation that includes inner-side  
relations of a semijoin or antijoin but not the join's outer side.  
Pushing a partial aggregate to the outer side of such a join, grouped  
by the join key, remains valid and is still allowed.  
  
Reported-by: Radim Marek <radim@boringsql.com>  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Discussion: https://postgr.es/m/CAJgoLk+d_P5sKrx-SZt01Acm_j0QnWn6aKJzFJ=waRu_3C8AoQ@mail.gmail.com  

commit   : ee2fa291c8b2f8abdbad57024b92652ac4a640ff    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Jun 2026 09:36:52 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Wed, 3 Jun 2026 09:36:52 +0900    

The check for window functions (point 4) guarded on the wrong bit: it  
tested UNSAFE_NOTIN_DISTINCTON_CLAUSE while setting  
UNSAFE_NOTIN_PARTITIONBY_CLAUSE.  Each check in this loop guards on  
the same bit it is about to set, as an idempotency optimization, since  
unsafeFlags[] is accumulated across the arms of a set operation and  
there is no point recomputing a column's status once its bit is  
present.  
  
This is not a live bug.  When UNSAFE_NOTIN_PARTITIONBY_CLAUSE is  
already set but UNSAFE_NOTIN_DISTINCTON_CLAUSE is not, the guard fails  
to skip targetIsInAllPartitionLists() and recomputes it, but setting  
the same bit again changes nothing.  When  
UNSAFE_NOTIN_DISTINCTON_CLAUSE is already set, point 4 is skipped and  
UNSAFE_NOTIN_PARTITIONBY_CLAUSE is left unset; but such a column is  
already unsafe for pushdown via UNSAFE_NOTIN_DISTINCTON_CLAUSE, so the  
outcome is unchanged.  
  
To fix, test UNSAFE_NOTIN_PARTITIONBY_CLAUSE, matching the bit being  
set and the pattern of the surrounding checks.  
  
Back-patch to v15, where the buggy check was introduced.  
  
Author: Richard Guo <guofenglinux@gmail.com>  
Reviewed-by: Tender Wang <tndrwang@gmail.com>  
Reviewed-by: David Rowley <dgrowleyml@gmail.com>  
Discussion: https://postgr.es/m/CAMbWs49Q_xnF_P2QSUyDzJ34MnrO7dh-cUAaK2HJPgSgh88NcA@mail.gmail.com  
Backpatch-through: 15  

commit   : d21604e17e491eef39626a2eff518b9731fefb91    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 08:58:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 08:58:26 +0900    

When an error is raised while processing a Sync message in a pipeline,  
like a deferred constraint violation, the error was not associated with  
the piped command and was not counted in available_results.  This caused  
assertion failures in discardAbortedPipelineResults(), keeping an  
incorrect state at pipeline exit, because the code assumed that the  
number of available and requested results would always be positive,  
expecting all the counters to be 0 at the end of a pipeline.  
  
This commit switches discardAbortedPipelineResults() and  
ExecQueryAndProcessResults() to take a softer approach when consuming  
and draining the results after an error.  If there are still piped syncs  
in the pipeline when it ends, we now attempt to consume them before  
leaving the pipeline mode.  
  
Alexander has been able to reach two assertion failures through his  
testing.  While investigating more this issue, I have bumped into two  
more.  Most of these cases are covered by the regression tests added in  
this commit, plus some cases with mixes of pipelines, deferred errors  
and results fetched.  Some of the tests discussed (like the backend  
termination one) could not be included in this commit but have been  
tested manually.  Another test scenario discussed involved the injection  
of an error state in the backend, that was able to trick libpq  
internally and put its queue out of sync.  This scenario is not going to  
happen in practice, but if we were to do something about it we would  
need to make libpq understand that it needs to fail in some cases but  
not block.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/19494-97a86d84fee71c47@postgresql.org  
Backpatch-through: 18  

commit   : a77bdb11e6ba47f1a3e8363411b84c7f35f676e2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 08:16:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jun 2026 08:16:42 +0900    

Several objects were allocated by libxml2 and never released in some  
error or even success paths, leading to some memory leaks that would  
stack across SQL calls:  
- In pgxml_xpath(), the result of xmlXPathCompiledEval() could leak.  
This now uses a TRY/CATCH block to ensure a correct cleanup of a  
workspace on failure.  
- In xpath_table() missed some objects not freed on failure.  Some  
xmlFree() calls were missing for the results copied after a success.  
- In pgxmlNodeSetToText(), xmlXPathCastNodeToString() allocates a result  
that the caller is responsible for freeing.  It was not freed.  
  
Most of the work of this commit stands on top of 732061150b0, that has  
refactored xml2 to make the handling of such leaks easier.  The leaks  
fixed here are more ancient than the commit mentioned above, and we have  
never bothered doing something about them in older stable branches.  
  
Author: Andrey Chernyy <andrey.cherny@tantorlabs.com>  
Co-authored-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/20260601010124.5edf9a20@andrnote  

commit   : 4b0bf0788b066a4ca1d4f959566678e44ec93422    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2026 16:02:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2026 16:02:13 -0400    

commit   : ef6a95c7c64de07dff4dd1f1da88ffae7b086ef3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jun 2026 12:13:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jun 2026 12:13:54 +0200    

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

commit   : 78ec4b69a0dc064fc8c65bf0711db5a32d030237    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 31 May 2026 23:19:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 31 May 2026 23:19:18 -0400    

commit   : 4ff61509881b708a96e7c0055038b46071f4b8b5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 31 May 2026 22:54:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 31 May 2026 22:54:03 -0400    

commit   : 39343218347b4bbd41bb8b4bbdac595695d59000    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 31 May 2026 16:17:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 31 May 2026 16:17:49 -0400    

commit   : 21298c2cd0cd8fe83e567f3f3f16475bd3934124    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 May 2026 17:49:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 May 2026 17:49:26 -0400    

commit   : 3e744cc745b894b3712990b84729f805e4333147    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 May 2026 14:55:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 May 2026 14:55:32 -0400    

These were previously marked as functions, not roles, and were in the  
wrong section.  
  
Reported-by: 彭冲 <chong.peng@enmotech.com>  
  
Discussion: https://postgr.es/m/tencent_5468291122A490C6578D9467@qq.com  

commit   : db5ed03217b9c238703df8b4b286115d6e940488    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 20 May 2026 08:49:15 +0800    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 20 May 2026 08:49:15 +0800    

The documentation says that when extension_control_path is set to an  
empty string, the default '$system' path is still assumed.  However,  
get_extension_control_directories() added the system extension directory  
with a NULL macro in that case.  As a result, pg_available_extensions  
could expose the expanded system directory path instead of reporting  
'$system' as the location.  
  
Record the implicitly-added system directory with the '$system' macro, so  
pg_available_extensions reports the documented symbolic location and does  
not leak the actual system path.  
  
Update the extension_control_path TAP test to check the reported location  
directly.  
  
Author: Chao Li <lic@highgo.com>  
Reviewed-by: Lu Feng <fnlo1995@gmail.com>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Jim Jones <jim.jones@uni-muenster.de>  
Discussion: https://postgr.es/m/357C774A-ECE9-4455-B641-315205D4D9A1@gmail.com  

commit   : 7dc5bbcf220be05786a08aad2455c61b6dbd4b78    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 20 Apr 2026 11:16:36 +0530    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 20 Apr 2026 11:16:36 +0530    

CopyToJsonOneRow() sent the output of composite_to_json() directly  
via CopySendData() without encoding conversion.  The text and CSV  
paths convert per-attribute via pg_server_to_any() when  
need_transcoding is true, but the JSON path skipped this entirely.  
  
This meant COPY ... TO ... WITH (FORMAT json, ENCODING 'LATIN1') on  
a UTF-8 server silently produced UTF-8 output, and COPY TO STDOUT  
with a non-UTF-8 client_encoding would send unconverted bytes to  
the client.  
  
Apply pg_server_to_any() to the whole JSON buffer after  
composite_to_json() returns, converting to the requested file  
encoding when it differs from the server encoding.  Tests cover  
both the explicit ENCODING option and the implicit case where  
file_encoding is inherited from client_encoding.  
  
Introduced by 7dadd38cda9 (json format for COPY TO).  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://postgr.es/m/CAJTYsWX-jsLzxGRAb-dWnEpGYRPbDYHwce8LctVE92LiDfM2Jw@mail.gmail.com  

commit   : 45b02984e2fa9ee7bd83f7e58797b160baf0cc13    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 30 May 2026 00:23:25 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Sat, 30 May 2026 00:23:25 +0200    

During REPACK CONCURRENTLY, logical decoding keeps replication  
slot.restart_lsn pinned behind the oldest running transaction, which is  
often the long-lived REPACK transaction itself. As a result, old WAL  
segments are retained longer than necessary.  
  
This commit advances the replication slot each time WAL insertion  
crosses a segment boundary, so obsolete WAL files can be recycled while  
REPACK is still running.  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
  
Discussion: https://postgr.es/m/TY4PR01MB17718B44164522D0798F8E898940A2@TY4PR01MB17718.jpnprd01.prod.outlook.com  

commit   : 08127c641c099b21480d4cd47c2706fe64ca1820    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 29 May 2026 14:40:20 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 29 May 2026 14:40:20 -0700    

During original feature development, the OAuth validator shutdown  
callback was invoked via before_shmem_exit(). That was changed to use a  
reset callback before commit, but I forgot to update the documentation  
for validator developers.  
  
Correct this and backport to 18, where OAuth was introduced. The  
callback is invoked whenever the server is "finished" with token  
validation. (We make no stronger guarantees here, in the hopes that this  
API might successfully navigate future multifactor authentication  
support and/or changes to the server threading model.)  
  
Reported-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CAN4CZFOuMb_gnLvCwRdMybg_k8WRNJTjcij%2BPoQkuQHDUzxGWg%40mail.gmail.com  
Backpatch-through: 18  

commit   : 89d243d52189ad426538012e0db9aad441240e68    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:52:35 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:52:35 +0200    

OpenSSL 4.0.0 changed some parameters and returnvalues to const, so  
we need to update our declarations and subsequently cast away const-  
ness from a few callsites to make libpq build without warnings. This  
is tested with OpenSSL 1.1.1 through 4.0.0 as well as with LibreSSL.  
No functional change is introduced, this commit only allows postgres  
to be compiled against OpenSSL 4.0.0 without warnings.  
  
There is also an errormessage change in OpenSSL 4.0.0 which needed  
to be covered by our testharness.  
  
This will be backpatched to all supported branches since they are  
all equally likely to be built against OpenSSL 4.0.0 as it becomes  
available in distributions.  Backpatching will be done once it has  
been in master for a few days without issues.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/066B07BB-85FA-487C-BE8C-40F791CFC3C4@yesql.se  
Backpatch-through: 14  

commit   : 5ab239c9a908ba5d8614d23fcdc425859a2fed3c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:25 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:25 +0200    

The launcher and worker for enabling/disabling checksums were named  
"datachecksum worker|launcher" but using the plural form makes more  
sense given the underlying GUC name data_checksums.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20260528.121622.1662808269492494574.horikyota.ntt@gmail.com  

commit   : 0ca1b3010597231b474d94d877ecc8266a473537    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:23 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:23 +0200    

The datachecksums launcher was using int for storing a PID, but  
the correct type is pid_t (which is defined to be a signed int).  
  
Author: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/f1281cf3-89a3-4936-9bc5-2a5a6291229f@vondra.me  

commit   : cd857dec0e0ae63dabf548d51fddb27c45561086    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:21 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:21 +0200    

Spelling fixes and rewording outdated information.  
  
Author: Tomas Vondra <tomas@vondra.me>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/f1281cf3-89a3-4936-9bc5-2a5a6291229f@vondra.me  

commit   : 5fee7cab1b8746c9e1bc25b20158cb074c7a76da    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:18 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 29 May 2026 21:26:18 +0200    

When a standby is promoted to primary during checksum enabling when the  
state is inprogress-on, the standby shall revert the state to off since  
checksums weren't fully enabled at the time of the crash.  Consider the  
following scenario:  
  
  1) primary/standby cluster has checksums off  
  2) primary starts enabling checksums  
  3) primary moves to inprogress-on  
  4) standby receives that and moves to inprogress-on too  
  5) primary crashes  
  6) standby gets promoted, and does the StartupXLOG thing  
  7) standby moves from inprogress-on back to off  
  
Any processes in the standby need to be informed at step 6 to change  
state with a procsignalbarrier, else they will stay in inprogress-on  
while new backends will see the state as off.  StartupXLOG failed to  
emit a procsignalbarrier which caused inconsistent state in the node  
promoted to primary.  
  
Fixed by emitting a procsignalbarrier during promotion, and adding a  
new test for this scenario.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: Tomas Vondra <tomas@vondra.me>  
Discussion: https://postgr.es/m/f1281cf3-89a3-4936-9bc5-2a5a6291229f@vondra.me  

commit   : 38470c2c1ea7dc0971d7abf65ef1dde80824ef43    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 May 2026 21:10:01 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 May 2026 21:10:01 +0200    

The existing logic computed an updated replicationSlotMinLSN from all  
slots' restart_lsn only when catalog_xmin also advanced.  This is not a  
problem in normal (non-repack) cases, because catalog_xmin changes  
pretty frequently, so the recomputation is triggered frequently enough.  
However, REPACK does not currently change its catalog snapshot, so that  
doesn't work very well if no other replication slot is being used.  
  
(After this commit, we still don't recycle WAL properly for REPACK,  
because its background worker is not advancing its restart_lsn either;  
that will be fixed in a separate commit.  However, this preexisting  
problem in older code is logically separate from that one.)  
  
Author: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/TY4PR01MB17718B44164522D0798F8E898940A2@TY4PR01MB17718.jpnprd01.prod.outlook.com  

commit   : 5d48d3b14e0e3a46e93b9f71b47205bebaab4b0e    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 May 2026 20:53:06 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 May 2026 20:53:06 +0200    

In reality, this changes nothing, since the signal handler in bgworkers  
is already die() since commit d62dca3b2974.  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/e60318b8-be75-4bfd-82f0-0829f51fa839@gmail.com  

commit   : 2368c14e9e205c5ee3cf0106bde028f2914f188a    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 29 May 2026 11:34:12 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 29 May 2026 11:34:12 -0700    

The existing documentation link for grease errors is fine, but something  
a little more user-friendly and updatable would be ideal, since the  
campaign won't last very long. The page  
  
    https://wiki.postgresql.org/wiki/Grease  
  
has been added for this purpose. (It's admin-protected, to avoid making  
it a spam target).  
  
Discussion: https://postgr.es/m/CAOYmi%2BkVfqgPAaR1QuY7%3DRPBYR6MsA3V3_f5%2BH-75uC06YCDDA%40mail.gmail.com  

commit   : 5ca41e4125e9822816a8c1fb79ec19077360b861    
  
author   : Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 29 May 2026 11:34:03 -0700    
  
committer: Jacob Champion <jchampion@postgresql.org>    
date     : Fri, 29 May 2026 11:34:03 -0700    

Double-quote the protocol extension name, and move it out of line with a  
%s specifier, to help with translation. Fixes up 4966bd3ed.  
  
Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Suggested-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/20260528.121622.1662808269492494574.horikyota.ntt%40gmail.com  

commit   : b1901e2895e08f57a5fedfd27375babd6c633893    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 May 2026 13:51:09 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 May 2026 13:51:09 -0400    

Generic tags allow sublists, e.g. MERGE_JOIN((x y)), but simple  
tags do not, e.g. SEQ_SCAN(x) is valid but SEQ_SCAN((x)) is not.  
DO_NOT_SCAN was intended to be simple tag, but was accidentally  
implemented as a generic one. This could result in assertion  
failures. Repair.  
  
Reported-by: Nikita Kalinin <n.kalinin@postgrespro.ru>  
Analyzed-by: Tender Wang <tndrwang@gmail.com>  
Analyzed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Discussion: http://postgr.es/m/19493-5878eac7a2525c23@postgresql.org  

commit   : 878839bafe259e6df355e7adc5a040a1541b63b8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 May 2026 13:25:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 May 2026 13:25:20 -0400    

Otherwise, the server will crash. This can only happen if the dump  
file has been corrupted or manually altered, but we should still  
defend against it.  
  
Reported-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Co-authored-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Co-authored-by: Robert Haas <rhaas@postgresql.org>  
Discussion: http://postgr.es/m/CAJTYsWWYhcEx1YqC=B331-Df9EpD8MxzwswWL0okz9LLCUUpBA@mail.gmail.com  

commit   : 2670cc298f42cd7b1c426bf7ccfb0652d8e0b347    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 May 2026 11:54:00 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Fri, 29 May 2026 11:54:00 +0200    

The coverage report shows that some error cases were not being tested;  
add test cases for them.  
  
While at it, move some recently added ones to the test_decoding suite:  
the preventative check added in 43649b6a53e9 now causes servers with  
wal_level=minimal to error out earlier than before.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Baji Shaik <baji.pgdev@gmail.com>  
Discussion: https://postgr.es/m/ahiwD29RNfVT4tjQ@alvherre.pgsql  

commit   : e2b35735b00181ba098d102d6504978a61fab983    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2026 21:38:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2026 21:38:21 +0300    

Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/20260528.114608.488039299811669368.horikyota.ntt@gmail.com  
Backpatch-through: 14  

commit   : 378dffaf8c80f07f2226538669da4d98ffaecefa    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 28 May 2026 20:29:20 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 28 May 2026 20:29:20 +0200    

We had discussed changing the wording of messages from "cannot repack  
table X" to "cannot execute REPACK on table X", so that translators  
don't have to figure out how to translate REPACK as a verb in their  
language.  We already do that for VACUUM and others and it's not very  
nice.  Also remove extra double-quotes in a message of that form which I  
mistakenly added in commit 43649b6a53e9.  
  
While at it, add specific error messages for the cases of a table with a  
deferrable primary key, and of REPLICA IDENTITY FULL; otherwise the user  
gets a message that the table doesn't have an identity index and it's  
not clear why that is.  
  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Discussion: https://postgr.es/m/CA+fm-ROdgh0rEVuXoViBk4TVgjodrN=MTR_RYuOuKLZ9voX4YA@mail.gmail.com  
Discussion: https://postgr.es/m/CABV9wwOo=wvq1hwTRK6HgBWUB=ekzsEebY30EWoc1V9UJQrrrw@mail.gmail.com  

commit   : 659701788171a5899119a6ddd98771371b355437    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2026 11:34:11 -0400    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2026 11:34:11 -0400    

With address sanitizer's stack-use-after-return check, stack variables are  
moved to heap allocations, to allow to detect references to the memory at a  
later time. That broke our stack-depth check, which is why we had to disable  
detect_stack_use_after_return in CI. Luckily __builtin_frame_address() works  
correctly, even under asan, so use that.  
  
We started using __builtin_frame_address() with de447bb8e6fb, however as of  
that commit we just used it for the stack base address, not for the value to  
compare to the base address.  Now we use it for both.  
  
When building without __builtin_frame_address() support, we continue to use  
stack variables for the stack depth determination.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/2kk4z4odvuyrg7qlwjd7ft4eron4cle4btb33v4qatgsdkayir@gj6e62rgsel4  
Backpatch-through: 14  

commit   : 497e92dce9b4c094fc6cee0ab37e6b9d65e67046    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 28 May 2026 16:46:12 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 28 May 2026 16:46:12 +0200    

A few of them were missing errcode(), and a couple could use some  
wordsmithing.  
  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CA+fm-ROdgh0rEVuXoViBk4TVgjodrN=MTR_RYuOuKLZ9voX4YA@mail.gmail.com  

commit   : 43649b6a53e9b3964e921cc962f5c977bce688fd    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 28 May 2026 15:04:36 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Thu, 28 May 2026 15:04:36 +0200    

The error emitted when REPACK (CONCURRENTLY) is run with too low a  
wal_level is thrown by CheckSlotRequirements(), which is a bit  
mysterious when the user doesn't know what's up.  Add an upfront check  
in check_concurrent_repack_requirements() for a more explicit, REPACK-  
centered report, which is easier to understand -- this also saves  
starting the worker just to have it die immediately.  
  
Author: Baji Shaik <baji.pgdev@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CA+fm-ROdgh0rEVuXoViBk4TVgjodrN=MTR_RYuOuKLZ9voX4YA@mail.gmail.com  

commit   : af23353a73d5b890181f8fc3d2c20ff35b655af0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 May 2026 21:53:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 May 2026 21:53:26 +0900    

Previously a continuation line in the call to libpqsrv_connect_params_start()  
in postgres_fdw/connection.c was indented with spaces, violating  
the PostgreSQL project's whitespace rules for C files and triggering  
git show --check.  
  
This commit reformats the code to avoid that layout and use indentation  
consistent with project style. No functional change.  
  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Author: Chao Li <lic@highgo.com>  
Author: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/2620a664-7b44-48b2-9aa8-5f0131702d9c@eisentraut.org  

commit   : 8a86aa313a714adc56c74e4b08793e4e6102b5ca    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 May 2026 20:58:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 May 2026 20:58:08 +0900    

The use_scram_passthrough option in postgres_fdw and dblink accepts  
only boolean values. However, unlike other boolean options such as  
keep_connections, its value was not previously validated.  
  
As a result, commands such as  
"CREATE SERVER ... OPTIONS (use_scram_passthrough 'invalid')"  
could succeed unexpectedly.  
  
This commit updates postgres_fdw and dblink to validate that  
use_scram_passthrough is assigned a valid boolean value, and throw an  
error for invalid input.  
  
Backpatch to v18, where use_scram_passthrough was introduced.  
  
Author: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwF+-k-Ehsu5W94ZP7GxS3wiBd+mi0PfGTdJ_i2Yr0zR3g@mail.gmail.com  
Backpatch-through: 18  

commit   : d79bf7612a07a6f053f4122a8bf88754217cd1c9    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 27 May 2026 16:25:56 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 27 May 2026 16:25:56 -0700    

Previously, ProcSignalInit() read the global barrier generation before  
publishing its PID into pss_pid. This created a race condition: a  
process could initialize its local generation with an older global  
value, while a concurrent EmitProcSignalBarrier() might skip that  
process because its pss_pid was still zero. This resulted in  
WaitForProcSignalBarrier() hanging indefinitely.  
  
Fix this by publishing pss_pid before reading psh_barrierGeneration  
with a memory barrier so that the store to pss_pid is ordered before  
the load. A concurrent EmitProcSignalBarrier() then either observes  
the published PID and signals this slot, or completes its generation  
increment before we load it.  
  
While this race has become more visible due to recent features using  
signal barriers in more places (such as online wal_level changes), the  
issue is theoretically present since signal barriers were introduced  
to release smgr caches (e.g., in DROP DATABASE). v14 has the  
procsiangl barrier infrastricutre but no in-tree caller that actually  
emits a barrier, so the case is unreachable there.  
  
This issue was also reported by buildfarm member flaviventris.  
  
Reported-by: Melanie Plageman <melanieplageman@gmail.com>  
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com  
Backpatch-through: 15  

commit   : 47ad2233fad4335fdd866c8ad55941706ae1661d    
  
author   : Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 27 May 2026 15:52:30 -0700    
  
committer: Masahiko Sawada <msawada@postgresql.org>    
date     : Wed, 27 May 2026 15:52:30 -0700    

Commit 2af1dc89282 placed the new "logical decoding disabled after  
REPACK (CONCURRENTLY)" check at the end of  
051_effective_wal_level.pl. That placement assumed the logical slot  
"test_slot" no longer existed when the check ran, but the assumption  
only holds on builds with injection points: the earlier  
injection-point-driven tests drop "test_slot" as a side effect, while  
on builds without injection points the slot persists.  When  
"test_slot" still exists, logical decoding remains enabled and the new  
check fails on those buildfarm members.  
  
Move the REPACK test earlier in the script, ensuring that the test  
starts with logical decoding disabled.  
  
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>  
Discussion: https://postgr.es/m/CAD21AoBmdmBQ-+Jga+jSKKq5OPGEP1pEjSJfRPT6MCwVHLD6og@mail.gmail.com  

commit   : 2af1dc89282bea681201cf66e2bb32537294e623    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 27 May 2026 20:11:21 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Wed, 27 May 2026 20:11:21 +0200    

REPACK (CONCURRENTLY) uses a temporary logical replication slot, which  
is dropped once done, but it wasn't calling RequestDisableLogicalDecoding(),  
leaving effective_wal_level stuck at 'logical'.  
  
Fix by adding a Boolean flag to ReplicationSlotDropAcquired() to have it  
request to disable logical decoding, and passing it as true on REPACK.  
Other callers of that function preserve their existing behavior.  
  
Author: Imran Zaheer <imran.zhir@gmail.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Discussion: https://postgr.es/m/CA+UBfaktds57dw2M8BEv_kS-=ixph3w+3MxKixtaDQMi_k7Ybg@mail.gmail.com  

commit   : 0f24332aeb4f43409c2a7bec9fef1e3317689bc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 May 2026 12:23:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 May 2026 12:23:35 -0400    

Commit 282b1cde9 made SignalBackends() ignore ListenerEntry entries  
whose "listening" flag said that the listener was not yet committed.  
That will be true for a new listener that has already registered its  
queue position, but has not yet reached AtCommit_Notify().  If another  
backend notifies the same channel in that window, SignalBackends()  
would directly advance the new listener's queue position, causing it  
to miss message(s).  Really this is a definitional question: is a new  
listener active as of PreCommit, or as of AtCommit?  But it seems to  
make more sense to expect that the new listener will see all messages  
after its initially-registered queue position, especially since the  
direct-advance logic is supposed to be an optimization that doesn't  
affect semantics.  
  
Fix this by treating all channel entries as valid wakeup targets.  
Rename the "listening" flag to removeOnAbort to reflect its remaining  
purpose: identifying staged LISTEN entries that abort cleanup must  
remove.  
  
While we're here, remove an obsolete test case added by 282b1cde9.  
The check for "ChannelHashAddListener array growth" was meant to  
exercise code that never made it into the committed patch, so now  
it's just a waste of test cycles.  
  
Author: Joel Jacobson <joel@compiler.org>  
Reviewed-by: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/9835b0a4-9121-47ac-9c44-427b8b1a7f1b@app.fastmail.com  
Discussion: https://postgr.es/m/6fe5ee75-537d-4d4f-909a-b21303c3ce75@app.fastmail.com  

commit   : 2fbb21170e9053720c2c374b21eb650a22b8aaea    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:58 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:58 +0300    

Concurrent DDL can leave behind objects referencing other objects that  
no longer exist. This can happen if an object is dropped, while a new  
object that depends on it is created concurrently. For example:  
  
session 1: BEGIN; CREATE FUNCTION myschema.myfunc() ...;  
session 2: DROP SCHEMA myschema;  
session 1: COMMIT;  
  
DROP SCHEMA does check that there are no objects dependending on the  
schema being dropped, but it does not see objects being concurrently  
created by other sessions. Even if it did, this scenario would still  
fail:  
  
session 1: BEGIN: DROP SCHEMA myschema;  
session 2: CREATE FUNCTION myschema.myfunc() ...;  
session 1: COMMIT;  
  
When the DROP SCHEMA runs, the schema was empty, but the new function  
is created in it before the dropping transaction completes. The CREATE  
FUNCTION does not see that the schema is concurrently being dropped.  
  
In both of these scenarios, the function is left behind in the schema  
that no longer exists.  
  
To fix, acquire AccessShareLock on all referenced objects when  
recording dependencies. This conflicts with the AccessExclusiveLock  
taken by DROP, preventing the race. After acquiring the lock, verify  
that the object still exists, and if it was dropped concurrently,  
report an error. We already had such a mechanism for shared  
dependencies, but for some reason we didn't do it for in-database  
dependendies.  
  
Ideally the locks would be acquired much earlier when creating a new  
object, but that will require modifying a lot of callers. This check  
while recording the dependency is a nice wholesale protection, and  
even if we change all the CREATE commands to acquire locks earlier,  
it's still good to have this as a backstop to catch any cases where we  
forgot to do so.  
  
The patch adds a few tests for some cases that left behind orphaned  
objects before this. It also adds a test for roles, which already had  
such protection, although that test is partially disabled because the  
error message includes an OID which is not predictable.  
  
Author: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>  
Reviewed-by: Heikki Linnakangas <heikki.linnakangas@iki.fi>  
Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 14  

commit   : fd93ee100830a1c0f4d292addd0a460cb48106a0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:55 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 27 May 2026 18:35:55 +0300    

When creating a relation with a dropped column, we called  
recordDependencyOn() also on the datatype of the dropped column, which  
is always InvalidOid. In versions 15 and above, that was harmless  
because recordDependencyOn() considers InvalidOid as a pinned object,  
and skips over it. On version 14, isPinnedObject() does not consider  
InvalidOid as pinned, so we created a bogus pg_depend entry with  
refobjectid == 0.  
  
As far as I can tell, the only case when AddNewAttributeTuples() is  
called with dropped columns is when performing a table-rewriting ALTER  
TABLE command. That temporarily creates a new relation with the same  
columns, including dropped ones, then swaps the relations, and drops  
the newly created table again. So even on version 14, the bogus  
pg_depend entry was only on the transient relation that was dropped at  
the end of the ALTER TABLE command, which was harmless.  
  
Even though this is harmless, let's be tidy, similar to commit  
713bce9484. The reason I noticed this now and why I backported this,  
is because the next commit will add code to acquire locks on the  
referenced objects, and we don't want to acquire a lock on InvalidOid.  
  
Discussion: https://postgr.es/m/ZiYjn0eVc7pxVY45@ip-10-97-1-34.eu-west-3.compute.internal  
Backpatch-through: 14  

commit   : ee31868a535d1fbe0ddbb698c9c947a2067c2b6f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 May 2026 17:12:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 May 2026 17:12:27 +0200    

This is mostly for notational consistency, since the result is stored  
in a variable of type int64.  

commit   : c71b94f03304954e4352f96595254622b64f851c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 27 May 2026 12:58:56 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 27 May 2026 12:58:56 +0200    

Commit 316472146 introduced support for ECDH key exchange with an ifdef  
guard to ensure support in the underlying OpenSSL installation.  Commit  
10bf4fc2c3 in OpenSSL removed this guard in 2015 which effectively made  
our check a no-op.  There has been no complaints that this doesn't work  
and OpenSSL installations without ECDH support are likely very rare, so  
remove the checks rather than re-implementing support.  Not backpatched  
since this fix doesn't alter functionality.  
  
Also fix a typo introduced in the original commit which had survived  
till this day.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>  
Discussion: https://postgr.es/m/1787BA9F-A11C-4A7A-9252-94C470D5CBE3@yesql.se  

commit   : 84b9d6bceab6e6ec4ff49fa52a7fc90d85e3798c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 17:19:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 17:19:20 +0900    

DisownLatch() was executed after the PGPROC entry of the process  
terminated is pushed back into a freelist.  A newly-forked backend that  
recycles the slot could call OwnLatch() and PANIC with a "latch already  
owned by PID", taking down the server.  
  
There were two scenarios related to lock groups where this issue could  
be reached:  
* A follower pushes the leader's PGPROC back to the freelist while the  
leader has not yet called DisownLatch() in its own ProcKill().  
* A leader outliving all its followers pushes its own PGPROC onto the  
freelist before reaching DisownLatch(), which would be the most common  
scenario.  
  
This issue is fixed by calling SwitchBackToLocalLatch() and  
DisownLatch() at an earlier phase of ProcKill(), before any freelist  
manipulation happens, so that the slot of the backend terminated is  
never exposed as owning a latch.  
  
Note that pgstat_reset_wait_event_storage() is kept at a later stage.  
An upcoming commit will take advantage of that by introducing a test  
able to check the original PANIC scenario.  
  
Author: Vlad Lesin <vladlesin@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com  
Backpatch-through: 14  

commit   : 56310452318cee4bb8c291be126ce0c2b2affa5f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 14:48:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 May 2026 14:48:56 +0900    

This commit fixes two bugs in ProcKill()'s lock-group teardown freelist  
publication:  
* a double push of the leader's PGPROC that corrupts the freelist.  
* a leak of the last follower's PGPROC slot.  
  
ProcKill()'s lock-group teardown had two PGPROC freelist updates  
scattered through the function, done under two separate freeProcsLock  
acquisitions:  
* A follower's push of the leader's PGPROC, done when a follower is the  
last group member exiting.  
* Every backend's self-push at the bottom of the function.  
  
The two freelist updates were coordinated only by inspecting  
proc->lockGroupLeader, which a follower could clear as a side effect of  
pushing the leader.  This coordination was broken.  For example, with  
two concurrent backends:  
* The follower clears leader->lockGroupLeader and pushes the leader's  
PGPROC under leader_lwlock.  
* The follower does not clear its own proc->lockGroupLeader, being  
skipped.  
* When the leader reaches the bottom of ProcKill(), it sees a NULL  
proc->lockGroupLeader (the follower cleared it) and pushes itself,  
causing a second dlist_push_tail() of the same node onto the same  
freelist.  
* The follower at the bottom sees its own proc->lockGroupLeader being  
not NULL (never cleared) and skips its own push, causing its own slot  
to leak.  
  
This commit refactors the freelist manipulation to be done in two  
distinct phases, each step using its own lock acquisition to ensure that  
each freelist operation happens in an isolated manner for each backend  
(follower or leader):  
- First, under a single leader_lwlock acquisition, check the state of  
the lock-group.  Depending on if we are dealing with a follower and/or a  
leader, and if the leader has exited before a follower, then set some  
state booleans that define which actions should be taken with the  
freelist.  
- Second, under a single freeProcsLock acquisition, perform the cleanup  
actions, self-push of a backend and/or push of the leader back to the  
freelist.  
  
This is an old issue, dating back to 9.6 where parallel workers and lock  
grouping has been added.  
  
Author: Vlad Lesin <vladlesin@gmail.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com  
Backpatch-through: 14  

commit   : 12d0004889e56d9883fafafc95c73a802307aaa7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 May 2026 10:34:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 May 2026 10:34:17 +0900    

When pg_createsubscriber fails after creating logical replication  
objects, it should remove the publication and replication slot that  
it created on the publisher.  
  
Previously, if dropping subscriber-side objects failed,  
pg_createsubscriber reset its internal cleanup state too early. As a  
result, the exit-time cleanup could skip removing the publication or  
replication slot on the publisher.  
  
This could leave pg_createsubscriber-created objects behind on  
the publisher after a failed run. That can make a retry harder,  
because the leftover publication or replication slot may need to be  
removed manually before running pg_createsubscriber again.  
In the case of a replication slot, leaving it behind can also retain  
WAL files longer than expected.  
  
The cause of this issue was that the flags made_publication and  
made_replslot tracking whether pg_createsubscriber created  
a publication or replication slot on the primary were incorrectly  
reset to false when failures occurred while dropping objects  
on the subscriber.  
  
This commit fixes the issue by preventing those cleanup flags from  
being reset even when failures occurred while dropping objects  
on the subscriber, ensuring proper cleanup of primary objects  
before exit on failure.  
  
Backpatch to v17, where pg_createsubscriber was added.  
  
Author: Nisha Moond <nisha.moond412@gmail.com>  
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CABdArM5V9QKK1PkLY9dpgAcZa3kUp84-wPqPovxvdLOri4=69w@mail.gmail.com  
Backpatch-through: 17  

commit   : 9a41b34a28702a71cc0a0e77dd80ca80366d12fb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 20:17:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 20:17:40 -0400    

Reported-by: X-MAN  
  
Author: X-MAN  
  
Discussion: https://postgr.es/m/tencent_90A64D807DE3586650CF3426C28BB599D30A@qq.com  

commit   : 0b866bb90368ba18a97772c21cd2e0952a16835d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 27 May 2026 03:07:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 27 May 2026 03:07:45 +0300    

Update stale comments and test names in 019_replslot_limit.pl to match  
the actual WAL advancement and wal_status checks.  Remove a redundant  
standby stop in the inactive_since coverage.  
  
Discussion: https://postgr.es/m/CABPTF7XxDonXAcz6DsN6AUJB3swYrZkJHq3UCDaD3Q2H%2Bj0gUA%40mail.gmail.com  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : cdb1d1cf1de63b5dfecd5ebb23fd277b0e767f57    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 27 May 2026 02:54:04 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 27 May 2026 02:54:04 +0300    

wait_for_catchup() has "wait for the standby to reach the target LSN"  
semantics.  However, the previous polling implementation actually waited for  
the primary to observe that position via pg_stat_replication.  
7e8aeb9e483 introduced the new WAIT FOR LSN-based implementation, which  
just probes the standby.  
  
019_replslot_limit.pl relied on the old side effect: its  
"slot state changes to extended/unreserved" subtests inspect  
primary-side pg_replication_slots, whose wal_status depends on  
restart_lsn, which only advances after the walsender processes a  
standby reply.  Make the test wait on what it actually needs by  
replacing each wait_for_catchup() with  
wait_for_slot_catchup('rep1', 'restart', primary->lsn('write')).  
  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/63f6abc9-c0ae-465d-a4e6-667eca6ea008@gmail.com  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Author: Alexander Korotkov <aekorotkov@gmail.com>  

commit   : bec61f59354e652598b4c8b52b4c022ebb616230    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 27 May 2026 02:26:50 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 27 May 2026 02:26:50 +0300    

EventTriggerOnLogin() tries to clear pg_database.dathasloginevt when  
the database no longer has any login event triggers but the flag is  
still set.  To make that safe against concurrent flag setters, it  
takes a conditional AccessExclusiveLock on the database object.  
  
On a hot standby, that lock acquisition fails outright with  
  
  FATAL:  cannot acquire lock mode AccessExclusiveLock on database  
          objects while recovery is in progress  
  
because LockAcquireExtended() refuses locks stronger than  
RowExclusiveLock on database objects during recovery.  The standby  
already replays the flag's value from the primary, so the dangling  
flag is the result of replaying a state in which the primary had  
already dropped its login event triggers but not yet run a login  
event trigger pass to clear the flag.  Any session connecting to the  
standby in that window therefore fails to connect.  
  
Skip the cleanup on a standby.  The flag will be cleared via WAL  
replay once the primary clears it on its side.  
  
Add a recovery TAP test that reproduces the original report: create  
and drop a login event trigger on the primary in one session, wait  
for the standby to replay, then verify that a fresh connection to  
the standby succeeds.  
  
Backpatch to v17, where the login event triggers were introduced.  
  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reported-by: Egor Chindyaskin <kyzevan23@mail.ru>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>  
Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org  
Backpatch-through: 17  

commit   : 490259d0729007c40aff1f5255550154fb7afcbc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 26 May 2026 15:16:12 -0700    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 26 May 2026 15:16:12 -0700    

Unlike the slotsync worker, whose retry cycles are separated by  
transaction boundaries, pg_sync_replication_slots() retries within a  
single SQL function call. Per-cycle allocations for slot names, plugin  
names, database names, and auxiliary list containers get accumulated  
across retries until the function returned. Memory growth is proportional  
to the number of retries and remote slots, and the function may wait an  
extended period between cycles when slots are slow to persist.  
  
Fix by running each retry cycle in a short-lived memory context  
(sync_retry_ctx) that is reset before the next attempt. Additionally,  
release tuple slots created with MakeSingleTupleTableSlot() before  
clearing the walreceiver result.  
  
Author: Xuneng Zhou <xunengzhou@gmail.com>  
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>  
Reviewed-by: shveta malik <shveta.malik@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/CABPTF7VVPxgfYyr8Kyi=+JACjckQ6NpniV9eRtHboj2hMn0REw@mail.gmail.com  

commit   : 8656ba7f71878eb16b2bcd6ec5d448dfb402bcfa    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 17:49:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 17:49:31 -0400    

Reported-by: Thom Brown  
  
Author: Thom Brown  
  
Discussion: https://postgr.es/m/CAA-aLv7B7M9s5fZgCoWzXqer5RJ9jqG_k0h8t5QHFW=Qbxa=Eg@mail.gmail.com  

commit   : 1d751b4b6b0165f122cd14ff84e556e2d2ebcb1e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 16:31:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 16:31:58 -0400    

Reported-by: Thom Brown  
  
Author: Thom Brown  
  
Discussion: https://postgr.es/m/CAA-aLv7w1wwucet76yAW0yq3-LrN5wL81uRrnpT3Tyxh7dmyTw@mail.gmail.com  

commit   : 61ea5cc6a61ff9eb8b3d7b055e507a726e5856c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2026 11:58:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2026 11:58:25 -0400    

QueueFKConstraintValidation() recurses through the partition hierarchy  
to queue child constraint validations and to mark child rows as  
validated.  With a sufficiently deep partition tree, this can result  
in a stack-overflow crash.  Defend against that as we do elsewhere.  
  
Bug: #19482  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19482-4cc37cbf52d55235@postgresql.org  
Backpatch-through: 18  

commit   : 1588d89af22f292e9ba44eaa33a14122e0754c3a    
  
author   : Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 26 May 2026 17:24:06 +0200    
  
committer: Álvaro Herrera <alvherre@kurilemu.de>    
date     : Tue, 26 May 2026 17:24:06 +0200    

The original code would leave a shared memory segment unreleased if we  
fail partway through initialization.  Change the shutdown order so that  
we always free it.  
  
Author: Álvaro Herrera <alvherre@kurilemu.de>  
Reviewed-by: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/agtNn6ZCmdI2KJFn@alvherre.pgsql  

commit   : cfedd45133574df0328bc02a2486d969e91d1556    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 10:59:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 26 May 2026 10:59:30 -0400    

Reported-by: Chong Peng  
  
Author: Chong Peng  
  
Discussion: https://postgr.es/m/CC2712F9-8457-4733-AA9D-7D7C9843B590@gmail.com  

commit   : 6aa26be288fa811270dfc1e39c015c23a97688b4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 May 2026 13:49:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 May 2026 13:49:04 +0900    

pg_get_multixact_stats() uses members_size to report the amount of  
storage used by the currently retained multixact members.  However,  
MultiXactOffsetStorageSize() divided the member count by the number of  
members per storage group before multiplying by the group size, so it  
was rounding down its result and incorrectly reported zero when there  
were few retained members.  The calculation is changed to calculate the  
same based on the member count.  
  
While on it, this fixes a different issue in the isolation test  
multixact-stats.  Three fields were defined for checks related to the  
oldest offset values, but were not used.  The offsets existed in an  
older version of the patch than what has been committed.  These are  
replaced by checks for members_size, checking the new calculation  
formula.  
  
Thinkos introduced in 97b101776ce2.  
  
Author: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/819AC1B2-1A71-4244-B081-3ADD85D1725D@gmail.com  

commit   : d40aed554227e5f8203798fda25b936a264638ec    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 May 2026 08:13:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 May 2026 08:13:22 +0900    

The wording of two error hints is tweaked in this commit:  
- Import of extended statistics, where the value of an array element is  
not a NULL or a string.  
- Online data checksum switch, where a period was missing.  
  
Author:  Baji Shaik <baji.pgdev@gmail.com>  
Reviewed-by: Chao Li <li.evan.chao@gmail.com>  
Discussion: https://postgr.es/m/CA+fm-RMrKbyky_+vi5SDdAVnFVjWh7zW3GoDAVnrp5OpDnW6tw@mail.gmail.com  

commit   : 524cc0f638745489f55bafa12f3f93fe8944e027    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2026 18:15:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2026 18:15:49 -0400    

Given a WHERE clause like "int[] @@ query_int" or "query_int ~~ int[]"  
where the query_int side is a table column having statistics,  
_int_matchsel() exited without remembering to free the statistics  
tuple.  This would typically lead to warnings about cache refcount  
leakage, like  
  WARNING:  resource was not closed: cache pg_statistic (73), tuple 42/12 has count 1  
It's been wrong since this code was added, in commit c6fbe6d6f.  
  
Bug: #19492  
Reported-by: Man Zeng <zengman@halodbtech.com>  
Author: Man Zeng <zengman@halodbtech.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/19492-ddcd0e22399ef85a@postgresql.org  
Backpatch-through: 14  

commit   : e2b8813403b19609a3f194b1d4cdb88df5aa4c7d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 May 2026 01:07:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 May 2026 01:07:24 +0900    

Previously, dblink accepted the use_scram_passthrough option on  
foreign-data wrappers via ALTER FOREIGN DATA WRAPPER dblink_fdw  
OPTIONS, even though the setting had no effect there.  
  
use_scram_passthrough should be only meaningful for foreign servers  
and user mappings, so this commit updates dblink to accept the option  
only in those contexts.  
  
Backpatch to v18, where use_scram_passthrough was introduced.  
  
Author: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com  
Backpatch-through: 18  

commit   : 5f5165e2fe193cc2c9e9078992cdb277013e8dec    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 May 2026 00:51:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 May 2026 00:51:18 +0900    

Commit 97f6fc10fff changed postgres_fdw so that user-mapping settings  
override foreign server settings for use_scram_passthrough. This commit  
applies the same behavior to dblink.  
  
Backpatch to v18, where use_scram_passthrough was introduced.  
  
Author: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com  
Backpatch-through: 18  

commit   : 97f6fc10fff0e42d08d78ce7f2a5b116e7f8d9b2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 May 2026 00:46:31 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 May 2026 00:46:31 +0900    

Previously, when use_scram_passthrough was specified on both a foreign server  
and a user mapping, the server-level setting took precedence over the  
user-mapping setting. This was inconsistent with the usual semantics of  
postgres_fdw options, where foreign server options provide shared defaults  
and user mapping options override them on a per-user basis.  
  
This commit updates postgres_fdw so that the user-mapping setting takes  
precedence when use_scram_passthrough is specified in both places. This  
matches the behavior of other connection options such as sslcert and sslkey.  
  
Backpatch to v18, where use_scram_passthrough was introduced. In v18,  
this only affects limited configurations that specify conflicting values  
at both the foreign server and user-mapping levels. In such cases, users  
would naturally expect the user-mapping setting to override the server-level  
setting, so changing the behavior should be minimally disruptive.  
Also keeping v18 as the only branch with different semantics for  
use_scram_passthrough would be unnecessarily confusing, so backpatch  
this fix to v18.  
  
Author: Matheus Alcantara <matheusssilv97@gmail.com>  
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>  
Discussion: https://postgr.es/m/CAHGQGwEJ8rZjmbOvCicyr4vbuLio082bNTde0WNoSWaWr9wVcg@mail.gmail.com  
Backpatch-through: 18