PostgreSQL 16.4 commit log

commit   : 2caa85f4aae689e6f6721d7363b4c66a2a6417d6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2024 16:05:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2024 16:05:35 -0400    

commit   : c04778592d6db6197819f95028347af135709e4b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2024 14:03:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2024 14:03:20 -0400    

Security: CVE-2024-7348  

commit   : 6aba85a4b0a0e60126cc7c598b3e010e272516ec    
  
author   : Masahiko Sawada <[email protected]>    
date     : Mon, 5 Aug 2024 06:05:28 -0700    
  
committer: Masahiko Sawada <[email protected]>    
date     : Mon, 5 Aug 2024 06:05:28 -0700    

When pg_dump retrieves the list of database objects and performs the  
data dump, there was possibility that objects are replaced with others  
of the same name, such as views, and access them. This vulnerability  
could result in code execution with superuser privileges during the  
pg_dump process.  
  
This issue can arise when dumping data of sequences, foreign  
tables (only 13 or later), or tables registered with a WHERE clause in  
the extension configuration table.  
  
To address this, pg_dump now utilizes the newly introduced  
restrict_nonsystem_relation_kind GUC parameter to restrict the  
accesses to non-system views and foreign tables during the dump  
process. This new GUC parameter is added to back branches too, but  
these changes do not require cluster recreation.  
  
Back-patch to all supported branches.  
  
Reviewed-by: Noah Misch  
Security: CVE-2024-7348  
Backpatch-through: 12  

commit   : d0311064041ad02b488b19caa7dd830ffd8e912a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2024 12:16:19 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2024 12:16:19 +0200    

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

commit   : 6804dbe255f6f77c6a29abda29355b4eb3c4a86d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2024 13:38:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2024 13:38:59 -0400    

commit   : ee219ee8c40d88e7a0ef52c3c1b76c90bbd0d164    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Aug 2024 16:24:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Aug 2024 16:24:17 -0400    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : 91f498fdec14888d58190021fc125ec468d3047b    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 13 May 2024 07:55:20 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 13 May 2024 07:55:20 +1200    

Back-patch of commit cff4e5a3 to 15 and 16, per request from Oleg  
Tselebrovskiy.  Original commit message:  
  
On other Windows build farm animals it is already skipped because they  
don't use UTF-8 encoding.  On "hamerkop", UTF-8 is used, and then the  
test fails.  
  
It is not clear to me (a non-Windows person looking only at buildfarm  
evidence) whether Windows is less sophisticated than other OSes and  
doesn't know how to downcase Turkish İ with the standard Unicode  
database, or if it is more sophisticated than other systems and uses  
locale-specific behavior like ICU does.  
  
Whichever the reason, the result is the same: we need to skip the test  
on Windows, just as we already do for ICU, at least until a  
Windows-savvy developer comes up with a better idea.  The technique for  
detecting the OS is borrowed from collate.windows.win1252.sql.  
  
This was anticipated by commit c2e8bd27, but the problem only surfaced  
when Windows build farm animals started using Meson.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGJ1LeC3aE2qQYTK95rFVON3ZVoTQpTKJqxkHdtEyawH4A%40mail.gmail.com  

commit   : 0540b5fd43d0617f413634c5cf492202a9bd4771    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 1 Aug 2024 17:45:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 1 Aug 2024 17:45:02 +0900    

We store tuples into the portal's tuple store for a PORTAL_ONE_MOD_WITH  
query as well.  
  
Back-patch to all supported branches.  
  
Reviewed by Andy Fan.  
  
Discussion: https://postgr.es/m/CAPmGK14HVYBZYZtHabjeCd-e31VT%3Dwx6rQNq8QfehywLcpZ2Hw%40mail.gmail.com  

commit   : 33187ab5984fcbb4afc0999e478b3e965c4262ab    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 20:54:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 20:54:59 -0400    

This reverts commit 849326e49a5dd56941eb8fb4699130c301bff303.  
  
Some buildfarm animals are failing with "cannot change  
"client_encoding" during a parallel operation".  It looks like  
assign_client_encoding is unhappy at being asked to roll back a  
client_encoding setting after a parallel worker encounters a  
failure.  There must be more to it though: why didn't I see this  
during local testing?  In any case, it's clear that moving the  
RestoreGUCState() call is not as side-effect-free as I thought.  
Given that the bug f5f30c22e intended to fix has gone unreported  
for years, it's not something that's urgent to fix; I'm not  
willing to risk messing with it further with only days to our  
next release wrap.  

commit   : 849326e49a5dd56941eb8fb4699130c301bff303    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 18:54:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2024 18:54:10 -0400    

Parallel workers failed after a sequence like  
	BEGIN;  
	CREATE USER foo;  
	SET SESSION AUTHORIZATION foo;  
because check_session_authorization could not see the uncommitted  
pg_authid row for "foo".  This is because we ran RestoreGUCState()  
in a separate transaction using an ordinary just-created snapshot.  
The same disease afflicts any other GUC that requires catalog lookups  
and isn't forgiving about the lookups failing.  
  
To fix, postpone RestoreGUCState() into the worker's main transaction  
after we've set up a snapshot duplicating the leader's.  This affects  
check_transaction_isolation and check_transaction_deferrable, which  
think they should only run during transaction start.  Make them  
act like check_transaction_read_only, which already knows it should  
silently accept the value when InitializingParallelWorker.  
  
Per bug #18545 from Andrey Rachitskiy.  Back-patch to all  
supported branches, because this has been wrong for awhile.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a459e583e06b640597c2e24ab6043a0701a5a545    
  
author   : David Rowley <[email protected]>    
date     : Thu, 1 Aug 2024 01:26:55 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 1 Aug 2024 01:26:55 +1200    

Prior to this commit, the docs for enable_partitionwise_aggregate and  
enable_partitionwise_join mentioned the additional overheads enabling  
these causes for the query planner, but they mentioned nothing about the  
possible surge in work_mem-consuming executor nodes that could end up in  
the final plan.  Dimitrios reported the OOM killer intervened on his  
query as a result of using enable_partitionwise_aggregate=on.  
  
Here we adjust the docs to mention the possible increase in the number of  
work_mem-consuming executor nodes that can appear in the final plan as a  
result of enabling these GUCs.  
  
Reported-by: Dimitrios Apostolou  
Reviewed-by: Ashutosh Bapat  
Discussion: https://postgr.es/m/3603c380-d094-136e-e333-610914fb3e80%40gmx.net  
Discussion: https://postgr.es/m/CAApHDvoZ0_yqwPFEpb6h261L76BUpmh5GxBQq0LeRzQ5Jh3zzg@mail.gmail.com  
Backpatch-through: 12, oldest supported version  

commit   : 403cbd21081939563ec79d100a83b168afcf0300    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 30 Jul 2024 16:23:20 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 30 Jul 2024 16:23:20 -0700    

strxfrm() is not guaranteed to return the exact number of bytes needed  
to store the result; it may return a higher value.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 16  

commit   : 9d198f4d3e3bee1b2f392c1466728f6d19c89ada    
  
author   : Melanie Plageman <[email protected]>    
date     : Mon, 29 Jul 2024 15:37:32 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Mon, 29 Jul 2024 15:37:32 -0400    

01e2b7f0fd02a44e introduced a test that vacuum correctly removes tuples  
older than OldestXmin. The same commit was backpatched on 14-16, but 16  
is the only version with meson and the test was mistakenly left off of  
the recovery test meson build file. Add it now.  
  
Discussion: https://postgr.es/m/CAAKRu_bWmMjmqL%2BOZ2duEQ80u7cRvpsExLNZNjzk-pXX5skwMQ%40mail.gmail.com  

commit   : 571e0ee40ebdaf0c75b11756620c9c9d453cc644    
  
author   : Melanie Plageman <[email protected]>    
date     : Mon, 29 Jul 2024 15:37:26 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Mon, 29 Jul 2024 15:37:26 -0400    

01e2b7f0fd02a44e introduced a test which generated dead tuples for  
vacuum with an UPDATE. The test only required enough dead TIDs for two  
rounds of index vacuuming. This can be accomplished with a DELETE  
instead of an UPDATE -- which generates about 50% less WAL and makes the  
test 20% faster in many cases. The test takes several seconds (more on  
slow buildfarm animals) because we need quite a few tuples to trigger  
two rounds of index vacuuming; so it is worth a follow-on commit to  
speed it up.  
  
Suggested-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAAKRu_bWmMjmqL%2BOZ2duEQ80u7cRvpsExLNZNjzk-pXX5skwMQ%40mail.gmail.com  
Backpatch-through: 14, the first version containing this test.  

commit   : 6f6b0f193db4f850a94aeabf363bf03bd0642e60    
  
author   : David Rowley <[email protected]>    
date     : Sun, 28 Jul 2024 22:23:54 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sun, 28 Jul 2024 22:23:54 +1200    

pg_size_pretty(bigint) would return the value in bytes rather than PB  
for the smallest-most bigint value.  This happened due to an incorrect  
assumption that the absolute value of -9223372036854775808 could be  
stored inside a signed 64-bit type.  
  
Here we fix that by instead storing that value in an unsigned 64-bit type.  
  
This bug does exist in versions prior to 15 but the code there is  
sufficiently different and the bug seems sufficiently non-critical that  
it does not seem worth risking backpatching further.  
  
Author: Joseph Koshakow <[email protected]>  
Discussion: https://postgr.es/m/CAAvxfHdTsMZPWEHUrZ=h3cky9Ccc3Mtx2whUHygY+ABP-mCmUw@mail.gmail.com  
Backpatch-through: 15  

commit   : c53016860b8e9c7d511efa86d6368456340343f5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 28 Jul 2024 09:12:00 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 28 Jul 2024 09:12:00 +0200    

Commit 453c4687377 introduced a use of strerror() into libpq, but that  
is not thread-safe.  Fix by using strerror_r() instead.  
  
In passing, update some of the code comments added by 453c4687377, as  
we have learned more about the reason for the change in OpenSSL that  
started this.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: Discussion: https://postgr.es/m/[email protected]  

commit   : 1091f8e0a48bf934e73260501799ce49405c67cf    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:16 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:16 +0300    

To build with -Dreadline=enabled one can use either readline or  
libedit. The -Dlibedit_preferred flag is supposed to control the order  
of names to lookup.  This works fine when either both libraries are  
present or -Dreadline is set to auto. However, explicitly enabling  
readline with only libedit present, but not setting libedit_preferred,  
or alternatively enabling readline with only readline present, but  
setting libedit_preferred, too, are both broken. This is because  
cc.find_library will throw an error for a not found dependency as soon  
as the first required dependency is checked, thus it's impossible to  
fallback to the alternative.  
  
Here we only check the second of the two dependencies for  
requiredness, thus we only fail when none of the two can be found.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : 7f61882b638a7c4caa88137d964d04052829dd38    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:14 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:14 +0300    

Passing an absolute bindir/libdir will install the binaries and  
libraries to <build>/tmp_install/<bindir> and  
<build>/tmp_install/<libdir> respectively.  
  
This path is correctly passed to the regression test suite via  
configure/make, but not via meson, yet. This is because the "/"  
operator in the following expression throws away the whole left side  
when the right side is an absolute path:  
  
    test_install_location / get_option('libdir')  
  
This was already correctly handled for dir_prefix, which is likely  
absolute as well. This patch handles both bindir and libdir in the  
same way - prefixing absolute paths with the tmp_install path  
correctly.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : 23be5206327cc09a870db346545f7a6a9e2485b3    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:11 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:11 +0300    

Some distributions put clang into a different path than the llvm  
binary path.  
  
For example, this is the case on NixOS / nixpkgs, which failed to find  
clang with meson before this patch.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : cc90d7823a6e888f5a50b98367b315a055d16895    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:08 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 27 Jul 2024 13:53:08 +0300    

The upstream name for the ossp-uuid package / pkg-config file is  
"uuid". Many distributions change this to be "ossp-uuid" to not  
conflict with e2fsprogs.  
  
This lookup fails on distributions which don't change this name, for  
example NixOS / nixpkgs. Both "ossp-uuid" and "uuid" are also checked  
in configure.ac.  
  
Author: Wolfgang Walther  
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut  
Reviewed-by: Tristan Partin  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : 441eba34dfc573f79c17501cc85c095bf300b8e3    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 16:29:52 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 16:29:52 +0200    

Commit 274bbced85 omitted the required changes for the MSVC build  
system in v16 through v12. Per buildfarm animal hamerkop.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 83b4a6358b0a1f2637872340fd072b3c42258747    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 16:29:47 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 16:29:47 +0200    

