PostgreSQL 16.7 commit log

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

commit   : 7e06ffbc6230a6f3e4cdc7599a5617d081d611f7    
  
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   : 0075a5c6ce5bb6f3ee005a54cd5b518f16659655    
  
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   : 41343f84052eb53a900ea464a8ce16a548cab901    
  
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   : 16ce519533bd03db726953db2364877a8944da4c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -0500    

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

commit   : 01784793fca3d998dd36ea21f120a78f0b3d5e85    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -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   : 92e4170f421832208a75645f4a4ea94494bdad4d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -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   : 56aa2dcddeb299f62dad98ba50ad8db47cddaf97    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -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   : 6e05b195d0e192e143db8c4c7ef2526860341a2c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Feb 2025 10:03:39 -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   : ef23624caf89aaf472bd9fa687534149be9f49ae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2025 15:05:03 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Feb 2025 15:05:03 +0100    

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

commit   : 2aa91e3513067e7e76f66a2f2a7f17d82c9a102d    
  
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   : 21b815f92e82f6aad557d99492b12a912943fdbc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Feb 2025 13:41:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Feb 2025 13:41:42 -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   : bbf1ef72c22f1f3db778db0aaab8a1daa82d81f8    
  
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   : 60516fc8b491f941988b6f4a3a55167b98a9351b    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 7 Feb 2025 15:09:13 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 7 Feb 2025 15:09:13 +0100    

Before OpenSSL 1.1.0 the legacy names ssleay32 and libeay32 were  
still used on Windows, and while we have support for this auto-  
conf the meson buildsystem only used the new names on all plat-  
forms.  This adds support for the old name scheme when building  
on Windows.  
  
This patch only applies to 17 and 16 as master no longer support  
OpenSSL 1.0.2.  
  
Author: Darek Ślusarczyk <dslusarczyk@splunk.com>  
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CAN55FZ1Nk8wqY=mTrN78H026TuGV50h2H6uq1PwxhTauPYi3ug@mail.gmail.com  
Backpatch-through: 16  

commit   : b26a3bc2f62433d1a8bc9ec9a7f8c52cc7a1677c    
  
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   : d9b5e2fc09b65a6512561c7dbb97e0836dcf933e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    

Meson 1.7 stopped building all the dependencies of tests as part of the  
default build target. But it does breaks CI because we only built the default  
target before running the test, and ran the tests with --no-rebuild.  
  
The simplest fix would be to remove --no-rebuild from MTEST_ARGS, but it seems  
better to explicitly build the test dependencies, so compiler warnings /  
errors are visible as part of the build step.  
  
Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com  
Backpatch: 16-, where meson was added  

commit   : ad80e5823a50c81502782ffd7d5a794005461f22    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    

The missing dependency was, e.g., visible when doing  
  ninja clean && ninja meson-test-prereq && meson test --no-rebuild --suite setup --suite libpq  
  
This is a bit more complicated than other related fixes, because until now  
libpq's tests depended on 'frontend_code', which includes a dependency on  
fe_utils, which in turns on libpq. That in turn required  
src/interfaces/libpq/test to be entered from the top-level, not from  
libpq/meson.build.  Because of that the test definitions in libpq/meson.build  
could not declare a dependency on the binaries defined in  
libpq/test/meson.build.  
  
To fix this, this commit creates frontend_no_fe_utils_code, which allows us to  
recurse into libpq/test from withing libpq/meson.build.  
  
Apply this to all branches with meson support, as part of an effort to fix  
incorrect test dependencies that can lead to test failures.  
  
Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com  
Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org  
Backpatch: 16-, where meson support was added  

commit   : 5acf0636f87410fef77d38a23738023267ab6dd3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    

The missing dependency was, e.g., visible when doing  
  ninja clean && ninja meson-test-prereq && meson test --no-rebuild --suite setup --suite libpq_pipeline  
  
Apply this to all branches with meson support, as part of an effort to fix  
incorrect test dependencies that can lead to test failures.  
  
Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com  
Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org  
Backpatch: 16-, where meson support was added  

commit   : 0577620667921328b94e96ed0bef98036f21cc95    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    

This is required to ensure correct test dependencies, previously  
pg_regress_ecpg would not necessarily be built.  
  
The missing dependency was, e.g., visible when doing  
  ninja clean && ninja meson-test-prereq && meson test --no-rebuild --suite setup --suite ecpg  
  
Apply this to all branches with meson support, as part of an effort to fix  
incorrect test dependencies that can lead to test failures.  
  
Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com  
Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org  
Backpatch: 16-, where meson support was added  

commit   : dab83a62fc62ecc3183314134d40b723eb4332cd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    

The missing dependency was, e.g., visible when doing  
  ninja clean && ninja meson-test-prereq && meson test --no-rebuild --suite setup --suite cube  
because meson (and thus its internal meson-test-prereq target) did not know  
about a lot of the required targets.  
  
