PostgreSQL 14.16 commit log

commit   : 6884202705699820ec9427d1fba7eeba0e2de03e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2025 18:26:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2025 18:26:37 -0500    

commit   : e748064669f40a2dc9cf29b8518902620e47e2db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2025 18:16:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2025 18:16:25 -0500    

Security: CVE-2025-1094  

commit   : e1f1b030d7d9fea27a77a335699372e0b222c61a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2025 16:30:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2025 16:30:03 -0500    

We need to tell fmtId() what encoding to assume, but this function  
doesn't know that.  Fortunately we can fix that without changing the  
function's API, because we can just use SQL_ASCII.  That's because  
database names in connection requests are effectively binary not text:  
no encoding-aware processing will happen on them.  
  
This fixes XversionUpgrade failures seen in the buildfarm.  The  
alternative of having pg_upgrade use setFmtEncoding() is unappetizing,  
given that it's connecting to multiple databases that may have  
different encodings.  
  
Andres Freund, Noah Misch, Tom Lane  
  
Security: CVE-2025-1094  

commit   : 4a6825c762112f085d6ee03bbce8e7abe2bf98e5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 12:09:23 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 12:09:23 -0500    

On machines where char is unsigned this could lead to option parsing looping  
endlessly. It's also too narrow a type on other hardware.  
  
Found via Tom Lane's monitoring of the buildfarm.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Security: CVE-2025-1094  
Backpatch-through: 13  

commit   : 17b789469106e156f559fcdab0c720db3c38151a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    

Backpatch-through: 13  
Security: CVE-2025-1094  

commit   : 46ddf98df0517d39108abdf5da29e0cae8d4ebfd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    

As highlighted by the prior commit, writing correct escape functions is less  
trivial than one might hope.  
  
This test module tries to verify that different escaping functions behave  
reasonably. It e.g. tests:  
  
- Invalidly encoded input to an escape function leads to invalidly encoded  
  output  
  
- Trailing incomplete multi-byte characters are handled sensibly  
  
- Escaped strings are parsed as single statement by psql's parser (which  
  derives from the backend parser)  
  
There are further tests that would be good to add. But even in the current  
state it was rather useful for writing the fix in the prior commit.  
  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Backpatch-through: 13  
Security: CVE-2025-1094  

commit   : e0ef3d776a349db2c63075241626563b79477bd4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    

Previously invalidly encoded input to various escaping functions could lead to  
the escaped string getting incorrectly parsed by psql.  To be safe, escaping  
functions need to ensure that neither invalid nor incomplete multi-byte  
characters can be used to "escape" from being quoted.  
  
Functions which can report errors now return an error in more cases than  
before. Functions that cannot report errors now replace invalid input bytes  
with a byte sequence that cannot be used to escape the quotes and that is  
guaranteed to error out when a query is sent to the server.  
  
The following functions are fixed by this commit:  
- PQescapeLiteral()  
- PQescapeIdentifier()  
- PQescapeString()  
- PQescapeStringConn()  
- fmtId()  
- appendStringLiteral()  
  
Reported-by: Stephen Fewer <stephen_fewer@rapid7.com>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 13  
Security: CVE-2025-1094  

commit   : 2ae54ae17eaad592991e7459140b2cad2e82745c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    

This commit adds fmtIdEnc() and fmtQualifiedIdEnc(), which allow to specify  
the encoding as an explicit argument.  Additionally setFmtEncoding() is  
provided, which defines the encoding when no explicit encoding is provided, to  
avoid breaking all code using fmtId().  
  
All users of fmtId()/fmtQualifiedId() are either converted to the explicit  
version or a call to setFmtEncoding() has been added.  
  
This commit does not yet utilize the now well-defined encoding, that will  
happen in a subsequent commit.  
  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Backpatch-through: 13  
Security: CVE-2025-1094  

commit   : 5bc33cbeae0e5cb8ecb410f8e47efb92811380fd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:40 -0500    

There are cases where we cannot / do not want to error out for invalidly  
encoded input. In such cases it can be useful to replace e.g. an incomplete  
multi-byte characters with bytes that will trigger an error when getting  
validated as part of a larger string.  
  
Unfortunately, until now, for some encoding no such sequence existed. For  
those encodings this commit removes one previously accepted input combination  
- we consider that to be ok, as the chosen bytes are outside of the valid  
ranges for the encodings, we just previously failed to detect that.  
  
As we cannot add a new field to pg_wchar_table without breaking ABI, this is  
implemented "in-line" in the newly added function.  
  
Author: Noah Misch <noah@leadboat.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Backpatch-through: 13  
Security: CVE-2025-1094  

commit   : 04f31c8d0d0f07cfd600e9a51496481da6fc14ed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2025 15:16:57 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2025 15:16:57 +0100    

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

commit   : 2e44eefb9dd93d3f05deb57edb5597df41c7cdde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Feb 2025 13:58:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Feb 2025 13:58:53 -0500    

commit   : 5addea71c7c7693ed9aa071e122038e2dd7011ab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Feb 2025 13:41:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Feb 2025 13:41:43 -0500    

Commit af35fe501 caused "pgbench -i" to emit a '\r' character  
for each data row loaded (when stderr is a terminal).  
That's effectively invisible on-screen, but it causes the  
connected terminal program to consume a lot of cycles.  
It's even worse if you're connected over ssh, as the data  
then has to pass through the ssh tunnel.  
  
Simplest fix is to move the added logic inside the if-tests  
that check whether to print a progress line.  We could do  
it another way that avoids duplicating these few lines,  
but on the whole this seems the most transparent way to  
write it.  
  
Like the previous commit, back-patch to all supported versions.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/4k4drkh7bcmdezq6zbkhp25mnrzpswqi2o75d5uv2eeg3aq6q7@b7kqdmzzwzgb  
Backpatch-through: 13  

commit   : 9f6ad2f43c2fd94cfca99bb178d4eb03754cdd9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Feb 2025 12:40:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Feb 2025 12:40:41 -0500    

Try to make it absolutely plain that we don't retain the  
originally specified time zone, only the UTC timestamp.  
  
While at it, make glossary entries for "UTC" and "GMT".  
  
Author: Robert Treat <rob@xzilla.net>  
Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/173796426022.1064.9135167366862649513@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : ceeae767042f67e548c8792262aa9f7aefb58d00    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 5 Feb 2025 13:58:40 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 5 Feb 2025 13:58:40 +0100    

Two links in the isn module documentation were pointing to tools  
which had been moved, resulting in 404 error responses.  Update  
to the new URLs for the tools.  The link to the Sequoia 2000 page  
in the history section was no longer working, and since the page  
is no longer available online update our link to point at the  
paper instead which is on a stable URL.  
  
These links exist in all versions of the documentation so backpatch  
to all supported branches.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reported-by: charukiewicz@protonmail.com  
Discussion: https://postgr.es/m/173679670185.705.8565555804465055355@wrigleys.postgresql.org  
Backpatch-through: 13  

commit   : f2205448b15e991478e8ba717732fc02b5a55d09    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 5 Feb 2025 00:15:17 +0200    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 5 Feb 2025 00:15:17 +0200    

Protect against malformed timestamps.  Also protect against negative WalSegSz  
as it triggers division by zero:  
  
((0x100000000UL) / (WalSegSz)) can turn into zero in  
  
XLogFileName(xlogfilename, ControlFile->checkPointCopy.ThisTimeLineID,  
             segno, WalSegSz);  
  
because if WalSegSz is -1 then by arithmetic rules in C we get  
0x100000000UL / 0xFFFFFFFFFFFFFFFFUL == 0.  
  
Author: Ilyasov Ian <ianilyasov@outlook.com>  
Author: Anton Voloshin <a.voloshin@postgrespro.ru>  
Backpatch-through: 13  

commit   : eeaf6891be48ac2940361717525c277a02c97e63    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 4 Feb 2025 13:26:57 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 4 Feb 2025 13:26:57 -0600    

A few of the version checks in vacuum_one_database() do not call  
PQfinish() before exiting.  This precedent was unintentionally  
established in commit 00d1e88d36, and while it's probably not too  
problematic, it seems better to properly close the connection.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/Z6JAwqN1I8ljTuXp%40nathan  
Backpatch-through: 13  

commit   : d7260f92adea66791b027ad46b44b2cb7d77b555    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Feb 2025 11:31:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Feb 2025 11:31:32 +0900    

logging_collector was only mentioning stderr and csvlog, and forgot  
about jsonlog.  Oversight in dc686681e079, that has added support for  
jsonlog in log_destination.  
  
While on it, the description in the GUC table is tweaked to be more  
consistent with the documentation and postgresql.conf.sample.  
  
Author: Umar Hayat  
Reviewed-by: Ashutosh Bapat, Tom Lane  
Discussion: https://postgr.es/m/CAD68Dp1K_vBYqBEukHw=1jF7e76t8aszGZTFL2ugi=H7r=a7MA@mail.gmail.com  
Backpatch-through: 13  

commit   : 71832a189b198d483fab61a529d48a417e64619c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jan 2025 11:06:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jan 2025 11:06:12 +0900    

The top comment of StrategySyncStart() mentions BufferSync(), but this  
function calls BgBufferSync(), not BufferSync().  
  
Oversight in 9cd00c457e6a.  
  
Author: Ashutosh Bapat  
Discussion: https://postgr.es/m/CAExHW5tgkjag8i-s=RFrCn5KAWDrC4zEPPkfUKczfccPOxBRQQ@mail.gmail.com  
Backpatch-through: 13  

commit   : 6a33bb35c0411e298c99dfd4b40772c3f91f08ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2025 15:36:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2025 15:36:07 -0500    

smgrDoPendingSyncs had two distinct risks of integer overflow while  
deciding which way to ensure durability of a newly-created relation.  
First, it accumulated the total size of all forks in a variable of  
type BlockNumber (uint32).  While we restrict an individual fork's  
size to fit in that, I don't believe there's such a restriction on  
all of them added together.  Second, it proceeded to multiply the  
sum by BLCKSZ, which most certainly could overflow a uint32.  
  