Commit 274bbced85383e831dde accidentally placed the pg_config.h.in  
for SSL_CTX_set_num_tickets on the wrong line wrt where autoheader  
places it.  Fix by re-arranging and backpatch to the same level as  
the original commit.  
  
Reported-by: Marina Polyakova <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : cc606afce1fb5c931469949f9ed8b17ec04668fb    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 11:09:45 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 26 Jul 2024 11:09:45 +0200    

OpenSSL supports two types of session tickets for TLSv1.3, stateless  
and stateful. The option we've used only turns off stateless tickets  
leaving stateful tickets active. Use the new API introduced in 1.1.1  
to disable all types of tickets.  
  
Backpatch to all supported versions.  
  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Reported-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : 67ab6ed4182c46077cbcf6e126484fc5e786c6eb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2024 19:52:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2024 19:52:08 -0400    

In the syntax synopses for SELECT, INSERT, UPDATE, etc,  
SELECT ... and RETURNING ... targetlists were missing { ... }  
braces around an OR (|) operator.  That allows misinterpretation  
which could lead to confusion.  
  
David G. Johnston, per gripe from [email protected].  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : daca4f1419e8a47d19fab107fbe6e3bc63013983    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 14:46:01 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 14:46:01 +1200    

Commit d01ce180 invented a new way to find the latest MacPorts version.  
By bad luck, a new beta release has just been published, and it seems  
to lack some packages we need.  Go back to searching for this specific  
version for now.  We still search with a pattern so that we can find the  
package for the running version of macOS, but for now we always look for  
2.9.3.  The code to do that had been anticipated already in a commented  
out line, I just didn't expect to have to use it so soon...  
  
Also include the whole MacPorts installation script in the cache key, so  
that changes to the script cause a fresh installation.  This should make  
it a bit easier to reason about the effect of changes on cached state in  
github accounts using CI, when we make adjustments.  
  
Back-patch to 15, like d01ce180.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com  

commit   : 9302f6fa58bad6bc7ffbe17b8980e022bf1116d8    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 11:26:48 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 25 Jul 2024 11:26:48 +1200    

1.  Previously we were using ghcr.io/cirruslabs/macos-XXX-base:latest  
images, but Cirrus has started ignoring that and using a particular  
image, currently ghcr.io/cirruslabs/macos-runner:sonoma, for github  
accounts using free CI resources (as opposed to dedicated runner  
machines, as cfbot uses).  Let's just ask for that image anyway, to stay  
in sync.  
  
2.  Instead of hard-coding a MacPorts installation URL, deduce it from  
the running macOS version and the available releases.  This removes the  
need to keep the ci_macports_packages.sh in sync with .cirrus.task.yml,  
and to advance the MacPorts version from time to time.  
  
3.  Change the cache key we use to cache the whole macports installation  
across builds to include the OS major version, to trigger a fresh  
installation when appropriate.  
  
Back-patch to 15 where CI began.  
  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com  

commit   : 7c32f2222f9919316bb7f104f271440039b2b07d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 14:13:55 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 14:13:55 +0200    

Per complaint from Grant Gryczan.  
  
It's a very old typo; backpatch all the way back.  
  
Author: Laurenz Albe <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 084814d888b163b20ab26674108363e3ef179769    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 12:38:18 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 24 Jul 2024 12:38:18 +0200    

We don't allow inheritance parents as partitions, and have checks to  
prevent this; but if a table _was_ in the past an inheritance parents  
and all their children are removed, the pg_class.relhassubclass flag  
may remain set, which confuses the partition pruning code (most  
obviously, it results in an assertion failure; in production builds it  
may be worse.)  
  
Fix by resetting relhassubclass on attach.  
  
Backpatch to all supported versions.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : a57d168653900903e8b1b4fe91d62de2c2f2693d    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 23 Jul 2024 21:59:02 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 23 Jul 2024 21:59:02 -0500    

When provided an empty initial array, array_set_slice() fails to  
check for overflow when computing the new array's dimensions.  
While such overflows are ordinarily caught by ArrayGetNItems(),  
commands with the following form are accepted:  
  
	INSERT INTO t (i[-2147483648:2147483647]) VALUES ('{}');  
  
To fix, perform the hazardous computations using overflow-detecting  
arithmetic routines.  As with commit 18b585155a, the added test  
cases generate errors that include a platform-dependent value, so  
we again use psql's VERBOSITY parameter to suppress printing the  
message text.  
  
Reported-by: Alexander Lakhin  
Author: Joseph Koshakow  
Reviewed-by: Jian He  
Discussion: https://postgr.es/m/31ad2cd1-db94-bdb3-f91a-65ffdb4bef95%40gmail.com  
Backpatch-through: 12  

commit   : 74e15462848de9cc9c302a8f6e12c3b04288b6a1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2024 19:43:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2024 19:43:12 -0400    

We were not being clear about which variants of the "direction"  
clause are permitted in MOVE.  Also, the text seemed to be  
written with only the FETCH/MOVE NEXT case in mind, so it  
didn't apply very well to other variants.  
  
Also, document that "MOVE count IN cursor" only works if count  
is a constant.  This is not the whole truth, because some other  
cases such as a parenthesized expression will also work, but  
we want to push people to use "MOVE FORWARD count" instead.  
The constant case is enough to cover what we allow in plain SQL,  
and that seems sufficient to claim support for.  
  
Update a comment in pl_gram.y claiming that we don't document  
that point.  
  
Per gripe from Philipp Salvisberg.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 13c58ca51883da23e0884dfeedf5e172d5eea80c    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    

Particularly on windows it's useful to look up dependencies via cmake, instead  
of pkg-config. Meson supports doing so. Unfortunately the dependency names  
used by various projects often differs between their pkg-config and cmake  
files.  
  
This would look a lot neater if we could rely on meson >= 0.60.0...  
  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : 793a5bebebbedd925311ba95cb77e3fb9b704200    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    

This is necessary as ossp-uuid on windows installs neither a pkg-config nor a  
cmake dependency information. Nor is there another supported uuid  
implementation available on windows.  
  
Reported-by: Dave Page <[email protected]>  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : 2b4593379b818ee81193b113dab3acdc3191f08d    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    

This is required as MIT Kerberos does provide neither pkg-config nor cmake  
dependency information on windows.  
  
Reported-by: Dave Page <[email protected]>  
Reviewed-by: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where meson support was added  

commit   : cc50694c8d9604374c27f7a1899c4721031fc008    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 20 Jul 2024 13:51:09 -0700    

These were missing since the initial introduction of the meson based build, in  
e6927270cd18. As-is this is unlikely to cause an issue, but a future commit  
will add support for detecting gssapi without use of dependency(), which could  
fail due to this.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson based build was added  

commit   : fd958bbbdf20c7f29188ee6f2687773edf0228af    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 20 Jul 2024 13:40:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 20 Jul 2024 13:40:15 -0400    

If a view has some updatable and some non-updatable columns, we failed  
to verify updatability of any columns for which an INSERT or UPDATE  
on the view explicitly specifies a DEFAULT item (unless the view has  
a declared default for that column, which is rare anyway, and one  
would almost certainly not write one for a non-updatable column).  
This would lead to an unexpected "attribute number N not found in  
view targetlist" error rather than the intended error.  
  
Per bug #18546 from Alexander Lakhin.  This bug is old, so back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 34e9dce69c4687f8c22831d6b0a1f65fa40c83b1    
  
author   : Nathan Bossart <[email protected]>    
date     : Fri, 19 Jul 2024 11:52:32 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Fri, 19 Jul 2024 11:52:32 -0500    

None of the arithmetic functions for the the money type handle  
overflow.  This commit introduces several helper functions with  
overflow checking and makes use of them in the money type's  
arithmetic functions.  
  
Fixes bug #18240.  
  
Reported-by: Alexander Lakhin  
Author: Joseph Koshakow  
Discussion: https://postgr.es/m/18240-c5da758d7dc1ecf0%40postgresql.org  
Discussion: https://postgr.es/m/CAAvxfHdBPOyEGS7s%2Bxf4iaW0-cgiq25jpYdWBqQqvLtLe_t6tw%40mail.gmail.com  
Backpatch-through: 12  

commit   : 01e2b7f0fd02a44e1d13357b20fecd79919d9031    
  
author   : Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:44:42 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:44:42 -0400    

If vacuum fails to prune a tuple killed before OldestXmin, it will later  
find that tuple dead in lazy_scan_prune() and loop infinitely.  
  
Add a test reproducing this scenario to the recovery suite which creates  
a table on a primary, updates the table to generate dead tuples for  
vacuum, and then, during the vacuum, uses a replica to force  
GlobalVisState->maybe_needed on the primary to move backwards and  
precede the value of OldestXmin set at the beginning of vacuuming the  
table.  
  
This commit is separate from the fix in case there are test stability  
issues.  
  
Discussion of the bug: https://postgr.es/m/CAAKRu_Y_NJzF4-8gzTTeaOuUL3CcGoXPjXcAHbTTygT8AyVqag%40mail.gmail.com  
Discussion of the test: https://postgr.es/m/CAAKRu_apNU2MPBK96V%2BbXjTq0RiZ-%3DA4ZTaysakpx9jxbq1dbQ%40mail.gmail.com  
  
Author: Melanie Plageman  
Reviewed-by: Peter Geoghegan  

commit   : 06bf404cd07bd82f08a3000d5977080f945e70ca    
  
author   : Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:44:36 -0400    
  
committer: Melanie Plageman <[email protected]>    
date     : Fri, 19 Jul 2024 10:44:36 -0400    

If vacuum fails to remove a tuple with xmax older than  
VacuumCutoffs->OldestXmin and younger than GlobalVisState->maybe_needed,  
it will loop infinitely in lazy_scan_prune(), which compares tuples'  
visibility information to OldestXmin.  
  
Starting in version 14, which uses GlobalVisState for visibility testing  
during pruning, it is possible for GlobalVisState->maybe_needed to  
precede OldestXmin if maybe_needed is forced to go backward while vacuum  
is running. This can happen if a disconnected standby with a running  
transaction older than VacuumCutoffs->OldestXmin reconnects to the  
primary after vacuum initially calculates GlobalVisState and OldestXmin.  
  
Fix this by having vacuum always remove tuples older than OldestXmin  
during pruning. This is okay because the standby won't replay the tuple  
removal until the tuple is removable. Thus, the worst that can happen is  
a recovery conflict.  
  
Fixes BUG# 17257  
  
Back-patched in versions 14-17  
  
Author: Melanie Plageman  
  
Reviewed-by: Noah Misch, Peter Geoghegan, Robert Haas, Andres Freund, and Heikki Linnakangas  
Discussion: https://postgr.es/m/CAAKRu_Y_NJzF4-8gzTTeaOuUL3CcGoXPjXcAHbTTygT8AyVqag%40mail.gmail.com  

commit   : d97f2ee50e49046a984665fb72fa14a06bd58435    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 19 Jul 2024 13:15:03 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 19 Jul 2024 13:15:03 +0900    

Commit d844cd75a disallowed rewind in a non-scrollable cursor to resolve  
anomalies arising from such a cursor operation.  However, this failed to  
take into account the assumption in postgres_fdw that when rescanning a  
foreign relation, it can rewind the cursor created for scanning the  
foreign relation without specifying the SCROLL option, regardless of its  
scrollability, causing this error when it tried to do such a rewind in a  
non-scrollable cursor.  Fix by modifying postgres_fdw to instead  
recreate the cursor, regardless of its scrollability, when rescanning  
the foreign relation.  (If we had a way to check its scrollability, we  
could improve this by rewinding it if it is scrollable and recreating it  
if not, but we do not have it, so this commit modifies it to recreate it  
in any case.)  
  
Per bug #17889 from Eric Cyr.  Devrim Gunduz also reported this problem.  
Back-patch to v15 where that commit enforced the prohibition.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/17889-e8c39a251d258dda%40postgresql.org  
Discussion: https://postgr.es/m/b415ac3255f8352d1ea921cf3b7ba39e0587768a.camel%40gunduz.org  

commit   : 9cd365f28f31dc8ea9d8c10ec7abd658aa29fcf5    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 19 Jul 2024 10:21:24 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 19 Jul 2024 10:21:24 +0900    

For utility statements defined within a function, the query tree is  
copied to a PlannedStmt as utility commands do not require planning.  
However, the query ID was missing from the information passed down.  
  