Previously tmp_install did not actually depend on the relevant files being  
built. That was mostly not visible, because "meson test" currently uses the  
'default' targets as a test's dependency if no dependency is specified.  
However, there are plans to narrow that on the meson side, to make it quicker  
to run tests.  
  
Apply this to all branches with meson support, as part of an effort to fix  
incorrect test dependencies that can lead to test failures.  
  
Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com  
Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org  
Backpatch: 16-, where meson support was added  

commit   : 80620931053dc64eb9cff7a77a5270b189ce7f39    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 4 Feb 2025 17:45:57 -0500    

Previously test dependencies, which are not actually installed, were  
unnecessarily built.  
  
Apply this to all branches with meson support, as part of an effort to fix  
incorrect test dependencies that can lead to test failures.  
  
Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com  
Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org  
Backpatch: 16-, where meson support was added  

commit   : d54d5668b4d7ef44e2c8475ed3944686293e9829    
  
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   : e8d8174caf75c5724847b43b886a7feb1628c4d4    
  
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   : f07ebd54a304002c7ae289cddb5666e03f32fcd2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Feb 2025 11:31:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Feb 2025 11:31:29 +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   : 2f9b769b3098556199445c98e15e0cb7174ea943    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jan 2025 11:06:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Jan 2025 11:06:09 +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   : f7a08b6e96eeedde1104a68220a9717ceb2c4ec9    
  
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   : 6655d931c659fda68cce090b7214cb1a9d4cfc65    
  
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   : 998c4fc7c2c89abad4171f78f9375bd31713b5ca    
  
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   : 9311fcb8648075782f59d534010352264bf8dc54    
  
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   : 3d57f7cf300540bea6939fe5bdd820a606aa2669    
  
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   : 53771e44df810d3fbccc26e71753e8e292125962    
  
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   : 92598f4fa58da45226b3414d6d880cf4622481a7    
  
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   : 155d6162e4578930d584f75599276de341685b23    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Jan 2025 10:26:12 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Jan 2025 10:26:12 +0100    

The sepgsql.sql file should be installed under share/contrib/, not  
share/extension/, since it is not an extension.  This makes it match  
what make install does.  
  
Discussion: https://www.postgresql.org/message-id/flat/651a5baf-5c45-4a5a-a202-0c8453a4ebf8@eisentraut.org  

commit   : 7ab181a29ba54c3a893587d37afa89a20fdcc75a    
  
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   : 8c57f548534b71b5977ccc7182521acc2dbfddf1    
  
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   : ddab512ebb97c03d3c0dcfe0ea20d053a31e24d8    
  
author   : Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jan 2025 14:53:46 +0100    
  
committer: Álvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jan 2025 14:53:46 +0100    

In common cases, foreign keys are defined on the toplevel partitioned  
table; but if instead one is defined on a partition and references a  
partitioned table, and the referencing partition is detached, we would  
examine the pg_constraint row on the partition being detached, and fail  
to realize that the sub-constraints must be left alone.  This causes the  
ALTER TABLE DETACH process to fail with  
  
 ERROR:  could not find ON INSERT check triggers of foreign key constraint NNN  
  
This is similar but not quite the same as what was fixed by  
53af9491a043.  This bug doesn't affect branches earlier than 15, because  
the detach procedure was different there, so we only backpatch down to  
15.  
  
Fix by skipping such modifying constraints that are children of other  
constraints being detached.  
  
Author: Amul Sul <sulamul@gmail.com>  
Diagnosys-by: Sami Imseih <samimseih@gmail.com>  
Discussion: https://postgr.es/m/CAAJ_b97GuPh6wQPbxQS-Zpy16Oh+0aMv-w64QcGrLhCOZZ6p+g@mail.gmail.com  

commit   : d62403c5129edc6444f5a17c7f15443d7500c5a3    
  
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   : 5054b7e107169de0b8ece0486943339638b6cd0d    
  
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   : b4b52c911aafe482f008142d751b9ede6f85f52e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 20 Jan 2025 15:17:47 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 20 Jan 2025 15:17:47 +1300    

If a WaitEventSetWait() caller asks for multiple events, an already set  
latch would previously prevent other events from being reported at the  
same time.  Now, we'll also poll the kernel for other events that would  
fit in the caller's output buffer with a zero wait time.  This policy  
change doesn't affect callers that ask for only one event.  
  
The main caller affected is the postmaster.  If its latch is set  
extremely frequently by backends launching workers and workers exiting,  
we don't want it to handle only those jobs and ignore incoming client  
connections.  
  
Back-patch to 16 where the postmaster began using the API.  The  
fast-return policy changed here is older than that, but doesn't cause  
any known problems in earlier releases.  
  
Reported-by: Nathan Bossart <nathandbossart@gmail.com>  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://postgr.es/m/Z1n5UpAiGDmFcMmd%40nathan  

