PostgreSQL 16.5 commit log

commit   : 8c9d34cdc4d213a57fa8b8a7197f7d6f22fca4c9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 17:44:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 17:44:10 -0500    

commit   : 03dc78ff644ca0c090cb4cdbf8fba64230e54238    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 17:40:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 17:40:13 -0500    

Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979  

commit   : 95f5a523729f6814c8757860d9a2264148b7b0df    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 17:05:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 17:05:53 -0500    

Commit 5a2fed911 had an unexpected side-effect: the parallel worker  
launched for the new test case would fail if it couldn't use a  
superuser-reserved connection slot.  The reason that test failed  
while all our pre-existing ones worked is that the connection  
privilege tests in InitPostgres had been based on the superuserness  
of the leader's AuthenticatedUserId, but after the rearrangements  
of 5a2fed911 we were testing the superuserness of CurrentUserId,  
which the new test case deliberately made to be a non-superuser.  
  
This all seems very accidental and probably not the behavior we really  
want, but a security patch is no time to be redesigning things.  
Pending some discussion about desirable semantics, hack it so that  
InitPostgres continues to pay attention to the superuserness of  
AuthenticatedUserId when starting a parallel worker.  
  
Nathan Bossart and Tom Lane, per buildfarm member sawshark.  
  
Security: CVE-2024-10978  

commit   : 64df8870097aa286363a5d81462802783abbfa61    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 13:57:21 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 13:57:21 -0500    

TestUpgradeXversion knows how to make the main regression database's  
references to pg_regress.so be version-independent.  But it doesn't  
do that for plperl's database, so that the C function added by  
commit b7e3a52a8 is causing cross-version upgrade test failures.  
Path of least resistance is to just drop the function at the end  
of the new test.  
  
In <= v14, also take the opportunity to clean up the generated  
test files.  
  
Security: CVE-2024-10979  

commit   : c335264c9e127ca0be828fc772702674f3563ba7    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 11 Nov 2024 10:55:18 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 11 Nov 2024 10:55:18 -0800    

v16 commit 8fe3e697a1a83a722b107c7cb9c31084e1f4d077 used REGRESS_OPTS in  
a way needing this.  That broke "vcregress plcheck".  Back-patch  
v16..v12; newer versions don't have this build system.  

commit   : 168579e23bdbeda1a140440c0272b335d53ad061    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 12:27:06 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 12:27:06 -0500    

Ooops, missed that v16 has another text2macro call in the MSVC scripts.  
  
Security: CVE-2024-10979  

commit   : 88269df4da032bb1536d4291a13f3af4e1e599ba    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 12:20:08 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 12:20:08 -0500    

meson makes the backslashes in text2macro.pl's --strip argument  
into forward slashes, effectively disabling comment stripping.  
That hasn't caused us issues before, but it breaks the test case  
for b7e3a52a8.  We don't really need the pattern to be adjustable,  
so just hard-wire it into the script instead.  
  
Context: https://github.com/mesonbuild/meson/issues/1564  
Security: CVE-2024-10979  

commit   : ae340d0318521ae7234ed3b7221a1f65f39a52c0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 10:29:54 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2024 10:29:54 -0500    

The SQL spec mandates that SET SESSION AUTHORIZATION implies  
SET ROLE NONE.  We tried to implement that within the lowest-level  
functions that manipulate these settings, but that was a bad idea.  
In particular, guc.c assumes that it doesn't matter in what order  
it applies GUC variable updates, but that was not the case for these  
two variables.  This problem, compounded by some hackish attempts to  
work around it, led to some security-grade issues:  
  
* Rolling back a transaction that had done SET SESSION AUTHORIZATION  
would revert to SET ROLE NONE, even if that had not been the previous  
state, so that the effective user ID might now be different from what  
it had been.  
  
* The same for SET SESSION AUTHORIZATION in a function SET clause.  
  
* If a parallel worker inspected current_setting('role'), it saw  
"none" even when it should see something else.  
  
Also, although the parallel worker startup code intended to cope  
with the current role's pg_authid row having disappeared, its  
implementation of that was incomplete so it would still fail.  
  
Fix by fully separating the miscinit.c functions that assign  
session_authorization from those that assign role.  To implement the  
spec's requirement, teach set_config_option itself to perform "SET  
ROLE NONE" when it sets session_authorization.  (This is undoubtedly  
ugly, but the alternatives seem worse.  In particular, there's no way  
to do it within assign_session_authorization without incompatible  
changes in the API for GUC assign hooks.)  Also, improve  
ParallelWorkerMain to directly set all the relevant user-ID variables  
instead of relying on some of them to get set indirectly.  That  
allows us to survive not finding the pg_authid row during worker  
startup.  
  
In v16 and earlier, this includes back-patching 9987a7bf3 which  
fixed a violation of GUC coding rules: SetSessionAuthorization  
is not an appropriate place to be throwing errors from.  
  
Security: CVE-2024-10978  

commit   : 562289460e118fcad44ec916dcdab21e4763c38c    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 11 Nov 2024 09:00:00 -0600    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 11 Nov 2024 09:00:00 -0600    

If a CTE, subquery, sublink, security invoker view, or coercion  
projection references a table with row-level security policies, we  
neglected to mark the plan as potentially dependent on which role  
is executing it.  This could lead to later executions in the same  
session returning or hiding rows that should have been hidden or  
returned instead.  
  
Reported-by: Wolfgang Walther  
Reviewed-by: Noah Misch  
Security: CVE-2024-10976  
Backpatch-through: 12  

commit   : 8fe3e697a1a83a722b107c7cb9c31084e1f4d077    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 11 Nov 2024 06:23:43 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 11 Nov 2024 06:23:43 -0800    

Many process environment variables (e.g. PATH), bypass the containment  
expected of a trusted PL.  Hence, trusted PLs must not offer features  
that achieve setenv().  Otherwise, an attacker having USAGE privilege on  
the language often can achieve arbitrary code execution, even if the  
attacker lacks a database server operating system user.  
  
To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just  
replaces each modification attempt with a warning.  Sites that reach  
these warnings should evaluate the application-specific implications of  
proceeding without the environment modification:  
  
  Can the application reasonably proceed without the modification?  
  
    If no, switch to plperlu or another approach.  
  
    If yes, the application should change the code to stop attempting  
    environment modifications.  If that's too difficult, add "untie  
    %main::ENV" in any code executed before the warning.  For example,  
    one might add it to the start of the affected function or even to  
    the plperl.on_plperl_init setting.  
  
In passing, link to Perl's guidance about the Perl features behind the  
security posture of PL/Perl.  
  
Back-patch to v12 (all supported versions).  
  
Andrew Dunstan and Noah Misch  
  
Security: CVE-2024-10979  

commit   : bd6ec082d09058dc96b61bc2d4cc484317153454    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2024 13:53:52 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2024 13:53:52 +0100    

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

commit   : 67d28bd02ec06f5056754bc295f57d2dd2bbd749    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 11 Nov 2024 10:19:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 11 Nov 2024 10:19:58 +0900    

This commit changes libpq so that errors reported by the backend during  
the protocol negotiation for SSL and GSS are discarded by the client, as  
these may include bytes that could be consumed by the client and write  
arbitrary bytes to a client's terminal.  
  
A failure with the SSL negotiation now leads to an error immediately  
reported, without a retry on any other methods allowed, like a fallback  
to a plaintext connection.  
  
A failure with GSS discards the error message received, and we allow a  
fallback as it may be possible that the error is caused by a connection  
attempt with a pre-11 server, GSS encryption having been introduced in  
v12.  This was a problem only with v17 and newer versions; older  
versions discard the error message already in this case, assuming a  
failure caused by a lack of support for GSS encryption.  
  
Author: Jacob Champion  
Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier  
Security: CVE-2024-10977  
Backpatch-through: 12  

commit   : f7ca23a6a3a1229ce8bab69558ed64ebdef9f67e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Nov 2024 13:40:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Nov 2024 13:40:41 -0500    

commit   : 06424e9a24f04234cff0ed4d333415895e99faeb    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Nov 2024 13:42:01 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Nov 2024 13:42:01 -0500    

Commit ac04aa84a put the shutoff for this into the planner, which is  
not ideal because it doesn't prevent us from re-using a previously  
made parallel plan.  Revert the planner change and instead put the  
shutoff into InitializeParallelDSM, modeling it on the existing code  
there for recovering from failure to allocate a DSM segment.  
  
However, that code path is mostly untested, and testing a bit harder  
showed there's at least one bug: ExecHashJoinReInitializeDSM is not  
prepared for us to have skipped doing parallel DSM setup.  I also  
thought the Assert in ReinitializeParallelWorkers is pretty  
ill-advised, and replaced it with a silent Min() operation.  
  
The existing test case added by ac04aa84a serves fine to test this  
version of the fix, so no change needed there.  
  
Patch by me, but thanks to Noah Misch for the core idea that we  
could shut off worker creation when !INTERRUPTS_CAN_BE_PROCESSED.  
Back-patch to v12, as ac04aa84a was.  
  
Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com  

commit   : f734b6b4d0cc6194cb93d74f179c8471306ea3b9    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 8 Nov 2024 16:30:07 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 8 Nov 2024 16:30:07 +0900    

If the collation of any join key column doesn’t match the collation of  
the corresponding partition key, partitionwise joins can yield incorrect  
results. For example, rows that would match under the join key collation  
might be located in different partitions due to the partitioning  
collation. In such cases, a partitionwise join would yield different  
results from a non-partitionwise join, so disallow it in such cases.  
  
Reported-by: Tender Wang <[email protected]>  
Author: Jian He <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Discussion: https://postgr.es/m/CAHewXNno_HKiQ6PqyLYfuqDtwp7KKHZiH1J7Pqyz0nr+PS2Dwg@mail.gmail.com  
Backpatch-through: 12  

commit   : dd2f8ebee221f8c2a8bcdd71be836f1482f17310    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 8 Nov 2024 16:07:05 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 8 Nov 2024 16:07:05 +0900    

If the collation of any grouping column doesn’t match the collation of  
the corresponding partition key, partitionwise grouping can yield  
incorrect results. For example, rows that would be grouped under the  
grouping collation may end up in different partitions under the  
partitioning collation. In such cases, full partitionwise grouping  
would produce results that differ from those without partitionwise  
grouping, so disallowed that.  
  
Partial partitionwise aggregation is still allowed, as the Finalize  
step reconciles partition-level aggregates with grouping requirements  
across all partitions, ensuring that the final output remains  
consistent.  
  
This commit also fixes group_by_has_partkey() by ensuring the  
RelabelType node is stripped from grouping expressions when matching  
them to partition key expressions to avoid false mismatches.  
  
Bug: #18568  
Reported-by: Webbo Han <[email protected]>  
Author: Webbo Han <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Reviewed-by: Aleksander Alekseev <[email protected]>  
Reviewed-by: Jian He <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAHewXNno_HKiQ6PqyLYfuqDtwp7KKHZiH1J7Pqyz0nr+PS2Dwg@mail.gmail.com  
Backpatch-through: 12  

commit   : 57c8b87262681a9d53e691fa3d1edc5efc1574e3    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 8 Nov 2024 07:17:55 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 8 Nov 2024 07:17:55 +0100    

Backpatch the part of edee0c621de that applies to a90bdd7a44d, which  
was also backpatched.  That way, the message is consistent in all  
branches.  

commit   : 6f4524729ca2595e7c0a78900a264a2e966653ce    
  
author   : Álvaro Herrera <[email protected]>    
date     : Thu, 7 Nov 2024 14:06:24 +0100    
  
committer: Álvaro Herrera <[email protected]>    
date     : Thu, 7 Nov 2024 14:06:24 +0100    

The previous wording is easy to read incorrectly; this change makes it  
simpler, less ambiguous, and less prominent.  
  
Backpatch to all live branches.  
  
Reviewed-by: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : ee67b73f5902178fba3b825013c4777ffdd0e7af    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 6 Nov 2024 22:04:44 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 6 Nov 2024 22:04:44 +1300    

Supply a new memory manager for RuntimeDyld, to avoid crashes in  
generated code caused by memory placement that can overflow a 32 bit  
data type.  This is a drop-in replacement for the  
llvm::SectionMemoryManager class in the LLVM library, with Michael  
Smith's proposed fix from  
https://www.github.com/llvm/llvm-project/pull/71968.  
  
We hereby slurp it into our own source tree, after moving into a new  
namespace llvm::backport and making some minor adjustments so that it  
can be compiled with older LLVM versions as far back as 12.  It's harder  
to make it work on even older LLVM versions, but it doesn't seem likely  
that people are really using them so that is not investigated for now.  
  