(The exact expression is total_blocks * BLCKSZ / 1024.  The  
compiler might choose to optimize that to total_blocks * 8,  
which is not at quite as much risk of overflow as a literal  
reading would be, but it's still wrong.)  
  
If an overflow did occur it could lead to a poor choice to  
shove a very large relation into WAL instead of fsync'ing it.  
This wouldn't be fatal, but it could be inefficient.  
  
Change total_blocks to uint64 which should be plenty, and  
rearrange the comparison calculation to be overflow-safe.  
  
I noticed this while looking for ramifications of the proposed  
change in MAX_KILOBYTES.  It's not entirely clear to me why  
wal_skip_threshold is limited to MAX_KILOBYTES in the  
first place, but in any case this code is unsafe regardless  
of the range of wal_skip_threshold.  
  
Oversight in c6b92041d which introduced wal_skip_threshold,  
so back-patch to v13.  
  
Discussion: https://postgr.es/m/1a01f0-66ec2d80-3b-68487680@27595217  
Backpatch-through: 13  

commit   : c05268e6ec931724282b5780f228e5a1aad94268    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2025 15:31:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2025 15:31:55 -0500    

If a column is omitted in an INSERT, and there's no column default,  
the code in preptlist.c generates a NULL Const to be inserted.  
Furthermore, if the column is of a domain type, we wrap the Const  
in CoerceToDomain, so as to throw a run-time error if the domain  
has a NOT NULL constraint.  That's fine as far as it goes, but  
there are two problems:  
  
1. We're being sloppy about the type/typmod that the Const is  
labeled with.  It really should have the domain's base type/typmod,  
since it's the input to CoerceToDomain not the output.  This can  
result in coerce_to_domain inserting a useless length-coercion  
function (useless because it's being applied to a null).  The  
coercion would typically get const-folded away later, but it'd  
be better not to create it in the first place.  
  
2. We're not applying expression preprocessing (specifically,  
eval_const_expressions) to the resulting expression tree.  
The planner's primary expression-preprocessing pass already happened,  
so that means the length coercion step and CoerceToDomain node miss  
preprocessing altogether.  
  
This is at the least inefficient, since it means the length coercion  
and CoerceToDomain will actually be executed for each inserted row,  
though they could be const-folded away in most cases.  Worse, it  
seems possible that missing preprocessing for the length coercion  
could result in an invalid plan (for example, due to failing to  
perform default-function-argument insertion).  I'm not aware of  
any live bug of that sort with core datatypes, and it might be  
unreachable for extension types as well because of restrictions of  
CREATE CAST, but I'm not entirely convinced that it's unreachable.  
Hence, it seems worth back-patching the fix (although I only went  
back to v14, as the patch doesn't apply cleanly at all in v13).  
  
There are several places in the rewriter that are building null  
domain constants the same way as preptlist.c.  While those are  
before the planner and hence don't have any reachable bug, they're  
still applying a length coercion that will be const-folded away  
later, uselessly wasting cycles.  Hence, make a utility routine  
that all of these places can call to do it right.  
  
Making this code more careful about the typmod assigned to the  
generated NULL constant has visible but cosmetic effects on some  
of the plans shown in contrib/postgres_fdw's regression tests.  
  
Discussion: https://postgr.es/m/1865579.1738113656@sss.pgh.pa.us  
Backpatch-through: 14  

commit   : 54f9afea7a7d356c8569014c5cf85a99455508ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2025 14:24:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2025 14:24:36 -0500    

When running on Windows, canonicalize_path() converts '\' to '/'  
to prevent confusing the Windows command processor.  It was  
doing that in a non-encoding-aware fashion; but in SJIS there  
are valid two-byte characters whose second byte matches '\'.  
So encoding corruption ensues if such a character is used in  
the path.  
  
We can fairly easily fix this if we know which encoding is  
in use, but a lot of our utilities don't have much of a clue  
about that.  After some discussion we decided we'd settle for  
fixing this only in psql, and assuming that its value of  
client_encoding matches what the user is typing.  
  
It seems hopeless to get the server to deal with the problematic  
characters in database path names, so we'll just declare that  
case to be unsupported.  That means nothing need be done in  
the server, nor in utility programs whose only contact with  
file path names is for database paths.  But psql frequently  
deals with client-side file paths, so it'd be good if it  
didn't mess those up.  
  
Bug: #18735  
Reported-by: Koichi Suzuki <koichi.suzuki@enterprisedb.com>  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Koichi Suzuki <koichi.suzuki@enterprisedb.com>  
Discussion: https://postgr.es/m/18735-4acdb3998bb9f2b1@postgresql.org  
Backpatch-through: 13  

commit   : 25e99483c4116313b678cc94df53d3ea28977752    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jan 2025 11:28:14 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jan 2025 11:28:14 -0800    

The right mix of DDL and VACUUM could corrupt a catalog page header such  
that PageIsVerified() durably fails, requiring a restore from backup.  
This affects only catalogs that both have a syscache and have DDL code  
that uses syscache tuples to construct updates.  One of the test  
permutations shows a variant not yet fixed.  
  
This makes !TransactionIdIsValid(TM_FailureData.xmax) possible with  
TM_Deleted.  I think core and PGXN are indifferent to that.  
  
Per bug #17821 from Alexander Lakhin.  Back-patch to v13 (all supported  
versions).  The test case is v17+, since it uses INJECTION_POINT.  
  
Discussion: https://postgr.es/m/17821-dd8c334263399284@postgresql.org  

commit   : 7b3259bd7cf37da472ff5c2ce25fe0aa552e6fe0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jan 2025 11:28:14 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Jan 2025 11:28:14 -0800    

Since commit 757fb0e5a9a61ac8d3a67e334faeea6dc0084b3f, these  
Informix-compat functions return 0 without changing the output  
parameter.  Initialize the output parameter before the test call, making  
that obvious.  Before this, the expected test output has been depending  
on freed stack memory.  "gcc -ftrivial-auto-var-init=pattern" revealed  
that.  Back-patch to v13 (all supported versions).  
  
Discussion: https://postgr.es/m/20250106192748.cf.nmisch@google.com  

commit   : 4106942f004fdd789ea4b35be0585c1f8268744d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jan 2025 12:42:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jan 2025 12:42:05 -0500    

This practice avoids possible problems caused by non-default psql  
options, such as disabling AUTOCOMMIT.  
  
Author: Shinya Kato <Shinya11.Kato@oss.nttdata.com>  
Reviewed-by: Robert Treat <rob@xzilla.net>  
Discussion: https://postgr.es/m/96ff23a5d858ff72ca8e823a014d16fe@oss.nttdata.com  
Backpatch-through: 13  

commit   : fb60050f42019b1dc5781fa0f43ca0fa7f0de9c7    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 25 Jan 2025 00:36:48 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 25 Jan 2025 00:36:48 +0100    

The sizeof() call should reference buffer.data, because that's the  
buffer we're reading data into, not the whole PGAlignedBuffer union.  
This was introduced by 44cac93464, which replaced the simple buffer  
with a PGAlignedBuffer field.  
  
It's benign, because the buffer is the largest field of the union, so  
the sizes are the same. But it's easy to trip over this in a patch, so  
fix and backpatch. Commit 44cac93464 went into 12, but that's EOL.  
  
Backpatch-through: 13  
Discussion: https://postgr.es/m/928bdab1-6567-449f-98c4-339cd2203b87@vondra.me  

commit   : 63a4b9f767866f4cbe7416c7eff7e35206d871b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2025 14:23:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jan 2025 14:23:04 -0500    

We thought that this condition was unreachable in ExitPostmaster,  
but actually it's possible if you have both a misconfigured locale  
setting and some other mistake that causes PostmasterMain to bail  
out before reaching its own check of pthread_is_threaded_np().  
  
Given the lack of other reports, let's not ask for bug reports if  
this occurs; instead just give the same hint as in PostmasterMain.  
  
Bug: #18783  
Reported-by: anani191181515@gmail.com  
Author: Tom Lane <tgl@sss.pgh.pa.us>  
Reviewed-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/18783-d1873b95a59b9103@postgresql.org  
Discussion: https://postgr.es/m/206317.1737656533@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 30859930528b50e55f1a3ea66b6a9a3704c8df62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jan 2025 11:58:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jan 2025 11:58:20 -0500    

This patch fixes two distinct errors that both ultimately trace  
to commit 71d60e2aa, which added the ats_modifiedcols field.  
  
The more severe error is that ats_modifiedcols wasn't accounted for  
in afterTriggerAddEvent's scanning loop that looks for a pre-existing  
duplicate AfterTriggerSharedData.  Thus, a new event could be  
incorrectly matched to an AfterTriggerSharedData that has a different  
value of ats_modifiedcols, resulting in the wrong tg_updatedcols  
bitmap getting passed to the trigger whenever it finally gets fired.  
We'd not noticed because (a) few triggers consult tg_updatedcols,  
and (b) we had no tests exercising a case where such a trigger was  
called as an AFTER trigger.  In the test case added by this commit,  
contrib/lo's trigger fails to remove a large object when expected  
because (without this fix) it thinks the LO OID column hasn't changed.  
  
The other problem was introduced by commit ce5aaea8c, which copied the  
modified-columns bitmap into trigger-related storage.  It made a copy  
for every trigger event, whereas what we really want is to make a new  
copy only when we make a new AfterTriggerSharedData entry.  (We could  
imagine adding extra logic to reduce the number of bitmap copies still  
more, but it doesn't look worthwhile at the moment.)  In a simple test  
of an UPDATE of 10000000 rows with a single AFTER trigger, this thinko  
roughly tripled the amount of memory consumed by the pending-triggers  
data structures, from 160446744 to 480443440 bytes.  
  
Fixing the first problem requires introducing a bms_equal() call into  
afterTriggerAddEvent's scanning loop, which is slightly annoying from  
a speed perspective.  However, getting rid of the excessive bms_copy()  
calls from the second problem balances that out; overall speed of  
trigger operations is the same or slightly better, in my tests.  
  
Discussion: https://postgr.es/m/3496294.1737501591@sss.pgh.pa.us  
Backpatch-through: 13  

commit   : 20b4819d0e351767f7f123ebdb5be246bba1a1bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2025 16:49:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2025 16:49:15 -0500    

DST law changes in Paraguay.  
Historical corrections for the Philippines.  
  
Backpatch-through: 13  

commit   : aac0384975ff1129557cd2158fab4656f933cdc8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2025 15:47:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2025 15:47:53 -0500    

The freshly-released 2025a version of tzdata has a refined estimate  
for the longitude of Manila, changing their value for LMT in  
pre-standardized-timezone days.  This changes the output of one of  
our test cases.  Since we need to be able to run with system tzdata  
files that may or may not contain this update, we'd better stop  
making that specific test.  
  
I switched it to use Asia/Singapore, which has a roughly similar UTC  
offset.  That LMT value hasn't changed in tzdb since 2003, so we can  
hope that it's well established.  
  
I also noticed that this set of make_timestamptz tests only exercises  
zones east of Greenwich, which seems rather sad, and was not the  
original intent AFAICS.  (We've already changed these tests once  
to stabilize their results across tzdata updates, cf 66b737cd9;  
it looks like I failed to consider the UTC-offset-sign aspect then.)  
To improve that, add a test with Pacific/Honolulu.  That LMT offset  
is also quite old in tzdb, so we'll cross our fingers that it doesn't  
get improved.  
  
Reported-by: Christoph Berg <cb@df7cb.de>  
Discussion: https://postgr.es/m/Z46inkznCxesvDEb@msg.df7cb.de  
Backpatch-through: 13  

commit   : a2d4f806c4b91496f6055ea1200b5268ee550fca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 20 Jan 2025 09:30:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 20 Jan 2025 09:30:39 +0900    

XLogPageRead() checks immediately for an invalid WAL record header on a  
standby, to be able to handle the case of continuation records that need  
to be read across two different sources.  As written, the check was too  
generic, applying to any target LSN.  Based on an analysis by Kyotaro  
Horiguchi, what really matters is to make sure that the page header is  
checked when attempting to read a LSN at the boundary of a segment, to  
handle the case of a continuation record that spawns across multiple  
pages when dealing with multiple segments, as WAL receivers are spawned  
they request WAL from the beginning of a segment.  This fix has been  
proposed by Kyotaro Horiguchi.  
  
This could cause standbys to loop infinitely when dealing with a  
continuation record during a timeline jump, in the case where the  
contents of the record in the follow-up page are invalid.  
  
Some regression tests are added to check such scenarios, able to  
reproduce the original problem.  In the test, the contents of a  
continuation record are overwritten with junk zeros on its follow-up  
page, and replayed on standbys.  This is inspired by 039_end_of_wal.pl,  
and is enough to show how standbys should react on promotion by not  
being stuck.  Without the fix, the test would fail with a timeout.  The  
test to reproduce the problem has been written by Alexander Kukushkin.  
  
The original check has been introduced in 066871980183, for a similar  
problem.  
  
Author: Kyotaro Horiguchi, Alexander Kukushkin  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAFh8B=mozC+e1wGJq0H=0O65goZju+6ab5AU7DEWCSUA2OtwDg@mail.gmail.com  
Backpatch-through: 13  

commit   : f4fd5325cc870cc7563703ed2dc3661139cf5d13    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Oct 2022 15:21:42 +1300    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 25 Oct 2022 15:21:42 +1300    

Since commit c5cb8f3b taught stat() to follow symlinks, and since initdb  
uses pg_mkdir_p(), and that examines parent directories, our humble  
readlink() implementation can now be exposed to junction points not of  
PostgreSQL origin.  Those might be corrupted by our naive path mangling,  
which doesn't really understand NT paths in general.  
  
Simply decline to transform paths that don't look like a drive absolute  
path.  That means that readlink() returns the NT path directly when  
checking a parent directory of PGDATA that happen to point to a drive  
using "rooted" format.  That  works for the purposes of our stat()  
emulation.  
  
Reported-by: Roman Zharkov <r.zharkov@postgrespro.ru>  
Reviewed-by: Roman Zharkov <r.zharkov@postgrespro.ru>  
Discussion: https://postgr.es/m/4590c37927d7b8ee84f9855d83229018%40postgrespro.ru  
Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com  
  
Backpatched commit f71007fb as above by Thomas Munro into releases 13 thru 15  
  
Discussion: https://postgr.es/m/CA+hUKGLbnv+pe3q1fYOVkLD3pMra7GuihfMxUN-1831YH9RYQg@mail.gmail.com  

commit   : 9f1c67488e59b9b8a1791e75783f7a817216259d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Oct 2022 15:24:41 +1300    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 25 Oct 2022 15:24:41 +1300    

Commit c5cb8f3b supposed that we'd only ever have to follow one junction  
point in stat(), because we don't construct longer chains of them ourselves.  
When examining a parent directory supplied by the user, we should really be  
able to cope with longer chains, just in case someone has their system  
set up that way.  Choose an arbitrary cap of 8, to match the minimum  
acceptable value of SYMLOOP_MAX in POSIX.  
  
Previously I'd avoided reporting ELOOP thinking Windows didn't have it,  
but it turns out that it does, so we can use the proper error number.  
  
Reviewed-by: Roman Zharkov <r.zharkov@postgrespro.ru>  
Discussion: https://postgr.es/m/CA%2BhUKGJ7JDGWYFt9%3D-TyJiRRy5q9TtPfqeKkneWDr1XPU1%2Biqw%40mail.gmail.com  
Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com  
  
Backpatched commit 4517358e as above by Thomas Munro into releases 13 thru 15  
  
Discussion: https://postgr.es/m/CA+hUKGLbnv+pe3q1fYOVkLD3pMra7GuihfMxUN-1831YH9RYQg@mail.gmail.com  

commit   : 060f9f5ea53752736fa5b3b7bf5779b257265b62    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2025 13:27:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2025 13:27:47 +0900    

This commit reverts 8f67f994e8ea (down to v13) and c3de0f9eed38 (down to  
v17), as these are proving to not be completely correct regarding two  
aspects:  
- In v17 and newer branches, c3de0f9eed38's check for epoch handling is  
incorrect, and does not correctly handle frozen epochs.  A logic closer  
to widen_snapshot_xid() should be used.  The 2PC code should try to  
integrate deeper with FullTransactionIds, 5a1dfde8334b being not enough.  
- In v13 and newer branches, 8f67f994e8ea is a workaround for the real  
issue, which is that we should not attempt CLOG lookups without reaching  
consistency.  This exists since 728bd991c3c4, and this is reachable with  
ProcessTwoPhaseBuffer() called by restoreTwoPhaseData() at the beginning  
of recovery.  
  
Per discussion with Noah Misch.  
  
Discussion: https://postgr.es/m/20250116010051.f3.nmisch@google.com  
Backpatch-through: 13  

commit   : 5f725648fa3b29ffcf25c8c5123cdd9a36642862    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2025 20:40:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2025 20:40:07 -0500    

We should run the expression subtrees of PartitionedRelPruneInfo  
structs through fix_scan_expr.  Failure to do so means that  
AlternativeSubPlans within those expressions won't be cleaned up  
properly, resulting in "unrecognized node type" errors since v14.  
  
It seems fairly likely that at least some of the other steps done  
by fix_scan_expr are important here as well, resulting in as-yet-  
undetected bugs.  Therefore, I've chosen to back-patch this to  
all supported branches including v13, even though the known  
symptom doesn't manifest in v13.  
  
Per bug #18778 from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/18778-24cd399df6c806af@postgresql.org  

commit   : 50406b15540cee90d3038229829b417cbd755bd7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jan 2025 09:26:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jan 2025 09:26:29 +0900    

These facilities were originally in the recovery TAP test  
039_end_of_wal.pl.  A follow-up bug fix with a TAP test doing similar  
WAL manipulations requires them, and all these had better not be  
duplicated due to their complexity.  The routine names are tweaked to  
use "wal" more consistently, similarly to the existing "advance_wal".  
  
In v14 and v13, the new routines are moved to PostgresNode.pm.  
039_end_of_wal.pl is updated to use the refactored routines, without  
changing its coverage.  
  
Reviewed-by: Alexander Kukushkin  
Discussion: https://postgr.es/m/CAFh8B=mozC+e1wGJq0H=0O65goZju+6ab5AU7DEWCSUA2OtwDg@mail.gmail.com  
Backpatch-through: 13  

commit   : 02e69313ad0c9687fc6ac90ea0daf74d9e8a6e50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2025 18:50:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2025 18:50:24 -0500    

In the name of ABI stability (that is, to avoid a library major  
version bump for libpq), libpq still exports a version of pqsignal()  
that we no longer want to use ourselves.  However, since that has  
the same link name as the function exported by src/port/pqsignal.c,  
there is a link ordering dependency determining which version will  
actually get used by code that uses libpq as well as libpgport.a.  
  
It now emerges that the wrong version has been used by pgbench and  
psql since commit 06843df4a rearranged their link commands.  This  
can result in odd failures in pgbench with the -T switch, since its  
SIGALRM handler will now not be marked SA_RESTART.  psql may have  
some edge-case problems in \watch, too.  
  
Since we don't want to depend on link ordering effects anymore,  
let's fix this in the same spirit as b6c7cfac8: use macros to change  
the actual link names of the competing functions.  We cannot change  
legacy-pqsignal.c's exported name of course, so the victim has to be  
src/port/pqsignal.c.  
  
In master, rename its exported name to be pqsignal_fe in frontend or  
pqsignal_be in backend.  (We could perhaps have gotten away with using  
the same symbol in both cases, but since the FE and BE versions now  
work a little differently, it seems advisable to use different names.)  
  
In back branches, rename to pqsignal_fe in frontend but keep it as  
pqsignal in backend.  The frontend change could affect third-party  
code that is calling pqsignal from libpgport.a or libpgport_shlib.a,  
but only if the code is compiled against port.h from a different minor  
release than libpgport.  Since we don't support using libpgport as a  
shared library, it seems unlikely that there will be such a problem.  
I left the backend symbol unchanged to avoid an ABI break for  
extensions.  This means that the link ordering hazard still exists  
for any extension that links against libpq.  However, none of our own  
extensions use both pqsignal() and libpq, and we're not making things  
any worse for third-party extensions that do.  
  
Report from Andy Fan, diagnosis by Fujii Masao, patch by me.  
Back-patch to all supported branches, as 06843df4a was.  
  
Discussion: https://postgr.es/m/87msfz5qv2.fsf@163.com  

commit   : d06ab3c0c1179e522812d0e25d63dcc7dcab3c9a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Jan 2025 01:24:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Jan 2025 01:24:24 +0900    

The ecpg command includes code to warn about unsupported COPY FROM STDIN  
statements in input files. However, since commit 3d009e45bd,  
this functionality has been broken due to a bug introduced in that commit,  
causing ecpg to fail to detect the statement.  
  
This commit resolves the issue, restoring ecpg's ability to detect  
COPY FROM STDIN and issue a warning as intended.  
  
Back-patch to all supported versions.  
  
Author: Ryo Kanbayashi  
Reviewed-by: Hayato Kuroda, Tom Lane  
Discussion: https://postgr.es/m/CANOn0Ez_t5uDCUEV8c1YORMisJiU5wu681eEVZzgKwOeiKhkqQ@mail.gmail.com  

commit   : fce17c3a53d6ea7b7aa2178328e8f5a438805244    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jan 2025 14:28:49 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jan 2025 14:28:49 +0200    

If a new catalog tuple is inserted that belongs to a catcache list  
entry, and cache invalidation happens while the list entry is being  
built, the list entry might miss the newly inserted tuple.  
  
To fix, change the way we detect concurrent invalidations while a  
catcache entry is being built. Keep a stack of entries that are being  
built, and apply cache invalidation to those entries in addition to  
the real catcache entries. This is similar to the in-progress list in  
relcache.c.  
  
Back-patch to all supported versions.  
  
Reviewed-by: Noah Misch  
Discussion: https://www.postgresql.org/message-id/2234dc98-06fe-42ed-b5db-ac17384dc880@iki.fi  

commit   : e35ff652056998e48c01c9e49c1a1b5ad6808f0a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jan 2025 15:13:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jan 2025 15:13:19 +0900    

This function expects an "int64" as result and stores the number of  
pages to add to the index scan bitmap as an "int", multiplying its final  
result by 10.  For a relation large enough, this can theoretically  
overflow if counting more than (INT32_MAX / 10) pages, knowing that the  
number of pages is upper-bounded by MaxBlockNumber.  
  
To avoid the overflow, this commit redefines "totalpages", used to  
calculate the result, to be an "int64" rather than an "int".  
  
Reported-by: Evgeniy Gorbanyov  
Author: James Hunter  
Discussion: https://www.postgresql.org/message-id/07704817-6fa0-460c-b1cf-cd18f7647041@basealt.ru  
Backpatch-through: 13  

commit   : 9e596a099ad49ad45065203f232bebc535e7ff5a    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sun, 12 Jan 2025 23:44:39 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sun, 12 Jan 2025 23:44:39 +0100    

Commit 27a1f8d108 missed updating the max HBA option count to  
account for the new option added.  Fix by bumping the counter  
and adjust the relevant comment to match.  Backpatch down to  
all supported branches like the erroneous commit.  
  
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/286764.1736697356@sss.pgh.pa.us  
Backpatch-through: v13  

commit   : dc8cd9cd0198ff1d87815e74b101b4c03754f513    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 12 Jan 2025 13:01:22 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 12 Jan 2025 13:01:22 +0000    

When deparsing an XMLTABLE() expression, XML namespace names were not  
quoted. However, since they are parsed as ColLabel tokens, some names  
require double quotes to ensure that they are properly interpreted.  
Fix by using quote_identifier() in the deparsing code.  
  
Back-patch to all supported versions.  
  
Dean Rasheed, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/CAEZATCXTpAS%3DncfLNTZ7YS6O5puHeLg_SUYAit%2Bcs7wsrd9Msg%40mail.gmail.com  

commit   : bcb4db0d379f39a913c8c38d5c6ca5006435be7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2025 11:45:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2025 11:45:56 -0500    

PLy_spi_execute_plan (PLyPlan.execute) and PLy_cursor_plan  
(plpy.cursor) use PLy_output_convert to convert Python values  
into Datums that can be passed to the query-to-execute.  But they  
failed to pay much attention to its warning that it can leave "cruft  
generated along the way" behind.  Repeated use of these methods can  
result in a substantial memory leak for the duration of the calling  
plpython function.  
  
To fix, make a temporary memory context to invoke PLy_output_convert  
in.  This also lets us get rid of the rather fragile code that was  
here for retail pfree's of the converted Datums.  Indeed, we don't  
need the PLyPlanObject.values field anymore at all, though I left it  
in place in the back branches in the name of ABI stability.  
  
Mat Arye and Tom Lane, per report from Mat Arye.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/CADsUR0DvVgnZYWwnmKRK65MZg7YLUSTDLV61qdnrwtrAJgU6xw@mail.gmail.com  

commit   : 83ffb9f20f06120273304332594b7fab159f738f    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 10 Jan 2025 22:02:58 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 10 Jan 2025 22:02:58 +0100    

The ldapscheme option was missed when inspecing the HbaLine for  
assembling rows for the pg_hba_file_rules function.  Backpatch  
to all supported versions.  
  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Reported-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Bug: 18769  
Discussion: https://postgr.es/m/18769-dd8610cbc0405172@postgresql.org  
Backpatch-through: v13  

commit   : 8f40d46126a04105ff0aa8353ec62c3c7d31af60    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Jan 2025 13:17:36 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Jan 2025 13:17:36 +1300    

walmethods.c used off_t to navigate around a pg_wal.tar file that could  
exceed 2GB, which doesn't work on Windows and would fail with misleading  
errors.  Use pgoff_t instead.  
  
Back-patch to all supported branches.  
  
Author: Davinder Singh <davinder.singh@enterprisedb.com>  
Reported-by: Jakub Wartak <jakub.wartak@enterprisedb.com>  
Discussion: https://postgr.es/m/CAKZiRmyM4YnokK6Oenw5JKwAQ3rhP0YTz2T-tiw5dAQjGRXE3Q%40mail.gmail.com  

commit   : 1636c5e56ed72e53127fc4cb0095422d9a0d250a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Jan 2025 12:10:26 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 Jan 2025 12:10:26 +1300    

Change our ftruncate() macro to use the 64-bit variant of chsize(), and  
add a new macro to redirect lseek() to _lseeki64().  
  
Back-patch to all supported releases, in preparation for a bug fix.  
  
Tested-by: Davinder Singh <davinder.singh@enterprisedb.com>  
Discussion: https://postgr.es/m/CAKZiRmyM4YnokK6Oenw5JKwAQ3rhP0YTz2T-tiw5dAQjGRXE3Q%40mail.gmail.com  

commit   : 049c8cb9a239c9b7136174eb038fc7cd902b487e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Jan 2025 16:54:45 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Jan 2025 16:54:45 +1300    

Commit 66aaabe7 (branches 13 - 17 only) was not acceptable to the Oracle  
Developer Studio compiler on build farm animal wrasse.  It accidentally  
used a C++ style return statement to wrap a void function.  None of the  
usual compilers complained, but it is right, that is not allowed in C.  
Fix.  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/Z33vgfVgvOnbFLN9%40paquier.xyz  

commit   : c53d90bb47ae488beebe64d651ef926c86a51bde    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2025 08:47:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2025 08:47:19 +0900    

pgoutput caches the attribute map of a relation, that is free()'d only  
when validating a RelationSyncEntry.  However, this code path is not  
taken when calling any of the SQL functions able to do some logical  
decoding, like pg_logical_slot_{get,peek}_changes(), leaking some memory  
into CacheMemoryContext on repeated calls.  
  
This is a follow-up of c9b3d4909bbf, this time for v13 and v14.  The  
relation attribute map is stored in a dedicated memory context, tracked  
with a static variable whose state is reset with a MemoryContext reset  
callback attached to PGOutputData->context.  This implementation is  
similar to the approach taken by cfd6cbcf9be0.  
  
Reported-by: Masahiko Sawada  
Author: Vignesh C  
Reviewed-by: Hou Zhijie  
Discussion: https://postgr.es/m/CAD21AoDkAhQVSukOfH3_reuF-j4EU0-HxMqU3dU+bSTxsqT14Q@mail.gmail.com  
Discussion: https://postgr.es/m/CALDaNm1hewNAsZ_e6FF52a=9drmkRJxtEPrzCB6-9mkJyeBBqA@mail.gmail.com  
Backpatch-through: 13  

commit   : f154f028d856bf5ad6ec419d7947865c172d14ae    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Jan 2025 07:50:30 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Jan 2025 07:50:30 +1300    

It's possible that external code is calling smgrtruncate().  Any  
external callers might like to consider the recent changes to  
RelationTruncate(), but commit 38c579b0 should not have changed the  
function prototype in the back-branches, per ABI stability policy.  
  
Restore smgrtruncate()'s traditional argument list in the back-branches,  
but make it a wrapper for a new function smgrtruncate2().  The three  
callers in core can use smgrtruncate2() directly.  In master (18-to-be),  
smgrtruncate2() is effectively renamed to smgrtruncate(), so this wart  
is cleaned up.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CA%2BhUKG%2BThae6x6%2BjmQiuALQBT2Ae1ChjMh1%3DkMvJ8y_SBJZrvA%40mail.gmail.com  

commit   : 9577dd523b3e3bb7fba66e708dfb9ca76e299b7e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 3 Jan 2025 09:23:46 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 3 Jan 2025 09:23:46 -0500    

Slightly faulty logic in the original jsonb code (commit d9134d0a355)  
results in an empty top level array sorting less than a json null. We  
can't change the sort order now since it would affect btree indexes over  
jsonb, so document the anomaly.  
  
Backpatch to all live branches (13 .. 17)  
  
In master, also add a code comment noting the anomaly.  
  
Reported-by: Yan Chengpen  
Reviewed-by: Jian He  
  
Discussion: https://postgr.es/m/OSBPR01MB45199DD8DA2D1CECD50518188E272@OSBPR01MB4519.jpnprd01.prod.outlook.com  

commit   : 6a2440167a8b778277907e8babea1840d1c5eee0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 1 Jan 2025 11:21:54 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 1 Jan 2025 11:21:54 -0500    

Backpatch-through: 13  

commit   : 58626e24a95d2709142045447fc310bd1dd65a44    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Dec 2024 08:06:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Dec 2024 08:06:45 +0900    

Before 728bd991c3c4, that has improved the support for 2PC files during  
recovery, the initial logic scanning files in pg_twophase was done so as  
files in the future of the transaction ID horizon were checked first,  
followed by a check if a transaction ID is aborted or committed which  
could involve a pg_xact lookup.  After this commit, these checks have  
been done in reverse order.  
  
Files detected as in the future do not have a state that can be checked  
in pg_xact, hence this caused recovery to fail abruptly should an  
orphaned 2PC file in the future of the transaction ID horizon exist in  
pg_twophase at the beginning of recovery.  
  
A test is added to check for this scenario, using an empty 2PC with a  
transaction ID large enough to be in the future when running the test.  
This test is added in 16 and older versions for now.  17 and newer  
versions are impacted by a second bug caused by the addition of the  
epoch in the 2PC file names.  An equivalent test will be added in these  
branches in a follow-up commit, once the second set of issues reported  
are fixed.  
  
Author: Vitaly Davydov, Michael Paquier  
Discussion: https://postgr.es/m/11e597-676ab680-8d-374f23c0@145466129  
Backpatch-through: 13  

commit   : c58b0c43d36f606d6c1f8e7e45cc383df9d1dc74    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Dec 2024 16:08:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Dec 2024 16:08:50 -0500    

Cause parallel workers to not check datallowconn, rolcanlogin, and  
ACL_CONNECT privileges.  The leader already checked these things  
(except for rolcanlogin which might have been checked for a different  
role).  Re-checking can accomplish little except to induce unexpected  
failures in applications that might not even be aware that their query  
has been parallelized.  We already had the principle that parallel  
workers rely on their leader to pass a valid set of authorization  
information, so this change just extends that a bit further.  
  
Also, modify the ReservedConnections, datconnlimit and rolconnlimit  
logic so that these limits are only enforced against regular backends,  
and only regular backends are counted while checking if the limits  
were already reached.  Previously, background processes that had an  
assigned database or role were subject to these limits (with rather  
random exclusions for autovac workers and walsenders), and the set of  
existing processes that counted against each limit was quite haphazard  
as well.  The point of these limits, AFAICS, is to ensure the  
availability of PGPROC slots for regular backends.  Since all other  
types of processes have their own separate pools of PGPROC slots, it  
makes no sense either to enforce these limits against them or to count  
them while enforcing the limit.  
  
While edge-case failures of these sorts have been possible for a  
long time, the problem got a good deal worse with commit 5a2fed911  
(CVE-2024-10978), which caused parallel workers to make some of these  
checks using the leader's current role where before we had used its  
AuthenticatedUserId, thus allowing parallel queries to fail after  
SET ROLE.  The previous behavior was fairly accidental and I have  
no desire to return to it.  
  
This patch includes reverting 73c9f91a1, which was an emergency hack  
to suppress these same checks in some cases.  It wasn't complete,  
as shown by a recent bug report from Laurenz Albe.  We can also revert  
fd4d93d26 and 492217301, which hacked around the same problems in one  
regression test.  
  
In passing, remove the special case for autovac workers in  
CheckMyDatabase; it seems cleaner to have AutoVacWorkerMain pass  
the INIT_PG_OVERRIDE_ALLOW_CONNS flag, now that that does what's  
needed.  
  
Like 5a2fed911, back-patch to supported branches (which sadly no  
longer includes v12).  
  
Discussion: https://postgr.es/m/1808397.1735156190@sss.pgh.pa.us  

commit   : 536acda0bc7900c407c76c6ca6293e0ac2041f8b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Dec 2024 07:16:22 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 28 Dec 2024 07:16:22 -0800    

Commit aac2c9b4fde889d13f859c233c2523345e72d32b mandated such locking  
and attempted to fulfill that mandate, but it missed REASSIGN OWNED.  
Hence, it remained possible to lose VACUUM's inplace update of  
datfrozenxid if a REASSIGN OWNED processed that database at the same  
time.  This didn't affect the other inplace-updated catalog, pg_class.  
For pg_class, REASSIGN OWNED calls ATExecChangeOwner() instead of the  
generic AlterObjectOwner_internal(), and ATExecChangeOwner() fulfills  
the locking mandate.  
  
Like in GRANT, implement this by following the locking protocol for any  
catalog subject to the generic AlterObjectOwner_internal().  It would  
suffice to do this for IsInplaceUpdateOid() catalogs only.  Back-patch  
to v13 (all supported versions).  
  
Kirill Reshke.  Reported by Alexander Kukushkin.  
  
Discussion: https://postgr.es/m/CAFh8B=mpKjAy4Cuun-HP-f_vRzh2HSvYFG3rhVfYbfEBUhBAGg@mail.gmail.com  

commit   : cfd6cbcf9be078fbdf9587014231a5772039b386    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Dec 2024 12:48:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Dec 2024 12:48:10 +0900    

The pgoutput module caches publication names in a list and frees it upon  
invalidation.  However, the code forgot to free the actual publication  
names within the list elements, as publication names are pstrdup()'d in  
GetPublication().  This would cause memory to leak in  
CacheMemoryContext, bloating it over time as this context is not  
cleaned.  
  
This is a problem for WAL senders running for a long time, as an  
accumulation of invalidation requests would bloat its cache memory  
usage.  A second case, where this leak is easier to see, involves a  
backend calling SQL functions like pg_logical_slot_{get,peek}_changes()  
which create a new decoding context with each execution.  More  
publications create more bloat.  
  
To address this, this commit adds a new memory context within the  
logical decoding context and resets it each time the publication names  
cache is invalidated, based on a suggestion from Amit Kapila.  This  
ensures that the lifespan of the publication names aligns with that of  
the logical decoding context.  
  
Contrary to the HEAD-only commit f0c569d71515 that has changed  
PGOutputData to track this new child memory context, the context is  
tracked with a static variable whose state is reset with a MemoryContext  
reset callback attached to PGOutputData->context, so as ABI  
compatibility is preserved in stable branches.  This approach is based  
on an suggestion from Amit Kapila.  
  
Analyzed-by: Michael Paquier, Jeff Davis  
Author: Masahiko Sawada  
Reviewed-by: Amit Kapila, Michael Paquier, Euler Taveira, Hou Zhijie  
Discussion: https://postgr.es/m/Z0khf9EVMVLOc_YY@paquier.xyz  
Backpatch-through: 13  

commit   : 41eafbb494c9578fa04ffa529a10e4cfd6942421    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 21 Dec 2024 23:42:39 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 21 Dec 2024 23:42:39 +0200    

GetSnapshotData() set TransactionXmin = MyProc->xmin, but when  
SnapshotResetXmin() advanced MyProc->xmin, it did not advance  
TransactionXmin correspondingly. That meant that TransactionXmin could  
be older than MyProc->xmin, and XIDs between than TransactionXmin and  
the real MyProc->xmin could be vacuumed away. One known consequence is  
in pg_subtrans lookups: we might try to look up the status of an XID  
that was already truncated away.  
  
Back-patch to all supported versions.  
  
Reviewed-by: Andres Freund  
Discussion: https://www.postgresql.org/message-id/d27a046d-a1e4-47d1-a95c-fbabe41debb4@iki.fi  

commit   : 23c743b645a546f7ec7aae0a3d7201328d6994b3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 20 Dec 2024 21:53:25 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 20 Dec 2024 21:53:25 +1300    

RelationTruncate() does three things, while holding an  
AccessExclusiveLock and preventing checkpoints:  
  
1. Logs the truncation.  
2. Drops buffers, even if they're dirty.  
3. Truncates some number of files.  
  
Step 2 could previously be canceled if it had to wait for I/O, and step  
3 could and still can fail in file APIs.  All orderings of these  
operations have data corruption hazards if interrupted, so we can't give  
up until the whole operation is done.  When dirty pages were discarded  
but the corresponding blocks were left on disk due to ERROR, old page  
versions could come back from disk, reviving deleted data (see  
pgsql-bugs #18146 and several like it).  When primary and standby were  
allowed to disagree on relation size, standbys could panic (see  
pgsql-bugs #18426) or revive data unknown to visibility management on  
the primary (theorized).  
  
Changes:  
  
 * WAL is now unconditionally flushed first  
 * smgrtruncate() is now called in a critical section, preventing  
   interrupts and causing PANIC on file API failure  
 * smgrtruncate() has a new parameter for existing fork sizes,  
   because it can't call smgrnblocks() itself inside a critical section  
  
The changes apply to RelationTruncate(), smgr_redo() and  
pg_truncate_visibility_map().  That last is also brought up to date with  
other evolutions of the truncation protocol.  
  
The VACUUM FileTruncate() failure mode had been discussed in older  
reports than the ones referenced below, with independent analysis from  
many people, but earlier theories on how to fix it were too complicated  
to back-patch.  The more recently invented cancellation bug was  
diagnosed by Alexander Lakhin.  Other corruption scenarios were spotted  
by me while iterating on this patch and earlier commit 75818b3a.  
  
Back-patch to all supported releases.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Reported-by: rootcause000@gmail.com  
Reported-by: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/18146-04e908c662113ad5%40postgresql.org  
Discussion: https://postgr.es/m/18426-2d18da6586f152d6%40postgresql.org  

commit   : 1f95181b44c843729caaa688f74babe9403b5850    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Jul 2022 10:16:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Jul 2022 10:16:12 +0900    

durable_rename_excl() attempts to avoid overwriting any existing files  
by using link() and unlink(), and it falls back to rename() on some  
platforms (aka WIN32), which offers no such overwrite protection.  Most  
callers use durable_rename_excl() just in case there is an existing  
file, but in practice there shouldn't be one (see below for more  
details).  
  
Furthermore, failures during durable_rename_excl() can result in  
multiple hard links to the same file.  As per Nathan's tests, it is  
possible to end up with two links to the same file in pg_wal after a  
crash just before unlink() during WAL recycling.  Specifically, the test  
produced links to the same file for the current WAL file and the next  
one because the half-recycled WAL file was re-recycled upon restarting,  
leading to WAL corruption.  
  
This change replaces all the calls of durable_rename_excl() to  
durable_rename().  This removes the protection against accidentally  
overwriting an existing file, but some platforms are already living  
without it and ordinarily there shouldn't be one.  The function itself  
is left around in case any extensions are using it.  It will be removed  
on HEAD via a follow-up commit.  
  
Here is a summary of the existing callers of durable_rename_excl() (see  
second discussion link at the bottom), replaced by this commit.  First,  
basic_archive used it to avoid overwriting an archive concurrently  
created by another server, but as mentioned above, it will still  
overwrite files on some platforms.  Second, xlog.c uses it to recycle  
past WAL segments, where an overwrite should not happen (origin of the  
change at f0e37a8) because there are protections about the WAL segment  
to select when recycling an entry.  The third and last area is related  
to the write of timeline history files.  writeTimeLineHistory() will  
write a new timeline history file at the end of recovery on promotion,  
so there should be no such files for the same timeline.  
What remains is writeTimeLineHistoryFile(), that can be used in parallel  
by a WAL receiver and the startup process, and some digging of the  
buildfarm shows that EEXIST from a WAL receiver can happen with an error  
of "could not link file \"pg_wal/xlogtemp.NN\" to \"pg_wal/MM.history\",  
which would cause an automatic restart of the WAL receiver as it is  
promoted to FATAL, hence this should improve the stability of the WAL  
receiver as rename() would overwrite an existing TLI history file  
already fetched by the startup process at recovery.  
  
This is the second time this change is attempted, ccfbd92 being the  
first one, but this time no assertions are added for the case of a TLI  
history file written concurrently by the WAL receiver or the startup  
process because we can expect one to exist (some of the TAP tests are  
able to trigger with a proper timing).  
  
This commit has been originally applied on v16~ as of dac1ff30906b, and  
we have received more reports of this issue, where clusters can become  
corrupted at replay in older stable branches with multiple links  
pointing to the same physical WAL segment file.  This backpatch  
addresses the problem for the v13~v15 range.  
  
Author: Nathan Bossart  
Reviewed-by: Robert Haas, Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20220407182954.GA1231544@nathanxps13  
Discussion: https://postgr.es/m/Ym6GZbqQdlalSKSG@paquier.xyz  
Discussion: https://postgr.es/m/CAJhEC04tBkYPF4q2uS_rCytauvNEVqdBAzasBEokfceFhF=KDQ@mail.gmail.com  

commit   : bdb07d24113b721f3c123304c162485f54e2f554    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 19 Dec 2024 13:13:31 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 19 Dec 2024 13:13:31 +1300    

If the non-recursive part of a recursive CTE ended up using  
TTSOpsBufferHeapTuple as the table slot type, then a duplicate value  
could cause an Assert failure in CheckOpSlotCompatibility() when  
checking the hash table for the duplicate value.  The expected slot type  
for the deform step was TTSOpsMinimalTuple so the Assert failed when the  
TTSOpsBufferHeapTuple slot was used.  
  
This is a long-standing bug which we likely didn't notice because it  
seems much more likely that the non-recursive term would have required  
projection and used a TTSOpsVirtual slot, which CheckOpSlotCompatibility  
is ok with.  
  
There doesn't seem to be any harm done here other than the Assert  
failure.  Both TTSOpsMinimalTuple and TTSOpsBufferHeapTuple slot types  
require tuple deformation, so the EEOP_*_FETCHSOME ExprState step would  
have properly existed in the ExprState.  
  
The solution is to pass NULL for the ExecBuildGroupingEqual's 'lops'  
parameter.  This means the ExprState's EEOP_*_FETCHSOME step won't  
expect a fixed slot type.  This makes CheckOpSlotCompatibility() happy as  
no checking is performed when the ExprEvalStep is not expecting a fixed  
slot type.  
  
Reported-by: Richard Guo  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAMbWs4-8U9q2LAtf8+ghV11zeUReA3AmrYkxzBEv0vKnDxwkKA@mail.gmail.com  
Backpatch-through: 13, all supported versions  

commit   : 84dc1303c9631343c74ce0ad806fb8fd202336f7    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 17 Dec 2024 15:24:45 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Tue, 17 Dec 2024 15:24:45 -0600    

If a dshash table grows very large (e.g., the dshash table for  
cumulative statistics when there are millions of tables), resizing  
it may fail with an error like:  
  
	ERROR: invalid DSA memory alloc request size 1073741824  
  
To fix, permit dshash resizing to allocate more than 1 GB by  
providing the DSA_ALLOC_HUGE flag.  
  
Reported-by: Andreas Scherbaum  
Author: Matthias van de Meent  
Reviewed-by: Cédric Villemain, Michael Paquier, Andres Freund  
Discussion: https://postgr.es/m/80a12d59-0d5e-4c54-866c-e69cd6536471%40pgug.de  
Backpatch-through: 13  

commit   : f5f5e7b47351f0443d9720bfc7916ed2af940bd3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 16 Dec 2024 15:56:38 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 16 Dec 2024 15:56:38 +0200    

The test failed if you ran the regression tests with TEMP_CONFIG with  
recovery_min_apply_delay = '500ms'. Fix the race condition by waiting  
for transaction to be applied in the replica, like in a few other  
tests.  
  
The failing test was introduced in commit cbfbda7841. Backpatch to all  
supported versions like that commit (except v12, which is no longer  
supported).  
  
Reported-by: Alexander Lakhin  
Discussion: https://www.postgresql.org/message-id/09e2a70a-a6c2-4b5c-aeae-040a7449c9f2@gmail.com  

commit   : 2a23dbcf35946b844699c65fdf2ee440251eab12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Dec 2024 14:14:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Dec 2024 14:14:15 -0500    

An \if command appearing within a false (not-to-be-executed) \if  
branch was incorrectly treated the same as \elif.  This could allow  
statements within the inner \if to be executed when they should  
not be.  Also the missing inner \if stack entry would result in an  
assertion failure (in assert-enabled builds) when the final \endif  
is reached.  
  
Report and patch by Michail Nikolaev.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/CANtu0oiA1ke=SP6tauhNqkUdv5QFsJtS1p=aOOf_iU+EhyKkjQ@mail.gmail.com  

commit   : c7f3c414fdedbb9a48d597a309c53fdf1ac3652a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2024 14:21:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2024 14:21:36 -0500    

If an owned sequence is considered interesting, force its owning  
table to be marked interesting too.  This ensures, in particular,  
that we'll fetch the owning table's column names so we have the  
data needed for ALTER TABLE ... ADD GENERATED.  Previously there were  
edge cases where pg_dump could get SIGSEGV due to not having filled in  
the column names.  (The known case is where the owning table has been  
made part of an extension while its identity sequence is not a member;  
but there may be others.)  
  
Also, if it's an identity sequence, force its dumped-components mask  
to exactly match the owning table: dump definition only if we're  
dumping the table's definition, dump data only if we're dumping the  
table's data, etc.  This generalizes the code introduced in commit  
b965f2617 that set the sequence's dump mask to NONE if the owning  
table's mask is NONE.  That's insufficient to prevent failures,  
because for example the table's mask might only request dumping ACLs,  
which would lead us to still emit ALTER TABLE ADD GENERATED even  
though we didn't create the table.  It seems better to treat an  
identity sequence as though it were an inseparable aspect of the  
table, matching the treatment used in the backend's dependency logic.  
Perhaps this policy needs additional refinement, but let's wait to  
see some field use-cases before changing it further.  
  
While here, add a comment in pg_dump.h warning against writing tests  
like "if (dobj->dump == DUMP_COMPONENT_NONE)", which was a bug in this  
case.  There is one other example in getPublicationNamespaces, which  
if it's not a bug is at least remarkably unclear and under-documented.  
Changing that requires a separate discussion, however.  
  
Per report from Artur Zakirov.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAKNkYnwXFBf136=u9UqUxFUVagevLQJ=zGd5BsLhCsatDvQsKQ@mail.gmail.com  

commit   : 4abf615cc8a8ca80430b5a0bfa18be6efcea96b2    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Dec 2024 16:21:18 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Dec 2024 16:21:18 +0100    

This backpatches commits beb4e9ba1652 and 1fb17b190341 (originally  
appearing in previously in REL_15_STABLE) to REL_14_STABLE.  Performance  
of the WAL archiver can become pretty critical at times, and reports  
exist of users getting in serious trouble (hours of downtime, loss of  
replicas) because of lack of this optimization.  
  
We'd like to backpatch these to REL_13_STABLE too, but because of the  
very invasive changes made by commit d75288fb27b8 in the 14 timeframe,  
we deem it too risky :-(  
  
Original commit messages appear below.  
  
Discussion: https://postgr.es/m/202411131605.m66syq5i5ucl@alvherre.pgsql  
  
  commit beb4e9ba1652a04f66ff20261444d06f678c0b2d  
  Author:     Robert Haas <rhaas@postgresql.org>  
  AuthorDate: Thu Nov 11 15:02:53 2021 -0500  
  
  Improve performance of pgarch_readyXlog() with many status files.  
  
  Presently, the archive_status directory was scanned for each file to  
  archive.  When there are many status files, say because archive_command  
  has been failing for a long time, these directory scans can get very  
  slow.  With this change, the archiver remembers several files to archive  
  during each directory scan, speeding things up.  
  
  To ensure timeline history files are archived as quickly as possible,  
  XLogArchiveNotify() forces the archiver to do a new directory scan as  
  soon as the .ready file for one is created.  
  
  Nathan Bossart, per a long discussion involving many people. It is  
  not clear to me exactly who out of all those people reviewed this  
  particular patch.  
  
  Discussion: http://postgr.es/m/CA+TgmobhAbs2yabTuTRkJTq_kkC80-+jw=pfpypdOJ7+gAbQbw@mail.gmail.com  
  Discussion: http://postgr.es/m/620F3CE1-0255-4D66-9D87-0EADE866985A@amazon.com  
  
  commit 1fb17b1903414676bd371068739549cd2966fe87  
  Author:     Tom Lane <tgl@sss.pgh.pa.us>  
  AuthorDate: Wed Dec 29 17:02:50 2021 -0500  
  
  Fix issues in pgarch's new directory-scanning logic.  
  
  The arch_filenames[] array elements were one byte too small, so that  
  a maximum-length filename would get corrupted if another entry  
  were made after it.  (Noted by Thomas Munro, fix by Nathan Bossart.)  
  
  Move these arrays into a palloc'd struct, so that we aren't wasting  
  a few kilobytes of static data in each non-archiver process.  
  
  Add a binaryheap_reset() call to make it plain that we start the  
  directory scan with an empty heap.  I don't think there's any live  
  bug of that sort, but it seems fragile, and this is very cheap  
  insurance.  
  
  Cleanup for commit beb4e9ba1, so no back-patch needed.  
  
  Discussion: https://postgr.es/m/CA+hUKGLHAjHuKuwtzsW7uMJF4BVPcQRL-UMZG_HM-g0y7yLkUg@mail.gmail.com  

commit   : 315264d70128445fd53de199e16bb8aa562cf36f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 10 Dec 2024 13:51:59 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 10 Dec 2024 13:51:59 -0800    

Since commit 97550c0711972a9856b5db751539bbaf2f88884c, these failed with  
"PANIC:  proc_exit() called in child process" due to uninitialized or  
stale MyProcPid.  That was reachable if close() failed in  
ClosePostmasterPorts() or setlocale(category, "C") failed, both  
unlikely.  Back-patch to v13 (all supported versions).  
  
Discussion: https://postgr.es/m/20241208034614.45.nmisch@google.com  

commit   : 4922ede979947bc2404e8675435184e61a57a530    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 10 Dec 2024 09:26:34 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 10 Dec 2024 09:26:34 +1300    

It looks like the example case was once modified to increase the number  
of rows but the EXPLAIN ANALYZE output wasn't updated to reflect that.  
  
Also adjust the text which discusses the index sizes.  With the example  
table size, the bloom index isn't quite 8 times more space efficient  
than the btree indexes.  
  
Discussion: https://postgr.es/m/CAApHDvovx8kQ0=HTt85gFDAwmTJHpCgiSvRmQZ_6u_g-vQYM_w@mail.gmail.com  
Backpatch-through: 13, all supported versions  

commit   : 8a95ad3b205cfce4441bdb6cae0475e1304cc3a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Dec 2024 14:38:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Dec 2024 14:38:19 -0500    

Our parallel-mode code only works when we are executing a query  
in full, so ExecutePlan must disable parallel mode when it is  
asked to do partial execution.  The previous logic for this  
involved passing down a flag (variously named execute_once or  
run_once) from callers of ExecutorRun or PortalRun.  This is  
overcomplicated, and unsurprisingly some of the callers didn't  
get it right, since it requires keeping state that not all of  
them have handy; not to mention that the requirements for it were  
undocumented.  That led to assertion failures in some corner  
cases.  The only state we really need for this is the existing  
QueryDesc.already_executed flag, so let's just put all the  
responsibility in ExecutePlan.  (It could have been done in  
ExecutorRun too, leading to a slightly shorter patch -- but if  
there's ever more than one caller of ExecutePlan, it seems better  
to have this logic in the subroutine than the callers.)  
  
This makes those ExecutorRun/PortalRun parameters unnecessary.  
In master it seems okay to just remove them, returning the  
API for those functions to what it was before parallelism.  
Such an API break is clearly not okay in stable branches,  
but for them we can just leave the parameters in place after  
documenting that they do nothing.  
  
Per report from Yugo Nagata, who also reviewed and tested  
this patch.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20241206062549.710dc01cf91224809dd6c0e1@sraoss.co.jp  

commit   : 1a34cf0f485bcf2d2989a8bf6c7fdf86c6dca1fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Dec 2024 15:56:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Dec 2024 15:56:28 -0500    

Usually an entry in pg_amop or pg_amproc does not need a dependency on  
its amoplefttype/amoprighttype/amproclefttype/amprocrighttype types,  
because there is an indirect dependency via the argument types of its  
referenced operator or procedure, or via the opclass it belongs to.  
However, for some support procedures in some index AMs, the argument  
types of the support procedure might not mention the column data type  
at all.  Also, the amop/amproc entry might be treated as "loose" in  
the opfamily, in which case it lacks a dependency on any particular  
opclass; or it might be a cross-type entry having a reference to a  
datatype that is not its opclass' opcintype.  
  
The upshot of all this is that there are cases where a datatype can  
be dropped while leaving behind amop/amproc entries that mention it,  
because there is no path in pg_depend showing that those entries  
depend on that type.  Such entries are harmless in normal activity,  
because they won't get used, but they cause problems for maintenance  
actions such as dropping the operator family.  They also cause pg_dump  
to produce bogus output.  The previous commit put a band-aid on the  
DROP OPERATOR FAMILY failure, but a real fix is needed.  
  
To fix, add pg_depend entries showing that a pg_amop/pg_amproc entry  
depends on its lefttype/righttype.  To avoid bloating pg_depend too  
much, skip this if the referenced operator or function has that type  
as an input type.  (I did not bother with considering the possible  
indirect dependency via the opclass' opcintype; at least in the  
reported case, that wouldn't help anyway.)  
  
Probably, the reason this has escaped notice for so long is that  
add-on datatypes and relevant opclasses/opfamilies are usually  
packaged as extensions nowadays, so that there's no way to drop  
a type without dropping the referencing opclasses/opfamilies too.  
Still, in the absence of pg_depend entries there's nothing that  
constrains DROP EXTENSION to drop the opfamily entries before the  
datatype, so it seems possible for a DROP failure to occur anyway.  
  
The specific case that was reported doesn't fail in v13, because  
v13 prefers to attach the support procedure to the opclass not the  
opfamily.  But it's surely possible to construct other edge cases  
that do fail in v13, so patch that too.  
  
Per report from Yoran Heling.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021  

commit   : d9d5e1b48e0db25961e108a13acb616a4911ee29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Dec 2024 14:28:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Dec 2024 14:28:16 -0500    

Yoran Heling reported a case where a data type could be dropped  
while references to its OID remain behind in pg_amproc.  This  
causes getObjectDescription to fail, which blocks dropping the  
operator family (since our DROP code likes to construct descriptions  
of everything it's dropping).  The proper fix for this requires  
adding more pg_depend entries.  But to allow DROP to go through with  
already-corrupt catalogs, tweak getObjectDescription to print "???"  
for the type instead of failing when it processes such an entry.  
  
I changed the logic for pg_amop similarly, for consistency,  
although it is not known that the problem can manifest in pg_amop.  
  
Per report from Yoran Heling.  Back-patch to all supported  
branches (although the problem may be unreachable in v13).  
  
Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021  

commit   : 5882a4ba0917c056d9ca78d61af44708b3e93b4c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Dec 2024 13:12:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Dec 2024 13:12:32 -0500    

These format codes produce or consume strings of digits, so they  
should be labeled with is_digit = true, but they were not.  
This has effect in only one place, where is_next_separator()  
is checked to see if the preceding format code should slurp up  
all the available digits.  Thus, with a format such as '...SSFF3'  
with remaining input '12345', the 'SS' code would consume all  
five digits (and then complain about seconds being out of range)  
when it should eat only two digits.  
  
Per report from Nick Davies.  This bug goes back to d589f9446  
where the FFn codes were introduced, so back-patch to v13.  
  
Discussion: https://postgr.es/m/AM8PR08MB6356AC979252CFEA78B56678B6312@AM8PR08MB6356.eurprd08.prod.outlook.com  

commit   : d24eb0e91f3f7fc54ed4e56d93b26e2f8d52c1ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Dec 2024 12:54:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Dec 2024 12:54:41 -0500    

check_restrict_nonsystem_relation_kind() correctly uses guc_malloc()  
in v16 and later.  But in older branches it must use malloc()  
directly, and it forgot to check for failure return.  
Faulty backpatching of 66e94448a.  
  
Karina Litskevich  
  
Discussion: https://postgr.es/m/CACiT8iZ=atkguKVbpN4HmJFMb4+T9yEowF5JuPZG8W+kkZ9L6w@mail.gmail.com  

commit   : 7d0b91a28421a7928fb45e10b31e7f1f81842ba7    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 3 Dec 2024 09:27:05 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 3 Dec 2024 09:27:05 +1300    

Previously, it set only DELAY_CHKPT_COMPLETE. That was important,  
because it meant that if the XLOG_SMGR_TRUNCATE record preceded a  
XLOG_CHECKPOINT_ONLINE record in the WAL, then the truncation would also  
happen on disk before the XLOG_CHECKPOINT_ONLINE record was  
written.  
  
However, it didn't guarantee that the sync request for the truncation  
was processed before the XLOG_CHECKPOINT_ONLINE record was written. By  
setting DELAY_CHKPT_START, we guarantee that if an XLOG_SMGR_TRUNCATE  
record is written to WAL before the redo pointer of a concurrent  
checkpoint, the sync request queued by that operation must be processed  
by that checkpoint, rather than being left for the following one.  
  
This is a refinement of commit 412ad7a5563.  Back-patch to all supported  
releases, like that commit.  
  
Author: Robert Haas <robertmhaas@gmail.com>  
Reported-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKG%2B-2rjGZC2kwqr2NMLBcEBp4uf59QT1advbWYF_uc%2B0Aw%40mail.gmail.com  

commit   : 52c7a44e9518b3bbb930184526e0ae4eac412a7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2024 14:15:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2024 14:15:37 -0500    

The loops over cursor argument variables neglected to ever advance  
"prevvar".  The code would accidentally do the right thing anyway  
when removing the first or second list entry, but if it had to  
remove the third or later entry then it would also remove all  
entries between there and the first entry.  AFAICS this would  
only matter for cursors that reference out-of-scope variables,  
which is a weird Informix compatibility hack; between that and  
the lack of impact for short lists, it's not so surprising that  
nobody has complained.  Nonetheless it's a pretty obvious bug.  
  
It would have been more obvious if these loops used a more standard  
coding style for chasing the linked lists --- this business with the  
"prev" pointer sometimes pointing at the current list entry is  
confusing and overcomplicated.  So rather than just add a minimal  
band-aid, I chose to rewrite the loops in the same style we use  
elsewhere, where the "prev" pointer is NULL until we are dealing with  
a non-first entry and we save the "next" pointer at the top of the  
loop.  (Two of the four loops touched here are not actually buggy,  
but it seems better to make them all look alike.)  
  
Coverity discovered this problem, but not until 2b41de4a5 added code  
to free no-longer-needed arguments structs.  With that, the incorrect  
link updates are possibly touching freed memory, and it complained  
about that.  Nonetheless the list corruption hazard is ancient, so  
back-patch to all supported branches.  

commit   : fa92c18efe24041240eea8045bb5b714f4ee2134    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 29 Nov 2024 10:58:01 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 29 Nov 2024 10:58:01 +1300    

Commit 352f6f2d used %d instead of %lu to format DWORD (unsigned long)  
with psprintf().  The _WIN32_WINNT value recently changed for MinGW in  
REL_15_STABLE (commit d700e8d7), so the code was suddenly being  
compiled, with warnings from gcc.  
  
The warnings were already fixed in 16+ by commits 495ed0ef and a9bc04b2  
after the _WIN32_WINNT value was increase there.  14 and 13 didn't warn  
because they still use a lower value for MinGW, and supported versions  
of Visual Studio should compile the code in all live branches but don't  
check our format string.  
  
The change doesn't affect the result: sizeof(int) == sizeof(long) on  
this platform, and the values are computed with expressions that cannot  
exceed INT_MAX so were never interpreted as negative.  
  
Back-patch the formatting change from those commits into 13-15.  This  
should turn CI's 15 branch green again and stop fairywren from warning  
about that on 15.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reported-by: Peter Eisentraut <peter@eisentraut.org>  
Discussion: https://postgr.es/m/t2vjrcb3bloxf5qqvxjst6r7lvrefqyecxgt2koy5ho5b5glr2%40yuupmm6whgob  

commit   : 4112a259021598d1bf5c39456cc6d6238baab065    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 28 Nov 2024 15:32:57 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 28 Nov 2024 15:32:57 +1300    

Commit 9044fc1d45a0 skipped SectionMemoryManager.h in headerscheck, and  
by extension also cpluspluscheck, because it's C++ and would fail both  
tests.  That worked in master and REL_17_STABLE due to 7b8e2ae2fd3b, but  
older branches have a separate cpluspluscheck script.  We need to copy  
the filtering rule into there too.  
  
This problem was being reported by CI's CompilerWarnings task in the 15  
and 16 branches, but was a victim of alert fatigue syndrome (unrelated  
problems in the back-branches).  
  
Fix 16, and back-patch to 13, as those are the live branches that have a  
separate cpluspluscheck script.  

commit   : 3aae60c851badb601df47f46ee459f047c998f59    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Nov 2024 09:43:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Nov 2024 09:43:26 +0900    

This reverts commit d77f91214fb7 on all stable branches, due to concerns  
regarding the compatility side effects this could create in a minor  
release.  The change still exists on HEAD.  
  
Discussion: https://postgr.es/m/CA+TgmoZqRgeFTg4+Yf_CMRRXiHuNz1u6ZC4FvVk+rxw0RmOPnw@mail.gmail.com  
Backpatch-through: 13  

commit   : 0f13e1a78b145935e5a128a44cb828ea24bac72d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Nov 2024 23:04:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Nov 2024 23:04:55 +0900    

During pgbench's table initialization, progress updates could display  
leftover characters from the previous message if the new message  
was shorter. This commit resolves the issue by appending spaces to  
the current message to fully overwrite any remaining characters from  
the previous line.  
  
Back-patch to all the supported versions.  
  
Author: Yushi Ogiwara, Tatsuo Ishii, Fujii Masao  
Reviewed-by: Tatsuo Ishii, Fujii Masao  
Discussion: https://postgr.es/m/9a9b8b95b6a709877ae48ad5b0c59bb9@oss.nttdata.com  

commit   : 4c0e70fc30e4800beb89af5dff44ab5f37fe6720    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Nov 2024 11:12:09 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Nov 2024 11:12:09 +0100    

from commit 9044fc1d45a  

commit   : 64c625ccc12d145bc6c638b9a00a88e3adc7900e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Nov 2024 11:08:12 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Nov 2024 11:08:12 +0100    

Commit 9044fc1d45a added some files from upstream LLVM.  These files  
have different whitespace rules, which make the git whitespace checks  
powered by gitattributes fail.  To fix, add those files to the exclude  
list.  

commit   : 1fd57e5bbf87d1229cf2725f0230755c1d886178    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 27 Nov 2024 15:43:18 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 27 Nov 2024 15:43:18 +1300    

Branches before 16 can't be compiled with a C23 compiler (see  
deprecation warnings silenced by commit f9a56e72, and non-back-patchable  
changes made in 16 by commit 1c27d16e).  Test __STDC_VERSION__, and if  
it's above C17 then try appending -std=gnu17.  The test is done with the  
user's CFLAGS, so an acceptable language version can also be configured  
manually that way.  
  
This is done in branches 15 and older, back to 9.2, per policy of  
keeping them buildable with modern tools.  
  
Discussion: https://postgr.es/m/87o72eo9iu.fsf%40gentoo.org  

commit   : 2366211949a0122ccadd56a34085478ebcfb2f5e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 Nov 2024 09:31:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 Nov 2024 09:31:42 +0900    

When using a pipeline, a transaction starts from the first command and  
is committed with a Sync message or when the pipeline ends.  
  
Functions like IsInTransactionBlock() or PreventInTransactionBlock()  
were already able to understand a pipeline as being in a transaction  
block, but it was not the case of CheckTransactionBlock().  This  
function is called for example to generate a WARNING for SET LOCAL,  
complaining that it is used outside of a transaction block.  
  
The current state of the code caused multiple problems, like:  
- SET LOCAL executed at any stage of a pipeline issued a WARNING, even  
if the command was at least second in line where the pipeline is in a  
transaction state.  
- LOCK TABLE failed when invoked at any step of a pipeline, even if it  
should be able to work within a transaction block.  
  
The pipeline protocol assumes that the first command of a pipeline is  
not part of a transaction block, and that any follow-up commands is  
considered as within a transaction block.  
  
This commit changes the backend so as an implicit transaction block is  
started each time the first Execute message of a pipeline has finished  
processing, with this implicit transaction block ended once a sync is  
processed.  The checks based on XACT_FLAGS_PIPELINING in the routines  
checking if we are in a transaction block are not necessary: it is  
enough to rely on the existing ones.  
  
Some tests are added to pgbench, that can be backpatched down to v17  
when \syncpipeline is involved and down to v14 where \startpipeline and  
\endpipeline are available.  This is unfortunately limited regarding the  
error patterns that can be checked, but it provides coverage for various  
pipeline combinations to check if these succeed or fail.  These tests  
are able to capture the case of SET LOCAL's WARNING.  The author has  
proposed a different feature to improve the coverage by adding similar  
meta-commands to psql where error messages could be checked, something  
more useful for the cases where commands cannot be used in transaction  
blocks, like REINDEX CONCURRENTLY or VACUUM.  This is considered as  
future work for v18~.  
  
Author: Anthonin Bonnefoy  
Reviewed-by: Jelte Fennema-Nio, Michael Paquier  
Discussion: https://postgr.es/m/CAO6_XqrWO8uNBQrSu5r6jh+vTGi5Oiyk4y8yXDORdE2jbzw8xw@mail.gmail.com  
Backpatch-through: 13  

commit   : a1168855e0df9aabb997ffc26dc8ef6afae2429b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Nov 2024 18:08:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Nov 2024 18:08:58 -0500    

If passed a read-write expanded object pointer, the EEOP_NULLIF  
code would hand that same pointer to the equality function  
and then (unless equality was reported) also return the same  
pointer as its value.  This is no good, because a function that  
receives a read-write expanded object pointer is fully entitled  
to scribble on or even delete the object, thus corrupting the  
NULLIF output.  (This problem is likely unobservable with the  
equality functions provided in core Postgres, but it's easy to  
demonstrate with one coded in plpgsql.)  
  
To fix, make sure the pointer passed to the equality function  
is read-only.  We can still return the original read-write  
pointer as the NULLIF result, allowing optimization of later  
operations.  
  
Per bug #18722 from Alexander Lakhin.  This has been wrong  
since we invented expanded objects, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/18722-fd9e645448cc78b4@postgresql.org  

commit   : 2690a4f5ddf2974c322f48588ff6877ec2caade2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 25 Nov 2024 14:42:35 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 25 Nov 2024 14:42:35 -0800    

This WARNING appeared because SearchSysCacheLocked1() read  
cc_relisshared before catcache initialization, when the field is false  
unconditionally.  On the basis of reading false there, it constructed a  
locktag as though pg_tablespace weren't relisshared.  Only shared  
catalogs could be affected, and only GRANT TABLESPACE was affected in  
practice.  SearchSysCacheLocked1() callers use one other shared-relation  
syscache, DATABASEOID.  DATABASEOID is initialized by the end of  
CheckMyDatabase(), making the problem unreachable for pg_database.  
  
Back-patch to v13 (all supported versions).  This has no known impact  
before v16, where ExecGrant_common() first appeared.  Earlier branches  
avoid trouble by having a separate ExecGrant_Tablespace() that doesn't  
use LOCKTAG_TUPLE.  However, leaving this unfixed in v15 could ensnare a  
future back-patch of a SearchSysCacheLocked1() call.  
  
Reported by Aya Iwata.  
  
Discussion: https://postgr.es/m/OS7PR01MB11964507B5548245A7EE54E70EA212@OS7PR01MB11964.jpnprd01.prod.outlook.com  

commit   : 2fc0199a5015b520da75dddb76a169f6a568ef12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Nov 2024 12:50:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Nov 2024 12:50:17 -0500    

On ARM platforms where the baseline CPU target lacks CRC instructions,  
we need to supply a -march flag to persuade the compiler to compile  
such instructions.  It turns out that our existing choice of  
"-march=armv8-a+crc" has not worked for some time, because recent gcc  
will interpret that as selecting software floating point, and then  
will spit up if the platform requires hard-float ABI, as most do  
nowadays.  The end result was to silently fall back to software CRC,  
which isn't very desirable since in practice almost all currently  
produced ARM chips do have hardware CRC.  
  
We can fix this by using "-march=armv8-a+crc+simd" to enable the  
correct ABI choice.  (This has no impact on the code actually  
generated, since neither of the files we compile with this flag  
does any floating-point stuff, let alone SIMD.)  Keep the test for  
"-march=armv8-a+crc" since that's required for soft-float ABI,  
but try that second since most platforms we're likely to build on  
use hard-float.  
  
Since this isn't working as-intended on the last several years'  
worth of gcc releases, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/4496616.iHFcN1HehY@portable-bastien  

commit   : 17d081a6f9e3d5cbdc53e42ca2ec449d4722d0e2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 25 Nov 2024 08:03:16 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 25 Nov 2024 08:03:16 +0100    

Tcl 9 changed several API functions to take Tcl_Size, which is  
ptrdiff_t, instead of int, for 64-bit enablement.  We have to change a  
few local variables to be compatible with that.  We also provide a  
fallback typedef of Tcl_Size for older Tcl versions.  
  
The affected variables are used for quantities that will not approach  
values beyond the range of int, so this doesn't change any  
functionality.  
  
Reviewed-by: Tristan Partin <tristan@partin.io>  
Discussion: https://www.postgresql.org/message-id/flat/bce0fe54-75b4-438e-b42b-8e84bc7c0e9c%40eisentraut.org  

commit   : e0874080c472bc9b5994d0b9fad9351136578975    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 25 Nov 2024 13:11:28 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 25 Nov 2024 13:11:28 +1300    

Previously we checked "for <stdbool.h> that conforms to C99" using  
autoconf's AC_HEADER_STDBOOL macro.  We've required C99 since PostgreSQL  
12, so the test was redundant, and under C23 it was broken: autoconf  
2.69's implementation doesn't understand C23's new empty header (the  
macros it's looking for went away, replaced by language keywords).  
Later autoconf versions fixed that, but let's just remove the  
anachronistic test.  
  
HAVE_STDBOOL_H and HAVE__BOOL will no longer be defined, but they  
weren't directly tested in core or likely extensions (except in 11, see  
below).  PG_USE_STDBOOL (or USE_STDBOOL in 11 and 12) is still defined  
when sizeof(bool) is 1, which should be true on all modern systems.  
Otherwise we define our own bool type and values of size 1, which would  
fail to compile under C23 as revealed by the broken test.  (We'll  
probably clean that dead code up in master, but here we want a minimal  
back-patchable change.)  
  
This came to our attention when GCC 15 recently started using using C23  
by default and failed to compile the replacement code, as reported by  
Sam James and build farm animal alligator.  
  
Back-patch to all supported releases, and then two older versions that  
also know about <stdbool.h>, per the recently-out-of-support policy[1].  
12 requires C99 so it's much like the supported releases, but 11 only  
assumes C89 so it now uses AC_CHECK_HEADERS instead of the overly picky  
AC_HEADER_STDBOOL.  (I could find no discussion of which historical  
systems had <stdbool.h> but failed the conformance test; if they ever  
existed, they surely aren't relevant to that policy's goals.)  
  
[1] https://wiki.postgresql.org/wiki/Committing_checklist#Policies  
  
Reported-by: Sam James <sam@gentoo.org>  
Reviewed-by: Peter Eisentraut <peter@eisentraut.org> (master version)  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (approach)  
Discussion: https://www.postgresql.org/message-id/flat/87o72eo9iu.fsf%40gentoo.org  

commit   : 7ca388fd0decece896518f61fb5e4c0648690deb    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 22 Nov 2024 14:53:21 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 22 Nov 2024 14:53:21 +1300    

If the executable's .o files were produced by a compiler (probably gcc)  
not using -moutline-atomics, and the corresponding .bc files were  
produced by clang using -moutline-atomics (probably by default), then  
the generated bitcode functions would have the target attribute  
"+outline-atomics", and could fail at runtime when inlined.  If the  
target ISA at bitcode generation time was armv8-a (the most conservative  
aarch64 target, no LSE), then LLVM IR atomic instructions would generate  
calls to functions in libgcc.a or libclang_rt.*.a that switch between  
LL/SC and faster LSE instructions depending on a runtime AT_HWCAP check.  
Since the corresponding .o files didn't need those functions, they  
wouldn't have been included in the executable, and resolution would  
fail.  
  
At least Debian and Ubuntu are known to ship gcc and clang compilers  
that target armv8-a but differ on the use of outline atomics by default.  
  
Fix, by suppressing the outline atomics attribute in bitcode explicitly.  
Inline LL/SC instructions will be generated for atomic operations in  
bitcode built for armv8-a.  Only configure scripts are adjusted for now,  
because the meson build system doesn't generate bitcode yet.  
  
This doesn't seem to be a new phenomenon, so real cases of functions  
using atomics that are inlined by JIT must be rare in the wild given how  
long it took for a bug report to arrive.  The reported case could be  
reduced to:  
  
postgres=# set jit_inline_above_cost = 0;  
SET  
postgres=# set jit_above_cost = 0;  
SET  
postgres=# select pg_last_wal_receive_lsn();  
WARNING:  failed to resolve name __aarch64_swp4_acq_rel  
FATAL:  fatal llvm error: Program used external function  
'__aarch64_swp4_acq_rel' which could not be resolved!  
  
The change doesn't affect non-ARM systems or later target ISAs.  
  
Back-patch to all supported releases.  
  
Reported-by: Alexander Kozhemyakin <a.kozhemyakin@postgrespro.ru>  
Discussion: https://postgr.es/m/18610-37bf303f904fede3%40postgresql.org  

commit   : 1c5fe56bc25926b9504532797c3b4fde816dfba5    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Nov 2024 17:04:26 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Nov 2024 17:04:26 +0100    

It failed to set the archive_command as it desired because of a syntax  
problem.  Oversight in commit 90bcc7c2db1d.  
  
This bug doesn't cause the test to fail, because the test only checks  
pg_rewind's output messages, not the actual outcome (and the outcome in  
both cases is that the file is kept, not deleted).  But in either case  
the message about the file being kept is there, so it's hard to get  
excited about doing much more.  
  
Reported-by: Antonin Houska <ah@cybertec.at>  
Author: Alexander Kukushkin <cyberdemn@gmail.com>  
Discussion: https://postgr.es/m/7822.1732167825@antos  

commit   : 4a20c83798edc09f4de3a2f833f97ea70f3905d2    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Nov 2024 16:54:36 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 21 Nov 2024 16:54:36 +0100    

Apparently this information has been outdated since first committed,  
because we adopted a different implementation during development per  
reviews and this detail was not updated in the README.  
  
This has been wrong since commit 0ac5ad5134f2 introduced the file in  
2013.  Backpatch to all live branches.  
  
Reported-by: Will Mortensen <will@extrahop.com>  
Discussion: https://postgr.es/m/CAMpnoC6yEQ=c0Rdq-J7uRedrP7Zo9UMp6VZyP23QMT68n06cvA@mail.gmail.com  

commit   : 3eb26524ca35f03faa5560debce253d3c8db5624    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2024 12:03:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2024 12:03:47 -0500    

Ordinarily transformSetOperationTree will collect all UNION/  
INTERSECT/EXCEPT steps into the setOperations tree of the topmost  
Query, so that leaf queries do not contain any setOperations.  
However, it cannot thus flatten a subquery that also contains  
WITH, ORDER BY, FOR UPDATE, or LIMIT.  I (tgl) forgot that in  
commit 07b4c48b6 and wrote an assertion in rule deparsing that  
a leaf's setOperations would always be empty.  
  
If it were nonempty then we would want to parenthesize the subquery  
to ensure that the output represents the setop nesting correctly  
(e.g. UNION below INTERSECT had better get parenthesized).  So  
rather than just removing the faulty Assert, let's change it into  
an additional case to check to decide whether to add parens.  We  
don't expect that the additional case will ever fire, but it's  
cheap insurance.  
  
Man Zeng and Tom Lane  
  
Discussion: https://postgr.es/m/tencent_7ABF9B1F23B0C77606FC5FE3@qq.com  

commit   : 44a4a521d03a0033fca696b5fa4725a436018ae6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2024 18:26:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2024 18:26:19 -0500    

In the dim past we figured it was okay to ignore collations  
when combining UNION set-operation nodes into a single N-way  
UNION operation.  I believe that was fine at the time, but  
it stopped being fine when we added nondeterministic collations:  
the semantics of distinct-ness are affected by those.  v17 made  
it even less fine by allowing per-child sorting operations to  
be merged via MergeAppend, although I think we accidentally  
avoided any live bug from that.  
  
Add a check that collations match before deciding that two  
UNION nodes are equivalent.  I also failed to resist the  
temptation to comment plan_union_children() a little better.  
  
Back-patch to all supported branches (v13 now), since they  
all have nondeterministic collations.  
  
Discussion: https://postgr.es/m/3605568.1731970579@sss.pgh.pa.us