commit   : 2c2e1d4f42c00784b46023ba123bd5cd38d914fb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 20 Jan 2025 09:30:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 20 Jan 2025 09:30:36 +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   : 4d72357c40ee0abfa5aa9361683aa08e257418c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2025 13:27:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2025 13:27:43 +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   : 94c02bd3345d7837bc1f240c14db2222c85aa18c    
  
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   : 9420f9bb61e6c244107a01b96e9ea07231b52ba7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jan 2025 09:26:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Jan 2025 09:26:26 +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   : b935691b8b2f7ec7d537b77cb262ee8363f4715c    
  
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   : 5c7c34db251161e07010d0122d2687135fc2212f    
  
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   : 91fc447c21d38f6631480ae6f252dbf4211b10b2    
  
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   : bfda7d8dd6b392c5d55bfb032aa7848b20227e12    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jan 2025 15:13:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Jan 2025 15:13:15 +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   : 116036d811cccacfb9eedb4f6261c9ecddcebcf3    
  
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   : 77763f3bef482f575fd51190f27f38d3bc5ba42a    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 12 Jan 2025 12:58:14 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 12 Jan 2025 12:58:14 +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   : 33a4e656dc10b3cb9023bccdc0a12dc604613195    
  
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   : c35bbdfbc0d30fee6037b7859501b68b28d68c34    
  
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   : 0b5927dfac26a620b0bed53d8955e68a134db452    
  
author   : Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 9 Jan 2025 17:10:13 -0600    
  
committer: Nathan Bossart <nathan@postgresql.org>    
date     : Thu, 9 Jan 2025 17:10:13 -0600    

This error message stated the privileges required to add a member  
to a group even if the user was trying to drop a member:  
  
	postgres=> alter group a drop user b;  
	ERROR:  permission denied to alter role  
	DETAIL:  Only roles with the ADMIN option on role "a" may add members.  
  
Since the required privileges for both operations are the same, we  
can fix this by modifying the message to mention both adding and  
dropping members:  
  
	postgres=> alter group a drop user b;  
	ERROR:  permission denied to alter role  
	DETAIL:  Only roles with the ADMIN option on role "a" may add or drop members.  
  
Author: ChangAo Chen  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/tencent_FAA0D00E3514AAF0BBB6322542A6094FEF05%40qq.com  
Backpatch-through: 16  

commit   : be7489662e7759de7a8338d3e65cd6a22dfa4976    
  
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   : 0bff6f1da8424efe1ce9a78d9bb2fdd91fdba651    
  
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   : 9defaaa1da60372f687e707c20c12aea713e1741    
  
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   : c957d7444fccb3c61b5f00908ef91aba012c683b    
  
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   : 653729ce0ec1c38b444740637896d6ec706ef13a    
  
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   : a1a9120c797d689be1dafd6fac8d956e3f667ba6    
  
author   : Richard Guo <rguo@postgresql.org>    
date     : Thu, 2 Jan 2025 18:02:02 +0900    
  
committer: Richard Guo <rguo@postgresql.org>    
date     : Thu, 2 Jan 2025 18:02:02 +0900    

When looking up statistical data about an expression, we do not need  
to concern ourselves with the outer joins that could null the  
Vars/PHVs contained in the expression.  Accounting for nullingrels in  
the expression could cause estimate_num_groups to count the same Var  
multiple times if it's marked with different nullingrels.  This is  
incorrect, and could lead to "ERROR:  corrupt MVNDistinct entry" when  
searching for multivariate n-distinct.  
  
Furthermore, the nullingrels could prevent us from matching an  
expression to expressional index columns or to the expressions in  
extended statistics, leading to inaccurate estimates.  
  
To fix, strip out all the nullingrels from the expression before we  
look up statistical data about it.  There is one ensuing plan change  
in the regression tests, but it looks reasonable and does not  
compromise its original purpose.  
  
This patch could result in plan changes, but it fixes an actual bug,  
so back-patch to v16 where the outer-join-aware-Var infrastructure was  
introduced.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs4-2Z4k+nFTiZe0Qbu5n8juUWenDAtMzi98bAZQtwHx0-w@mail.gmail.com  

commit   : c4f8291cf00a9101a80e77f0efd70b4836a4ebae    
  
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   : e3a27fd06d06726546bccf22ac986c67f0e84dd5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Dec 2024 13:33:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Dec 2024 13:33:59 +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.  
  
To address this, a relation's attribute map is allocated in  
PGOutputData's cachectx, free()'d at the end of the execution of these  
SQL functions when logical decoding ends.  This is available down to 15.  
v13 and v14 have a similar leak, which will be dealt with later.  
  
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: 15  

commit   : 359f31c638eb7ccf0c049c9cd0f717a88b82681a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Dec 2024 08:06:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Dec 2024 08:06:42 +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   : 41a252c2ca68ba7239e73abd99fdbf28871f5f07    
  
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   : 5d94aa4dc3a492830e0ac8f0292e26f5c6bd2b5b    
  
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   : 643efb18bf80ff179981cbd91c843cc6ae97a713    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 25 Dec 2024 19:22:25 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 25 Dec 2024 19:22:25 +0200    