The problem could also be addressed by switching to JITLink instead of  
RuntimeDyld, and that is the LLVM project's recommended solution as  
the latter is about to be deprecated.  We'll have to do that soon enough  
anyway, and then when the LLVM version support window advances far  
enough in a few years we'll be able to delete this code.  Unfortunately  
that wouldn't be enough for PostgreSQL today: in most relevant versions  
of LLVM, JITLink is missing or incomplete.  
  
Several other projects have already back-ported this fix into their fork  
of LLVM, which is a vote of confidence despite the lack of commit into  
LLVM as of today.  We don't have our own copy of LLVM so we can't do  
exactly what they've done; instead we have a copy of the whole patched  
class so we can pass an instance of it to RuntimeDyld.  
  
The LLVM project hasn't chosen to commit the fix yet, and even if it  
did, it wouldn't be back-ported into the releases of LLVM that most of  
our users care about, so there is not much point in waiting any longer  
for that.  If they make further changes and commit it to LLVM 19 or 20,  
we'll still need this for older versions, but we may want to  
resynchronize our copy and update some comments.  
  
The changes that we've had to make to our copy can be seen by diffing  
our SectionMemoryManager.{h,cpp} files against the ones in the tree of  
the pull request.  Per the LLVM project's license requirements, a copy  
is in SectionMemoryManager.LICENSE.  
  
This should fix the spate of crash reports we've been receiving lately  
from users on large memory ARM systems.  
  
Back-patch to all supported releases.  
  
Co-authored-by: Thomas Munro <[email protected]>  
Co-authored-by: Anthonin Bonnefoy <[email protected]>  
Reviewed-by: Anthonin Bonnefoy <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]> (license aspects)  
Reported-by: Anthonin Bonnefoy <[email protected]>  
Discussion: https://postgr.es/m/CAO6_Xqr63qj%3DSx7HY6ZiiQ6R_JbX%2B-p6sTPwDYwTWZjUmjsYBg%40mail.gmail.com  

commit   : 925b3aa85700f35f6ca861ea6a25abee606d3c14    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2024 09:40:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 5 Nov 2024 09:40:58 +0900    

PgStat_HashKey is currently initialized in a way that could result in  
random data if the structure has any padding bytes.  The structure  
has no padding bytes currently, fortunately, but it could become a  
problem should the structure change at some point in the future.  
  
The code is changed to use some memset(0) so as any padding would be  
handled properly, as it would be surprising to see random failures in  
the pgstats entry lookups.  PgStat_HashKey is a structure internal to  
pgstats, and an ABI change could be possible in the scope of a bug fix,  
so backpatch down to 15 where this has been introduced.  
  
Author: Bertrand Drouvot  
Reviewed-by: Jelte Fennema-Nio, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 5e08ac63a26561bddbd8d400c623f33460c51bb8    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Nov 2024 18:08:48 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Nov 2024 18:08:48 -0500    

We had been using "diff -upd", which evidently works for most people,  
but Solaris's diff doesn't like it.  (We'd not noticed because the  
Solaris buildfarm animals weren't running this test until they were  
upgraded to the latest buildfarm client script.)  Change to "diff -U3"  
which is what pg_regress has used for ages.  
  
Per buildfarm (and off-list discussion with Noah Misch).  
  
Back-patch to v16 where this test was added.  In v16,  
also back-patch the relevant part of 628c1d1f2 so that  
the test script looks about the same in all branches.  

commit   : f8f9110b4d33821ccb3e67454b3799448e2a325f    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 19:42:52 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 19:42:52 -0700    

Buildfarm member mamba fails to deduce that the function never uses this  
variable without initializing it.  Back-patch to v12, like commit  
b412f402d1e020c5dac94f3bf4a005db69519b99.  

commit   : 6c837c237bf821ee78522259c847f417d1e11fd7    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 09:04:55 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 09:04:55 -0700    

Commit a07e03fd8fa7daf4d1356f7cb501ffe784ea6257 enlarged the work done  
here under the pg_class heap buffer lock.  Two preexisting actions are  
best done before holding that lock.  Both RelationGetNumberOfBlocks()  
and visibilitymap_count() do I/O, and the latter might exclusive-lock a  
visibility map buffer.  Moving these reduces contention and risk of  
undetected LWLock deadlock.  Back-patch to v12, like that commit.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6f9dd2282e37589bdadf15423b0395ce11735f82    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 09:05:00 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 09:05:00 -0700    

This reverts commit 95c5acb3fc261067ab65ddc0b2dca8e162f09442 (v17) and  
counterparts in each other non-master branch.  If released, that commit  
would have caused a worst-in-years minor release regression, via  
undetected LWLock self-deadlock.  This commit and its self-deadlock fix  
warrant more bake time in the master branch.  
  
Reported by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d5be10758b3645e30937509d7056d2dc28eb128e    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 09:04:59 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 2 Nov 2024 09:04:59 -0700    

This reverts commit bfd5c6e279c8e1702eea882439dc7ebdf4d4b3a5 (v17) and  
counterparts in each other non-master branch.  This unblocks reverting a  
commit on which it depends.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 098f2343bc9feb4284ea88fe24d19fa72f423833    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 1 Nov 2024 13:54:28 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 1 Nov 2024 13:54:28 -0400    

It used to refer to CREATE DOMAIN, but CREATE DOMAIN allows NULL, while  
ALTER DOMAIN does not.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : 59c2890dffff170198e41fc5b52075442ed272e0    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 1 Nov 2024 11:30:53 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 1 Nov 2024 11:30:53 -0400    

Replace with Strawberry Perl and Magicsplat Tcl.  
  
Reported-by: Yasir Hussain  
  
Discussion: https://postgr.es/m/CAA9OW9fAAM_WDYYpAquqF6j1hmfRMzHPsFkRfP5E6oSfkF=dMA@mail.gmail.com  
  
Backpatch-through: 12  

commit   : f7d510a382451d4f29a3bbc97a98a6b0061ea0b6    
  
author   : Álvaro Herrera <[email protected]>    
date     : Wed, 30 Oct 2024 10:54:03 +0100    
  
committer: Álvaro Herrera <[email protected]>    
date     : Wed, 30 Oct 2024 10:54:03 +0100    

* In DetachPartitionFinalize() we were applying a tuple conversion map  
  to tuples that didn't need one, which can lead to erratic behavior if  
  a partitioned table has a partition with a different column order, as  
  reported by Alexander Lakhin. This was introduced by 53af9491a043.  
  Don't do that.  Also, modify a recently added test case to exercise  
  this.  
  
* The same function as well as CloneFkReferenced() were acquiring  
  AccessShareLock on a partition, only to have CreateTrigger() later  
  acquire ShareRowExclusiveLock on it.  This can lead to deadlock by  
  lock escalation, unnecessarily.  Avoid that by acquiring the stronger  
  lock to begin with.  This probably dates back to branch 12, but I have  
  never seen a report of this being a problem in the field.  
  
* Innocuous but wasteful: also introduced by 53af9491a043, we were  
  reading a pg_constraint tuple from syscache that we don't need, as  
  reported by Tender Wang.  Don't.  
  
Backpatch to 15.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 370bc7740286d342068ce8813ce87aaa4e97973a    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 29 Oct 2024 09:39:55 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 29 Oct 2024 09:39:55 -0700    

Commit a07e03fd8fa7daf4d1356f7cb501ffe784ea6257 changed inplace updates  
to wait for heap_update() commands like GRANT TABLE and GRANT DATABASE.  
By keeping the pin during that wait, a sequence of autovacuum workers  
and an uncommitted GRANT starved one foreground LockBufferForCleanup()  
for six minutes, on buildfarm member sarus.  Prevent, at the cost of a  
bit of complexity.  Back-patch to v12, like the earlier commit.  That  
commit and heap_inplace_lock() have not yet appeared in any release.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a0c8d600bb74e4e8914eceed219bfb069b7908cb    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Oct 2024 11:49:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Oct 2024 11:49:38 -0400    

Historical corrections for Mexico, Mongolia, and Portugal.  
Notably, Asia/Choibalsan is now an alias for Asia/Ulaanbaatar  
rather than being a separate zone, mainly because the differences  
between those zones were found to be based on untrustworthy data.  

commit   : a1b859c6893af2314fa29f8ac3c8bc8f3ad418e5    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 29 Oct 2024 15:35:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 29 Oct 2024 15:35:18 +0900    

There are two functions that can be used in event triggers to get more  
details about a rewrite happening on a relation.  Both had a limited  
documentation:  
- pg_event_trigger_table_rewrite_reason() and  
pg_event_trigger_table_rewrite_oid() were not mentioned in the main  
event trigger section in the paragraph dedicated to the event  
table_rewrite.  
- pg_event_trigger_table_rewrite_reason() returns an integer which is a  
bitmap of the reasons why a rewrite happens.  There was no explanation  
about the meaning of these values, forcing the reader to look at the  
code to find out that these are defined in event_trigger.h.  
  
While on it, let's add a comment in event_trigger.h where the  
AT_REWRITE_* are defined, telling to update the documentation when  
these values are changed.  
  
Backpatch down to 13 as a consequence of 1ad23335f36b, where this area  
of the documentation has been heavily reworked.  
  
Author: Greg Sabino Mullane  
Discussion: https://postgr.es/m/CAKAnmmL+Z6j-C8dAx1tVrnBmZJu+BSoc68WSg3sR+CVNjBCqbw@mail.gmail.com  
Backpatch-through: 13  

commit   : 4f47ee03d5f8adad0da40f650a165393b49cbcf1    
  
author   : David Rowley <[email protected]>    
date     : Tue, 29 Oct 2024 16:25:08 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 29 Oct 2024 16:25:08 +1300    

Disabling enable_indexscan has always also disabled Index Only Scans.  
Here we make that more clear in the documentation in an attempt to  
prevent future complaints complaining about this expected behavior.  
  
Reported-by: Melanie Plageman  
Author: David G. Johnston, David Rowley  
Backpatch-through: 12, oldest supported version  
Discussion: https://postgr.es/m/CAAKRu_atV=kovgpaLREyG68PB5+ncKvJ2UNoeRetEgyC3Yb5Sw@mail.gmail.com  

commit   : 16ebf4f9714a2b8f7f17c537743046a9a59c801b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Oct 2024 14:33:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Oct 2024 14:33:55 -0400    

Coverity complained that pg_saslprep() could suffer integer overflow,  
leading to under-allocation of the output buffer, if the input string  
exceeds SIZE_MAX/4.  This hazard seems largely hypothetical, but it's  
easy enough to defend against, so let's do so.  
  
This patch creates a third place in src/common/ where we are locally  
defining MaxAllocSize so that we can test against that in the same way  
in backend and frontend compiles.  That seems like about two places  
too many, so the next patch will move that into common/fe_memutils.h.  
I'm hesitant to do that in back branches however.  
  
Back-patch to v14.  The code looks similar in older branches, but  
before commit 67a472d71 there was a separate test on the input string  
length that prevented this hazard.  
  
Per Coverity report.  

commit   : 211e6a5b2b26ce99098146f67cd89220429b3613    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 28 Oct 2024 14:07:38 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 28 Oct 2024 14:07:38 +0200    

This was introduced in commit bfa2cee784, which replaced the old  
bsearch_cmp() function we had in extended_stats.c with the current  
implementation. The original discussion or commit message of  
bfa2cee784 didn't mention where the new implementation came from, but  
based on some googling, I'm guessing *BSD or libiberty, all of which  
share this same code, with or without this fix.  
  
Author: Ranier Vilela  
Reviewed-by: Nathan Bossart  
Backpatch-through: 14  
Discussion: https://www.postgresql.org/message-id/CAEudQAp34o_8u6sGSVraLwuMv9F7T9hyHpePXHmRaxR2Aboi%2Bw%40mail.gmail.com  

commit   : 659903f8e792a96a098a593fe2d847755f34545d    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 25 Oct 2024 06:51:03 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 25 Oct 2024 06:51:03 -0700    

A buffer lock won't stop a reader having already checked tuple  
visibility.  If a vac_update_datfrozenid() and then a crash happened  
during inplace update of a relfrozenxid value, datfrozenxid could  
overtake relfrozenxid.  That could lead to "could not access status of  
transaction" errors.  Back-patch to v12 (all supported versions).  In  
v14 and earlier, this also back-patches the assertion removal from  
commit 7fcf2faf9c7dd473208fd6d5565f88d7f733782b.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ce8c571d014e0abf2c1e4f5c3fd5d80783be4fa7    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 25 Oct 2024 06:51:02 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 25 Oct 2024 06:51:02 -0700    