This leads to plugins relying on the query ID like pg_stat_statements to  
not be able to track utility statements within function calls.  Tests  
are added to check this behavior, depending on pg_stat_statements.track.  
  
This is an old bug.  Now, query IDs for utilities are compiled using  
their parsed trees rather than the query string since v16  
(3db72ebcbe20), leading to less bloat with utilities, so backpatch down  
only to this version.  
  
Author: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/CAO6_XqrGp-uwBqi3vBPLuRULKkddjC7R5QZCgsFren=8E+m2Sg@mail.gmail.com  
Backpatch-through: 16  

commit   : 071ed76a06cfc42107bb3126cb6075c962879569    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 17 Jul 2024 10:35:50 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 17 Jul 2024 10:35:50 -0400    

Error was detected when testing use of libpq sessions instead of psql  
for polling queries.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches  

commit   : 212b0262d60e921d97f1b824734d2c607e49fa6d    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 15:17:31 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 15:17:31 -0700    

Oops.  
  
Reported-by: Nathan Bossart <[email protected]>  
Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan  
Backpatch: 12-, like 43cd30bcd1c  

commit   : be0fa5ba003ce1fb955211bead796ae97afbd2a4    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:02 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:02 -0700    

Bullseye is getting long in the tooth, upgrade to the current stable version.  
  
Backpatch to all versions with CI support, we don't want to generate CI images  
for multiple Debian versions.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com  
Backpatch: 15-, where CI was added  

commit   : 2ad3b9350f7338b9ba0327ccd307a0fbba2208dc    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:02 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 15 Jul 2024 09:26:02 -0700    

Before this change guc_var_compare() cast the input arguments to  
const struct config_generic *.  That's not quite right however, as the input  
on one side is often just a char * on one side.  
  
Instead just use char *, the first field in config_generic.  
  
This fixes a -Warray-bounds warning with some versions of gcc. While the  
warning is only known to be triggered for <= 15, the issue the warning points  
out seems real, so apply the fix everywhere.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Reported-by: Erik Rijkers <[email protected]>  
Suggested-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl  

commit   : 8fc4876147fb62825cd27712d25f90a4eebf44fb    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Jul 2024 13:49:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Jul 2024 13:49:46 -0400    

checkWellFormedRecursion would issue "missing recursive reference"  
if a WITH RECURSIVE query contained a single self-reference but  
that self-reference was inside a top-level WITH, ORDER BY, LIMIT,  
etc, rather than inside the second arm of the UNION as expected.  
We already intended to throw more-on-point errors for such cases,  
but those error checks must be done before examining the UNION arm  
in order to have the desired results.  So this patch need only  
move some code (and improve the comments).  
  
Per bug #18536 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e81deeefcac2a0de06f51e82405f63935f00e2bc    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 13 Jul 2024 08:09:33 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 13 Jul 2024 08:09:33 -0700    

ANALYZE sets relhassubclass=f when a partitioned table no longer has  
partitions.  An ANALYZE doing that proceeded to apply the inplace update  
of pg_class.reltuples to the old pg_class tuple instead of the new  
tuple, losing that reltuples=0 change if the ANALYZE committed.  
Non-partitioning inheritance trees were unaffected.  Back-patch to v14,  
where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced  
maintenance of partitioned table pg_class.reltuples.  
  
Reported by Alexander Lakhin.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 75f4ae2b8065ca7d29bec55f261828f794fbba1e    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 12 Jul 2024 18:29:15 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 12 Jul 2024 18:29:15 -0400    

The current code can have pg_isready unexpectedly succeed if there is a  
server running on the default port. To avoid this we delay running the  
test until after a node has been created but before it starts, and then  
use that node's port, so we are fairly sure there is nothing running on  
the port.  
  
Backpatch to all live branches.  

commit   : a622095bcc4d12c5ff3caa02756a8ab2e0813ed3    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 13 Jul 2024 14:59:46 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 13 Jul 2024 14:59:46 +1200    

Winsock only signals an FD_CLOSE event once if the other end of the  
socket shuts down gracefully.  Because each WaitLatchOrSocket() call  
constructs and destroys a new event handle every time, with unlucky  
timing we can lose it and hang.  We get away with this only if the other  
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled  
in that case.  
  
To fix this design flaw in our Windows socket support fundamentally,  
we'd probably need to rearchitect it so that a single event handle  
exists for the lifetime of a socket, or switch to completely different  
multiplexing or async I/O APIs.  That's going to be a bigger job  
and probably wouldn't be back-patchable.  
  
This brute force kludge closes the race by explicitly polling with  
MSG_PEEK before sleeping.  
  
Back-patch to all supported releases.  This should hopefully clear up  
some random build farm and CI hang failures reported over the years.  It  
might also allow us to try using graceful shutdown in more places again  
(reverted in commit 29992a6) to fix instability in the transmission of  
FATAL error messages, but that isn't done by this commit.  
  
Reported-by: Tom Lane <[email protected]>  
Tested-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us  

commit   : 34eb37f7921b0f0dd720570957858b9650dfc1ab    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 13:44:19 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 13:44:19 +0200    

Per buildfarm.  

commit   : 00a40e33c0a4b34e5c8456cd0b5ab4084bba78a0    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 12:54:01 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 12 Jul 2024 12:54:01 +0200    