This fixes "unresolved external symbol" errors with extensions that  
use functions from libpgport that need special CFLAGS to  
compile. Currently, that includes the CRC-32 functions.  
  
Commit 2571c1d5cc did this for libcommon, but I missed that libpqport  
has the same issue.  
  
Reported-by: Tom Lane  
Backpatch-through: 16, where Meson was introduced  
Discussion: https://www.postgresql.org/message-id/CAOdR5yF0krWrxycA04rgUKCgKugRvGWzzGLAhDZ9bzNv8g0Lag@mail.gmail.com  

commit   : 4e0d71ff22594b50d6ee545a12072306589cc462    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 25 Dec 2024 18:14:18 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 25 Dec 2024 18:14:18 +0200    

This fixes "unresolved external symbol" errors with extensions that  
use functions from libcommon. This was reported with pgvector.  
  
Reported-by: Andrew Kane  
Author: Vladlen Popolitov  
Backpatch-through: 16, where Meson was introduced  
Discussion: https://www.postgresql.org/message-id/CAOdR5yF0krWrxycA04rgUKCgKugRvGWzzGLAhDZ9bzNv8g0Lag@mail.gmail.com  

commit   : 4d45e7490c417d477458865926555895db125910    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Dec 2024 12:48:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Dec 2024 12:48:08 +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   : 9d8ab2c461d706ca22adf86c057d4f76ca7f6da6    
  
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   : ba02d24bacbb221891370a6b2c2655f24f128305    
  
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   : 093fc156b0ef69fdbe2a345c4ba6bca461c62631    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 19 Dec 2024 13:12:41 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 19 Dec 2024 13:12:41 +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   : 8cfff087b55f6688e2f3b5f1ba303dc5fb8222c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Dec 2024 22:31:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Dec 2024 22:31:26 -0500    

EndCompressorZstd() neglected to free everything.  This was  
most visible with a lot of large objects in the dump.  
  
Per report from Tomasz Szypowski.  Back-patch to v16  
where this code came in.  
  
Discussion: https://postgr.es/m/DU0PR04MB94193D038A128EF989F922D199042@DU0PR04MB9419.eurprd04.prod.outlook.com  

commit   : 2a74023221f9b9e484611581542c14fc6ef6d239    
  
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   : 3231cb57d886450f0251f64e440ac51d4675bef2    
  
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   : 076b09123078033ebef609c91a9a276ee6e1bcb3    
  
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   : 31daa10facec70f62ac66f0187fa203c3fa77074    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2024 16:07:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2024 16:07:18 -0500    

The @extschema:name@ feature added by 72a5b1fc8 allows us to  
make earthdistance's references to the cube extension fully  
search-path-secure, so long as all those references are  
resolved at extension installation time not runtime.  
To do that, we must convert earthdistance's SQL functions to  
the new SQL-standard style; but we wanted to do that anyway.  
  
The functions can be updated in our customary style by running  
CREATE OR REPLACE FUNCTION in an extension update script.  
However, there's still problems in the "CREATE DOMAIN earth"  
command: its references to cube functions could be captured  
by hostile objects in earthdistance's installation schema,  
if that's not where the cube extension is.  Worse, the reference  
to the cube type itself as the domain's base could be captured,  
and that's not something we could fix after-the-fact in the  
update script.  
  
What I've done about that is to change the "CREATE DOMAIN earth"  
command in the base script earthdistance--1.1.sql.  Ordinarily,  
changing a released extension script is forbidden; but I think  
it's okay here since the results of successful (non-trojaned)  
script execution will be identical to before.  
  
A good deal of care is still needed to make the extension's scripts  
proof against search-path-based attacks.  We have to make sure that  
all the function and operator invocations have exact argument-type  
matches, to forestall attacks based on supplying a better match.  
Fortunately earthdistance isn't very big, so I've just gone through  
it and inspected each call to be sure of that.  The only actual code  
changes needed were to spell all floating-point constants in the style  
'-1'::float8, rather than depending on runtime type conversions and/or  
negations.  (I'm not sure that the shortcuts previously used were  
attackable, but removing run-time effort is a good thing anyway.)  
  
I believe that this fixes earthdistance enough that we could  
mark it trusted and remove the warnings about it that were  
added by 7eeb1d986; but I've not done that here.  
  
The primary reason for dealing with this now is that we've  
received reports of pg_upgrade failing for databases that use  
earthdistance functions in contexts like generated columns.  
That's a consequence of 2af07e2f7 having restricted the search_path  
used while evaluating such expressions.  The only way to fix that  
is to make the earthdistance functions independent of run-time  
search_path.  This patch is very much nicer than the alternative of  
attaching "SET search_path" clauses to earthdistance's functions:  
it is more secure and doesn't create a run-time penalty.  Therefore,  
I've chosen to back-patch this to v16 where @extschema:name@  
was added.  It won't help unless users update to 16.7 and issue  
"ALTER EXTENSION earthdistance UPDATE" before upgrading to 17,  
but at least there's now a way to deal with the problem without  
manual intervention in the dump/restore process.  
  