The inplace update survives ROLLBACK.  The inval didn't, so another  
backend's DDL could then update the row without incorporating the  
inplace update.  In the test this fixes, a mix of CREATE INDEX and ALTER  
TABLE resulted in a table with an index, yet relhasindex=f.  That is a  
source of index corruption.  Back-patch to v12 (all supported versions).  
The back branch versions don't change WAL, because those branches just  
added end-of-recovery SIResetAll().  All branches change the ABI of  
extern function PrepareToInvalidateCacheTuple().  No PGXN extension  
calls that, and there's no apparent use case in extensions.  
  
Reviewed by Nitin Motiani and (in earlier versions) Andres Freund.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d36b4d8ec3227c1406c2a3e046153b32b33cecd8    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 25 Oct 2024 06:51:06 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 25 Oct 2024 06:51:06 -0700    

An inplace update's invalidation messages are part of its transaction's  
commit record.  However, the update survives even if its transaction  
aborts or we stop recovery before replaying its transaction commit.  
After recovery, a backend that started in recovery could update the row  
without incorporating the inplace update.  That could result in a table  
with an index, yet relhasindex=f.  That is a source of index corruption.  
  
This bulk invalidation avoids the functional consequences.  A future  
change can fix the !RecoveryInProgress() scenario without changing the  
WAL format.  Back-patch to v17 - v12 (all supported versions).  v18 will  
instead add invalidations to WAL.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2d63c964f0104337ba109a96304491df25e167f2    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 24 Oct 2024 09:16:14 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 24 Oct 2024 09:16:14 -0700    

Stop computing a never-used value.  This removes the read; the read had  
no functional implications.  Back-patch to v12, like commit  
a07e03fd8fa7daf4d1356f7cb501ffe784ea6257.  
  
Reported by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ad88b2020a6846c56da591b84e2f10cd49137e42    
  
author   : Amit Langote <[email protected]>    
date     : Wed, 23 Oct 2024 17:54:48 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Wed, 23 Oct 2024 17:54:48 +0900    

Relations opened by the executor are only closed once in  
ExecCloseRangeTableRelations(), so the word "again" in the comment  
for ExecGetRangeTableRelation() is misleading and unnecessary.  
  
Discussion: https://postgr.es/m/CA+HiwqHnw-zR+u060i3jp4ky5UR0CjByRFQz50oZ05de7wUg=Q@mail.gmail.com  
Backpatch-through: 12  

commit   : a1e613b81aa05b5e29dcb531016269b103208a7d    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2024 08:35:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2024 08:35:02 +0900    

It was possible for the code to read out-of-bound data from the  
"day_tab" table with some crafted input data.  Let's treat these as  
invalid input as the month number is incorrect.  
  
A test is added to test this case with a check on the errno returned by  
the decoding routine.  A test close to the new one added in this commit  
was testing for a failure, but did not look at the errno generated, so  
let's use this commit to also change it, adding a check on the errno  
returned by DecodeDateTime().  
  
Like the other test scripts, dt_test should likely be expanded to  
include more checks based on the errnos generated in these code paths.  
This is left as future work.  
  
This issue exists since 2e6f97560a83, so backpatch all the way down.  
  
Reported-by: Pavel Nekrasov  
Author: Bruce Momjian, Pavel Nekrasov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 2aaf2a28b87eca69b9799ad427f66ba8eddb00c5    
  
author   : Álvaro Herrera <[email protected]>    
date     : Tue, 22 Oct 2024 16:01:18 +0200    
  
committer: Álvaro Herrera <[email protected]>    
date     : Tue, 22 Oct 2024 16:01:18 +0200    

... to fix bugs when the referenced table is partitioned.  
  
The catalog representation we chose for foreign keys connecting  
partitioned tables (in commit f56f8f8da6af) is inconvenient, in the  
sense that a standalone table has a different way to represent the  
constraint when referencing a partitioned table, than when the same  
table becomes a partition (and vice versa).  Because of this, we need to  
create additional catalog rows on detach (pg_constraint and pg_trigger),  
and remove them on attach.  We were doing some of those things, but not  
all of them, leading to missing catalog rows in certain cases.  
  
The worst problem seems to be that we are missing action triggers after  
detaching a partition, which means that you could update/delete rows  
from the referenced partitioned table that still had referencing rows on  
that table, the server failing to throw the required errors.  
  
!!!  
Note that this means existing databases with FKs that reference  
partitioned tables might have rows that break relational integrity, on  
tables that were once partitions on the referencing side of the FK.  
  
Another possible problem is that trying to reattach a table  
that had been detached would fail indicating that internal triggers  
cannot be found, which from the user's point of view is nonsensical.  
  
In branches 15 and above, we fix this by creating a new helper function  
addFkConstraint() which is in charge of creating a standalone  
pg_constraint row, and repurposing addFkRecurseReferencing() and  
addFkRecurseReferenced() so that they're only the recursive routine for  
each side of the FK, and they call addFkConstraint() to create  
pg_constraint at each partitioning level and add the necessary triggers.  
These new routines can be used during partition creation, partition  
attach and detach, and foreign key creation.  This reduces redundant  
code and simplifies the flow.  
  
In branches 14 and 13, we have a much simpler fix that consists on  
simply removing the constraint on detach.  The reason is that those  
branches are missing commit f4566345cf40, which reworked the way this  
works in a way that we didn't consider back-patchable at the time.  
  
We opted to leave branch 12 alone, because it's different from branch 13  
enough that the fix doesn't apply; and because it is going in EOL mode  
very soon, patching it now might be worse since there's no way to undo  
the damage if it goes wrong.  
  
Existing databases might need to be repaired.  
  
In the future we might want to rethink the catalog representation to  
avoid this problem, but for now the code seems to do what's required to  
make the constraints operate correctly.  
  
Co-authored-by: Jehan-Guillaume de Rorthais <[email protected]>  
Co-authored-by: Tender Wang <[email protected]>  
Co-authored-by: Alvaro Herrera <[email protected]>  
Reported-by: Guillaume Lelarge <[email protected]>  
Reported-by: Jehan-Guillaume de Rorthais <[email protected]>  
Reported-by: Thomas Baehler (SBB CFF FFS) <[email protected]>  
Discussion: https://postgr.es/m/20230420144344.40744130@karst  
Discussion: https://postgr.es/m/20230705233028.2f554f73@karst  
Discussion: https://postgr.es/m/GVAP278MB02787E7134FD691861635A8BC9032@GVAP278MB0278.CHEP278.PROD.OUTLOOK.COM  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6c3b2d204f2b02dd80357742713d47050af30613    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2024 15:08:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2024 15:08:22 -0400    

If the query is rewritten into a NOTIFY command by a DO INSTEAD  
rule, we'd get an assertion failure, or in non-assert builds  
issue a rather confusing error message.  Improve that.  
  
Also fix a longstanding grammar mistake in a nearby error message.  
  
Per bug #18664 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Tender Wang and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 22665f2106248793cfd8dd0a49fe3c5f7a4bfdfe    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 21 Oct 2024 09:49:21 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 21 Oct 2024 09:49:21 +0300    

The finished transaction list can contain XIDs that are older than the  
serializable global xmin. It's a short-lived state;  
ClearOldPredicateLocks() removes any such transactions from the list,  
and it's called whenever the global xmin advances. But if another  
backend calls SummarizeOldestCommittedSxact() in that window, it will  
call SerialAdd() on an XID that's older than the global xmin, or if  
there are no more transactions running, when global xmin is  
invalid. That trips the assertion in SerialAdd().  
  
Fixes bug #18658 reported by Andrew Bille. Thanks to Alexander Lakhin  
for analysis. Backpatch to all versions.  
  
Discussion: https://www.postgresql.org/message-id/18658-7dab125ec688c70b%40postgresql.org  

commit   : 1257fea164ee32798f271407974943e7ee23b848    
  
author   : Álvaro Herrera <[email protected]>    
date     : Sun, 20 Oct 2024 15:36:20 +0200    
  
committer: Álvaro Herrera <[email protected]>    
date     : Sun, 20 Oct 2024 15:36:20 +0200    

Missed in 8b08f7d4820f; backpatch to all supported branches.  
  
Reported-by: [email protected]  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : fa4f11854c8b56e094c12c7c25e23d9d456cd5cb    
  
author   : Amit Langote <[email protected]>    
date     : Sun, 20 Oct 2024 12:21:03 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Sun, 20 Oct 2024 12:21:03 +0900    