When a partitioned table has an index that doesn't support a constraint,  
but a partition has an equivalent index that does, then a DETACH  
operation would misbehave: a crash in assertion-enabled systems (because  
we fail to find the constraint in the parent that we expect to), or a  
broken coninhcount value (-1) in production systems (because we blindly  
believe that we've successfully detached the parent).  
  
While we should reject an ATTACH of a partition with such an index, we  
have failed to do so in existing releases, so adding an error in stable  
releases might break the (unlikely) existing applications that rely on  
this behavior.  At this point I don't even want to reject them in  
master, because it'd break pg_upgrade if such databases exist, and there  
would be no easy way to fix existing databases without expensive index  
rebuilds.  
  
(Later on we could add ALTER TABLE ... ADD CONSTRAINT USING INDEX to  
partitioned tables, which would allow the user to fix such patterns.  At  
that point we could add more restrictions to prevent the problem from  
its root.)  
  
Also, add a test case that leaves one table in this condition, so that  
we can verify that pg_upgrade continues to work if we later decide to  
change the policy on the master branch.  
  
Backpatch to all supported branches.  
  
Co-authored-by: Tender Wang <[email protected]>  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2f3304ce133f4e9c0992ff72ece47093833da55d    
  
author   : Masahiko Sawada <[email protected]>    
date     : Thu, 11 Jul 2024 22:48:18 +0900    
  
committer: Masahiko Sawada <[email protected]>    
date     : Thu, 11 Jul 2024 22:48:18 +0900    

When creating and initializing a logical slot, the restart_lsn is set  
to the latest WAL insertion point (or the latest replay point on  
standbys). Subsequently, WAL records are decoded from that point to  
find the start point for extracting changes in the  
DecodingContextFindStartpoint() function. Since the initial  
restart_lsn could be in the middle of a transaction, the start point  
must be a consistent point where we won't see the data for partial  
transactions.  
  
Previously, when not building a full snapshot, serialized snapshots  
were restored, and the SnapBuild jumps to the consistent state even  
while finding the start point. Consequently, the slot's restart_lsn  
and confirmed_flush could be set to the middle of a transaction. This  
could lead to various unexpected consequences. Specifically, there  
were reports of logical decoding decoding partial transactions, and  
assertion failures occurred because only subtransactions were decoded  
without decoding their top-level transaction until decoding the commit  
record.  
  
To resolve this issue, the changes prevent restoring the serialized  
snapshot and jumping to the consistent state while finding the start  
point.  
  
On v17 and HEAD, a flag indicating whether snapshot restores should be  
skipped has been added to the SnapBuild struct, and SNAPBUILD_VERSION  
has been bumpded.  
  
On backbranches, the flag is stored in the LogicalDecodingContext  
instead, preserving on-disk compatibility.  
  
Backpatch to all supported versions.  
  
Reported-by: Drew Callahan  
Reviewed-by: Amit Kapila, Hayato Kuroda  
Discussion: https://postgr.es/m/2444AA15-D21B-4CCE-8052-52C7C2DAFE5C%40amazon.com  
Backpatch-through: 12  

commit   : f85c91a1867b45742bb28e4578ca2b4a0976383f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Jul 2024 20:15:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Jul 2024 20:15:52 -0400    

This back-patches HEAD commits 066e8ac6e, 6082b3d5d, e7192486d,  
and 896cd266f into supported branches.  Changes:  
  
* Use xmlAddChildList not xmlAddChild in XMLSERIALIZE  
(affects v16 and up only).  This was a flat-out coding mistake  
that we got away with due to lax checking in previous versions  
of xmlAddChild.  
  
* Use xmlParseInNodeContext not xmlParseBalancedChunkMemory.  
This is to dodge a bug in xmlParseBalancedChunkMemory in libxm2  
releases 2.13.0-2.13.2.  While that bug is now fixed upstream and  
will probably never be seen in any production-oriented distro, it is  
currently a problem on some more-bleeding-edge-friendly platforms.  
  
* Suppress "chunk is not well balanced" errors from libxml2,  
unless it is the only error.  This eliminates an error-reporting  
discrepancy between 2.13 and older releases.  This error is  
almost always redundant with previous errors, if not flat-out  
inappropriate, which is why 2.13 changed the behavior and why  
nobody's likely to miss it.  
  
Erik Wienhold and Tom Lane, per report from Frank Streitzig.  
  
Discussion: https://postgr.es/m/trinity-b0161630-d230-4598-9ebc-7a23acdb37cb-1720186432160@3c-app-gmx-bap25  
Discussion: https://postgr.es/m/trinity-361ba18b-541a-4fe7-bc63-655ae3a7d599-1720259822452@3c-app-gmx-bs01  

commit   : 0d483ad4cc4c4d4ebdbe456a5565f11fa137bd24    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 10 Jul 2024 15:56:07 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 10 Jul 2024 15:56:07 +0900    

The I/O timing information collected when track_io_timing is  
enabled is now documented to appear in the pg_stat_io view,  
which was previously not mentioned.  
  
This commit also enhances the description of track_io_timing  
to clarify that it monitors not only block read and write  
but also block extend and fsync operations. Additionally,  
the description of track_wal_io_timing has been improved  
to mention both WAL write and WAL fsync monitoring.  
  
Backpatch to v16 where pg_stat_io was added.  
  
Author: Hajime Matsunaga  
Reviewed-by: Melanie Plageman, Nazir Bilal Yavuz, Fujii Masao  
Discussion: https://postgr.es/m/TYWPR01MB10742EE4A6F34C33061429D38A4D52@TYWPR01MB10742.jpnprd01.prod.outlook.com  

commit   : 4ac08251eb3db0de3924c788d81a776cc6008edd    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 13:46:21 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 13:46:21 -0400    

This reverts commit e9f15bc9. Instead of a hacky solution that didn't  
work on Windows, we avoid trying to move the directory possibly across  
drives, and instead remove it and recreate it in the new location.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to release 14 like the previous patch.  

commit   : 2e9dfa5e02e63732937fca270bbee77660401b04    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 11:18:06 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 11:18:06 -0400    

If we choose ports in the range typically used for ephemeral ports there  
is a danger of encountering a port conflict due to a race condition  
between the time we choose the port in a range below that typically used  
to allocate ephemeral ports, but higher than the range typically used by  
well known services.  
  
Author: Jelte Fenema-Nio, with some editing by me.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches (12 and up)  

commit   : 85242f9cbce2f9b8c728423a863037aa455e980f    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 05:51:26 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 8 Jul 2024 05:51:26 -0400    

Currently they are started in unix socket mode in ost cases, and then  
converted to run in TCP mode. This can result in port collisions, and  
there is no virtue in startng in unix socket mode, so start as we will  
be going on.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches (12 and up).  

commit   : f7aec8c1df904888e6fc0e817e460c73aad4cbd2    
  
author   : Dean Rasheed <[email protected]>    
date     : Mon, 8 Jul 2024 17:52:52 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Mon, 8 Jul 2024 17:52:52 +0100    

The numeric round() and trunc() functions clamp the scale argument to  
the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much  
smaller than the actual allowed range of type numeric. As a result,  
they return incorrect results when asked to round/truncate more than  
2000 digits before or after the decimal point.  
  
Fix by using the correct upper and lower scale limits based on the  
actual allowed (and documented) range of type numeric.  
  
While at it, use the new NUMERIC_WEIGHT_MAX constant instead of  
SHRT_MAX in all other overflow checks, and fix a comment thinko in  
power_var() introduced by e54a758d24 -- the minimum value of  
ln_dweight is -NUMERIC_DSCALE_MAX (-16383), not -SHRT_MAX, though this  
doesn't affect the point being made in the comment, that the resulting  
local_rscale value may exceed NUMERIC_MAX_DISPLAY_SCALE (1000).  
  
Back-patch to all supported branches.  
  
Dean Rasheed, reviewed by Joel Jacobson.  
  
Discussion: https://postgr.es/m/CAEZATCXB%2BrDTuMjhK5ZxcouufigSc-X4tGJCBTMpZ3n%3DxxQuhg%40mail.gmail.com  

commit   : 507f2347e7f5257200e5630a0e0c9d0e33be2498    
  
author   : Richard Guo <[email protected]>    
date     : Mon, 8 Jul 2024 10:30:28 +0900    
  
committer: Richard Guo <[email protected]>    
date     : Mon, 8 Jul 2024 10:30:28 +0900    

For an inner_unique join, we always assume that the executor will stop  
scanning for matches after the first match.  Therefore, for a mergejoin  
that is inner_unique and whose mergeclauses are sufficient to identify a  
match, we set the skip_mark_restore flag to true, indicating that the  
executor need not do mark/restore calls.  However, merge-right-anti-join  
did not get this memo and continues scanning the inner side for matches  
after the first match.  If there are duplicates in the outer scan, we  
may incorrectly skip matching some inner tuples, which can lead to wrong  
results.  
  
Here we fix this issue by ensuring that merge-right-anti-join also  
advances to next outer tuple after the first match in inner_unique  
cases.  This also saves cycles by avoiding unnecessary scanning of inner  
tuples after the first match.  
  
Although hash-right-anti-join does not suffer from this wrong results  
issue, we apply the same change to it as well, to help save cycles for  
the same reason.  
  
Per bug #18522 from Antti Lampinen, and bug #18526 from Feliphe Pozzer.  
Back-patch to v16 where right-anti-join was introduced.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/[email protected]  

commit   : 49e29cbe8cbcb6bd4ac6c5dc64b1ad27844c1b5c    
  
author   : David Rowley <[email protected]>    
date     : Sat, 6 Jul 2024 14:00:29 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sat, 6 Jul 2024 14:00:29 +1200    

This only affects MEMORY_CONTEXT_CHECKING builds.  
  
This fixes an off-by-one issue in GenerationRealloc() where the  
fast-path code which tries to reuse the existing allocation if the  
existing chunk is >= the new requested size.  The code there thought it  
was always ok to use the existing chunk, but when oldsize == size there  
isn't enough space to store the sentinel byte.  If both sizes matched  
exactly set_sentinel() would overwrite the first byte beyond the chunk  
and then subsequent GenerationRealloc() calls could then fail the  
Assert(chunk->requested_size < oldsize) check which is trying to ensure  
the chunk is large enough to store the sentinel.  
  
The same issue does not exist in aset.c as the sentinel checking code  
only adds a sentinel byte if there's enough space in the chunk.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16, where the problem was introduced by 0e480385e  

commit   : 31423bc4489d03112343395e94c9330e44983beb    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 6 Jul 2024 10:24:49 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 6 Jul 2024 10:24:49 +1200    

macOS 15's SDK pulls in headers related to <regex.h> when we include  
<xlocale.h>.  This causes our own regex_t implementation to clash with  
the OS's regex_t implementation.  Luckily our function names already had  
pg_ prefixes, but the macros and typenames did not.  
  
Include <regex.h> explicitly on all POSIX systems, and fix everything  
that breaks.  Then we can prove that we are capable of fully hiding and  
replacing the system regex API with our own.  
  
1.  Deal with standard-clobbering macros by undefining them all first.  
POSIX says they are "symbolic constants".  If they are macros, this  
allows us to redefine them.  If they are enums or variables, our macros  
will hide them.  
  
2.  Deal with standard-clobbering types by giving our types pg_  
prefixes, and then using macros to redirect xxx_t -> pg_xxx_t.  
  
After including our "regex/regex.h", the system <regex.h> is hidden,  
because we've replaced all the standard names.  The PostgreSQL source  
tree and extensions can continue to use standard prefix-less type and  
macro names, but reach our implementation, if they included our  
"regex/regex.h" header.  
  
Back-patch to all supported branches, so that macOS 15's tool chain can  
build them.  
  
Reported-by: Stan Hu <[email protected]>  
Suggested-by: Tom Lane <[email protected]>  
Tested-by: Aleksander Alekseev <[email protected]>  
Discussion: https://postgr.es/m/CAMBWrQnEwEJtgOv7EUNsXmFw2Ub4p5P%2B5QTBEgYwiyjy7rAsEQ%40mail.gmail.com  

commit   : 5c25f34d4da2669c32c983cab9c7104aaf119dc1    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 Jul 2024 13:23:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 Jul 2024 13:23:32 -0400    

State explicitly that the coordinates in our geometric data types are  
float8.  Also explain that polygons store their bounding box.  
  
While here, fix the table of geometric data types to show type  
"line"'s size correctly: it's 24 bytes not 32.  This has somehow  
escaped notice since that table was made in 1998.  
  
Per suggestion from Sebastian Skałacki.  The size error seems  
important enough to justify back-patching.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 678b5455830c697e8200de175373afb0d6fcaffc    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Thu, 4 Jul 2024 11:38:37 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Thu, 4 Jul 2024 11:38:37 +0200    

The ssl_prefer_server_ciphers setting is quite important from a  
security point of view, so simply stating that older versions  
doesn't have it isn't very helpful.  This adds the version when  
the GUC was added to help readers.  
  
Backpatch to all supported versions since this setting has been  
around since 9.4.  
  
Reviewed-by: Peter Eisentraut <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v12  

commit   : 7768b6569de95de7517bd6520acbe6e599fc6601    
  
author   : Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 15:09:59 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Fri, 28 Jun 2024 15:09:59 +0900    

JSON_OBJECT(), JSON_OBJETAGG(), JSON_ARRAY(), and JSON_ARRAYAGG()  
added in 7081ac46ace are not transformed into direct calls to  
user-defined functions as the comments claim. Fix by mentioning  
instead that they are transformed into JsonConstructorExpr nodes,  
which may call them, for example, for the *AGG() functions.  
  
Reported-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/058c856a-e090-ac42-ff00-ffe394f52a87%40gmail.com  
Backpatch-through: 16  

commit   : 54a7b21b3a9dc4c8be5f7fec47e435ce5b1772bb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 1 Jul 2024 12:21:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 1 Jul 2024 12:21:07 -0400    

ProcessIncomingNotify is called from the main processing loop that  
normally runs in MessageContext.  That outer-loop code assumes that  
whatever it allocates will be cleaned up when we're done processing  
the current client message --- but if we service a notify interrupt,  
then whatever gets allocated before the next switch into  
MessageContext will be permanently leaked in TopMemoryContext,  
because CommitTransactionCommand sets CurrentMemoryContext to  
TopMemoryContext.  There are observable leaks associated with  
(at least) encoding conversion of incoming queries and parameters  
attached to Bind messages.  
  
sinval catchup interrupts have a similar problem.  There might be  
others, but I've not identified any other clear cases.  
  
To fix, take care to save and restore CurrentMemoryContext across  
the Start/CommitTransactionCommand calls in these functions.  
  
Per bug #18512 from wizardbrony.  Commit to back branches only;  
in HEAD, this was dealt with by the riskier but more thoroughgoing  
approach in commit 1afe31f03.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7857c8dc4481970c27a44a4d1073064ff674b1de    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 28 Jun 2024 09:33:40 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 28 Jun 2024 09:33:40 -0700    

Per buildfarm members prion and trilobite.  Back-patch to v12 (all  
supported versions), like commit  
0844b3968985447ed0a6937cfc8639e379da2fe6.  
  
Strategy reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e352ba7b750982417796955359af4e5c4f38d657    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    

Commit 2c03216d831160bedd72d45f712601b6f7d03f1c moved the tuple data  
from there to the buffer-0 data.  Back-patch to v12 (all supported  
versions), the plan for the next change to this struct.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e4afd7153bd80404bffc4d17b37451d7317ae53e    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:06 -0700    

This extends ad98fb14226ae6456fbaed7990ee7591cbe5efd2 to invals of  
inplace updates.  Trouble requires an inplace update of a catalog having  
a TOAST table, so only pg_database was at risk.  (The other catalog on  
which core code performs inplace updates, pg_class, has no TOAST table.)  
Trouble would require something like the inplace-inval.spec test.  
Consider GRANT ... ON DATABASE fetching a stale row from cache and  
discarding a datfrozenxid update that vac_truncate_clog() has already  
relied upon.  Back-patch to v12 (all supported versions).  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : fc8c25806e84c38f3920fd3507a389eac34d62a5    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

This has no user-visible, important consequences, since other sessions'  
catalog scans can't find the relation until we commit.  However, this  
unblocks introducing a rule about locks required to heap_update() a  
pg_class row.  CREATE TABLE has been acquiring this lock eventually, but  
it can heap_update() pg_class.relchecks earlier.  create_toast_table()  
has been acquiring only ShareLock.  Back-patch to v12 (all supported  
versions), the plan for the commit relying on the new rule.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 480b58fabd353015319f6621ff8c351bf3a6d520    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Commit 5b562644fec696977df4a82790064e8287927891 added a comment that  
SetRelationHasSubclass() callers must hold this lock.  When commit  
17f206fbc824d2b4b14480199ca9ff7dea417eda extended use of this column to  
partitioned indexes, it didn't take the lock.  As the latter commit  
message mentioned, we currently never reset a partitioned index to  
relhassubclass=f.  That largely avoids harm from the lock omission.  The  
cause for fixing this now is to unblock introducing a rule about locks  
required to heap_update() a pg_class row.  This might cause more  
deadlocks.  It gives minor user-visible benefits:  
  
- If an ALTER INDEX SET TABLESPACE runs concurrently with ALTER TABLE  
  ATTACH PARTITION or CREATE PARTITION OF, one transaction blocks  
  instead of failing with "tuple concurrently updated".  (Many cases of  
  DDL concurrency still fail that way.)  
  
- Match ALTER INDEX ATTACH PARTITION in choosing to lock the index.  
  
While not user-visible today, we'll need this if we ever make something  
set the flag to false for a partitioned index, like ANALYZE does today  
for tables.  Back-patch to v12 (all supported versions), the plan for  
the commit relying on the new rule.  In back branches, add  
LockOrStrongerHeldByMe() instead of adding a LockHeldByMe() parameter.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 112d055706bfe653685ec24552429a19830a7ef3    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

These commands already make the persistence of owned sequences follow  
owned table persistence changes.  They didn't lock those sequences.  
They lost the effect of nextval() calls that other sessions make after  
the ALTER TABLE command, before the ALTER TABLE transaction commits.  
Fix by acquiring the same lock that ALTER SEQUENCE SET { LOGGED |  
UNLOGGED } acquires.  This might cause more deadlocks.  Back-patch to  
v15, where commit 344d62fb9a978a72cf8347f0369b9ee643fd0b31 introduced  
unlogged sequences.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f8135d8b54ff68f0788779d86edd796efc330ff4    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

Most comments concern RELKIND_VIEW.  One addresses the ExecUpdate()  
"tupleid" parameter.  A later commit will rely on these facts, but they  
hold already.  Back-patch to v12 (all supported versions), the plan for  
that commit.  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dd8008e8ec956845a3a25060e596994192489f0a    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:05 -0700    

This covers both regular and inplace changes, since bugs arise at their  
intersection.  Where marked, these witness extant bugs.  Back-patch to  
v12 (all supported versions).  
  
Reviewed (in an earlier version) by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 288426902ee54a22d22ede769d14c5b7d4b59d99    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:04 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 27 Jun 2024 19:21:04 -0700    

This could have caused spurious failures only on SPARC Linux, because  
today's only todo_start tests for that platform.  Back-patch to v16,  
where Meson support first appeared.  
  
Reviewed by Robert Haas.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 07d66d3cc2a92f58a8c30a99ec7c9c68684900e9    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2024 14:43:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2024 14:43:59 -0400    

errfinish() assumes that the __FUNC__ and __FILE__ arguments it's  
passed are compile-time constant strings that can just be pointed  
to rather than physically copied.  However, it's possible for LLVM  
to generate code in which those pointers point into a dynamically  
loaded code segment.  If that segment gets unloaded before we're  
done with the ErrorData struct, we have dangling pointers that  
will lead to SIGSEGV.  In simple cases that won't happen, because we  
won't unload LLVM code before end of transaction.  But it's possible  
to happen if the error is thrown within end-of-transaction code run by  
_SPI_commit or _SPI_rollback, because since commit 2e517818f those  
functions clean up by ending the transaction and starting a new one.  
  
Rather than fixing this by adding pstrdup() overhead to every  
elog/ereport sequence, let's fix it by copying the risky pointers  
in CopyErrorData().  That solves it for _SPI_commit/_SPI_rollback  
because they use that function to preserve the error data across  
the transaction end/restart sequence; and it seems likely that  
any other code doing something similar would need to do that too.  
  
I'm suspicious that this behavior amounts to an LLVM bug (or a  
bug in our use of it?), because it implies that string constant  
references that should be pointer-equal according to a naive  
understanding of C semantics will sometimes not be equal.  
However, even if it is a bug and someday gets fixed, we'll have  
to cope with the current behavior for a long time to come.  
  