Tom Lane and Ronan Dunklau  
  
Discussion: https://postgr.es/m/3316564.aeNJFYEL58@aivenlaptop  
Discussion: https://postgr.es/m/6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org  

commit   : 782cc1aa3d158906cdfb9ca809c9ca4241a33041    
  
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   : 058b208a5d129dbc1d857338ad68b1fd6613d0e2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Dec 2024 08:48:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Dec 2024 08:48:53 +0900    

On failure, the pg_upgrade log files are automatically appended to the  
test log file, but the information reported was inconsistent.  
  
A header, with the log file name, was reported with note(), while the  
log contents and a footer used print(), making it harder to diagnose  
failures when these are split into console output and test log file  
because the pg_upgrade log file path in the header may not be included  
in the test log file.  
  
The output is now consolidated so as the header uses print() rather than  
note().  An extra note() is added to inform that the contents of a  
pg_upgrade log file are appended to the test log file.  
  
The diffs from the regression test suite and dump files all use print()  
to show their contents on failure.  
  
Author: Joel Jacobson  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/49f7e64a-b9be-4a90-a9fe-210a7740405e@app.fastmail.com  
Backpatch-through: 15  

commit   : ac4a2b40392bd5ca9e9e02bad50d437411a8adfb    
  
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   : f0672b6787ab48204dc8aebbcd1bae0a5775ff8b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Dec 2024 13:02:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Dec 2024 13:02:27 +0900    

The GUC assign and check hooks used "assign_timezone_abbreviations",  
which was incorrect.  
  
Issue noticed while browsing this area of the code, introduced in  
0a20ff54f5e6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/Z1eV6Y8yk77GZhZI@paquier.xyz  
Backpatch-through: 16  

commit   : 8ac97ce42c8c0180328c80a06bf9c0bcae500477    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Dec 2024 12:54:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 10 Dec 2024 12:54:16 +0900    

This routine documented that "iterations" would use a default value if  
set to 0 by the caller.  However, the iteration should always be set by  
the caller to a value strictly more than 0, as documented by an  
assertion.  
  
Oversight in b577743000cd, that has made the iteration count of SCRAM  
configurable.  
  
Author: Matheus Alcantara  
Discussion: https://postgr.es/m/ac858943-4743-44cd-b4ad-08a0c10cbbc8@gmail.com  
Backpatch-through: 16  

commit   : b0a04ce0916b370e70ccf0a2e6a5d4d7607efe25    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 10 Dec 2024 09:25:50 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 10 Dec 2024 09:25:50 +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   : be9dac9afc25a1edaf4ad708b4efb909029b4198    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 9 Dec 2024 20:58:23 +0100    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 9 Dec 2024 20:58:23 +0100    

Follow-up commit to a9d58bfe8a3a.  Backpatch down to v16 where  
this was added in order to keep the code consistent for future  
backpatches.  
  
Author: Tofig Aliev <t.aliev@postgrespro.ru>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/bba4313fdde9db46db279f96f3b748b1@postgrespro.ru  
Backpatch-through: 16  

commit   : bb649b553c589a3fd1f36b2280e984622e6fdcdb    
  
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   : ec194b448cbc7f9fe2204cdb7690eb4c21a46d8e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Dec 2024 14:35:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Dec 2024 14:35:46 +0900    

pgstat_write_statsfile() discards any entries marked as dropped from  
being written to the stats file at shutdown, and also included an  
assertion based on the same condition.  
  
The intention of the assertion is to track that no pgstats entries  
should be left around as terminating backends should drop any entries  
they still hold references on before the stats file is written by the  
checkpointer, and it not worth taking down the server in this case if  
there is a bug making that possible.  
  
Let's improve the comment of this area to document clearly what's  
intended.  
  
Based on a discussion with Bertrand Drouvot and Anton A. Melnikov.  
  
Author: Bertrand Drouvot  
Discussion: https://postgr.es/m/a13e8cdf-b97a-4ecb-8f42-aaa367974e29@postgrespro.ru  
Backpatch-through: 15  

commit   : ae77bcc3aa1b869568c6b01726e4f1276f7381bb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Dec 2024 10:46:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 9 Dec 2024 10:46:09 +0900    

818119afccd3 has introduced the "generation" concept in pgstats entries,  
incremented a counter when a pgstats entry is reinitialized, but it did  
not count on the fact that backends still holding local references to  
such entries need to be refreshed if the cache age is outdated.  The  
previous logic only updated local references when an entry was dropped,  
but it needs also to consider entries that are reinitialized.  
  