The decision in b6e1157e7 to ignore raw_expr when evaluating a  
JsonValueExpr was incorrect.  While its value is not ultimately  
used (since formatted_expr's value is), failing to initialize it  
can lead to problems, for instance,  when the expression tree in  
raw_expr contains Aggref nodes, which must be initialized to  
ensure the parent Agg node works correctly.  
  
Also, optimize eval_const_expressions_mutator()'s handling of  
JsonValueExpr a bit.  Currently, when formatted_expr cannot be folded  
into a constant, we end up processing it twice -- once directly in  
eval_const_expressions_mutator() and again recursively via  
ece_generic_processing().  This recursive processing is required to  
handle raw_expr. To avoid the redundant processing of formatted_expr,  
we now  process raw_expr directly in eval_const_expressions_mutator().  
  
Finally, update the comment of JsonValueExpr to describe the roles of  
raw_expr and formatted_expr more clearly.  
  
Bug: #18657  
Reported-by: Alexander Lakhin <[email protected]>  
Diagnosed-by: Fabio R. Sluzala <[email protected]>  
Diagnosed-by: Tender Wang <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 0f4045814fd2e7200dfdf39b568140d8867c18d8    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 18 Oct 2024 10:20:15 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 18 Oct 2024 10:20:15 -0500    

The present wording about viewing shared_memory_size_in_huge_pages  
seems to suggest that the parameter cannot be viewed after startup  
at all, whereas the intent is to make it clear that you can't use  
"postgres -C" to view this parameter while the server is running.  
This commit rephrases this section to remove the ambiguity.  
  
Author: Seino Yuki  
Reviewed-by: Michael Paquier, David G. Johnston, Fujii Masao  
Discussion: https://postgr.es/m/420584fd274f9ec4f337da55ffb3b790%40oss.nttdata.com  
Backpatch-through: 15  

commit   : 53edc948580ff2d2fdbe1b34ed39aeffa61d6564    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2024 15:52:24 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2024 15:52:24 +1300    

After repartitioning the inner side of a hash join that would have  
exceeded the allowed size, we check if all the tuples from a parent  
partition moved to one child partition.  That is evidence that it  
contains duplicate keys and later attempts to repartition will also  
fail, so we should give up trying to limit memory (for lack of a better  
fallback strategy).  
  
A thinko prevented the check from working correctly in partition 0 (the  
one that is partially loaded into memory already).  After  
repartitioning, we should check for extreme skew if the *parent*  
partition's space_exhausted flag was set, not the child partition's.  
The consequence was repeated futile repartitioning until per-partition  
data exceeded various limits including "ERROR: invalid DSA memory alloc  
request size 1811939328", OS allocation failure, or temporary disk space  
errors.  (We could also do something about some of those symptoms, but  
that's material for separate patches.)  
  
This problem only became likely when PostgreSQL 16 introduced support  
for Parallel Hash Right/Full Join, allowing NULL keys into the hash  
table.  Repartitioning always leaves NULL in partition 0, no matter how  
many times you do it, because the hash value is all zero bits.  That's  
unlikely for other hashed values, but they might still have caused  
wasted extra effort before giving up.  
  
Back-patch to all supported releases.  
  
Reported-by: Craig Milhiser <[email protected]>  
Reviewed-by: Andrei Lepikhov <[email protected]>  
Discussion: https://postgr.es/m/CA%2BwnhO1OfgXbmXgC4fv_uu%3DOxcDQuHvfoQ4k0DFeB0Qqd-X-rQ%40mail.gmail.com  

commit   : a34297926c9fec113eadf49f6429729bd5ab991a    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 17 Oct 2024 07:21:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 17 Oct 2024 07:21:43 +0900    

Some queries in copy2 are there to check various option combinations,  
and used "stdin" or "stdout" incompatible with the COPY TO or FROM  
clauses combined with them, which was confusing.  This commit rewrites  
these queries to use a compatible grammar.  
  
The coverage of the tests is unchanged.  Like the original commit  
451d1164b9d0, backpatch down to 16 where these have been introduced.  A  
follow-up commit will rely on this area of the tests for a bug fix.  
  
Author: Joel Jacobson  
Reviewed-by: Zhang Mingli  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 25d639eea04300e8bc7bc8258a07e19b13dfb1f3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Oct 2024 17:36:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Oct 2024 17:36:29 -0400    

Commit 2dc1deaea turns out to have been still a brick shy of a load,  
because CALL statements executing within a plpgsql exception block  
could still pass the wrong snapshot to stable functions within the  
CALL's argument list.  That happened because standard_ProcessUtility  
forces isAtomicContext to true if IsTransactionBlock is true, which  
it always will be inside a subtransaction.  Then ExecuteCallStmt  
would think it does not need to push a new snapshot --- but  
_SPI_execute_plan didn't do so either, since it thought it was in  
nonatomic mode.  
  
The best fix for this seems to be for _SPI_execute_plan to operate  
in atomic execution mode if IsSubTransaction() is true, even when the  
SPI context as a whole is non-atomic.  This makes _SPI_execute_plan  
have the same rules about when non-atomic execution is allowed as  
_SPI_commit/_SPI_rollback have about when COMMIT/ROLLBACK are allowed,  
which seems appropriately symmetric.  (If anyone ever tries to allow  
COMMIT/ROLLBACK inside a subtransaction, this would all need to be  
rethought ... but I'm unconvinced that such a thing could be logically  
consistent at all.)  
  
For further consistency, also check IsSubTransaction() in  
SPI_inside_nonatomic_context.  That does not matter for its  
one present-day caller StartTransaction, which can't be reached  
inside a subtransaction.  But if any other callers ever arise,  
they'd presumably want this definition.  
  
Per bug #18656 from Alexander Alehin.  Back-patch to all  
supported branches, like previous fixes in this area.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 05e982cdc4dfcc340f2db9bfd9dbd92844cf9b01    
  
author   : Masahiko Sawada <[email protected]>    
date     : Wed, 16 Oct 2024 12:08:00 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Wed, 16 Oct 2024 12:08:00 -0700    

Commit a4ccc1cef introduced the Generation Context and modified the  
logical decoding process to use a Generation Context with a fixed  
block size of 8MB for storing tuple data decoded during logical  
decoding (i.e., rb->tup_context). Several reports have indicated that  
the logical decoding process can be terminated due to  
out-of-memory (OOM) situations caused by excessive memory usage in  
rb->tup_context.  
  
This issue can occur when decoding a workload involving several  
concurrent transactions, including a long-running transaction that  
modifies tuples. By design, the Generation Context does not free a  
memory block until all chunks within that block are  
released. Consequently, if tuples modified by the long-running  
transaction are stored across multiple memory blocks, these blocks  
remain allocated until the long-running transaction completes, leading  
to substantial memory fragmentation. The memory usage during logical  
decoding, tracked by rb->size, does not account for memory  
fragmentation, resulting in potentially much higher memory consumption  
than the value of the logical_decoding_work_mem parameter.  
  
Various improvement strategies were discussed in the relevant  
thread. This change reduces the block size of the Generation Context  
used in rb->tup_context from 8MB to 8kB. This modification  
significantly decreases the likelihood of substantial memory  
fragmentation occurring and is relatively straightforward to  
backport. Performance testing across multiple platforms has confirmed  
that this change will not introduce any performance degradation that  
would impact actual operation.  
  
Backport to all supported branches.  
  
Reported-by: Alex Richman, Michael Guissine, Avi Weinberg  
Reviewed-by: Amit Kapila, Fujii Masao, David Rowley  
Tested-by: Hayato Kuroda, Shlok Kyal  
Discussion: https://postgr.es/m/CAD21AoBTY1LATZUmvSXEssvq07qDZufV4AF-OHh9VD2pC0VY2A%40mail.gmail.com  
Backpatch-through: 12  

commit   : 4a933eefe11208d02552f34c8fb3a2b13caeb286    
  
author   : Amit Langote <[email protected]>    
date     : Wed, 16 Oct 2024 18:11:53 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Wed, 16 Oct 2024 18:11:53 +0900    

An oversight of 3a8a1f3254b.  
  
Reported-by: Tender Wang <[email protected]>  
Author: Tender Wang <[email protected]>  
Backpatch-through: 16  

commit   : 6331972c7bc9897780ed9a7ff2320e5c85052a69    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 14 Oct 2024 12:28:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 14 Oct 2024 12:28:01 +0900    

Attempting to use an interval of time less than 1ms would cause \watch  
to hang.  This was confusing, so let's change the logic so as an  
interval lower than 1ms behaves the same as 0.  
  
Comments are added to mention that the internals of do_watch() had  
better rely on "sleep_ms", the interval value in milliseconds.  While on  
it, this commit adds a test to check the behavior of interval values  
less than 1ms.  
  
\watch hanging for interval values less than 1ms existed before  
6f9ee74d45aa, that has changed the code to support an interval value of  
0.  
  
Reported-by: Heikki Linnakangas  
Author: Andrey M. Borodin, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 64635c8af92dafa94a807331c2f0f0b3d6aff402    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 12 Oct 2024 14:56:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 12 Oct 2024 14:56:08 -0400    

find_computable_ec_member() had the wrong mental model of what  
its primary caller prepare_sort_from_pathkeys() would do with  
the selected EquivalenceClass member expression.  We will not  
compute the EC expression in a plan node atop the one returning  
the passed-in targetlist; rather, the EC expression will be  
computed as an additional column of that targetlist.  So any  
Var or quasi-Var used in the given tlist is also available to the  
EC expression.  In simple cases this makes no difference because  
the given tlist is just a list of Vars or quasi-Vars --- but if  
we are considering an appendrel member produced by flattening  
a UNION ALL, the tlist may contain expressions, resulting in  
failure to match and a "could not find pathkey item to sort"  
error.  
  
To fix, we can flatten both the tlist and the EC members with  
pull_var_clause(), and then just check for subset-ness, so  
that the code is actually shorter than before.  
  
While this bug is quite old, the present patch only works back to  
v13.  We could possibly make it work in v12 by back-patching parts  
of 375398244.  On the whole though I don't like the risk/reward  
ratio of that idea.  v12's final release is next month, meaning  
there would be no chance to correct matters if the patch causes a  
regression.  Since this failure has escaped notice for 14 years,  
it's likely nobody will hit it in the field with v12.  
  
Per bug #18652 from Alexander Lakhin.  
  
Andrei Lepikhov and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f21e51ea73973f87715581fc68a6caf97f56505e    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 9 Oct 2024 09:34:34 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 9 Oct 2024 09:34:34 +0200    

Commit 149ac7d4559 which re-implemented pgindent in Perl explicitly  
imported the devnull function from File::Spec, but the module does  
not export anything.  In recent versions of Perl calling a missing  
import function cause a warning, which combined with warnings being  
fatal cause pgindent to error out.  
  
Backpatch to all supported versions.  
  
Author: Erik Wienhold <[email protected]>  
Reviewed-by: Andrew Dunstan <[email protected]>  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discusson: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : 0c40d901907ab16dcfc3895a16d718231e2f8729    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 8 Oct 2024 12:01:35 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 8 Oct 2024 12:01:35 +0530    

The test was unstable in branches 14 and 15 as we were relying on the  
number of changes in the table having a toast column to start streaming.  
On branches >= 16, we have a GUC debug_logical_replication_streaming which  
can stream each change, so the test was stable in those branches.  
  
Change the test to use PREPARE TRANSACTION as that should make the result  
consistent and test the code changed in 022564f60c.  
  
Reported-by: Daniel Gustafsson as per buildfarm  
Author: Hou Zhijie, Amit Kapila  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : eba8cc1af8ec57aff99f11ef9cdf24a641c159b0    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 7 Oct 2024 16:49:20 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 7 Oct 2024 16:49:20 -0500    

Commit 1ab67c9dfa, which modified this catalog query so that it  
doesn't return temporary relations, forgot to schema-qualify the  
operator.  A comment earlier in the function implores us to fully  
qualify everything in the query:  
  
	 * Since we execute the constructed query with the default search_path  
	 * (which could be unsafe), everything in this query MUST be fully  
	 * qualified.  
  
This commit fixes that.  While at it, add a newline for consistency  
with surrounding code.  
  
Reviewed-by: Noah Misch  
Discussion: https://postgr.es/m/ZwQJYcuPPUsF0reU%40nathan  
Backpatch-through: 12  

commit   : 8aaf88b63de3d6e665b0fcf1ff123f08b961fe66    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 7 Oct 2024 13:51:03 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 7 Oct 2024 13:51:03 -0500    

Several places treat MyStartTime as a "long", which is only 32 bits  
wide on some platforms.  In reality, MyStartTime is a pg_time_t,  
i.e., a signed 64-bit integer.  This will lead to interesting bugs  
on the aforementioned systems in 2038 when signed 32-bit integers  
are no longer sufficient to store Unix time (e.g., "pg_ctl start"  
hanging).  To fix, ensure that MyStartTime is handled as a 64-bit  
value everywhere.  (Of course, users will need to ensure that  
time_t is 64 bits wide on their system, too.)  
  
Co-authored-by: Max Johnson  
Discussion: https://postgr.es/m/CO1PR07MB905262E8AC270FAAACED66008D682%40CO1PR07MB9052.namprd07.prod.outlook.com  
Backpatch-through: 12  

commit   : 0f0e253dbf9ed60e037e9b90120404e385c8377b    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 7 Oct 2024 15:04:05 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 7 Oct 2024 15:04:05 +0530    

During logical decoding of in-progress transactions, we perform the toast  
table scan while fetching the default toast value for an attribute. We  
forgot to initialize the flag during this scan to indicate that the system  
table scan is in progress. We need this flag to ensure that during logical  
decoding we never directly access the tableam or heap APIs because we check  
for concurrent aborts only in systable_* APIs.  
  
Reported-by: Alexander Lakhin  
Author: Takeshi Ideriha, Hou Zhijie  
Reviewed-by: Amit Kapila, Hou Zhijie  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5de77b609cbeffcb0b9a570f3848c60bc99ca7fa    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Oct 2024 16:03:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Oct 2024 16:03:48 -0400    

pg_cursor() supposed that any Portal it finds in the hash table must  
have sourceText set up, but there's an edge case where that is not so.  
A newly-created Portal has sourceText = NULL, and that doesn't change  
until PortalDefineQuery is called.  In SPI_cursor_open_internal,  
we perform GetCachedPlan between CreatePortal and PortalDefineQuery,  
and it's possible for user-defined code to execute during that  
planning and cause a fetch from the pg_cursors view, resulting in a  
null-pointer-dereference crash.  (It looks like the same could happen  
in exec_bind_message, but I've not tried to provoke a failure there.)  
  
I considered trying to fix this by setting sourceText sooner, but  
there may be instances of this same calling pattern in extensions,  
and we couldn't be sure they'd get the memo promptly.  It seems  
better to redefine pg_cursor as not showing Portals that have  
not yet had PortalDefineQuery called on them, which we can do by  
just skipping them if sourceText is still NULL.  
  
(Before a1c692358, pg_cursor would instead return a row with NULL  
in the statement column.  We could revert to that behavior but it  
doesn't really seem like a better definition, especially since our  
documentation doesn't suggest that the column could be NULL.)  
  
Per report from PetSerAl.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAKygsHTBXLXjwV43kpZa+Cs+XTiaeeJiZdL4cPBm9f4MTdw7wg@mail.gmail.com  

commit   : ce17de580f90929127fc6290301258e921156bea    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 5 Oct 2024 13:48:33 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 5 Oct 2024 13:48:33 +1300    

Commit bf03cfd1 started scanning all available BCP 47 locale names on  
Windows.  This caused an abort/crash in the Windows runtime library if  
the default locale name contained non-ASCII characters, because of our  
use of the setlocale() save/restore pattern with "char" strings.  After  
switching to another locale with a different encoding, the saved name  
could no longer be understood, and setlocale() would abort.  
  
"Turkish_Türkiye.1254" is the example from recent reports, but there are  
other examples of countries and languages with non-ASCII characters in  
their names, and they appear in Windows' (old style) locale names.  
  
To defend against this:  
  
1.  In initdb, reject non-ASCII locale names given explicity on the  
command line, or returned by the operating system environment with  
setlocale(..., ""), or "canonicalized" by the operating system when we  
set it.  
  
2.  In initdb only, perform the save-and-restore with Windows'  
non-standard wchar_t variant of setlocale(), so that it is not subject  
to round trip failures stemming from char string encoding confusion.  
  
3.  In the backend, we don't have to worry about the save-and-restore  
problem because we have already vetted the defaults, so we just have to  
make sure that CREATE DATABASE also rejects non-ASCII names in any new  
databases.  SET lc_XXX doesn't suffer from the problem, but the ban  
applies to it too because it uses check_locale().  CREATE COLLATION  
doesn't suffer from the problem either, but it doesn't use  
check_locale() so it is not included in the new ban for now, to minimize  
the change.  
  
Anyone who encounters the new error message should either create a new  
duplicated locale with an ASCII-only name using Windows Locale Builder,  
or consider using BCP 47 names like "tr-TR".  Users already couldn't  
initialize a cluster with "Turkish_Türkiye.1254" on PostgreSQL 16+, but  
the new failure mode is an error message that explains why, instead of a  
crash.  
  
Back-patch to 16, where bf03cfd1 landed.  Older versions are affected  
in theory too, but only 16 and later are causing crash reports.  
  
Reviewed-by: Andrew Dunstan <[email protected]> (the idea, not the patch)  
Reported-by: Haifang Wang (Centific Technologies Inc) <[email protected]>  
Discussion: https://postgr.es/m/PH8PR21MB3902F334A3174C54058F792CE5182%40PH8PR21MB3902.namprd21.prod.outlook.com  

commit   : 65f431affda822b3734f04d31c46107e15bc2d34    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Oct 2024 17:30:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Oct 2024 17:30:36 -0400    

Use pqParseIntParam (nee parse_int_param) instead of using strtol  
directly.  This allows trailing whitespace, which the previous coding  
didn't, and makes the spelling of the error message consistent with  
other similar cases.  
  
This seems to be an oversight in commit e7a221797, which introduced  
parse_int_param.  That fixed places that were using atoi(), but missed  
this place which was randomly using strtol() instead.  
  
Ordinarily I'd consider this minor cleanup not worth back-patching.  
However, it seems that ecpg assumes it can add trailing whitespace  
to URL parameters, so that use of the keepalives option fails in  
that context.  Perhaps that's worth improving as a separate matter.  
In the meantime, back-patch this to all supported branches.  
  
Yuto Sasaki (some further cleanup by me)  
  
Discussion: https://postgr.es/m/TY2PR01MB36286A7B97B9A15793335D18C1772@TY2PR01MB3628.jpnprd01.prod.outlook.com  

commit   : e4859f857b6ed3d789231632a4085e9f554859cf    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2024 11:12:48 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 2 Oct 2024 11:12:48 +0900    

The fork name is always separated with the block number by an underscore  
in the names of the files generated, but the docs stuck them together  
without a separator, which was confusing.  
  
Author: Christoph Berg  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 7de9b64a51632e527b0cfb563dae323e51c115ae    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 1 Oct 2024 15:44:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 1 Oct 2024 15:44:09 +0900    

COMMIT PREPARED removes on-disk 2PC files near its end, but the state  
checked if a file is on-disk or not gets read from shared memory while  
not holding the two-phase state lock.  
  
Because of that, there was a small window where a second backend doing a  
PREPARE TRANSACTION could reuse the GlobalTransaction put back into the  
2PC free list by the COMMIT PREPARED, overwriting the "ondisk" flag read  
afterwards by the COMMIT PREPARED to decide if its on-disk two-phase  
state file should be removed, preventing the file deletion.  
  
This commit fixes this issue so as the "ondisk" flag in the  
GlobalTransaction is read while holding the two-phase state lock, not  
from shared memory after its entry has been added to the free list.  
  
Orphaned two-phase state files flushed to disk after a checkpoint are  
discarded at the beginning of recovery.  However, a truncation of  
pg_xact/ would make the startup process issue a FATAL when it cannot  
read the SLRU page holding the state of the transaction whose 2PC file  
was orphaned, which is a necessary step to decide if the 2PC file should  
be removed or not.  Removing manually the file would be necessary in  
this case.  
  
Issue introduced by effe7d9552dd, so backpatch all the way down.  
  
Mea culpa.  
  
Author: wuchengwen  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : e183d72521a863fe3ebbd4b561ef5a018acff977    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 1 Oct 2024 11:36:43 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 1 Oct 2024 11:36:43 +0900    

There were unnecessary non-breaking spaces (nbsp, U+00A0, 0xc2a0 in  
UTF-8) in the docs.  This commit replaces them with ASCII spaces  
(0x20).  
  
config.sgml is backpatched through 17.  
ref/drop_extension.sgml is backpatched through 13.  
  
Discussion: https://postgr.es/m/20240930.153404.202479334310259810.ishii%40postgresql.org  
Reviewed-by: Yugo Nagata, Daniel Gustafsson  
Backpatch-through: 17, 13  

commit   : 653ce5b8b79cffb163216cd53fec78d260d992b8    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 30 Sep 2024 11:13:55 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 30 Sep 2024 11:13:55 +0900    

Reindexing temp tables or indexes of other sessions is not allowed.  
However, reindexdb in parallel mode previously listed them as  
the objects to process, leading to failures.  
  
This commit ensures reindexdb in parallel mode skips temporary tables  
and indexes by adding a condition based on the relpersistence column  
in pg_class to the object listing queries, preventing these issues.  
  
Note that this commit does not affect reindexdb when temporary tables  
or indexes are explicitly specified using the -t or -j options;  
reindexdb in that case still does not skip them and can cause an error.  
  
Back-patch to v13 where parallel mode was introduced in reindexdb.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4c922821e12e5a7526dac9049a4c8af861375103    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 29 Sep 2024 15:54:25 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 29 Sep 2024 15:54:25 -0700    

Defect in last week's commit aac2c9b4fde889d13f859c233c2523345e72d32b,  
per Coverity.  Reaching this would need catalog corruption.  Back-patch  
to v12, like that commit.  

commit   : 0a709c456fc97b6d5452fe2117afc9a4c3b09da9    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 27 Sep 2024 15:28:56 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 27 Sep 2024 15:28:56 -0700    

Back-patch to v12 (all supported versions).  

commit   : afbd3dc7d22379b9aacfa8a695a07e2621e6a55e    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2024 09:40:16 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2024 09:40:16 +0900    

An invalid toast index is skipped in reindex_relation().  These would be  
remnants of a failed REINDEX CONCURRENTLY and they should never been  
rebuilt as there can only be one valid toast index at a time.  
  
REINDEX_REL_SUPPRESS_INDEX_USE, used by CLUSTER and VACUUM FULL, needs  
to maintain a list of the indexes being processed.  The list of indexes  
is retrieved from the relation cache, and includes invalid indexes.  The  
code has missed that invalid toast indexes are ignored in  
reindex_relation() as this leads to a hard failure in reindex_index(),  
and they were left in the reindex pending list, making the list  
inconsistent when rechecked.  The incorrect memory access was happening  
when scanning pg_class for the refresh of pg_database.datfrozenxid, when  
doing a scan of pg_class.  
  
This issue exists since REINDEX CONCURRENTLY exists, where invalid toast  
indexes can exist, so backpatch all the way down.  
  
Reported-by: Alexander Lakhin  
Author: Tender Wang  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 1ea4d9c001e686133f6f7c553221abd109117a0c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2024 14:44:53 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Sep 2024 14:44:53 +0900    

Running vacuumdb with a non-superuser while another user has created a  
temporary table would lead to a mid-flight permission failure,  
interrupting the operation.  vacuum_rel() skips temporary relations of  
other backends, and it makes no sense for vacuumdb to know about these  
relations, so let's switch it to ignore temporary relations entirely.  
  
Adding a qual in the query based on relpersistence simplifies the  
generation of its WHERE clause in vacuum_one_database(), per se the  
removal of "has_where".  
  
Author: VaibhaveS, Michael Paquier  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CAM_eQjwfAR=y3G1fGyS1U9FTmc+FyJm9amNfY2QCZBnDDbNPZg@mail.gmail.com  
Backpatch-through: 12  

commit   : 90f5412a9a513f2d8e4fee1102946219482b8af1    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 17:16:36 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 17:16:36 -0700    

Per buildfarm member akepa and others.  Back-patch to v16 and v15.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 51ff46de29f67d73549b2858f57e77ada8513369    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    

The previous commit fixed some ways of losing an inplace update.  It  
remained possible to lose one when a backend working toward a  
heap_update() copied a tuple into memory just before inplace update of  
that tuple.  In catalogs eligible for inplace update, use LOCKTAG_TUPLE  
to govern admission to the steps of copying an old tuple, modifying it,  
and issuing heap_update().  This includes MERGE commands.  To avoid  
changing most of the pg_class DDL, don't require LOCKTAG_TUPLE when  
holding a relation lock sufficient to exclude inplace updaters.  
Back-patch to v12 (all supported versions).  In v13 and v12, "UPDATE  
pg_class" or "UPDATE pg_database" can still lose an inplace update.  The  
v14+ UPDATE fix needs commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35,  
and it wasn't worth reimplementing that fix without such infrastructure.  
  
Reviewed by Nitin Motiani and (in earlier versions) Heikki Linnakangas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 63f01980560adb57524f8b004b8f47de7e29cc38    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    

As previously-added tests demonstrated, heap_inplace_update() could  
instead update an unrelated tuple of the same catalog.  It could lose  
the update.  Losing relhasindex=t was a source of index corruption.  
Inplace-updating commands like VACUUM will now wait for heap_update()  
commands like GRANT TABLE and GRANT DATABASE.  That isn't ideal, but a  
long-running GRANT already hurts VACUUM progress more just by keeping an  
XID running.  The VACUUM will behave like a DELETE or UPDATE waiting for  
the uncommitted change.  
  
For implementation details, start at the systable_inplace_update_begin()  
header comment and README.tuplock.  Back-patch to v12 (all supported  
versions).  In back branches, retain a deprecated heap_inplace_update(),  
for extensions.  
  
Reported by Smolkin Grigory.  Reviewed by Nitin Motiani, (in earlier  
versions) Heikki Linnakangas, and (in earlier versions) Alexander  
Lakhin.  
  
Discussion: https://postgr.es/m/CAMp+ueZQz3yDk7qg42hk6-9gxniYbp-=bG2mgqecErqR5gGGOA@mail.gmail.com  

commit   : acc63ef4fbe686b0a21000d391d42bbf6b8296eb    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 24 Sep 2024 15:25:18 -0700    

The current use always releases this locktag.  A planned use will  
continue that intent.  It will involve more areas of code, making unlock  
omissions easier.  Warn under debug_assertions, like we do for various  
resource leaks.  Back-patch to v12 (all supported versions), the plan  
for the commit of the new use.  
  
Reviewed by Heikki Linnakangas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f663f4daf075b75268579c9a19d79de81b18c67b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Apr 2024 19:46:33 -0400    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 29 Apr 2024 19:46:33 -0400    

This had been disabled because the test "doesn't delete its user".  
It doesn't seem like a great idea for the meson tests to act  
differently from the makefile tests, though, and the makefiles  
had no such exception (which is how come only copperhead noticed  
the problem just fixed in 534287403).  In any case, the premise  
is false since 936e3fa37, so let's remove the restriction.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4dd17490faa34c2dc4725593f7866c3f18f76e7d    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 3 Apr 2024 13:33:25 +0200    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 3 Apr 2024 13:33:25 +0200    

Project policy is to not leave global objects behind after a regress  
test run.  This was found as a result of the development of a patch  
to make pg_regress detect such leftovers automatically, which in the  
end was withdrawn due to issues with parallel runs.  
  
This was originally committed as 936e3fa3787a, but the issue also exists  
in the 12~16 range.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 8e16522163efce0e2d75b6e8c4413be22e637550    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 15:56:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2024 15:56:34 -0400    

This has always been possible, but the syntax is a bit obscure,  
and our user-facing docs were not very helpful.  Spell it out  
more clearly.  
  
Per complaint from Dominique Devienne.  Back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/CAFCRh-8JNEy+dV4SXFOrWca50u+d=--TO4cq=+ac1oBtfJy4AA@mail.gmail.com  

commit   : 5a56bd4ed0f98f737a0f575c31e1f809bad399f6    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 18:05:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 18:05:22 -0400    

Make paragraph empty instead of removing it.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : 80c8184dc30b3667147f4dc03001ad9138a12248    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 12:01:59 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 12:01:59 -0400    

Backpatch-through: 12  

commit   : 05bbd42562926e1f307fc148194098eaaa244821    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 09:47:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 09:47:22 -0400    

FYI, during PDF builds, this link type generates a "Unresolved ID  
reference found" warning because it is suppressed from the PDF output.  
  
Backpatch-through: 12  

commit   : 43a6b90aaec52149945bdf9e25a8f59802ad93d0    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 08:45:32 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 19 Sep 2024 08:45:32 -0400    

Reported-by: Andrew Dunstan  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Andrew Dunstan  
  
Backpatch-through: 12  

commit   : c2fb2f9e200f43133e4d910d4d9c27cf5e1bb29d    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 16:25:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2024 16:25:11 +0900    

Calling \bind repeatedly would cause the memory allocated for the list  
of bind parameters to be leaked after each call, as the list is reset  
when beginning a single call.  
  
This issue is fixed by making the cleanup of the bind parameter list  
more aggressive, refactoring it into a single routine called after  
processing a query and before running an individual \bind.  
  
HEAD required more surgery and has been fixed by 87eeadaea143.  Issue  
introduced by 5b66de3433e2.  
  
Reported-by: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 00c8c4180a385ced340d52fed41b34ee83731ce4    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 17:13:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 17:13:19 -0400    

And suppress the symbol in print mode, where the section symbol does not  
appear.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : 801cd89ab4bee8efc05b7d4a5bbbb3e76d3fc7a1    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 16:34:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Sep 2024 16:34:52 -0400    

In print output, there are too many commit links for footnotes in the  
release notes to be useful.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : 6f6521de9a961e9365bc84e95a04a7afaafb2f95    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 17 Sep 2024 19:53:11 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 17 Sep 2024 19:53:11 -0700    

Doing so caused the leader to hang in wait_event=ParallelFinish, which  
required an immediate shutdown to resolve.  Back-patch to v12 (all  
supported versions).  
  
Francesco Degrassi  
  
Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com  

commit   : 21aad4bea86d7fc139eefaa55b92da9ba5f0dd5e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 09:59:19 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Sep 2024 09:59:19 +0900    

This commit adds query ID reports for two code paths when processing  
extended query protocol messages:  
- When receiving a bind message, setting it to the first Query retrieved  
from a cached cache.  
- When receiving an execute message, setting it to the first PlannedStmt  
stored in a portal.  
  
An advantage of this method is that this is able to cover all the types  
of portals handled in the extended query protocol, particularly these  
two when the report done in ExecutorStart() is not enough (neither is an  
addition in ExecutorRun(), actually, for the second point):  
- Multiple execute messages, with multiple ExecutorRun().  
- Portal with execute/fetch messages, like a query with a RETURNING  
clause and a fetch size that stores the tuples in a first execute  
message going though ExecutorStart() and ExecuteRun(), followed by one  
or more execute messages doing only fetches from the tuplestore created  
in the first message.  This corresponds to the case where  
execute_is_fetch is set, for example.  
  
Note that the query ID reporting done in ExecutorStart() is still  
necessary, as an EXECUTE requires it.  Query ID reporting is optimistic  
and more calls to pgstat_report_query_id() don't matter as the first  
report takes priority except if the report is forced.  The comment in  
ExecutorStart() is adjusted to reflect better the reality with the  
extended query protocol.  
  
The test added in pg_stat_statements is a courtesy of Robert Haas.  This  
uses psql's \bind metacommand, hence this part is backpatched down to  
v16.  
  
Reported-by:  Kaido Vaikla, Erik Wienhold  
Author: Sami Imseih  
Reviewed-by: Jian He, Andrei Lepikhov, Michael Paquier  
Discussion: https://postgr.es/m/CA+427g8DiW3aZ6pOpVgkPbqK97ouBdf18VLiHFesea2jUk3XoQ@mail.gmail.com  
Discussion: https://postgr.es/m/CA+TgmoZxtnf_jZ=VqBSyaU8hfUkkwoJCJ6ufy4LGpXaunKrjrg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14  

commit   : b8b175a4c89519dc22ad706d685ac2f0be53bd88    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Sep 2024 15:53:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Sep 2024 15:53:26 -0400    

Since we introduced unlogged sequences in v15, identity sequences  
have defaulted to having the same persistence as their owning table.  
However, it is possible to change that with ALTER SEQUENCE, and  
pg_dump tries to preserve the logged-ness of sequences when it doesn't  
match (as indeed it wouldn't for an unlogged table from before v15).  
  
The fly in the ointment is that ALTER SEQUENCE SET [UN]LOGGED fails  
in binary-upgrade mode, because it needs to assign a new relfilenode  
which we cannot permit in that mode.  Thus, trying to pg_upgrade a  
database containing a mismatching identity sequence failed.  
  
To fix, add syntax to ADD/ALTER COLUMN GENERATED AS IDENTITY to allow  
the sequence's persistence to be set correctly at creation, and use  
that instead of ALTER SEQUENCE SET [UN]LOGGED in pg_dump.  (I tried to  
make SET [UN]LOGGED work without any pg_dump modifications, but that  
seems too fragile to be a desirable answer.  This way should be  
markedly faster anyhow.)  
  
In passing, document the previously-undocumented SEQUENCE NAME option  
that pg_dump also relies on for identity sequences; I see no value  
in trying to pretend it doesn't exist.  
  
Per bug #18618 from Anthony Hsu.  
Back-patch to v15 where we invented this stuff.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bff6573c3ab9a9a44647508fed5ccf41f597834e    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 14:23:39 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 14:23:39 -0400    

Backpatch-through: 12  

commit   : b0d6026f7c77458616ccad0de59c33bcd62737aa    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 14:14:38 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 14:14:38 -0400    

Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : dab80b93037c3eb6cef4a1d835d36364980cdf6a    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 13:26:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 16 Sep 2024 13:26:37 -0400    

Reported-by: jian he  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : 4c9bf947a9ecccc8fc6f7f531530656c5b99a93c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2024 13:33:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2024 13:33:09 -0400    

In existing releases of libxml2, xmlXPathCompile can be driven  
to stack overflow because it fails to protect itself against  
too-deeply-nested input.  While there is an upstream fix as of  
yesterday, it will take years for that to propagate into all  
shipping versions.  In the meantime, we can protect our own  
usages basically for free by calling xmlXPathCtxtCompile instead.  
  
(The actual bug is that libxml2 keeps its nesting counter in the  
xmlXPathContext, and its parsing code was willing to just skip  
counting nesting levels if it didn't have a context.  So if we supply  
a context, all is well.  It seems odd actually that it works at all  
to not supply a context, because this means that XPath parsing does  
not have access to XML namespace info.  Apparently libxml2 never  
checks namespaces until runtime?  Anyway, this seems like good  
future-proofing even if its only immediate effect is to dodge a bug.)  
  
Sadly, this hack only offers protection with libxml2 2.9.11 and newer.  
Before that there are multiple similar problems, so if you are  
processing untrusted XML it behooves you to get a newer version.  
But we have some pretty old libxml2 in the buildfarm, so it seems  
impractical to add a regression test to verify this fix.  
  
Per bug #18617 from Jingzhou Fu.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799  

commit   : 121a03d3e338bfa566aa925a3e66acd42f918249    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 19:51:55 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 14 Sep 2024 19:51:55 -0400    

This is needed for a future script to add commit links;  specifically we  
need the closing parentheses of the attribution.  
  
Backpatch-through: 12  

commit   : 2abc88958039990ba82669aa9beebd394d06e9a2    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 17:55:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 14 Sep 2024 17:55:03 -0400    

Historically we've used timezone "PST8PDT", but the recent release  
2024b of tzdb changes the definition of that zone in a way that  
breaks many test cases concerned with dates before 1970.  Although  
we've not yet adopted 2024b into our own tree, this is already  
problematic for people using --with-system-tzdata if their platform  
has already adopted 2024b.  To work with both older and newer  
versions of tzdb, switch to using "America/Los_Angeles", accepting  
the ensuing changes in regression test results.  
  
Back-patch to all supported branches.  
  
Per report and patch from Wolfgang Walther.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cb52d1cdd1031d3b0d66a001b7b153990a0497c8    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 10:26:25 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 10:26:25 -0400    

The current method of detecting perl build flags breaks if the path to  
perl contains a space. This change makes two improvements. First,  
instead of getting a list of ldflags and ccdlflags and then trying to  
filter those out of the reported ldopts, we tell perl to suppress  
reporting those in the first instance. Second, it tells perl to parse  
those and output them, one per line. Thus any space on the option in a  
file name, for example, is preserved.  
  
Issue reported off-list by Muralikrishna Bandaru  
  
Discussion: https://postgr.es/[email protected]  
  
Backpatch to release 16.  

commit   : 0a0db46313749bb379db65eb987af6bf29470300    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 08:37:08 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 14 Sep 2024 08:37:08 -0400    

Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we  
therefore get a handshake error when building against such instances.  
The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is  
defined and only define NO_THREAD_SAFE_LOCALE if it isn't.  
  
Backpatch the meson.build fix back to release 16 and apply the same  
logic to Mkvcbuild.pm in releases 12 through 16.  
  
Original report of the issue from Muralikrishna Bandaru.  

commit   : d23109f4bd65ef217dbd72846afa949927640463    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 13 Sep 2024 16:16:47 -0400    

When we are building a hash index that is large enough to need  
pre-sorting (larger than either maintenance_work_mem or NBuffers),  
the initial sorting phase is interruptible, but the insertion  
phase wasn't.  Add the missing CHECK_FOR_INTERRUPTS().  
  
Per bug #18616 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Pavel Borisov  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0938a4ecda33ce0630dd4cb01466f8ef4c41f8b4    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 10:16:40 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 13 Sep 2024 10:16:40 -0500    

I managed to break this test in two different ways in commit  
05036a3155.  
  
First, the output of the new call to tuple_data_split() on the test  
sequence is dependent on endianness.  This is fixed by setting a  
special start value for the test sequence that produces the same  
output regardless of the endianness of the machine.  
  
Second, on versions older than v15, the new test case fails under  
"force_parallel_mode = regress" with the following error:  
  
	ERROR:  cannot access temporary tables during a parallel operation  
  
This is because pageinspect's disk-accessing functions are  
incorrectly marked PARALLEL SAFE on versions older than v15 (see  
commit aeaaf520f4 for details).  This one is fixed by changing the  
test sequence to be permanent.  The only reason it was previously  
marked temporary was to avoid needing a DROP SEQUENCE command at  
the end of the test.  Unlike some other tests in this file, the use  
of a permanent sequence here shouldn't result in any test  
instability like what was fixed by commit e2933a6e11.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/ZuOKOut5hhDlf_bP%40nathan  
Backpatch-through: 12  

commit   : 2bd4c06bba8ce1264ae3d5810b6aea1bfacbadf7    
  
author   : Nathan Bossart <[email protected]>    
date     : Thu, 12 Sep 2024 16:31:29 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Thu, 12 Sep 2024 16:31:29 -0500    

Commit 4b82664156 restricted a number of functions provided by  
contrib modules to only relations that use the "heap" table access  
method.  Sequences always use this table access method, but they do  
not advertise as such in the pg_class system catalog, so the  
aforementioned commit also (presumably unintentionally) removed  
support for sequences from some of these functions.  This commit  
reintroduces said support for sequences to these functions and adds  
a couple of relevant tests.  
  
Co-authored-by: Ayush Vatsa  
Reviewed-by: Robert Haas, Michael Paquier, Matthias van de Meent  
Discussion: https://postgr.es/m/CACX%2BKaP3i%2Bi9tdPLjF5JCHVv93xobEdcd_eB%2B638VDvZ3i%3DcQA%40mail.gmail.com  
Backpatch-through: 12  

commit   : 4f601b9598a4e241d3b3f08d5a1c46eee09f70df    
  
author   : David Rowley <[email protected]>    
date     : Thu, 12 Sep 2024 22:37:54 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 12 Sep 2024 22:37:54 +1200    

A few recent JSON aggregates have been added without much consideration  
to the existing order.  Put these back in alphabetical order (with the  
exception of the JSONB variant of each JSON aggregate).  
  
Author: Wolfgang Walther <[email protected]>  
Reviewed-by: Marlene Reiterer <[email protected]>  
Discussion: https://postgr.es/m/6a7b910c-3feb-4006-b817-9b4759cb6bb6%40technowledgy.de  
Backpatch-through: 16, where these aggregates were added  

commit   : f3336626d2e35d490fe26a8af0f993a32105a226    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 11 Sep 2024 11:41:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 11 Sep 2024 11:41:47 -0400    

check_agglevels_and_constraints() asserted that if we find an  
aggregate function in an EXPR_KIND_FROM_SUBSELECT expression, the  
expression must be in a LATERAL subquery.  Alexander Lakhin found a  
case where that's not so: because of the odd scoping rules for NEW/OLD  
within a rule, a reference to NEW/OLD could cause an aggregate to be  
considered top-level even though it's in an unmarked sub-select.  
The error message that would be thrown seems sufficiently on-point,  
so just remove the Assert.  (Hence, this is not a bug for production  
builds.)  
  
This Assert was added by me in commit eaccfded9 (9.3 era).  It looks  
like I put it in to cross-check that the new logic for detecting  
misplaced aggregates (using agglevelsup) caught the same cases that a  
previous check on p_lateral_active did.  So there might have been some  
related misbehavior before eaccfded9 ... but that's very ancient  
history by now, so I didn't dig any deeper.  
  
Per bug #18608 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8e65d9ff963e707c51216db24252ebd608758e99    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 11 Sep 2024 13:21:05 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 11 Sep 2024 13:21:05 +0200    

When building a JSON object, the code builds a hash table of keys, to  
allow checking if the keys are unique. The uniqueness check and adding  
the new key happens in json_unique_check_key(), but this assumes the  
pointer to the key remains valid.  
  
Unfortunately, two places passed pointers to keys in a buffer, while  
also appending more data (additional key/value pairs) to the buffer.  
With enough data the buffer is resized by enlargeStringInfo(), which  
calls repalloc(), invalidating the earlier key pointers.  
  
Due to this the uniqueness check may fail with both false negatives and  
false positives, producing JSON objects with duplicate keys or failing  
to produce a perfectly valid JSON object.  
  
This affects multiple functions that enforce uniqueness of keys, all  
introduced in PG16 with the new SQL/JSON:  
  
- json_object_agg_unique / jsonb_object_agg_unique  
- json_object / jsonb_objectagg  
  
Existing regression tests did not detect the issue, simply because the  
initial buffer size is 1024 and the objects were small enough not to  
require the repalloc.  
  
With a sufficiently large object, AddressSanitizer reported the access  
to invalid memory immediately. So would valgrind, of course.  
  
Fixed by copying the key into the hash table memory context, and adding  
regression tests with enough data to repalloc the buffer. Backpatch to  
16, where the functions were introduced.  
  
Reported by Alexander Lakhin. Investigation and initial fix by Junwang  
Zhao, with various improvements and tests by me.  
  
Reported-by: Alexander Lakhin  
Author: Junwang Zhao, Tomas Vondra  
Backpatch-through: 16  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAEG8a3JjH0ReJF2_O7-8LuEbO69BxPhYeXs95_x7+H9AMWF1gw@mail.gmail.com  

commit   : 06c285018a81ce4364e370d276be796a632115f8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2024 16:20:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2024 16:20:31 -0400    

We must drop whitespace while parsing the input, else libxml2  
will include "blank" nodes that interfere with the desired  
indentation behavior.  The end result is that we didn't indent  
nodes separated by whitespace.  
  
Also, it seems that libxml2 may add a trailing newline when working  
in DOCUMENT mode.  This is semantically insignificant, so strip it.  
  
This is in the gray area between being a bug fix and a definition  
change.  However, the INDENT option is still pretty new (since v16),  
so I think we can get away with changing this in stable branches.  
Hence, back-patch to v16.  
  
Jim Jones  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : edb0f6e41b09d261326c5340acad3a2cea59d718    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 9 Sep 2024 13:50:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 9 Sep 2024 13:50:02 +0900    

As introduced by f9900df5f94, a REINDEX CONCURRENTLY job done for an  
index with predicates or expressions would set PROC_IN_SAFE_IC in its  
MyProc->statusFlags, causing it to be ignored by other concurrent  
operations.  
  
Such concurrent index rebuilds should never be ignored, as a predicate  
or an expression could call a user-defined function that accesses a  
different table than the table where the index is rebuilt.  
  
A test that uses injection points is added, backpatched down to 17.  
Michail has proposed a different test, but I have added something  
simpler with more coverage.  
  
Oversight in f9900df5f949.  
  
Author: Michail Nikolaev  
Discussion: https://postgr.es/m/CANtu0oj9A3kZVduFTG0vrmGnKB+DCHgEpzOp0qAyOgmks84j0w@mail.gmail.com  
Backpatch-through: 14  

commit   : dd20f950d4a37da3e71684f254fcdf4317b752b5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Sep 2024 11:57:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Sep 2024 11:57:57 -0400    

pg_stat_get_io() applied TimestampTzGetDatum twice to the  
stat_reset_timestamp value.  On 64-bit builds that's harmless because  
TimestampTzGetDatum is a no-op, but on 32-bit builds it results in  
displaying garbage in the stats_reset column of the pg_stat_io view.  
  
Bug dates to commit a9c70b46d which introduced pg_stat_io, so  
back-patch to v16 where that came in.  
  
Bertrand Drouvot  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4fd4d7653e2cee887b636b7ebb0054ad62a7a506    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 Sep 2024 12:42:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 Sep 2024 12:42:33 -0400    

Since commit 2549f0661, we reject an identifier immediately following  
a numeric literal (without separating whitespace), because that risks  
ambiguity with hex/octal/binary integers.  However, that patch used  
token patterns like "{integer}{ident_start}", which is problematic  
because {ident_start} matches only a single byte.  If the first  
character after the integer is a multibyte character, this ends up  
with flex reporting an error message that includes a partial multibyte  
character.  That can cause assorted bad-encoding problems downstream,  
both in the report to the client and in the postmaster log file.  
  
To fix, use {identifier} not {ident_start} in the "junk" token  
patterns, so that they will match complete multibyte characters.  
This seems generally better user experience quite aside from the  
encoding problem: for "123abc" the error message will now say that  
the error appeared at or near "123abc" instead of "123a".  
  
While at it, add some commentary about why these patterns exist  
and how they work.  
  
Report and patch by Karina Litskevich; review by Pavel Borisov.  
Back-patch to v15 where the problem came in.  
  
Discussion: https://postgr.es/m/CACiT8iZ_diop=0zJ7zuY3BXegJpkKK1Av-PU7xh0EDYHsa5+=g@mail.gmail.com  

commit   : 2015dd5c9024b3be9f712acae7b50dc942e70cda    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 31 Aug 2024 14:32:08 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 31 Aug 2024 14:32:08 +1200    

The first test was sensitive to the insert LSN after setting up the  
catalogs, which depended on environmental things like the locales on the  
OS and usernames.  Switch to a new WAL file before the first test, as a  
simple way to put every computer into the same state.  
  
Back-patch to all supported releases.  
  
Reported-by: Anton Voloshin <[email protected]>  
Reported-by: Nathan Bossart <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Reviewed-by: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/b26aeac2-cb6d-4633-a7ea-945baae83dcf%40postgrespro.ru  

commit   : f3a33111108b1d06f2966e50bad50434026ff5c6    
  
author   : Masahiko Sawada <[email protected]>    
date     : Fri, 30 Aug 2024 15:06:04 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Fri, 30 Aug 2024 15:06:04 -0700    

This change improves the description of the  
restrict_nonsystem_relation_kind parameter in guc_table.c and the  
documentation for better clarity.  
  
Backpatch to 12, where this GUC parameter was introduced.  
  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/6a96f1af-22b4-4a80-8161-1f26606b9ee2%40eisentraut.org  
Backpatch-through: 12  

commit   : 80d9c07a4a8c43955c6c818a125057f4315476a1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2024 12:42:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2024 12:42:13 -0400    

Commit 2489d76c4 removed some logic from pullup_replace_vars()  
that avoided wrapping a PlaceHolderVar around a pulled-up  
subquery output expression if the expression could be proven  
to go to NULL anyway (because it contained Vars or PHVs of the  
pulled-up relation and did not contain non-strict constructs).  
But removing that logic turns out to cause performance regressions  
in some cases, because the extra PHV blocks subexpression folding,  
and will do so even if outer-join reduction later turns it into a  
no-op with no phnullingrels bits.  This can for example prevent  
an expression from being matched to an index.  
  
The reason for always adding a PHV was to ensure we had someplace  
to put the varnullingrels marker bits of the Var being replaced.  
However, it turns out we can optimize in exactly the same cases that  
the previous code did, because we can instead attach the needed  
varnullingrels bits to the contained Var(s)/PHV(s).  
  
This is not a complete solution --- it would be even better if we  
could remove PHVs after reducing them to no-ops.  It doesn't look  
practical to back-patch such an improvement, but this change seems  
safe and at least gets rid of the performance-regression cases.  
  
Per complaint from Nikhil Raj.  Back-patch to v16 where the  
problem appeared.  
  
Discussion: https://postgr.es/m/CAG1ps1xvnTZceKK24OUfMKLPvDP2vjT-d+F2AOCWbw_v3KeEgg@mail.gmail.com  

commit   : 9fe6319dcc1060c9b65d13f61440bfcfc772803a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Aug 2024 13:24:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Aug 2024 13:24:17 -0400    

If an ORDER BY item in SELECT is a bare identifier, the parser  
first seeks it as an output column name of the SELECT (for SQL92  
compatibility).  However, ruleutils.c is expecting the SQL99  
interpretation where such a name is an input column name.  So it's  
possible to produce an incorrect display of a view in the (admittedly  
pretty ill-advised) case where some other column is renamed in the  
SELECT output list to match an ORDER BY column.  
  
This can be fixed by table-qualifying such names in the dumped  
view text.  To avoid cluttering less-ill-advised queries, we'd  
like to do so only when there's an actual name conflict.  
That requires passing the current get_query_def call's resultDesc  
parameter down to get_variable, so that it can determine what  
the output column names are.  In hopes of reducing rather than  
increasing notational clutter in ruleutils.c, I moved that value  
into the deparse_context struct and removed it from the parameter  
lists of get_query_def's other subroutines.  
  
I made a few other cosmetic changes while at it:  
* Likewise move the colNamesVisible parameter into deparse_context.  
* Rename deparse_context's windowTList field to targetList,  
since it's no longer used only in connection with WINDOW clauses.  
* Replace the special_exprkind field with a bool inGroupBy,  
since that was all it was being used for, and the apparent  
flexibility of storing a ParseExprKind proved to be illusory.  
(We need a separate varInOrderBy field to make this patch work.)  
* Remove useless save/restore logic in get_select_query_def.  
  
In principle, this bug is quite old.  However, it seems unreachable  
before 1b4d280ea, because before that the presence of "new" and "old"  
entries in a view's rangetable caused us to always table-qualify every  
Var reference in dumped views.  Hence, back-patch to v16 where that  
came in.  
  
Per bug #18589 from Quynh Tran.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5867ee0056a2db40160926e1a4684d435a099ef4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 29 Aug 2024 08:38:29 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 29 Aug 2024 08:38:29 +0200    

This does not make sense.  It would write the output of the USING  
clause into the converted column, which would violate the generation  
expression.  This adds a check to error out if this is specified.  
  
There was a test for this, but that test errored out for a different  
reason, so it was not effective.  
  
Reported-by: Jian He <[email protected]>  
Reviewed-by: Yugo NAGATA <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/c7083982-69f4-4b14-8315-f9ddb20b9834%40eisentraut.org  

commit   : b39c5272c1d22d80a736647081b60a55a2d9d51e    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 21 Aug 2024 09:01:11 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 21 Aug 2024 09:01:11 +0530    

We advance origin progress during abort on successful streaming and  
application of ROLLBACK in parallel streaming mode. But the origin  
shouldn't be advanced during an error or unsuccessful apply due to  
shutdown. Otherwise, it will result in a transaction loss as such a  
transaction won't be sent again by the server.  
  
Reported-by: Hou Zhijie  
Author: Hayato Kuroda and Shveta Malik  
Reviewed-by: Amit Kapila  
Backpatch-through: 16  
Discussion: https://postgr.es/m/TYAPR01MB5692FAC23BE40C69DA8ED4AFF5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com  

commit   : 25642b2a8b4215722a0eeb0bc3cf6907808b8e47    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2024 17:53:40 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2024 17:53:40 -0400    

For readability.  Backpatch to 16.  
  
Author: Erik Wienhold <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 845f9835e80738f44e8a78003f7d80019f13f8fe    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 20 Aug 2024 13:43:20 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 20 Aug 2024 13:43:20 -0500    

The descriptions for ProcArrayGroupUpdate and XactGroupUpdate claim  
that these events mean we are waiting for the group leader "at end  
of a parallel operation," but neither pertains to parallel  
operations.  This commit reverts these descriptions to their  
wording before commit 3048898e73, i.e., "end of a parallel  
operation" is changed to "transaction end."  
  
Author: Sameer Kumar  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAGPeHmh6UMrKQHKCmX%2B5vV5TH9P%3DKw9en3k68qEem6J%3DyrZPUA%40mail.gmail.com  
Backpatch-through: 13  

commit   : 409be33c3136dce56f7605dd4f9b4e8fe7f5d693    
  
author   : John Naylor <[email protected]>    
date     : Tue, 20 Aug 2024 10:02:34 +0700    
  
committer: John Naylor <[email protected]>    
date     : Tue, 20 Aug 2024 10:02:34 +0700    

Document the hard limit stemming from the size of an OID, and also  
mention the perfomance impact that occurs before the hard limit  
is reached.  
  
Jakub Wartak and Robert Haas  
Backpatch to all supported versions  
  
Discussion: https://postgr.es/m/CAKZiRmwWhp2yxjqJLwbBjHdfbJBcUmmKMNAZyBjjtpgM9AMatQ%40mail.gmail.com  

commit   : a6ff329e7b7231aba9789922daa25e2367709d50    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2024 16:09:10 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2024 16:09:10 -0400    

When a partition is detached and immediately dropped, a prepared  
statement could try to compute a new partition descriptor that includes  
it.  This leads to this kind of error:  
ERROR:  could not open relation with OID 457639  
  
Avoid this by skipping the partition in expand_partitioned_rtentry if it  
doesn't exist.  
  
Noted by me while investigating bug #18559.  Kuntal Gosh helped to  
identify the exact failure.  
  
Backpatch to 14, where DETACH CONCURRENTLY was introduced.  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Kuntal Ghosh <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : f6991cafa36ee8cb943a34f13452fd166b7907c2    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 13:31:51 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 13:31:51 +0200    

Add a comment explaining dropdb() can't rely on syscache. The issue with  
flattened rows was fixed by commit 0f92b230f88b, but better to have  
a clear explanation why the systable scan is necessary. The other places  
doing in-place updates on pg_database have the same comment.  
  
Suggestion and patch by Yugo Nagata. Backpatch to 12, same as the fix.  
  
Author: Yugo Nagata  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com  

commit   : 9333174af47560677b62ae5025e4414f860a84a7    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 19 Aug 2024 12:55:11 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 19 Aug 2024 12:55:11 +0200    

Commit 274bbced disabled session tickets for TLSv1.3 on top of the  
already disabled TLSv1.2 session tickets, but accidentally caused  
a regression where TLSv1.2 session tickets were incorrectly sent.  
Fix by unconditionally disabling TLSv1.2 session tickets and only  
disable TLSv1.3 tickets when the right version of OpenSSL is used.  
  
Backpatch to all supported branches.  
  
Reported-by: Cameron Vogt <[email protected]>  
Reported-by: Fire Emerald <[email protected]>  
Reviewed-by: Jacob Champion <[email protected]>  
Discussion: https://postgr.es/m/DM6PR16MB3145CF62857226F350C710D1AB852@DM6PR16MB3145.namprd16.prod.outlook.com  
Backpatch-through: v12  

commit   : 283964ee4dd1b447e3f7a847802ef183f7ac5e74    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 21:21:03 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 21:21:03 +1200    

Commit ca051d8b101 called newlocale(LC_COLLATE, ...) instead of  
newlocale(LC_COLLATE_MASK, ...), in code reached only on FreeBSD.  They  
have the same value on that OS, explaining why it worked.  Fix.  
  
Back-patch to 14, where ca051d8b101 landed.  

commit   : 1553c84960b0fce23f1ea51b7b5f9362af61f253    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 11:47:37 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 19 Aug 2024 11:47:37 +1200    

MacPorts version 2.9.3 started failing in our ci_macports_packages.sh  
script, for reasons not fully determined, but plausibly linked to the  
release of 2.10.1.  2.10.1 seems to work, so let's switch to it.  
  
Back-patch to 15, where CI began.  
  
Reported-by: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/81f104e8-f0a9-43c0-85bd-2bbbf590a5b8%40eisentraut.org  

commit   : 545794515c8718e4b8b81768644b5f8abe01da80    
  
author   : Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 00:04:41 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Mon, 19 Aug 2024 00:04:41 +0200    

Commit c66a7d75e652 modified DROP DATABASE so that if interrupted, the  
database is known to be in an invalid state and can only be dropped.  
This is done by setting a flag using an in-place update, so that it's  
not lost in case of rollback.  
  
For databases with many ACLs, this may however fail like this:  
  
  ERROR:  wrong tuple length  
  
This happens because with many ACLs, the pg_database.datacl attribute  
gets TOASTed. The dropdb() code reads the tuple from the syscache, which  
means it's detoasted. But the in-place update expects the tuple length  
to match the on-disk tuple.  
  
Fixed by reading the tuple from the catalog directly, not from syscache.  
  
Report and fix by Ayush Tiwari. Backpatch to 12. The DROP DATABASE fix  
was backpatched to 11, but 11 is EOL at this point.  
  
Reported-by: Ayush Tiwari  
Author: Ayush Tiwari  
Reviewed-by: Tomas Vondra  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com  

commit   : cad21a95ece5fa3293396ff1de3bb71aa6669380    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 22:50:54 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2024 22:50:54 -0400    

Change "$1" to "username".  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 12  

commit   : 1b9dd6b05a27ad96a027a0b8ab1e5efd418605a2    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 12 Aug 2024 18:17:56 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 12 Aug 2024 18:17:56 -0400    

If a partition undergoes DETACH CONCURRENTLY immediately followed by  
DROP, this could cause a problem for a concurrent transaction  
recomputing the partition descriptor when running a prepared statement,  
because it tries to dereference a pointer to a tuple that's not found in  
a catalog scan.  
  
The existing retry logic added in commit dbca3469ebf8 is sufficient to  
cope with the overall problem, provided we don't try to dereference a  
non-existant heap tuple.  
  
Arguably, the code in RelationBuildPartitionDesc() has been wrong all  
along, since no check was added in commit 898e5e3290a7 against receiving  
a NULL tuple from the catalog scan; that bug has only become  
user-visible with DETACH CONCURRENTLY which was added in branch 14.  
Therefore, even though there's no known mechanism to cause a crash  
because of this, backpatch the addition of such a check to all supported  
branches.  In branches prior to 14, this would cause the code to fail  
with a "missing relpartbound for relation XYZ" error instead of  
crashing; that's okay, because there are no reports of such behavior  
anyway.  
  
Author: Kuntal Ghosh <[email protected]>  
Reviewed-by: Junwang Zhao <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9db6650a5a66d75234a155b20e18c8dfd7e9c22b    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 11 Aug 2024 12:24:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 11 Aug 2024 12:24:56 -0400    

Coverity thinks dpns->plan could be null at these points.  That  
shouldn't really be possible, but it's easy enough to modify the  
Asserts so they'd not core-dump if it were true.  
  
These are new in b919a97a6.  Back-patch to v13; the v12 version  
of the patch didn't have these Asserts.  

commit   : f3ab5d3a2d19aa9f7243cee6ecd7fec6a36c63c1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 10 Aug 2024 15:51:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 10 Aug 2024 15:51:28 -0400    

The code intends to allow GUCs to be set within parallel workers  
via function SET clauses, but not otherwise.  However, doing so fails  
for "session_authorization" and "role", because the assign hooks for  
those attempt to set the subsidiary "is_superuser" GUC, and that call  
falls foul of the "not otherwise" prohibition.  We can't switch to  
using GUC_ACTION_SAVE for this, so instead add a new GUC variable  
flag GUC_ALLOW_IN_PARALLEL to mark is_superuser as being safe to set  
anyway.  (This is okay because is_superuser has context PGC_INTERNAL  
and thus only hard-wired calls can change it.  We'd need more thought  
before applying the flag to other GUCs; but maybe there are other  
use-cases.)  This isn't the prettiest fix perhaps, but other  
alternatives we thought of would be much more invasive.  
  
While here, correct a thinko in commit 059de3ca4: when rejecting  
a GUC setting within a parallel worker, we should return 0 not -1  
if the ereport doesn't longjmp.  (This seems to have no consequences  
right now because no caller cares, but it's inconsistent.)  Improve  
the comments to try to forestall future confusion of the same kind.  
  
Despite the lack of field complaints, this seems worth back-patching.  
Thanks to Nathan Bossart for the idea to invent a new flag,  
and for review.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 93c82d0e6a252dc2fb6d6c7ed240508140cd1480    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 9 Aug 2024 10:52:37 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 9 Aug 2024 10:52:37 -0500    

This section claims we use CRC-32 for WAL records and two-phase  
state files, but we've actually used CRC-32C since v9.5 (commit  
5028f22f6e).  Fix that.  
  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/ZrUFpLP-w2zTAHqq%40nathan  
Backpatch-through: 12  

commit   : 03f679475d9ae6cafa1ea155e9f77255f245ef79    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2024 11:21:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2024 11:21:39 -0400    

To deparse a reference to a field of a RECORD-type output of a  
subquery, EXPLAIN normally digs down into the subquery's plan to try  
to discover exactly which anonymous RECORD type is meant.  However,  
this can fail if the subquery has been optimized out of the plan  
altogether on the grounds that no rows could pass the WHERE quals,  
which has been possible at least since 3fc6e2d7f.  There isn't  
anything remaining in the plan tree that would help us, so fall back  
to printing the field name as "fN" for the N'th column of the record.  
(This will actually be the right thing some of the time, since it  
matches the column names we assign to RowExprs.)  
  
In passing, fix a comment typo in create_projection_plan, which  
I noticed while experimenting with an alternative fix for this.  
  
Per bug #18576 from Vasya B.  Back-patch to all supported branches.  
  
Richard Guo and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ada34d7146c343a143de811eefc4fdd190ce40a5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2024 19:35:13 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2024 19:35:13 -0400    

Trying to attach a table as a partition which is already on the  
referenced side of a foreign key on the partitioned table that it is  
being attached to, leads to strange behavior: we try to clone the  
foreign key from the parent to the partition, but this new FK points to  
the partition itself, and the mix of pg_constraint rows and triggers  
doesn't behave well.  
  
Rather than trying to untangle the mess (which might be possible given  
sufficient time), I opted to forbid the ATTACH.  This doesn't seem a  
problematic restriction, given that we already fail to create the  
foreign key if you do it the other way around, that is, having the  
partition first and the FK second.  
  
Backpatch to all supported branches.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : e8240dbd86f70e268ebda57c07eb98bd80a4e6f0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 8 Aug 2024 10:20:25 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 8 Aug 2024 10:20:25 +0300    

getTimelineHistory() is called twice, to read the source and the  
target timeline history files. However, the loop to print the file  
with the --debug option used the wrong variable when dealing with the  
source. As a result, the source's history was always printed as empty.  
  
Spotted while debugging bug #18575, but this does not fix that bug,  
just the debugging output. Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : ee2997c678d86568328f0221717676f86b8aa6f6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 7 Aug 2024 09:21:07 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 7 Aug 2024 09:21:07 +0200    

Commit 0b9466fce added a dependency on fe_memutils' pnstrdup() inside  
informix.c.  This adds an exit() path in a library, which we don't  
want.  (Unlike libpq, the ecpg libraries don't have an automated check  
for that, but it makes sense to keep them to a similar standard.)  The  
ecpg code can already handle failure results from the *strdup() call  
by itself.  
  
Author: Jacob Champion <[email protected]>  
Discussion: https://www.postgresql.org/message-id/CAOYmi+=pg=W5L1h=3MEP_EB24jaBu2FyATrLXqQHGe7cpuvwyg@mail.gmail.com  

commit   : a073835c19cfcd5ce1c9826f2f9356944d807b0e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2024 12:54:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2024 12:54:39 -0400    

If the plancache entry for the CALL statement is already stale,  
it's possible for us to fetch an old procedure OID out of it,  
and then fail with "cache lookup failed for function NNN".  
In ordinary usage this never happens because make_callstmt_target  
is called just once immediately after building the plancache  
entry.  It can be forced however by setting up an erroneous CALL  
(that causes make_callstmt_target itself to report an error),  
then dropping/recreating the target procedure, then repeating  
the erroneous CALL.  
  
To fix, use SPI_plan_get_cached_plan() to fetch the plancache's  
plan, rather than assuming we can use SPI_plan_get_plan_sources().  
This shouldn't add any noticeable overhead in the normal case,  
and in the stale-plan case we'd have had to replan anyway a little  
further down.  
  
The other callers of SPI_plan_get_plan_sources() seem OK, because  
either they don't need up-to-date plans or they know that the  
query was just (re) planned.  But add some commentary in hopes  
of not falling into this trap again.  
  
Per bug #18574 from Song Hongyu.  Back-patch to v14 where this coding  
was introduced.  (Older branches have comparable code, but it's run  
after any required replanning, so there's no issue.)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0583863e9e6e9ce412bf82658d691370336fa9c0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2024 10:43:52 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2024 10:43:52 +0300    

Replace a static scratch buffer with a local variable, because a  
static buffer makes the function not thread-safe. This function is  
used in client-code in libpq, so it needs to be thread-safe. It was  
until commit b67b57a966, which replaced the implementation with the  
one from pgcrypto.  
  
Backpatch to v14, where we switched to the new implementation.  
  
Reviewed-by: Robert Haas, Michael Paquier  
Discussion: https://www.postgresql.org/message-id/[email protected]