Report and patch by me.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b5b418b689ec5d3807b0eea34e58166191e18499    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:32 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:32 +0300    

We did not recover the subtransaction IDs of prepared transactions  
when starting a hot standby from a shutdown checkpoint. As a result,  
such subtransactions were considered as aborted, rather than  
in-progress. That would lead to hint bits being set incorrectly, and  
the subtransactions suddenly becoming visible to old snapshots when  
the prepared transaction was committed.  
  
To fix, update pg_subtrans with prepared transactions's subxids when  
starting hot standby from a shutdown checkpoint. The snapshots taken  
from that state need to be marked as "suboverflowed", so that we also  
check the pg_subtrans.  
  
Backport to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : e00a9a4c7bcae0f1b798b567bb37841ae7c6ff7d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:27 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 21:06:27 +0300    

This went unnoticed, because only a few existing callers of  
BackgroundPsql->query used the result, and the ones that did were not  
bothered by an extra newline. I noticed because I was about to add a  
new test that checks the result.  
  
Backport to all supported versions, since I just backported the  
BackgroundPsql facility to all supported versions too.  

commit   : 79228c0459817cfbf830395c77735d8f3bce3f47    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2024 19:51:47 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2024 19:51:47 +0200    

The first one was noticed by Tender Wang and introduced with  
8aba9322511f; the other one was newly introduced with dbca3469ebf8.  

commit   : 187b8991f70fc3d2a13dc709edd408a8df0be055    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 19:00:59 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 27 Jun 2024 19:00:59 +0300    

Backport the new BackgroundPsql modules and the constructor functions,  
background_psql() and interactive_psql, to all supported  
branches. That makes it easier to backpatch tests that use it.  
  
BackgroundPsql was introduced in version 16. On version 16, this  
commit backports just the new timeout argument from master (commit  
334f512f45). On older branches, the whole facility. This includes the  
change to `use warnings FATAL => 'all'`, which we haven't otherwise  
backported, but it seems good to keep the file identical across  
branches.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : b8f953d8d7bff6ca5d7fc8cb0f37a9d3d7a7462b    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 27 Jun 2024 11:19:57 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 27 Jun 2024 11:19:57 +0530    

In pgoutput, when converting the child table's tuple format to match the  
parent table's, we temporarily create a new slot to store the converted  
tuple. However, we missed to drop such temporary slots, leading to  
resource leakage.  
  
Reported-by: Bowen Shi  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 15  
Discussion: https://postgr.es/m/CAM_vCudv8dc3sjWiPkXx5F2b27UV7_YRKRbtSCcE-pv=cVACGA@mail.gmail.com  

commit   : 6f61d0e7e2f1395d0a2e06c52b36721cf1656a55    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 27 Jun 2024 09:44:51 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 27 Jun 2024 09:44:51 +0900    

When pgstats is initialized for a backend, it uses dsa_attach_in_place()  
without a "segment" provided.  Hence, no callback is registered to  
automatically release the DSA attached once a backend exits.  Not doing  
any cleanup causes the reference count of the pgstats DSA to  
continuously increment, at some point overflowing it (the more the  
number of connections, the faster it is to reach this state).  Once the  
reference count overflows and then gets back to 0, new backends are not  
able to attach to the pgstats DSA, failing startup.  
  
This issue is resolved by adding in the pgstats shutdown hook a call to  
dsa_release_in_place(), ensuring that the DSA attached at backend  
startup is correctly released, keeping the reference count at bay.  
  
The author of this patch has been able to see this issue on a server  
with a long uptime and a high connection turnover.  
  
Issue introduced by 5891c7a8ed8f, so backpatch down to 15.  
  
Author: Anthonin Bonnefoy  
Discussion: https://postgr.es/m/CAO6_XqqJbJBL=M7Ym13TcB4Xnq58vRa2jcC+gwEPBgbAda6B1Q@mail.gmail.com  
Backpatch-through: 15  

commit   : e7cbe5a85864a32b8a452cb19f32c5ebafbf6f2d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Jun 2024 18:31:15 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 21 Jun 2024 18:31:15 +0300    

1. TruncateMultiXact() performs the SLRU truncations in a critical  
section. Deleting the SLRU segments calls ForwardSyncRequest(), which  
will try to compact the request queue if it's full  
(CompactCheckpointerRequestQueue()). That in turn allocates memory,  
which is not allowed in a critical section. Backtrace:  
  
    TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File: "../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981  
    postgres: autovacuum worker template0(ExceptionalCondition+0x6e)[0x560a501e866e]  
    postgres: autovacuum worker template0(+0x5dce3d)[0x560a50217e3d]  
    postgres: autovacuum worker template0(ForwardSyncRequest+0x8e)[0x560a4ffec95e]  
    postgres: autovacuum worker template0(RegisterSyncRequest+0x2b)[0x560a50091eeb]  
    postgres: autovacuum worker template0(+0x187b0a)[0x560a4fdc2b0a]  
    postgres: autovacuum worker template0(SlruDeleteSegment+0x101)[0x560a4fdc2ab1]  
    postgres: autovacuum worker template0(TruncateMultiXact+0x2fb)[0x560a4fdbde1b]  
    postgres: autovacuum worker template0(vac_update_datfrozenxid+0x4b3)[0x560a4febd2f3]  
    postgres: autovacuum worker template0(+0x3adf66)[0x560a4ffe8f66]  
    postgres: autovacuum worker template0(AutoVacWorkerMain+0x3ed)[0x560a4ffe7c2d]  
    postgres: autovacuum worker template0(+0x3b1ead)[0x560a4ffecead]  
    postgres: autovacuum worker template0(+0x3b620e)[0x560a4fff120e]  
    postgres: autovacuum worker template0(+0x3b3fbb)[0x560a4ffeefbb]  
    postgres: autovacuum worker template0(+0x2f724e)[0x560a4ff3224e]  
    /lib/x86_64-linux-gnu/libc.so.6(+0x27c8a)[0x7f62cc642c8a]  
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f62cc642d45]  
    postgres: autovacuum worker template0(_start+0x21)[0x560a4fd16f31]  
  
To fix, bail out in CompactCheckpointerRequestQueue() without doing  
anything, if it's called in a critical section. That covers the above  
call path, as well as any other similar cases where  
RegisterSyncRequest might be called in a critical section.  
  
2. After fixing that, another problem became apparent: Autovacuum  
process doing that truncation can deadlock with the checkpointer  
process. TruncateMultiXact() sets "MyProc->delayChkptFlags |=  
DELAY_CHKPT_START". If the sync request queue is full and cannot be  
compacted, the process will repeatedly sleep and retry, until there is  
room in the queue. However, if the checkpointer is trying to start a  
checkpoint at the same time, and is waiting for the DELAY_CHKPT_START  
processes to finish, the queue will never shrink.  
  
More concretely, the autovacuum process is stuck here:  
  
    #0  0x00007fc934926dc3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6  
    #1  0x000056220b24348b in WaitEventSetWaitBlock (set=0x56220c2e4b50, occurred_events=0x7ffe7856d040, nevents=1, cur_timeout=<optimized out>) at ../src/backend/storage/ipc/latch.c:1570  
    #2  WaitEventSetWait (set=0x56220c2e4b50, timeout=timeout@entry=10, occurred_events=<optimized out>, occurred_events@entry=0x7ffe7856d040, nevents=nevents@entry=1,  
        wait_event_info=wait_event_info@entry=150994949) at ../src/backend/storage/ipc/latch.c:1516  
    #3  0x000056220b243224 in WaitLatch (latch=<optimized out>, latch@entry=0x0, wakeEvents=wakeEvents@entry=40, timeout=timeout@entry=10, wait_event_info=wait_event_info@entry=150994949)  
        at ../src/backend/storage/ipc/latch.c:538  
    #4  0x000056220b26cf46 in RegisterSyncRequest (ftag=ftag@entry=0x7ffe7856d0a0, type=type@entry=SYNC_FORGET_REQUEST, retryOnError=true) at ../src/backend/storage/sync/sync.c:614  
    #5  0x000056220af9db0a in SlruInternalDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1495  
    #6  0x000056220af9dab1 in SlruDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1566  
    #7  0x000056220af98e1b in PerformMembersTruncation (oldestOffset=<optimized out>, newOldestOffset=<optimized out>) at ../src/backend/access/transam/multixact.c:3006  
    #8  TruncateMultiXact (newOldestMulti=newOldestMulti@entry=3221225472, newOldestMultiDB=newOldestMultiDB@entry=4) at ../src/backend/access/transam/multixact.c:3201  
    #9  0x000056220b098303 in vac_truncate_clog (frozenXID=749, minMulti=<optimized out>, lastSaneFrozenXid=749, lastSaneMinMulti=3221225472) at ../src/backend/commands/vacuum.c:1917  
    #10 vac_update_datfrozenxid () at ../src/backend/commands/vacuum.c:1760  
    #11 0x000056220b1c3f76 in do_autovacuum () at ../src/backend/postmaster/autovacuum.c:2550  
    #12 0x000056220b1c2c3d in AutoVacWorkerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/autovacuum.c:1569  
  
and the checkpointer is stuck here:  
  
    #0  0x00007fc9348ebf93 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6  
    #1  0x00007fc9348fe353 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6  
    #2  0x000056220b40ecb4 in pg_usleep (microsec=microsec@entry=10000) at ../src/port/pgsleep.c:50  
    #3  0x000056220afb43c3 in CreateCheckPoint (flags=flags@entry=108) at ../src/backend/access/transam/xlog.c:7098  
    #4  0x000056220b1c6e86 in CheckpointerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/checkpointer.c:464  
  
To fix, add AbsorbSyncRequests() to the loops where the checkpointer  
waits for DELAY_CHKPT_START or DELAY_CHKPT_COMPLETE operations to  
finish.  
  
Backpatch to v14. Before that, SLRU deletion didn't call  
RegisterSyncRequest, which avoided this failure. I'm not sure if there  
are other similar scenarios on older versions, but we haven't had  
any such reports.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 96105ebfe21848c58e009c388da4ee7f513c0033    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jun 2024 15:56:32 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Jun 2024 15:56:32 +0200    

When detaching partition in concurrent mode, it's possible for partition  
descriptors to not match the set that was recently seen when the plan  
was made, causing an assertion failure or (in production builds) failure  
to construct a working plan.  The case that was reported involves  
prepared statements, but I think it may be possible to hit this bug  
without that too.  
  
The problem is that CreatePartitionPruneState is constructing a  
PartitionPruneState under the assumption that new partitions can be  
added, but never removed, but it turns out that this isn't true: a  
prepared statement gets replanned when the DETACH CONCURRENTLY session  
sends out its invalidation message, but if the invalidation message  
arrives after ExecInitAppend started, we would build a partition  
descriptor without the partition, and then CreatePartitionPruneState  
would refuse to work with it.  
  
CreatePartitionPruneState already contains code to deal with the new  
descriptor having more partitions than before (and behaving for the  
extra partitions as if they had been pruned), but doesn't have code to  
deal with less partitions than before, and it is naïve about the case  
where the number of partitions is the same.  We could simply add that a  
new stanza for less partitions than before, and in simple testing it  
works to do that; but it's possible to press the test scripts even  
further and hit the case where one partition is added and a partition is  
removed quickly enough that we see the same number of partitions, but  
they don't actually match, causing hangs during execution.  
  
To cope with both these problems, we now memcmp() the arrays of  
partition OIDs, and do a more elaborate mapping (relying on the fact  
that both OID arrays are in partition-bounds order) if they're not  
identical.  
  