This matters for replication slot stats (as well as custom pgstats kinds  
in 18~), where concurrent drops and creates of a slot could cause  
incorrect stats to be locally referenced.  This would lead to an  
assertion failure at shutdown when writing out the stats file, as the  
backend holding an outdated local reference would not be able to drop  
during its shutdown sequence the stats entry that should be dropped, as  
the last process holding a reference to the stats entry.  The  
checkpointer was then complaining about such an entry late in the  
shutdown sequence, after the shutdown checkpoint is finished with the  
control file updated, causing the stats file to not be generated.  In  
non-assert builds, the entry would just be skipped with the stats file  
written.  
  
Note that only logical replication slots use statistics.  
  
A test case based on TAP is added to test_decoding, where a persistent  
connection peeking at a slot's data is kept with concurrent drops and  
creates of the same slot.  This is based on the isolation test case that  
Anton has sent.  As it requires a node shutdown with a check to make  
sure that the stats file is written with this specific sequence of  
events, TAP is used instead.  
  
Reported-by: Anton A. Melnikov  
Reviewed-by: Bertrand Drouvot  
Discussion: https://postgr.es/m/56bf8ff9-dd8c-47b2-872a-748ede82af99@postgrespro.ru  
Backpatch-through: 15  

commit   : c1d6506acc2b0b8c0aa1209ce5187b20caee205e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Dec 2024 14:24:34 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Dec 2024 14:24:34 +1300    

When short-circuiting WindowAgg node evaluation on the top-level  
WindowAgg node using quals on monotonic window functions, because the  
WindowAgg run condition can mean there's no need to evaluate subsequent  
window function results in the same partition once the run condition  
becomes false, it was possible that the executor would use stale results  
from the previous invocation of the window function in some cases.  
  
A fix for this was partially done by a5832722, but that commit only  
fixed the issue for non-top-level WindowAgg nodes.  I mistakenly thought  
that the top-level WindowAgg didn't have this issue, but Jayesh's example  
case clearly shows that's incorrect.  At the time, I also thought that  
this only affected 32-bit systems as all window functions which then  
supported run conditions returned BIGINT, however, that's wrong as  
ExecProject is still called and that could cause evaluation of any other  
window function belonging to the same WindowAgg node, one of which may  
return a byref type.  
  