Backpatch to 14, where DETACH CONCURRENTLY appeared.  
  
Reported-by: yajun Hu <[email protected]>  
Reviewed-by: Tender Wang <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3c469a939cf1cc95b136653e7c6e27e472dc0472    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 21 Jun 2024 09:49:30 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 21 Jun 2024 09:49:30 +0530    

Add a note in docs that generated columns are skipped for logical  
replication.  
  
Author: Peter Smith  
Reviewed-by: Peter Eisentraut  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAHut+PuXb1GLQztQkoWzYjSwkAZZ0dgCJaAHyJtZF3kmtcL=kA@mail.gmail.com  

commit   : 4f196667627055ce7c6b3e8d3e9a4f5f6a906b86    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Jun 2024 14:21:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Jun 2024 14:21:36 -0400    

afterTriggerInvokeEvents and AfterTriggerExecute have always  
treated it as an error if the trigger OID mentioned in a queued  
after-trigger event can't be found.  However, that fails to  
account for the edge case where the trigger's been dropped in  
the current transaction since queueing the event.  There seems  
no very good reason to disallow that case, so instead silently  
do nothing if the trigger OID can't be found.  
  
This does give up a little bit of bug-detection ability, but I don't  
recall that these error messages have ever actually revealed a bug,  
so it seems mostly theoretical.  Alternatives such as marking  
pending events DONE at the time of dropping a trigger would be  
complicated and perhaps introduce bugs of their own.  
  
Per bug #18517 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6143c9c03f7f43a1a16e2587c6f12aa7d81558c8    
  
author   : David Rowley <[email protected]>    
date     : Wed, 19 Jun 2024 10:21:00 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 19 Jun 2024 10:21:00 +1200    

In cost_memoize_rescan(), when calculating the hit_ratio using the calls  
and ndistinct estimations, if the value that was set in  
MemoizePath.calls had not been processed through clamp_row_est(), then it  
was possible that it was set to some non-integer value which could result  
in ndistinct being 1 higher than calls due to estimate_num_groups()  
performing clamp_row_est() on its input_rows.  This could result in  
hit_ratio values slightly below 0.0, which would cause an Assert failure.  
  
The value of MemoizePath.calls comes from the final parameter in the  
create_memoize_path() function, of which we only have one true caller of.  
That caller passes outer_path->rows.  All the core code I looked at  
always seems to call clamp_row_est() on the Path.rows, so there might  
have been no issues with any core Paths causing troubles here.  The bug  
report was about a CustomPath with a non-clamped row estimated.  
  
The misbehavior as a result of this seems to be mostly limited to the  
Assert() failing.  Aside from that, it seems the Memoize costs would  
just come out slightly higher than they should have, which is likely  
fairly harmless.  
  
Reported-by: Kohei KaiGai <[email protected]>  
Discussion: https://postgr.es/m/CAOP8fzZnTU+N64UYJYogb1hN-5hFP+PwTb3m_cnGAD7EsQwrKw@mail.gmail.com  
Reviewed-by: Richard Guo  
Backpatch-through: 14, where Memoize was introduced  

commit   : 06f81fed3cdd566c4c9767790e9965d17ffbd0c5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 14:30:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Jun 2024 14:30:59 -0400    

Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may  
insert some REDIRECT tuples.  This will typically happen in  
a transaction that lacks an XID, which leads either to assertion  
failure in spgFormDeadTuple or to insertion of a REDIRECT tuple  
with zero xid.  The latter's not good either, since eventually  
VACUUM will apply GlobalVisTestIsRemovableXid() to the zero xid,  
resulting in either an assertion failure or a garbage answer.  
  
In practice, since REINDEX CONCURRENTLY locks out index scans  
till it's done, it doesn't matter whether it inserts REDIRECTs  
or PLACEHOLDERs; and likewise it doesn't matter how soon VACUUM  
reduces such a REDIRECT to a PLACEHOLDER.  So in non-assert builds  
there's no observable problem here, other than perhaps a little  
index bloat.  But it's not behaving as intended.  
  
To fix, remove the failing Assert in spgFormDeadTuple, acknowledging  
that we might sometimes insert a zero XID; and guard VACUUM's  
GlobalVisTestIsRemovableXid() call with a test for valid XID,  
ensuring that we'll reduce such a REDIRECT the first time VACUUM  
sees it.  (Versions before v14 use TransactionIdPrecedes here,  
which won't fail on zero xid, so they really have no bug at all  
in non-assert builds.)  
  
Another solution could be to not create REDIRECTs at all during  
REINDEX CONCURRENTLY, making the relevant code paths treat that  
case like index build (which likewise knows that no concurrent  
index scans can be happening).  That would allow restoring the  
Assert in spgFormDeadTuple, but we'd still need the VACUUM change  
because redirection tuples with zero xid may be out there already.  
But there doesn't seem to be a nice way for spginsert() to tell that  
it's being called in REINDEX CONCURRENTLY without some API changes,  
so we'll leave that as a possible future improvement.  
  