The only queries affected by this are WindowAggs with a "Run Condition"  
which contains at least one window function with a byref result type,  
such as lead() or lag() on a byref column.  The window clause must also  
contain a PARTITION BY clause (without a PARTITION BY, execution of the  
WindowAgg stops immediately when the run condition becomes false and  
there's no risk of using the stale results).  
  
Reported-by: Jayesh Dehankar  
Discussion: https://postgr.es/m/193261e2c4d.3dd3cd7c1842.871636075166132237@zohocorp.com  
Backpatch-through: 15, where WindowAgg run conditions were added  

commit   : be5db08ed341728bce63361f1cbeeaf2a8c23b29    
  
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   : faad0183507b9185382b0ab6f7701144b8cc5687    
  
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   : 26c233b8b8f536f4ed252f9145c2ee365bb04b99    
  
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   : ad485171c703915b09a9f498fad69e89f75c9568    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Dec 2024 12:55:55 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Dec 2024 12:55:55 +0100    

The corresponding read-only server settings have been removed since  
in PG16. See commit b0f6c437160db6.  
  
Author: Pierre Giraud <pierre.giraud@dalibo.com>  
Discussion: https://www.postgresql.org/message-id/flat/a75a2fb0-f4b3-4c0c-be3d-7a62d266d760%40dalibo.com  

commit   : ad5aa7bfd042c9d0588f206f4c4ac65c3203bd48    
  
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   : cca34f68c6fa827728f16e563b16d90aa1679ab2    
  
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   : 7b456f040fb6ca320c756cd822cfbd219b0c4078    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Nov 2024 12:42:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Nov 2024 12:42:20 -0500    

As I'd feared, commit 5c9d8636d was still a few bricks shy of a load.  
We can't just leave pulled-up lateral-reference Vars with no new  
nullingrels: we have to carefully compute what subset of the  
to-be-replaced Var's nullingrels apply to them, else we still get  
"wrong varnullingrels" errors.  This is a bit tedious, but it looks  
like we can use the nullingrel data this patch computes for other  
purposes, enabling better optimization.  We don't want to inject  
unnecessary plan changes into stable branches though, so leave that  
idea for a later HEAD-only patch.  
  
Patch by me, but thanks to Richard Guo for devising a test case that  
broke 5c9d8636d, and for preliminary investigation about how to fix  
it.  As before, back-patch to v16.  
  
Discussion: https://postgr.es/m/E1tGn4j-0003zi-MP@gemulon.postgresql.org  

commit   : 85990e2fd5610576635c65db9292297b1730c947    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Nov 2024 17:33:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Nov 2024 17:33:16 -0500    

If we are pulling up a subquery that's under an outer join, and  
the subquery's target list contains a strict expression that uses  
both a subquery variable and a lateral-reference variable, it's okay  
to pull up the expression without wrapping it in a PlaceHolderVar.  
That's safe because if the subquery variable is forced to NULL  
by the outer join, the expression result will come out as NULL too,  
so we don't have to force that outcome by evaluating the expression  
below the outer join.  It'd be correct to wrap in a PHV, but that can  
lead to very significantly worse plans, since we'd then have to use  
a nestloop plan to pass down the lateral reference to where the  
expression will be evaluated.  
  
However, when we do that, we should not mark the lateral reference  
variable as being nulled by the outer join, because it isn't after  
we pull up the expression in this way.  So the marking logic added  
by cb8e50a4a was incorrect in this detail, leading to "wrong  
varnullingrels" errors from the consistency-checking logic in  
setrefs.c.  It seems to be sufficient to just not mark lateral  
references at all in this case.  (I have a nagging feeling that more  
complexity may be needed in cases where there are several levels of  
outer join, but some attempts to break it with that didn't succeed.)  
  
Per report from Bertrand Mamasam.  Back-patch to v16, as the previous  
patch was.  
  
Discussion: https://postgr.es/m/CACZ67_UA_EVrqiFXJu9XK50baEpH=ofEPJswa2kFxg6xuSw-ww@mail.gmail.com  

commit   : 06d601edc7b82ecdc24e48305f9808a3b5425752    
  
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   : 76653134ae87c7c08e1eb58da07af9f64ec78ccb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Nov 2024 09:43:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Nov 2024 09:43:22 +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   : c26831e7362487b4f2c606e1223207baa1d495cb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 27 Nov 2024 11:30:08 -0500    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 27 Nov 2024 11:30:08 -0500    

1.  The error reporting of "port setrequested list-of-packages..."  
changed, hiding errors we were relying on to know if all packages in our  
list were already installed.  Use a loop instead.  
  
2.  The cached MacPorts installation was shared between PostgreSQL  
major branches, though each branch wanted different packages.  Add the  
list of packages to cache key, so that different branches, when tested  
in one github account/repo such as postgres/postgres, stop fighting with  
each other, adding and removing packages.  
  
Back-patch to 15 where CI began.  
  
Author: Thomas Munro <thomas.munro@gmail.com>  
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>  
Suggested-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/au2uqfuy2nf43nwy2txmc5t2emhwij7kzupygto3d2ffgtrdgr%40ckvrlwyflnh2  

commit   : 1cf646957135d1200c2b7765e6446fb91bb47d86    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Nov 2024 23:03:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 27 Nov 2024 23:03:44 +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   : 56265ed6a12c3ccf13a1a702748fcab8d1c6111b    
  
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   : 467df7f561dde102029e20e0011dc98987de47ff    
  
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   : a8abd36e88f50531177d5b52026194af52d45421    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 Nov 2024 09:31:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 27 Nov 2024 09:31:38 +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   : 1250adfdf07da7eb6e1f629d7ffafd8372e0ad6d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 May 2024 17:34:45 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 May 2024 17:34:45 -0400    

The OSSP uuid.h file includes unistd.h, so to use it with MSVC we need to  
include the postgres include directories so it picks up our version of  
that in src/include/port/win32_msvc. Adjust the meson test accordingly.  
  
Backported from commit 7c655a04a2, so we can build release 16 with UUID  
  
per request from Marina Polyakova  

commit   : 766b0b40aa6a537e8bf899c48736c2ec3ae89869    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 Nov 2024 18:06:08 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 Nov 2024 18:06:08 +0100    

This matches the behavior of the makefiles and the old MSVC build  
system.  The main effect is that the build result gets installed into  
pkglibdir rather than bindir.  The documentation says to locate the  
library in pkglibdir, so this makes the code match the documentation  
again.  
  
Reviewed-by: Ryohei Takahashi (Fujitsu) <r.takahashi_2@fujitsu.com>  
Discussion: https://www.postgresql.org/message-id/flat/TY3PR01MB118912125614599641CA881B782522%40TY3PR01MB11891.jpnprd01.prod.outlook.com  

commit   : f7a929a007e64aa9a2c7d65555029ae90c5ed6bd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 22 Oct 2024 08:12:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 22 Oct 2024 08:12:43 +0200    

The approach of declaring a function pointer with an empty argument  
list and hoping that the compiler will not complain about casting it  
to another type no longer works with C23, because foo() is now  
equivalent to foo(void).  
  
We don't need to do this here.  With a few struct forward declarations  
we can supply a correct argument list without having to pull in  
another header file.  
  
(This is the only new warning with C23.  Together with the previous  
fix a67a49648d9, this makes the whole code compile cleanly under C23.)  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/95c6a9bf-d306-43d8-b880-664ef08f2944%40eisentraut.org  
Discussion: https://www.postgresql.org/message-id/flat/87o72eo9iu.fsf%40gentoo.org  

commit   : ae145d1de6773d43169f7aefb5666fe9ecb6d470    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Aug 2024 06:15:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Aug 2024 06:15:28 +0200    

constexpr is a keyword in C23.  Rename a conflicting identifier for  
future-proofing.  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/08abc832-1384-4aca-a535-1a79765b565e%40eisentraut.org  
Discussion: https://www.postgresql.org/message-id/flat/87o72eo9iu.fsf%40gentoo.org  

commit   : 4aba56adcd29c5d9a6f38f9bc428b916e3d08d5d    
  
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   : c1285bbeb962750d9d1aa5e84a6761d7d135146a    
  
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   : 5609b474dba3f8e4874fa8ac08a98f4f00bd063c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Nov 2024 11:29:31 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 26 Nov 2024 11:29:31 +1300    

Commit bc5a4dfc accidentally left a check for <stdbool.h> in  
meson.build's header_checks.  Synchronize with configure, which no  
longer defines HAVE_STDBOOL_H.  
  
There is still a reference to <stdbool.h> in an earlier test to see if  
we need -std=c99 to get C99 features, like autoconf 2.69's  
AC_PROG_CC_C99.  (Therefore the test remove by this commit was  
tautological since day one: you'd have copped "C compiler does not  
support C99" before making it this far.)  
  
Back-patch to 16, where meson begins.  

commit   : 1f4aadec41b8655e4e37c18c3c11552091ef7123    
  
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   : 07c77803c82bf251b085611f72e2a10ebe8ab51c    
  
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   : 0f6d902308a82db2edaa0bc33f6ed5e5a00e8752    
  
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   : ee3415c00a3156d9355ba75e369e10a25ce96c55    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Nov 2024 09:15:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Nov 2024 09:15:43 +0900    

Per PEP 3114, iterator.next() has been renamed to iterator.__next__(),  
and one example in the documentation still used next().  This caused the  
example provided to fail the function creation since Python 2 is not  
supported anymore since 19252e8ec93.  
  
Author: Erik Wienhold  
Discussion: https://postgr.es/m/173209043143.2092749.13692266486972491694@wrigleys.postgresql.org  
Backpatch-through: 15  

commit   : 4ecb136bfaa72780332c495259d99ffd236da50e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Nov 2024 12:17:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Nov 2024 12:17:55 +0900    

psql's --help was missed the description of the \pset variable  
xheader_width, that should be listed when using \? or --help=commands,  
and described for --help=variables.  
  
Oversight in a45388d6e098.  
  
Author: Pavel Luzanov  
Discussion: https://postgr.es/m/1e3e06d6-0807-4e62-a9f6-c11481e6eb10@postgrespro.ru  
Backpatch-through: 16  

commit   : 6de14dbb3629eb5393db9bfab8ea3d5b1b8a0c23    
  
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   : 50010c6f6c4d10e8d78d2d550bdaea461d0c83a9    
  
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   : aca1599d694d672d65d4f9d2f8378bb93de14c7b    
  
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   : e749eaf46e9b05d25592d9c83bde7fb026e9c6eb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Nov 2024 15:14:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Nov 2024 15:14:13 +0900    

RelationSyncCache, the hash table in charge of tracking the relation  
schemas sent through pgoutput, was forgetting to free the TupleDesc  
associated to the two slots used to store the new and old tuples,  
causing some memory to be leaked each time a relation is invalidated  
when the slots of an existing relation entry are cleaned up.  
  
This is rather hard to notice as the bloat is pretty minimal, but a  
long-running WAL sender would be in trouble over time depending on the  
workload.  sysbench has proved to be pretty good at showing the problem,  
coupled with some memory monitoring of the WAL sender.  
  
Issue introduced in 52e4f0cd472d, that has added row filters for tables  
logically replicated.  
  
Author: Boyu Yang  
Reviewed-by: Michael Paquier, Hou Zhijie  
Discussion: https://postgr.es/m/DM3PR84MB3442E14B340E553313B5C816E3252@DM3PR84MB3442.NAMPRD84.PROD.OUTLOOK.COM  
Backpatch-through: 15  

commit   : fe084039e482673c2d7fbd881f7ce918c2512d50    
  
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   : 1c99d8186fbf3a55de4d7b6dd03a1a0ba4ed8997    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Nov 2024 14:21:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Nov 2024 14:21:17 +0900    

In 17~, age(xid) and mxid_age(xid) were listed as deprecated.  Based on  
the discussion that led to 48b5aa3143, this is not intentional as this  
could break many existing monitoring queries.  Note that vacuumdb also  
uses both of them.  
  
In 16, both functions were listed under "Control Data Functions", which  
is incorrect, so let's move them to the list of functions related to  
transaction IDs and snapshots.  
  
Author: Bertrand Drouvot  
Discussion: https://postgr.es/m/Zzr2zZFyeFKXWe8a@ip-10-97-1-34.eu-west-3.compute.internal  
Discussion: https://postgr.es/m/20231114013224.4z6oxa6p6va33rxr@awork3.anarazel.de  
Backpatch-through: 16  

commit   : f286f64bcf01106fc08ea1c14252ae2c26b7d189    
  
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