In HEAD, also rename the SpGistState.myXid field to redirectXid,  
which seems less misleading (since it might not in fact be our  
transaction's XID) and is certainly less uninformatively generic.  
  
Per bug #18499 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b3255faaa27da3ccc1fca226f70cccefd27b1cea    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Sun, 16 Jun 2024 16:25:07 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Sun, 16 Jun 2024 16:25:07 +0900    

There was a small mistake in the create role manual.  
  
Author: Satoru Koizumi  
Reviewed-by: David G. Johnston  
Discussion: https://postgr.es/m/flat/20240616.112523.1208348667552014162.t-ishii%40sranhm.sra.co.jp  
Backpatch-through: 16  

commit   : 9cf4beb9e7adf3225c33df256c4e7d54805ec4f8    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2024 16:20:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2024 16:20:35 -0400    

DeleteInitPrivs did not get the memo about how, when dropping a  
whole object (with subid == 0), you should drop entries relating  
to its sub-objects too.  This is visible in the test_pg_dump test  
case if one drops the extension at the end: the entry for  
	GRANT SELECT(col1) ON regress_pg_dump_table TO public;  
was still present in pg_init_privs afterwards, although it was  
pointing to a dangling table OID.  
  
Noted while fooling with a fix for REASSIGN OWNED for pg_init_privs  
entries.  This bug is aboriginal in the pg_init_privs feature  
though, and there seems no reason not to back-patch the fix.  

commit   : 086ecd12bc1c27054ded1eeea5329e84e3f72c97    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 20:34:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 20:34:42 -0400    

The manual says clearly that punctuation in the input of  
websearch_to_tsquery() is ignored, except for the special cases  
of dashes and quotes.  However, this failed for cases like  
"(foo bar) or something", or in general an ISOPERATOR character  
in front of the "or".  We'd switch back to WAITOPERAND state,  
then ignore the operator character while remaining in that state,  
and then reach the "or" in WAITOPERAND state which (intentionally)  
makes us treat it as data.  
  
The fix is simple enough: if we see an ISOPERATOR character while in  
WAITOPERATOR state, we have to skip it while staying in that state.  
(We don't need to worry about other punctuation characters: those will  
be consumed as though they were words, but then rejected by lexizing.)  
  
In v14 and up (since commit eb086056f) we can simplify the code a bit  
more too, because there is no longer a reason for the WAITOPERAND  
state to distinguish between quoted and unquoted operands.  
  
Per bug #18479 from Manos Emmanouilidis.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d0b0454d3808c7d5294c548aa9f0ee137430e183    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 14 Jun 2024 09:26:35 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 14 Jun 2024 09:26:35 +0900    

The WAL writer is an auxiliary process, but its description in the  
glossary did not match that.  
  
This is inexact since d3014fff4cd4.  
  
Author: Masahiro Ikeda  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 82a931d3d2fe6c97c022399605413179b6c3c0aa    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 13:37:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2024 13:37:46 -0400    

The previous coding here assumed that we didn't need to recheck any  
of the querytree tests made in exec_simple_check_plan().  I think  
we supposed that those properties were fully determined by the  
syntax of the source text and hence couldn't change.  That is true  
for most of them, but at least hasTargetSRFs and hasAggs can change  
by dint of forcibly dropping an originally-referenced function and  
recreating it with new properties.  That leads to "unexpected plan  
node type" or similar failures.  
  
These tests are pretty cheap compared to the cost of replanning, so  
rather than sweat over exactly which properties need to be rechecked,  
let's just recheck them all.  Hence, factor out those tests into a new  
function exec_is_simple_query(), and rearrange callers as needed.  
  
A second problem in the same area was that if we failed during  
replanning or during exec_save_simple_expr(), we'd potentially  
leave behind now-dangling pointers to the old simple expression,  
potentially resulting in crashes later.  To fix, clear those pointers  
before replanning.  
  
The v12 code looks quite different in this area but still has the  
bug about needing to recheck query simplicity.  I chose to back-patch  
all of the plpgsql_simple.sql test script, which formerly didn't exist  
in this branch.  
  
Per bug #18497 from Nikita Kalinin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 566a7d9182de9c06b786a747dfd3d42a938299c7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 13 Jun 2024 19:01:30 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 13 Jun 2024 19:01:30 +0300    

The purpose of the function is to reduce the effective  
autovacuum_multixact_freeze_max_age if the multixact members SLRU is  
approaching wraparound, to make multixid freezing more aggressive.  
The returned value should therefore never be greater than plain  
autovacuum_multixact_freeze_max_age.  
  
Reviewed-by: Robert Haas  
Discussion: https://www.postgresql.org/message-id/[email protected]  
Backpatch-through: 12, all supported versions  

commit   : 32c5dc0ebe83e927c953c42ad79148a03933c6ba    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:38:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:38:48 -0400    

These are checks that are already skipped on other Windows systems.  
  
Backpatch to all live branches, as appropriate.  

commit   : a13c7ee87b0ab31ecbf1a9e9302ee48b52d1cf9a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:30:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 13 Jun 2024 07:30:10 -0400    

Required for Cygwin.  
  
Backpatch to release 16.  

commit   : b188e1bf75760fed76406a48c81bcd8ac6a8fda9    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2024 17:57:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2024 17:57:46 -0400    

infer_arbiter_indexes failed to renumber varnos in index expressions  
or predicates that it got from the catalogs.  This escaped detection  
up to now because the stored varnos in such trees will be 1, and an  
INSERT's result relation is usually the first rangetable entry,  
so that that was fine.  However, in cases such as inserting through  
an updatable view, it's not fine, leading to failure to match the  
expressions to the query with ensuing "there is no unique or exclusion  
constraint matching the ON CONFLICT specification" errors.  
  
Fix by copy-and-paste from get_relation_info().  
  
Per bug #18502 from Michael Wang.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bf78abebf3e5c827a48186b2b1388c691e16fafc    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 11 Jun 2024 11:38:45 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 11 Jun 2024 11:38:45 +0200    

When a partition is being detached in concurrent mode, it is possible  
for find_inheritance_children_extended() to return that partition in the  
list, and immediately after that receive an invalidation message that  
sets its relpartbound to NULL just before we read it.  (This can happen  
because table_open() reads invalidation messages.)  Currently we raise  
an error  
  ERROR:  missing relpartbound for relation %u  
about the situation, but that's bogus because the table is no longer a  
partition, so we shouldn't be complaining about it.  A better reaction  
is to retry the find_inheritance_children_extended call to get a new  
list, which will no longer have the partition being detached.  
  
Noticed while investigating bug #18377.  
  
Backpatch to 14, where DETACH CONCURRENTLY appeared.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c7972f12261717dfb1009096a45babcb2f9b5275    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 11 Jun 2024 09:27:06 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 11 Jun 2024 09:27:06 +0530    

The behavior for columns added later to the table for publications with no  
specified column lists was not clear.  
  
Reported-by: Koen De Groote  
Author: Peter Smith  
Reviewed-by: Vignesh C, Laurenz Albe  
Backpatch-through: 15  
Discussion: https://postgr.es/m/[email protected]  

commit   : f1f6ded66897efbf2ee520a8213a43251398ddf2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2024 16:45:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2024 16:45:56 -0400    

test_predtest() neglected to consider the possibility that  
SPI_plan_get_cached_plan would return NULL.  This led to a core  
dump if the input (incorrectly) contains more than one SQL  
command.  
  
While here, let's expend more than zero effort on the error  
message for this case and nearby ones.  
  
Per (half of) bug #18483 from Alexander Kozhemyakin.  
Back-patch to all supported branches, not because this is  
very significant (it's merely test scaffolding) but to make  
our world a bit safer for fuzz testing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8397f161e47c0b79075e015dd963e6db30e0d7a3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2024 14:50:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2024 14:50:09 -0400    

Normally this case isn't even reachable by non-superusers, since  
permissions checks prevent naming such a table.  However, it is  
possible to make it happen by altering a parent table whose child  
is another session's temp table.  
  
We definitely can't support any such ALTER that requires modifying  
the contents of such a table, since we lack access to the other  
session's temporary-buffer pool.  But there seems no good reason  
to allow it even if it'd only require changing catalog contents.  
One reason not to allow it is that we'd rather not expose the  
implementation-dependent behavior of whether a specific ALTER  
requires touching the table contents.  Another is that there may  
be (in future, even if not today) optimizations that assume that  
a session's own temp tables won't be modified by other sessions.  
  
Hence, add a RELATION_IS_OTHER_TEMP() check to all the places  
where ALTER TABLE currently does CheckTableNotInUse().  (I looked  
through all other callers of CheckTableNotInUse(), and they seem  
OK already.)  
  
Per bug #18492 from Alexander Lakhin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0d18b8eb409ce5cbc14c61e4883240d4668df655    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2024 13:27:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2024 13:27:26 -0400    

If the CALL is within an atomic context (e.g. there's an outer  
transaction block), _SPI_execute_plan should acquire a fresh snapshot  
to execute any such functions with.  We failed to do that and instead  
passed them the Portal snapshot, which had been acquired at the start  
of the current SQL command.  This'd lead to seeing stale values of  
rows modified since the start of the command.  
  
This is arguably a bug in 84f5c2908: I failed to see that "are we in  
non-atomic mode" needs to be defined the same way as it is further  
down in _SPI_execute_plan, i.e. check !_SPI_current->atomic not just  
options->allow_nonatomic.  Alternatively the blame could be laid on  
plpgsql, which is unconditionally passing allow_nonatomic = true  
for CALL/DO even when it knows it's in an atomic context.  However,  
fixing it in spi.c seems like a better idea since that will also fix  
the problem for any extensions that may have copied plpgsql's coding  
pattern.  
  
While here, update an obsolete comment about _SPI_execute_plan's  
snapshot management.  
  
Per report from Victor Yegorov.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/CAGnEboiRe+fG2QxuBO2390F7P8e2MQ6UyBjZSL_w1Cej+E4=Vw@mail.gmail.com  

commit   : 83f415e2d92e7a6f28fd816cd23f09d24801bd3c    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 7 Jun 2024 18:46:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 7 Jun 2024 18:46:30 +0900    

Floris Van Nee has reported a bug in the pgstats facility where a stats  
entry already dropped would get again dropped.  This case should not  
happen, still the error generated did not offer any details about the  
stats entry getting dropped.  
  
This commit improves the error message generated to inform about the  
stats entry kind, database OID, object OID and refcount, which should  
help to debug more the problem reported.  Bertrand Drouvot has been  
independently able to reach this error path while writing a new feature,  
and more details about the failure would have been helpful for  
debugging.  
  
Author: Andres Freund, Bertrand Drouvot  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/ZkM30paAD8Cr/[email protected]  
Backpatch-through: 15  

commit   : 8405d5a37a25c53e568b2bf290a0ba5189940190    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 7 Jun 2024 17:45:02 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 7 Jun 2024 17:45:02 +0900    

Previously, when considering LIMIT pushdown, postgres_fdw failed to  
check whether the query has this clause, which led to pushing false  
LIMIT clauses, causing incorrect results.  
  
This clause has been supported since v13, so we need to do a  
remote-version check before deciding that it will be safe to push such a  
clause, but we do not currently have a way to do the check (without  
accessing the remote server); disable pushing such a clause for now.  
  
Oversight in commit 357889eb1.  Back-patch to v13, where that commit  
added the support.  
  
Per bug #18467 from Onder Kalaci.  
  
Patch by Japin Li, per a suggestion from Tom Lane, with some changes to  
the comments by me.  Review by Onder Kalaci, Alvaro Herrera, and me.  
  
Discussion: https://postgr.es/m/18467-7bb89084ff03a08d%40postgresql.org  

commit   : d9ff92c235226f68bbafcc8bb5260a8a51aedec1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 7 Jun 2024 08:02:15 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 7 Jun 2024 08:02:15 +0200    

The wording from the "columns" view was copied to the "attributes"  
view without the required adjustments.  

commit   : bb331af4aeb714cb63ae0340bd07d7c98576957c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 6 Jun 2024 15:16:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 6 Jun 2024 15:16:56 -0400    

Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to  
resolve polymorphic output types and then just throws up its hands and  
assumes the check will be made at runtime.  I think that's true for  
ordinary functions returning RECORD, but it doesn't happen in CALL,  
potentially resulting in crashes if the actual output of the SQL  
procedure's SELECT doesn't match the type inferred from polymorphism.  
With a little bit of rearrangement, we can use get_call_result_type  
instead of get_func_result_type and thereby infer the correct types.  
  
I'm still unwilling to back-patch all of 913bbd88d, so if the types  
don't match you'll get an error rather than perhaps silently inserting  
a cast as v13 and later can.  That's consistent with prior behavior  
though, so it seems fine.  
  
Prior to 70ffb27b2, you'd typically get other errors due to other  
shortcomings of CALL's management of polymorphism.  Nonetheless,  
this is an independent bug.  
  
Although there is no bug in v13 and up, it seems prudent to add  
the test case for this to the newer branches too.  It's clearly  
an under-tested area.  
  
Per report from Andrew Bille.  
  
Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com  

commit   : f2c922ff2fed2c17116a625ec7311e8200b1c9f2    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 6 Jun 2024 08:48:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 6 Jun 2024 08:48:17 +0900    

Concurrent activity around replication slot creation and drop could  
cause a replication slot to use a stats entry it should not have used  
when created, triggering an assertion failure when retrieving this  
inconsistent entry from the dshash table used by the stats facility.  
  
The issue is that pgstat_drop_replslot() calls pgstat_drop_entry()  
without checking the result.  If pgstat_drop_entry() cannot free the  
entry related to the object dropped, pgstat_request_entry_refs_gc()  
should be called.  AtEOXact_PgStat_DroppedStats() and surrounding  
routines dropping stats entries already do that.  
  
This is documented in pgstat_internal.h, but let's add a comment at the  
top of pgstat_drop_entry() as that can be easy to miss.  
  
Reported-by: Alexander Lakhin  
Author: Floris Van Nee  
Analyzed-by: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : da565f3a4a2e1f04fd85805cbe3965188b330587    
  
author   : Nathan Bossart <[email protected]>    
date     : Wed, 5 Jun 2024 15:32:47 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Wed, 5 Jun 2024 15:32:47 -0500    

The documentation for POSIX semaphores is missing a reference to  
max_wal_senders.  This commit fixes that in the same way that  
commit 4ebe51a5fb fixed the same issue in the documentation for  
System V semaphores.  
  
Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13  
Backpatch-through: 12  

commit   : 75714e7cae82d7aa2f85fc9c0dde62fd8a771ed5    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 5 Jun 2024 19:56:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 5 Jun 2024 19:56:55 +0900    

This HBA entry was using "local" while specifying an address, which was  
incorrect.  While in it, this adjusts the format of the entry to be  
aligned with the surroundings.  
  
Oversight in 8fea86830e1d.  
  
Reported-by: Stéphane Schildknecht  
Reviewed-by: David G. Johnston  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : c236ecc82983ac01f504f7d6d286612fb9c3fad5    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2024 18:02:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2024 18:02:13 -0400    

In a procedure or function returning tuple, we use that function to  
parse the Tcl script's result, which is supposed to be a Tcl list.  
If it isn't, you get an error.  Commit 26abb50c4 incautiously  
supposed that we could use throw_tcl_error() to report such an error.  
That doesn't actually work, because low-level functions like  
Tcl_ListObjGetElements() don't fill Tcl's errorInfo variable.  
The result is either a null-pointer-dereference crash or emission  
of misleading context information describing the previous Tcl error.  
  
Back off to just reporting the interpreter's result string, and  
improve throw_tcl_error()'s comment to explain when to use it.  
  
Also, although the similar code in pltcl_trigger_handler() avoided  
this mistake, it was using a fairly confusing wording of the  
error message.  Improve that while we're here.  
  
Per report from A. Kozhemyakin.  Back-patch to all supported  
branches.  
  
Erik Wienhold and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b4e909082fa114d5934ca622b225d2352ec639fa    
  
author   : Dean Rasheed <[email protected]>    
date     : Tue, 4 Jun 2024 11:51:25 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Tue, 4 Jun 2024 11:51:25 +0100    

Commit faff8f8e47 allowed integer literals to contain underscores, but  
failed to update the lexer's "numericfail" rule. As a result, a  
decimal integer literal containing underscores would fail to parse, if  
used in an integer range with no whitespace after the first number,  
such as "1_001..1_003" in a PL/pgSQL FOR loop.  
  
Fix and backpatch to v16, where support for underscores in integer  
literals was added.  
  
Report and patch by Erik Wienhold.  
  
Discussion: https://postgr.es/m/808ce947-46ec-4628-85fa-3dd600b2c154%40ewie.name  

commit   : 3a2cc5a5b99ab04b9dc7e5f6c46b564739b5eb1b    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 3 Jun 2024 19:06:50 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 3 Jun 2024 19:06:50 -0700    

The VS and MinGW Windows images have been merged, to reduce the space needed  
for images. Before 98811323c8e the split helped boot performance, but now that  
we are using VMs that doesn't appear to be the case anymore.  
  
Author: Nazir Bilal Yavuz <[email protected]>  
Discussion: https://postgr.es/m/CAN55FZ2kWYjPd7uUC5QswrB3tfVJDiURqC%2BMGM6a3oeev%3DVgOA%40mail.gmail.com  
Backpatch: 15-, where CI was added  

commit   : 65b8c401af0a1d98ad34e60f8667e149796f8889    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 3 Jun 2024 12:10:43 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 3 Jun 2024 12:10:43 -0500    

The formulas for SEMMNI and SEMMNS do not include the archiver  
process, which was converted to an auxiliary process in v14, and  
the WAL summarizer process, which was introduced in v17.  This  
commit corrects these formulas and adds a missing reference to  
max_wal_senders nearby.  Since this section of the documentation  
tends to be incorrect quite often, we should likely give up on  
documenting the exact formulas in favor of something less fragile,  
but that is left as a future exercise.  
  
Reported-by: Sami Imseih  
Reviewed-by: Sami Imseih  
Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13  
Backpatch-through: 12  

commit   : 338fb8714c6cfe30c567ecb79812ec3879bd117f    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 24 May 2024 11:21:27 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 24 May 2024 11:21:27 +0900    

This test was failing when using wal_debug=on and -DWAL_DEBUG because of  
additional log entries that made the test grab an LSN not mapping with  
the error expected in the test.  
  
Previously the test would look for the first matching line to get the  
LSN to skip up to.  This is improved by having the test scan the logs  
with a regexp that checks for the expected ERROR string, ensuring that  
the wanted LSN comes from the correct context.  
  
Backpatch down to 15 where this test has been introduced.  
  
Author: Ian Ilyasov  
Discussion: https://postgr.es/m/GV1P251MB100415F17E6B2FDD7188777ECDE32@GV1P251MB1004.EURP251.PROD.OUTLOOK.COM  
Backpatch-through: 15  

commit   : 78030a66d75b19a6428f30e31b12bc6059c1fff3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 May 2024 15:52:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 May 2024 15:52:06 -0400    

Coverity complains that ECPGdebug is accessing debugstream without  
holding debug_mutex, which is a fair complaint: we should take  
debug_mutex while changing the settings ecpg_log looks at.  
  
In some branches it also complains about unlocked use of simple_debug.  
I think it's intentional and safe to have a quick unlocked check of  
simple_debug at the start of ecpg_log, since that early exit will  
always be taken in non-debug cases.  But we should recheck  
simple_debug after acquiring the mutex.  In the worst case, calling  
ECPGdebug concurrently with ecpg_log in another thread could result  
in a null-pointer dereference due to debugstream transiently being  
NULL while simple_debug isn't 0.  
  
This is largely hypothetical, since it's unlikely anybody uses  
ECPGdebug() at all in the field, and our own regression tests  
don't seem to be hitting the theoretical race conditions either.  
Still, if we're going to the trouble of having mutexes here, we ought  
to be using them in a way that's actually safe not just almost safe.  
Hence, back-patch to all supported branches.  

commit   : b4f808467a56b69838730164df5a22f946087b82    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 23 May 2024 13:03:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 23 May 2024 13:03:13 +0900    

Parameter column_name must be an existing column because ALTER  
MATERIALIZED VIEW cannot add new columns.  The old description was  
likely copied from ALTER TABLE.  
  
Author: Erik Wienhold  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : 019ea7675c7722ff7f9016b878feea8e7faac608    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 22 May 2024 18:22:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 22 May 2024 18:22:51 -0400    

Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype"  
manipulations it added to DecodeDateTime.  While likely harmless  
at the time, it became a problem after 5b3c59535 added an error check  
that ptype must be zero once we exit the parsing loop (that is, there  
shouldn't be any unused prefixes).  The consequence was that we'd  
reject time or timetz input like T12:34:56 (the "extended" format  
per ISO 8601-1:2019), even though that still worked in timestamp  
input.  
  
Since this is clearly under-tested code, add test cases covering all  
the ISO 8601 time formats.  (Note: although 8601 allows just "Thh",  
we have never accepted that, and this patch doesn't change that.  
I'm content to leave that as-is because it seems too likely to be  
a mistake rather than intended input.  If anyone wants to allow  
that, it should be a separate patch anyway, and not back-patched.)  
  
Per bug #18470 from David Perez.  Back-patch to v16 where we  
broke it.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2aa90c02dc6983bf0066bf6df18b713fde916cf7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 22 May 2024 17:54:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 22 May 2024 17:54:17 -0400    

transformTableLikeClause believed that it could process extended  
statistics immediately because "the representation of CreateStatsStmt  
doesn't depend on column numbers".  That was true when extended stats  
were first introduced, but it was falsified by the addition of  
extended stats on expressions: the parsed expression tree is fed  
forward by the LIKE option, and that will contain Vars.  So if the  
new table doesn't have attnums identical to the old one's (typically  
because there are some dropped columns in the old one), that doesn't  
work.  The CREATE goes through, but it emits invalid statistics  
objects that will cause problems later.  
  
Fortunately, we already have logic that can adapt expression trees  
to the possibly-new column numbering.  To use it, we have to delay  
processing of CREATE_TABLE_LIKE_STATISTICS into expandTableLikeClause,  
just as for other LIKE options that involve expressions.  
  
Per bug #18468 from Alexander Lakhin.  Back-patch to v14 where  
extended statistics on expressions were added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ce0d1654463e4f6080cfe83df74ed978945608a1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 18 May 2024 14:31:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 18 May 2024 14:31:35 -0400    

We are capable of optimizing MIN() and MAX() aggregates on indexed  
columns into subqueries that exploit the index, rather than the normal  
thing of scanning the whole table.  When we do this, we replace the  
Aggref node(s) with Params referencing subquery outputs.  Such Params  
really ought to be included in the per-plan-node extParam/allParam  
sets computed by SS_finalize_plan.  However, we've never done so  
up to now because of an ancient implementation choice to perform  
that substitution during set_plan_references, which runs after  
SS_finalize_plan, so that SS_finalize_plan never sees these Params.  
  
The cleanest fix would be to perform a separate tree walk to do  
these substitutions before SS_finalize_plan runs.  That seems  
unattractive, first because a whole-tree mutation pass is expensive,  
and second because we lack infrastructure for visiting expression  
subtrees in a Plan tree, so that we'd need a new function knowing  
as much as SS_finalize_plan knows about that.  I also considered  
swapping the order of SS_finalize_plan and set_plan_references,  
but that fell foul of various assumptions that seem tricky to fix.  
So the approach adopted here is to teach SS_finalize_plan itself  
to check for such Aggrefs.  I refactored things a bit in setrefs.c  
to avoid having three copies of the code that does that.  
  
Back-patch of v17 commits d0d44049d and 779ac2c74.  When d0d44049d  
went in, there was no evidence that it was fixing a reachable bug,  
so I refrained from back-patching.  Now we have such evidence.  
  
Per bug #18465 from Hal Takahara.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 382284519e141d41f7dc021d6a5fccd5888af8a1    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 16 May 2024 14:11:00 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 16 May 2024 14:11:00 -0700    

Specifically, it terminates a background worker even if the caller  
couldn't terminate the background worker with pg_terminate_backend().  
Commit 3a9b18b3095366cd0c4305441d426d04572d88c1 neglected to update  
this.  Back-patch to v13, which introduced DROP DATABASE FORCE.  
  
Reviewed by Amit Kapila.  Reported by Kirill Reshke.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0ae05c18e0bf740e6457e710f9323e75f6619c35    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 15 May 2024 22:48:51 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 15 May 2024 22:48:51 +0200    

9a974cbcba00 moved the query in binary_upgrade_set_pg_class_oids to the  
outer level, but left the PQclear and query buffer destruction in the  
is_index conditional.  353708e1fb2d fixed the leak of the query buffer  
but left the PGresult leak. This moves clearing the result to the outer  
level ensuring that it will be called.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v15  

commit   : 315661ecafbcbb23116cceea2ea80657d7763af0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 15 May 2024 13:49:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 15 May 2024 13:49:41 +0200    

Underscores were added to numeric literals in faff8f8e47.  This change  
also affected the positional parameters (e.g., $1) rule, which uses  
the same production for its digits.  But this did not actually work,  
because the digits for parameters are processed using atol(), which  
does not handle underscores and ignores whatever it cannot parse.  
  
The underscores notation is probably not useful for positional  
parameters, so for simplicity revert that rule to its old form that  
only accepts digits 0-9.  
  
Author: Erik Wienhold <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/5d216d1c-91f6-4cbe-95e2-b4cbd930520c%40ewie.name  

commit   : 987ab19ec9260618b36c186e0777f0bd43b8ded1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 15 May 2024 13:05:30 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 15 May 2024 13:05:30 +0200    

Erroneously introduced by 571df93cff8.  
  
Reviewed-by: Daniel Gustafsson <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/8458c9c5-18f1-46d7-94c4-1c30e4f44908%40eisentraut.org  

commit   : 8e0e99972ad92cc128c18bc6af41ef0e4d89e7ae    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 14 May 2024 20:19:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 14 May 2024 20:19:20 -0400    

Most of the infrastructure for procedure arguments was already  
okay with polymorphic output arguments, but it turns out that  
CallStmtResultDesc() was a few bricks shy of a load here.  It thought  
all it needed to do was call build_function_result_tupdesc_t, but  
that function specifically disclaims responsibility for resolving  
polymorphic arguments.  Failing to handle that doesn't seem to be  
a problem for CALL in plpgsql, but CALL from plain SQL would get  
errors like "cannot display a value of type anyelement", or even  
crash outright.  
  
In v14 and later we can simply examine the exposed types of the  
CallStmt.outargs nodes to get the right type OIDs.  But it's a lot  
more complicated to fix in v12/v13, because those versions don't  
have CallStmt.outargs, nor do they do expand_function_arguments  
until ExecuteCallStmt runs.  We have to duplicatively run  
expand_function_arguments, and then re-determine which elements  
of the args list are output arguments.  
  
Per bug #18463 from Drew Kimball.  Back-patch to all supported  
versions, since it's busted in all of them.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c1664c8eefad0a034d64adde1c2ff70d23be6a2c    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 13 May 2024 15:53:50 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 13 May 2024 15:53:50 -0500    

Presently, when this function is called for an unlogged sequence on  
a standby server, it will error out with a message like  
  
	ERROR:  could not open file "base/5/16388": No such file or directory  
  
Since the pg_sequences system view uses pg_sequence_last_value(),  
it can error similarly.  To fix, modify the function to return NULL  
for unlogged sequences on standby servers.  Since this bug is  
present on all versions since v15, this approach is preferable to  
making the ERROR nicer because we need to repair the pg_sequences  
view without modifying its definition on released versions.  For  
consistency, this commit also modifies the function to return NULL  
for other sessions' temporary sequences.  The pg_sequences view  
already appropriately filters out such sequences, so there's no bug  
there, but we might as well offer some defense in case someone  
invokes this function directly.  
  
Unlogged sequences were first introduced in v15, but temporary  
sequences are much older, so while the fix for unlogged sequences  
is only back-patched to v15, the temporary sequence portion is  
back-patched to all supported versions.  
  
We could also remove the privilege check in the pg_sequences view  
definition in v18 if we modify this function to return NULL for  
sequences for which the current user lacks privileges, but that is  
left as a future exercise for when v18 development begins.  
  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/20240501005730.GA594666%40nathanxps13  
Backpatch-through: 12  

commit   : 52ea653aa9d867be70b2d86fe8310dde48507b6a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 May 2024 13:16:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 May 2024 13:16:21 -0400    

If we recursed to a new call of the same function, with a different  
coldeflist (AS clause), it would fail because the inner call would  
overwrite the outer call's idea of what to return.  This is vaguely  
like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:  
it's just that we computed the actual output rowtype at the start of  
the call, and saved it in the per-procedure data structure.  We can  
fix it at basically zero cost by doing the computation at the end  
of each call instead of the start.  
  
It's not clear that there's any real-world use-case for such a  
function, but given that it doesn't cost anything to fix,  
it'd be silly not to.  
  
Per report from Andreas Karlsson.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5396a2987cc679a3ab5db26b54c8b76149489e29    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 9 May 2024 12:45:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 9 May 2024 12:45:43 +0900    

json_lex_string() relies on pg_encoding_mblen_bounded() to point to the  
end of a JSON string when generating an error message, and the input it  
uses is not guaranteed to be null-terminated.  
  
It was possible to walk off the end of the input buffer by a few bytes  
when the last bytes consist of an incomplete multi-byte sequence, as  
token_terminator would point to a location defined by  
pg_encoding_mblen_bounded() rather than the end of the input.  This  
commit switches token_terminator so as the error uses data up to the  
end of the JSON input.  
  
More work should be done so as this code could rely on an equivalent of  
report_invalid_encoding() so as incorrect byte sequences can show in  
error messages in a readable form.  This requires work for at least two  
cases in the JSON parsing API: an incomplete token and an invalid escape  
sequence.  A more complete solution may be too invasive for a backpatch,  
so this is left as a future improvement, taking care of the overread  
first.  
  
A test is added on HEAD as test_json_parser makes this issue  
straight-forward to check.  
  
Note that pg_encoding_mblen_bounded() no longer has any callers.  This  
will be removed on HEAD with a separate commit, as this is proving to  
encourage unsafe coding.  
  
Author: Jacob Champion  
Discussion: https://postgr.es/m/CAOYmi+ncM7pwLS3AnKCSmoqqtpjvA8wmCdoBtKA3ZrB2hZG6zA@mail.gmail.com  
Backpatch-through: 13  

commit   : 5dce8ce0ac48bc8af33d7efcdbfee713781598ed    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 7 May 2024 18:22:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 7 May 2024 18:22:52 -0400    

If -l was specified together with selective-restore options such as -n  
or -N, dependent TOC entries such as comments would be omitted from  
the listing, even when an actual restore would have selected them.  
This happened because PrintTOCSummary neglected to update the te->reqs  
marking of the entry they depended on.  
  
Per report from Justin Pryzby.  This has been wrong since 0d4e6ed30  
taught _tocEntryRequired to sometimes look at the "reqs" marking of  
other TOC entries, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023  

commit   : be18a12b663181f304d49022a452e31e4df42ff2    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 7 May 2024 18:15:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 7 May 2024 18:15:00 -0400    

If a plpython-language trigger caused another one to be invoked,  
the "TD" dictionary created for the inner one would overwrite the  
outer one's "TD" dictionary.  This is more or less the same problem  
that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it  
the same way, by saving and restoring "TD" during a recursive  
invocation.  
  
This fix makes an ABI-incompatible change in struct PLySavedArgs.  
I'm not too worried about that because it seems highly unlikely that  
any extension is messing with those structs.  We could imagine doing  
something weird to preserve nominal ABI compatibility in the back  
branches, like keeping the saved TD object in an extra element of  
namedargs[].  However, that would only be very nominal compatibility:  
if anything *is* touching PLySavedArgs, it would likely do the wrong  
thing due to not knowing about the additional value.  So I judge it  
not worth the ugliness to do something different there.  
  
(I also changed struct PLyProcedure, but its added field fits  
into formerly-padding space, so that should be safe.)  
  
Per bug #18456 from Jacques Combrink.  This bug is very ancient,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]