PostgreSQL 11.22 commit log

commit   : fd851f9e4a13d81cccc4ac5d6059d732c7518111    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 17:13:58 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 17:13:58 -0500    

commit   : 3dbb3dd2d641af0da92e0a25b490b5bc38490e58    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 13:26:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 13:26:33 -0500    

Security: CVE-2023-5868, CVE-2023-5869, CVE-2023-5870  

commit   : c48008f599fd0e3bca2923ff5b40b559ae1e4e2e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 10:56:43 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 10:56:43 -0500    

array_set_element() and related functions allow an array to be  
enlarged by assigning to subscripts outside the current array bounds.  
While these places were careful to check that the new bounds are  
allowable, they neglected to consider the risk of integer overflow  
in computing the new bounds.  In edge cases, we could compute new  
bounds that are invalid but get past the subsequent checks,  
allowing bad things to happen.  Memory stomps that are potentially  
exploitable for arbitrary code execution are possible, and so is  
disclosure of server memory.  
  
To fix, perform the hazardous computations using overflow-detecting  
arithmetic routines, which fortunately exist in all still-supported  
branches.  
  
The test cases added for this generate (after patching) errors that  
mention the value of MaxArraySize, which is platform-dependent.  
Rather than introduce multiple expected-files, use psql's VERBOSITY  
parameter to suppress the printing of the message text.  v11 psql  
lacks that parameter, so omit the tests in that branch.  
  
Our thanks to Pedro Gallegos for reporting this problem.  
  
Security: CVE-2023-5869  

commit   : 8c6633f4deb6ace445fc3d72d54585c373187d2d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 10:38:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 10:38:00 -0500    

transformAggregateCall() captures the datatypes of the aggregate's  
arguments immediately to construct the Aggref.aggargtypes list.  
This seems reasonable because the arguments have already been  
transformed --- but there is an edge case where they haven't been.  
Specifically, if we have an unknown-type literal in an ANY argument  
position, nothing will have been done with it earlier.  But if we  
also have DISTINCT, then addTargetToGroupList() converts the literal  
to "text" type, resulting in the aggargtypes list not matching the  
actual runtime type of the argument.  The end result is that the  
aggregate tries to interpret a "text" value as being of type  
"unknown", that is a zero-terminated C string.  If the text value  
contains no zero bytes, this could result in disclosure of server  
memory following the text literal value.  
  
To fix, move the collection of the aggargtypes list to the end  
of transformAggregateCall(), after DISTINCT has been handled.  
This requires slightly more code, but not a great deal.  
  
Our thanks to Jingzhou Fu for reporting this problem.  
  
Security: CVE-2023-5868  

commit   : a27be40c1bc328f4bab324ccecd601909ec94ac9    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 6 Nov 2023 06:14:13 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 6 Nov 2023 06:14:13 -0800    

It was always false in single-user mode, in autovacuum workers, and in  
background workers.  This had no specifically-identified security  
consequences, but non-core code or future work might make it  
security-relevant.  Back-patch to v11 (all supported versions).  
  
Jelte Fennema-Nio.  Reported by Jelte Fennema-Nio.  

commit   : e082734c8e78e6622a0422e612a870278721e83f    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 6 Nov 2023 06:14:13 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 6 Nov 2023 06:14:13 -0800    

Documentation says it cannot signal "a backend owned by a superuser".  
On the contrary, it could signal background workers, including the  
logical replication launcher.  It could signal autovacuum workers and  
the autovacuum launcher.  Block all that.  Signaling autovacuum workers  
and those two launchers doesn't stall progress beyond what one could  
achieve other ways.  If a cluster uses a non-core extension with a  
background worker that does not auto-restart, this could create a denial  
of service with respect to that background worker.  A background worker  
with bugs in its code for responding to terminations or cancellations  
could experience those bugs at a time the pg_signal_backend member  
chooses.  Back-patch to v11 (all supported versions).  
  
Reviewed by Jelte Fennema-Nio.  Reported by Hemanth Sandrana and  
Mahendrakar Srinivasarao.  
  
Security: CVE-2023-5870  

commit   : b29af71cd9a32b11e9e41f66c3068070a01e544d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 6 Nov 2023 13:29:04 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 6 Nov 2023 13:29:04 +0100    

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

commit   : a8b766a916e43a08eddb6514df9a3585576e398e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 5 Nov 2023 13:14:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 5 Nov 2023 13:14:07 -0500    

commit   : 930bc76bec1021c9ab8c8cb41cc08d598c2e26d8    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 13:57:58 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 13:57:58 -0400    

Reported-by: Svante Richter  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : 54af107cb119fb635c912362a425242bccffb485    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 13:39:50 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 13:39:50 -0400    

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

commit   : 3f9fe9b76f908e7ebf697c6b96f39601b6f803f3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Nov 2023 11:48:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Nov 2023 11:48:23 -0400    

This text left one with the impression that an ON SELECT rule could  
be attached to a plain table, which has not been true since commit  
264c06820 (meaning the text was already misleading when written,  
evidently by me in 96bd67f61).  However, it didn't get really bad  
until b23cd185f removed the convert-a-table-to-a-view logic, which  
had made it possible for scripts that thought they were attaching  
ON SELECTs to tables to still work.  
  
Rewrite into a form that makes it clear that an ON SELECT rule  
is better regarded as an implementation detail of a view.  
Pre-v16, point out that adding ON SELECT to a table actually  
converts it to a view.  
  
Per bug #18178 from Joshua Uyehara.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 272db03bb9d5fbf55cfe39776973dae72cb4bec7    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 09:51:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 09:51:52 -0400    

Reported-by: Jordi Gutiérrez Hermoso  
  
Discussion: https://postgr.es/m/[email protected]  
  
Co-authored-by: Laurenz Albe  
  
Backpatch-through: 11  

commit   : 6e1cca5113487bb9ef4daa1bb2833c6333466410    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 2 Nov 2023 11:47:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 2 Nov 2023 11:47:33 -0400    

get_explain_guc_options() crashed if a string GUC marked GUC_EXPLAIN  
has a NULL boot_val.  Nosing around found a couple of other places  
that seemed insufficiently cautious about NULL string values, although  
those are likely unreachable in practice.  Add some commentary  
defining the expectations for NULL values of string variables,  
in hopes of forestalling future additions of more such bugs.  
  
Xing Guo, Aleksander Alekseev, Tom Lane  
  
Discussion: https://postgr.es/m/CACpMh+AyDx5YUpPaAgzVwC1d8zfOL4JoD-uyFDnNSa1z0EsDQQ@mail.gmail.com  

commit   : f8b96c211da0037269e31bd2be5e0f730ec5a2bc    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Nov 2023 07:33:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Nov 2023 07:33:02 +0900    

This part of the documentation refers to exceptions as handled by  
PL/pgSQL, and using the internal error code is confusing.  
  
Per thinko in 66bde49d96a9.  
  
Reported-by: Euler Taveira, Bruce Momjian  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 468377fab7faf87fef85b6cb085ba79dc75fedbf    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 10:21:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 10:21:31 -0400    

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

commit   : 55ce8fc3998a899d09038fb2bb31874e9894a7b1    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 09:10:34 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 09:10:34 -0400    

This also updates some C comments.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/167336599095.2667301.15497893107226841625@wrigleys.postgresql.org  
  
Author: Laurenz Albe (doc patch)  
  
Backpatch-through: 11  

commit   : bae063db499fbe29b62a18fe3a9227a59ca2ef0f    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 30 Oct 2023 14:46:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 30 Oct 2023 14:46:05 -0700    

pgstatindex failed with ERRCODE_DATA_CORRUPTED, of the "can't-happen"  
class XX.  The other functions succeeded on an empty index; they might  
have malfunctioned if the failed index build left torn I/O or other  
complex state.  Report an ERROR in statistics functions pgstatindex,  
pgstatginindex, pgstathashindex, and pgstattuple.  Report DEBUG1 and  
skip all index I/O in maintenance functions brin_desummarize_range,  
brin_summarize_new_values, brin_summarize_range, and  
gin_clean_pending_list.  Back-patch to v11 (all supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e04509f3246df6cfd96ff5a47f7facd459c72f2b    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 30 Oct 2023 14:46:05 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 30 Oct 2023 14:46:05 -0700    

This prevents false-positive reports about "the first child of leftmost  
target page is not leftmost of its level", "block %u is not leftmost"  
and "left link/right link pair".  They appeared if amcheck ran before  
VACUUM cleaned things, after a cluster exited recovery between the  
first-stage and second-stage WAL records of a deletion.  Back-patch to  
v11 (all supported versions).  
  
Reviewed by Peter Geoghegan.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c804ffb5622b5efe7bda78570aa1911073a7491d    
  
author   : Dean Rasheed <[email protected]>    
date     : Sun, 29 Oct 2023 11:14:32 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sun, 29 Oct 2023 11:14:32 +0000    

Formerly, the value computed by leftmostvalue_interval() was a long  
way short of the minimum possible interval value.  As a result, an  
index scan on a GIN index on an interval column with < or <= operators  
would miss large negative interval values.  
  
Fix by setting all fields of the leftmost interval to their minimum  
values, ensuring that the result is less than any other possible  
interval.  Since this only affects index searches, no index rebuild is  
necessary.  
  
Back-patch to all supported branches.  
  
Dean Rasheed, reviewed by Heikki Linnakangas.  
  
Discussion: https://postgr.es/m/CAEZATCV80%2BgOfF8ehNUUfaKBZgZMDfCfL-g1HhWGb6kC3rpDfw%40mail.gmail.com  

commit   : 7ab6971c657fdc3b1612d6c4989f886bf997ade6    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Oct 2023 14:04:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 28 Oct 2023 14:04:43 -0400    

When looping around after finding that the set-returning function  
returned zero rows for the current input tuple, ExecProjectSet  
neglected to reset either of the two memory contexts it's  
responsible for cleaning out.  Typically this wouldn't cause much  
problem, because once the SRF does return at least one row, the  
contexts would get reset on the next call.  However, if the SRF  
returns no rows for many input tuples in succession, quite a lot  
of memory could be transiently consumed.  
  
To fix, make sure we reset both contexts while looping around.  
  
Per bug #18172 from Sergei Kornilov.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 64fc5e00542125000f7de649c0f69f16fdb4909f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Oct 2023 11:54:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 28 Oct 2023 11:54:40 -0400    

Debian recently decided to split out a bunch of "obsolete" timezone  
names into a new tzdata-legacy package, which isn't installed by  
default.  One of these zone names is Pacific/Enderbury, and that  
breaks our regression tests (on --with-system-tzdata builds)  
because our default timezone abbreviations list defines PHOT as  
Pacific/Enderbury.  
  
Pacific/Enderbury got renamed to Pacific/Kanton in tzdata 2021b,  
so that in distros that still have this entry it's just a symlink  
to Pacific/Kanton anyway.  So one answer would be to redefine PHOT  
as Pacific/Kanton.  However, then things would fail if the  
installed tzdata predates 2021b, which is recent enough that that  
seems like a real problem.  
  
Instead, let's just remove PHOT from the default list.  That seems  
likely to affect nobody in the real world, because (a) it was an  
abbreviation that the tzdb crew made up in the first place, with  
no evidence of real-world usage, and (b) the total human population  
of the Phoenix Islands is less than two dozen persons, per Wikipedia.  
If anyone does use this zone abbreviation they can easily put it back  
via a custom abbreviations file.  
  
We'll keep PHOT in the Pacific.txt reference file, but change it  
to Pacific/Kanton there, as that definition seems more likely to  
be useful to future readers of that file.  
  
Per report from Victor Wagner.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9e8a18d692a973a2bc1c19208bcb774fca8b90e8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 25 Oct 2023 17:34:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 25 Oct 2023 17:34:47 -0400    

As far as I can see, ecpg has no notion of a "default" open  
connection.  You can do "CONNECT TO DEFAULT" but that just specifies  
letting libpq use all its default connection parameters --- the  
resulting connection is not special subsequently.  In particular,  
SET CONNECTION = DEFAULT and DISCONNECT DEFAULT simply act on a  
connection named DEFAULT, if you've made one; they do not have  
special lookup rules.  But the documentation of these commands  
makes it look like they do.  
  
Simplest fix, I think, is just to remove the paras suggesting that  
DEFAULT is special here.  
  
Also, SET CONNECTION *does* have one special lookup rule, which  
is that it recognizes CURRENT as an alias for the currently selected  
connection.  SET CONNECTION = CURRENT is a no-op, so it's pretty  
useless, but nonetheless it does something different from selecting  
a connection by name; so we'd better document it.  
  
Per report from Sylvain Frandaz.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 93e1d5ce161508ad16deac3525b537355373a3e4    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 25 Oct 2023 11:33:24 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 25 Oct 2023 11:33:24 +0200    

The link to pg_type was accidentally linking to pg_authid instead.  
Backpatch to 12 and 11.  
  
Author: Maxim Yablokov <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11, 12  

commit   : 06e4f9c436be40dcc8aba6a8f34edf659dda1762    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Oct 2023 09:41:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Oct 2023 09:41:17 +0900    

Author: Ekaterina Kiryanova, Elena Indrupskaya, Oleg Sibiryakov, Maxim  
Yablokov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 0a6e2c7f86940f6d7c18c5dc2c50bf5f7ed3654d    
  
author   : Thomas Munro <[email protected]>    
date     : Sun, 22 Oct 2023 14:17:00 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Sun, 22 Oct 2023 14:17:00 +1300    

When scanning build farm results, it's useful to be able to see which  
version is in use.  For the Meson build system, this information was  
already displayed.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us  

commit   : e98f47d570a22e7aaaf71b79d6ce6852701bbd8d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Oct 2023 13:40:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Oct 2023 13:40:15 -0400    

This avoids a compiler bug occurring in AIX's xlc, even in pretty  
late-model revisions.  Buildfarm testing has now confirmed that  
only 64-bit xlc is affected.  Although we are contemplating  
dropping support for xlc in v17, it's still supported in the  
back branches, so we need this fix.  
  
Back-patch of code changes from HEAD commit 19fa97731.  
(The test cases were already back-patched, in 4a427b82c et al.)  
  
Discussion: https://postgr.es/m/CA+hUKGK=DOC+hE-62FKfZy=Ybt5uLkrg3zCZD-jFykM-iPn8yw@mail.gmail.com  

commit   : 32d31182fe6508d05cbcaada4f09db5c5c4db579    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Oct 2023 13:01:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Oct 2023 13:01:02 -0400    

This doco said that use of => as an operator "is deprecated".  
It's been fully disallowed since 865f14a2d back in 9.5, but  
evidently that commit missed updating this statement.  
Do so now.  

commit   : bc322c73cfaa9d8b93d6894fb591ec1592e98b31    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 17 Oct 2023 16:11:18 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 17 Oct 2023 16:11:18 -0500    

This commit (c290e79cf0) was originally back-patched to v15.  
Commit 97550c0711 added a new use of STDERR_FILENO, and it was  
back-patched all the way to v11, thus breaking MSVC builds for v11  
through v14.  Since STDERR_FILENO is now needed on older versions,  
let's back-patch c290e79cf0 down to v11, too.  
  
Here follows the original commit message describing the change:  
  
Because they are not available we've used _fileno(stdin) in some places, but  
that doesn't reliably work, because stdin might be closed. This is the  
prerequisite of the subsequent commit, fixing a failure introduced in  
76e38b37a5.  
  
Author: Andres Freund <[email protected]>  
Reported-By: Sandeep Thakkar <[email protected]>  
Message-Id: [email protected] (on pgsql-packagers)  
Discussion: https://postgr.es/m/20231017164517.GA613565%40nathanxps13  
Backpatch-through: 11  

commit   : 05b4614decacbe84fb3fde0d9266fe66f525a7e7    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 17 Oct 2023 13:55:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 17 Oct 2023 13:55:45 -0400    

Per code coverage reports, we had zero regression test coverage  
of these functions.  That came back to bite us, as apparently  
that's allowed us to miss discovering misbehavior of this code  
with AIX's xlc compiler.  Install relevant portions of the  
test cases added in 97957fdba, 2f0472030, 19fa97731.  
  
(Assuming the expected outcome that the xlc problem does appear  
in back branches, a code fix will follow.)  
  
Discussion: https://postgr.es/m/CA+hUKGK=DOC+hE-62FKfZy=Ybt5uLkrg3zCZD-jFykM-iPn8yw@mail.gmail.com  

commit   : d0e7f95b48453703d7c740438198e47d03497cec    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 17 Oct 2023 10:42:28 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 17 Oct 2023 10:42:28 -0500    

The SIGTERM handler for the startup process immediately calls  
proc_exit() for the duration of the restore_command, i.e., a call  
to system().  This system() call forks a new process to execute the  
shell command, and this child process inherits the parent's signal  
handlers.  If both the parent and child processes receive SIGTERM,  
both will attempt to call proc_exit().  This can end badly.  For  
example, both processes will try to remove themselves from the  
PGPROC shared array.  
  
To fix this problem, this commit adds a check in  
StartupProcShutdownHandler() to see whether MyProcPid == getpid().  
If they match, this is the parent process, and we can proc_exit()  
like before.  If they do not match, this is a child process, and we  
just emit a message to STDERR (in a signal safe manner) and  
_exit(), thereby skipping any problematic exit callbacks.  
  
This commit also adds checks in proc_exit(), ProcKill(), and  
AuxiliaryProcKill() that verify they are not being called within  
such child processes.  
  
Suggested-by: Andres Freund  
Reviewed-by: Thomas Munro, Andres Freund  
Discussion: https://postgr.es/m/Y9nGDSgIm83FHcad%40paquier.xyz  
Discussion: https://postgr.es/m/20230223231503.GA743455%40nathanxps13  
Backpatch-through: 11  

commit   : a295684b89143bc4bf51e1b40eb195de35570feb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 16 Oct 2023 14:06:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 16 Oct 2023 14:06:12 -0400    

Dropping a temp table could entail TOAST table access to clean out  
toasted catalog entries, such as large pg_constraint.conbin strings  
for complex CHECK constraints.  If we did that via ON COMMIT DROP,  
we triggered the assertion in init_toast_snapshot(), because  
there was no provision for setting up a snapshot for the drop  
actions.  Fix that.  
  
(I assume here that the adjacent truncation actions for ON COMMIT  
DELETE ROWS don't have a similar problem: it doesn't seem like  
nontransactional truncations would need to touch any toasted fields.  
If that proves wrong, we could refactor a bit to have the same  
snapshot acquisition cover that too.)  
  
The test case added here does not fail before v15, because that  
assertion was added in 277692220 which was not back-patched.  
However, the race condition the assertion warns of surely  
exists further back, so back-patch to all supported branches.  
  
Per report from Richard Guo.  
  
Discussion: https://postgr.es/m/CAMbWs4-x26=_QxxgdJyNbiCDzvtr2WV5ZDso_v-CukKEe6cBZw@mail.gmail.com  

commit   : f1634c968101ebe48e5b7b8b274a9170669384ce    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 16 Oct 2023 10:43:47 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 16 Oct 2023 10:43:47 +1300    

Commit dc7d70ea added functions that read the control file, but didn't  
acquire ControlFileLock.  With unlucky timing, file systems that have  
weak interlocking like ext4 and ntfs could expose partially overwritten  
contents, and the checksum would fail.  
  
Back-patch to all supported releases.  
  
Reviewed-by: David Steele <[email protected]>  
Reviewed-by: Anton A. Melnikov <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de  

commit   : 2759924f33a6b7021f68dda05bb34b10bb4579e2    
  
author   : David Rowley <[email protected]>    
date     : Fri, 13 Oct 2023 01:15:12 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 13 Oct 2023 01:15:12 +1300    

This could only affect HASH partitioned tables with at least 2 partition  
key columns.  
  
If partition pruning was delayed until execution and the query contained  
an IS NULL qual on one of the partitioned keys, and some subsequent  
partitioned key was being compared to a non-Const, then this could result  
in a crash due to the incorrect keyno being used to calculate the  
stateidx for the expression evaluation code.  
  
Here we fix this by properly skipping partitioned keys which have a  
nullkey set.  Effectively, this must be the same as what's going on  
inside perform_pruning_base_step().  
  
Sergei Glukhov also provided a patch, but that's not what's being used  
here.  
  
Reported-by: Sergei Glukhov  
Reviewed-by: tender wang, Sergei Glukhov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11, where runtime partition pruning was added.  

commit   : 8f1d44b648901497b82db3f08ead48e253046c09    
  
author   : David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 21:17:49 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 21:17:49 +1300    

Author: Andrew Atkinson  
Reviewed-by: Ashutosh Bapat  
Discussion: https://postgr.es/m/CAG6XLEnC%3DEgq0YHRic2kWWDs4xwQnQ_kBA6qhhzAq1-pO_9Tfw%40mail.gmail.com  
Backpatch-through: 11, where enable_partitionwise_aggregate was added  

commit   : 07f261b3172d6371019af38f61d17f5c3c1fe9aa    
  
author   : David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 19:53:50 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 19:53:50 +1300    

get_steps_using_prefix_recurse() incorrectly assumed that it could stop  
recursive processing of the 'prefix' list when cur_keyno was one before  
the step_lastkeyno.  Since hash partition pruning can prune using IS  
NULL quals, and these IS NULL quals are not present in the 'prefix'  
list, then that logic could cause more levels of recursion than what is  
needed and lead to there being no more items in the 'prefix' list to  
process.  This would manifest itself as a crash in some code that  
expected the 'start' ListCell not to be NULL.  
  
Here we adjust the logic so that instead of stopping recursion at 1 key  
before the step_lastkeyno, we just look at the llast(prefix) item and  
ensure we only recursively process up until just before whichever the last  
key is.  This effectively allows keys to be missing in the 'prefix' list.  
  
This change does mean that step_lastkeyno is no longer needed, so we  
remove that from the static functions.  I also spent quite some time  
reading this code and testing it to try to convince myself that there  
are no other issues.  That resulted in the irresistible temptation of  
rewriting some comments, many of which were just not true or inconcise.  
  
Reported-by: Sergei Glukhov  
Reviewed-by: Sergei Glukhov, tender wang  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11, where partition pruning was introduced.  

commit   : 2b729cf2ce3231338d0034071b309251292dbab1    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 16:51:08 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 16:51:08 -0400    

Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/167846222574.1803490.15815104179136215862@wrigleys.postgresql.org  
  
Backpatch-through: 11  

commit   : 7ef23b87d98258337f6c16391e0526b7fb9ecdbd    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 16:04:56 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 16:04:56 -0400    

Reported-by: Pete Storer  
  
Discussion: https://postgr.es/m/BL0PR05MB66283C57D72E321591AE4EB1F3CE9@BL0PR05MB6628.namprd05.prod.outlook.com  
  
Backpatch-through: 11  

commit   : fb2763fc44d3abae6ef1f13205c10e2f2b3d23bf    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 15:54:28 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 15:54:28 -0400    

Reported-by: Steve Atkins  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : b9de00e8c6e41ad86e7ec9ad6b62af84200b6438    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 15:14:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 15:14:18 -0400    

Autovacuum does not do it.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : 04f0baa85865c2775ef123ecb7f3cf0b079ff959    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 10 Oct 2023 11:01:13 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 10 Oct 2023 11:01:13 -0700    

Mark the buffers dirty before writing WAL.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 11  

commit   : 694d6700e8866941a72b9f34955fc6ede67cbd63    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Oct 2023 11:29:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Oct 2023 11:29:21 -0400    

While these two built-in functions do exactly the same thing,  
CURRENT_USER seems preferable to use in documentation examples.  
It's easier to look up if the reader is unsure what it is.  
Also, this puts these examples in sync with an adjacent example  
that already used CURRENT_USER.  
  
Per question from Kirk Parker.  
  
Discussion: https://postgr.es/m/CANwZ8rmN_Eb0h0hoMRS8Feftaik0z89PxVsKg+cP+PctuOq=Qg@mail.gmail.com  

commit   : 4f16152d9711a59e1b2ad8a4bc26d4455da709e6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Oct 2023 13:27:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Oct 2023 13:27:51 -0400    

In a selective restore, ACLs for a table should be dumped if the  
table is selected to be dumped.  However, if the table has both  
table-level and column-level ACLs, only the table-level ACL was  
restored.  This happened because _tocEntryRequired assumed that  
an ACL could have only one dependency (the one on its table),  
and punted if there was more than one.  But since commit ea9125304,  
column-level ACLs also depend on the table-level ACL if any, to  
ensure correct ordering in parallel restores.  To fix, adjust the  
logic in _tocEntryRequired to ignore dependencies on ACLs.  
  
I extended a test case in 002_pg_dump.pl so that it purports to  
test for this; but in fact the test passes even without the fix.  
That's because this bug only manifests during a selective restore,  
while the scenarios 002_pg_dump.pl tests include only selective dumps.  
Perhaps somebody would like to extend the script so that it can test  
scenarios including selective restore, but I'm not touching that.  
  
Euler Taveira and Tom Lane, per report from Kong Man.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/DM4PR11MB73976902DBBA10B1D652F9498B06A@DM4PR11MB7397.namprd11.prod.outlook.com  

commit   : 7a310cae0861cfd3a76ce4ace02ed72641039e15    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2023 13:16:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2023 13:16:47 -0400    

After receiving position data for a lexeme, tsvectorrecv()  
advanced its "datalen" value by (npos+1)*sizeof(WordEntry)  
where the correct calculation is (npos+1)*sizeof(WordEntryPos).  
This accidentally failed to render the constructed tsvector  
invalid, but it did result in leaving some wasted space  
approximately equal to the space consumed by the position data.  
That could have several bad effects:  
  
* Disk space is wasted if the received tsvector is stored into a  
  table as-is.  
  
* A legal tsvector could get rejected with "maximum total lexeme  
  length exceeded" if the extra space pushes it over the MAXSTRPOS  
  limit.  
  
* In edge cases, the finished tsvector could be assigned a length  
  larger than the allocated size of its palloc chunk, conceivably  
  leading to SIGSEGV when the tsvector gets copied somewhere else.  
  The odds of a field failure of this sort seem low, though valgrind  
  testing could probably have found this.  
  
While we're here, let's express the calculation as  
"sizeof(uint16) + npos * sizeof(WordEntryPos)" to avoid the type  
pun implicit in the "npos + 1" formulation.  It's not wrong  
given that WordEntryPos had better be 2 bytes to avoid padding  
problems, but it seems clearer this way.  
  
Report and patch by Denis Erokhin.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 90ef9d9c9498980258a01ab3d746d4832145cb4a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2023 20:20:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2023 20:20:57 -0400    

Add "-gmt 1" to our test invocations of the Tcl "clock" command,  
so that they do not consult the timezone environment.  While it  
doesn't really matter which timezone is used here, it does  
matter that the command not fall over entirely.  We've now  
discovered that at least on FreeBSD, "clock scan" will fail if  
/etc/localtime is missing.  It seems worth making the test  
insensitive to that.  
  
Per Tomas Vondras' buildfarm animal dikkop.  Thanks to  
Thomas Munro for the diagnosis.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4d10fda52042ecab89d8018acf41c791036c24c5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2023 14:07:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2023 14:07:30 -0400    

As of Xcode 15 (macOS Sonoma), the linker complains about duplicate  
references to the same library.  We see warnings about libpgport and  
libpgcommon being duplicated in many client executables.  This is a  
consequence of the hack introduced in commit 6b7ef076b to list  
libpgport before libpq while not removing it from $(LIBS).  
(Commit 8396447cd later applied the same rule to libpgcommon.)  
  
The concern in 6b7ef076b was to ensure that the client executable  
wouldn't unintentionally depend on pgport functions from libpq.  
That concern is obsolete on any platform for which we can do symbol  
export control, because if we can then the pgport functions in libpq  
won't be exposed anyway.  Hence, we can fix this problem by just  
removing libpgport and libpgcommon from $(libpq_pgport), and letting  
clients depend on the occurrences in $(LIBS).  
  
In the back branches, do that only on macOS (which we know has  
symbol export control).  In HEAD, let's be more aggressive and  
remove the extra libraries everywhere.  The only still-supported  
platforms that lack export control are MinGW/Cygwin, and it  
doesn't seem worth sweating over ABI stability details for those  
(or if somebody does care, it'd probably be possible to perform  
symbol export control for those too).  As well as being simpler,  
this might give some microscopic improvement in build time.  
  
The meson build system is not changed here, as it doesn't have  
this particular disease, though it does have some related issues  
that we'll fix separately.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f9cbff459061b80a56b440401670ce809dc395b9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2023 13:13:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Sep 2023 13:13:54 -0400    

Try to make these option descriptions a little clearer for novices.  
Per gripe from Attila Gulyás.  
  
Discussion: https://postgr.es/m/169590536647.3727336.11070254203649648453@wrigleys.postgresql.org  

commit   : 750beed859f0ea4f87f2812177755ef4234dfb80    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 29 Sep 2023 15:55:37 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 29 Sep 2023 15:55:37 +0200    

Commit 7d3b7011b added a link to the statistics functions, which at the  
time were anchored under the section for statistics views.  aebe989477a  
added a separate section for statistics functions, but the link was not  
updated to point to the new anchor.  Fix by changing the xref.  
  
Backpatch to all supported branches.  
  
Author: Peter Smith <[email protected]>  
Discussion: https://postgr.es/m/CAHut+Ptr0jKzNNtWnssLq+3jNhbyaBseqf6NPrWHk08mQFRoTg@mail.gmail.com  
Backpatch-through: 11  

commit   : 7c07305e6f025a97732adb01ca6fcb499655a886    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 28 Sep 2023 16:29:22 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 28 Sep 2023 16:29:22 -0700    

nbtree's mark/restore processing failed to correctly handle an edge case  
involving array key advancement and related search-type scan key state.  
Scans with ScalarArrayScalarArrayOpExpr quals requiring mark/restore  
processing (for a merge join) could incorrectly conclude that an  
affected array/scan key must not have advanced during the time between  
marking and restoring the scan's position.  
  
As a result of all this, array key handling within btrestrpos could skip  
a required call to _bt_preprocess_keys().  This confusion allowed later  
primitive index scans to overlook tuples matching the true current array  
keys.  The scan's search-type scan keys would still have spurious values  
corresponding to the final array element(s) -- not values matching the  
first/now-current array element(s).  
  
To fix, remember that "array key wraparound" has taken place during the  
ongoing btrescan in a flag variable stored in the scan's state, and use  
that information at the point where btrestrpos decides if another call  
to _bt_preprocess_keys is required.  
  
Oversight in commit 70bc5833, which taught nbtree to handle array keys  
during mark/restore processing, but missed this subtlety.  That commit  
was itself a bug fix for an issue in commit 9e8da0f7, which taught  
nbtree to handle ScalarArrayOpExpr quals natively.  
  
Author: Peter Geoghegan <[email protected]>  
Discussion: https://postgr.es/m/CAH2-WzkgP3DDRJxw6DgjCxo-cu-DKrvjEv_ArkP2ctBJatDCYg@mail.gmail.com  
Backpatch: 11- (all supported branches).  

commit   : 3caedf246123b4629ccf33270f778f000a16cf02    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Sep 2023 14:05:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Sep 2023 14:05:26 -0400    

This code was sloppy about comparison of index columns that  
are expressions.  It didn't reliably reject cases where one  
index has an expression where the other has a plain column,  
and it could index off the start of the attmap array, leading  
to a Valgrind complaint (though an actual crash seems unlikely).  
  
I'm not sure that the expression-vs-column sloppiness leads  
to any visible problem in practice, because the subsequent  
comparison of the two expression lists would reject cases  
where the indexes have different numbers of expressions  
overall.  Maybe we could falsely match indexes having the  
same expressions in different column positions, but it'd  
require unlucky contents of the word before the attmap array.  
It's not too surprising that no problem has been reported  
from the field.  Nonetheless, this code is clearly wrong.  
  
Per bug #18135 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0e0de20c88b978e13ad756a74462bf28cd1574bd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2023 21:06:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Sep 2023 21:06:21 -0400    

We started to use this linker switch in commit 9df308697 of  
2004-07-13, which was in the OS X 10.3 era.  Apparently it's been a  
no-op since around OS X 10.9.  Apple's most recent toolchain version  
actively complains about it, so it's time to get rid of it.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a4a8c0de2b8120b909510ebd33f28c29b038e685    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:44:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:44:21 -0400    

Reported-by: Sami Imseih  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : ba0eb75dac99470d259de58760379ed0159bfd16    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:23:58 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:23:58 -0400    

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

commit   : 14e60252c441d39f244497b60ea60e69d52e39f8    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:02:17 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:02:17 -0400    

Reported-by: Gurjeet Singh  
  
Discussion: https://postgr.es/m/CABwTF4WYPD9ov-kcSq1+J+ZJ5wYDQLXquY6Lu2cvb-Y7pTpSGA@mail.gmail.com  
  
Backpatch-through: 11  

commit   : 71c27e88e5a790a73895fb7c6bc649bda7db5c8c    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 18:54:10 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 18:54:10 -0400    

Also mention that mismatching primary/standby LSNs should never  
happen.  
  
Reported-by: Nikolay Samokhvalov  
  
Discussion: https://postgr.es/m/CAM527d8heqkjG5VrvjU3Xjsqxg41ufUyabD9QZccdAxnpbRH-Q@mail.gmail.com  
  
Backpatch-through: 11  

commit   : e1ae79b99a9ccbd1022bd1c8c6dc6053d75bc9e9    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 17:31:05 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 17:31:05 -0400    

Reported-by: hape <[email protected]>  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 11  

commit   : 6181eca090da350580e3dcea378cf3f85b1a54e2    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 26 Sep 2023 08:16:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 26 Sep 2023 08:16:49 +0900    

There was no mention of this command in the documentation, and it is  
useful to run the TAP tests of a target source directory.  
  
Author: Yugo Nagata  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 6a3b19bbefd782605765c67990e9d8b4dd5e9f87    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 25 Sep 2023 11:50:02 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 25 Sep 2023 11:50:02 -0700    

For some reason I used not_like = { pg_dumpall_dbprivs => 1, } in the test  
condition of one of the tests added in in c66a7d75e65. That doesn't make sense  
for two reasons: 1) not_like isn't a valid test condition 2) the database  
should not be dumped in any of the tests.  Due to 1), the test achieved its  
goal, but clearly the formulation is confusing.  Instead use like => {}, with  
a comment explaining why.  
  
Reported-by: Peter Eisentraut <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, like c66a7d75e65  

commit   : fdc7cf73b424e4da7b1e61e7467441622758a00a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2023 14:41:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2023 14:41:57 -0400    

Parse analysis of a CallStmt will inject mutable information,  
for instance the OID of the called procedure, so that subsequent  
DDL may create a need to re-parse the CALL.  We failed to detect  
this for CALLs in plpgsql routines, because no dependency information  
was collected when putting a CallStmt into the plan cache.  That  
could lead to misbehavior or strange errors such as "cache lookup  
failed".  
  
Before commit ee895a655, the issue would only manifest for CALLs  
appearing in atomic contexts, because we re-planned non-atomic  
CALLs every time through anyway.  
  
It is now apparent that extract_query_dependencies() probably  
needs a special case for every utility statement type for which  
stmt_requires_parse_analysis() returns true.  I wanted to add  
something like Assert(!stmt_requires_parse_analysis(...)) when  
falling out of extract_query_dependencies_walker without doing  
anything, but there are API issues as well as a more fundamental  
point: stmt_requires_parse_analysis is supposed to be applied to  
raw parser output, so it'd be cheating to assume it will give the  
correct answer for post-parse-analysis trees.  I contented myself  
with adding a comment.  
  
Per bug #18131 from Christian Stork.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0fb91ed2b0af3fbe1889a6951b4e9f1331e70822    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2023 11:50:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 25 Sep 2023 11:50:28 -0400    

The initial estimate of the number of distinct ParsedWords is just  
that: an estimate.  Don't let it exceed what palloc is willing to  
allocate.  If in fact we need more entries, we'll eventually fail  
trying to enlarge the array.  But if we don't, this allows success on  
inputs that currently draw "invalid memory alloc request size".  
  
Per bug #18080 from Uwe Binder.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2a47c04535286f2a43bbc4a1694d5efb884a8220    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Sep 2023 14:52:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Sep 2023 14:52:36 -0400    

The previous wording had a faint archaic whiff to it, and more  
importantly used "catalogs" as a verb, which while cutely  
self-referential seems likely to provoke confusion in this  
particular context.  Also consistently use "kind" not "type" to  
refer to the different kinds of relations distinguished by relkind.  
  
Per gripe from Martin Nash.  Back-patch to supported versions.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c994d06f105a6812a8b1f13c7e6c12e294f4d548    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 21 Sep 2023 19:45:11 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 21 Sep 2023 19:45:11 +0900    

The comment introduced by commit e7cb7ee14 was a bit too terse, which  
could lead to extensions doing different things within the hook function  
than we intend to allow.  Extend the comment to explain what they can do  
within the hook function.  
  
Back-patch to all supported branches.  
  
In passing, I rephrased a nearby comment that I recently added to the  
back branches.  
  
Reviewed by David Rowley and Andrei Lepikhov.  
  
Discussion: https://postgr.es/m/CAPmGK15SBPA1nr3Aqsdm%2BYyS-ay0Ayo2BRYQ8_A2To9eLqwopQ%40mail.gmail.com  

commit   : f1a99e13ca631e9a481450960a7844d13c056891    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 19 Sep 2023 11:53:51 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 19 Sep 2023 11:53:51 +0300    

The text got the condition backwards, it's "NSN > LSN", not "NSN < LSN".  
While we're at it, expand it a little for clarity.  
  
Reviewed-by: Daniel Gustafsson  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : ddded779a77368482c22e489ef7eb0a57d205167    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 19 Sep 2023 08:31:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 19 Sep 2023 08:31:31 +0900    

PLy_elog() was not able to handle correctly cases where a SPI called  
failed, which would fill in a DETAIL string able to trigger an  
assertion.  We may want to improve this infrastructure so as it is able  
to provide any extra detail information provided by an error stack, but  
this is left as a future improvement as it could impact existing error  
stacks and any applications that depend on them.  For now, the assertion  
is removed and a regression test is added to cover the case of a failure  
with a detail string.  
  
This problem exists since 2bd78eb8d51c, so backpatch all the way down  
with tweaks to the regression tests output added where required.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : db00be6d7845b5ed0d4a30946c2336da9a9b3ba9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Sep 2023 14:27:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Sep 2023 14:27:47 -0400    

cursor_to_xmlschema() assumed that any Portal must have a tupDesc,  
which is not so.  Add a defensive check.  
  
It's plausible that this mistake occurred because of the rather  
poorly chosen name of the lookup function SPI_cursor_find(),  
which in such cases is returning something that isn't very much  
like a cursor.  Add some documentation to try to forestall future  
errors of the same ilk.  
  
Report and patch by Boyu Yang (docs changes by me).  Back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/dd343010-c637-434c-a8cb-418f53bda3b8.yangboyu.yby@alibaba-inc.com  

commit   : a374f6c61681fe072526fc5580df191347bea061    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Sep 2023 17:01:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Sep 2023 17:01:26 -0400    

expandRecordVariable() failed to adjust the parse nesting structure  
correctly when recursing to inspect an outer-level Var.  This could  
result in assertion failures or core dumps in corner cases.  
  
Likewise, get_name_for_var_field() failed to adjust the deparse  
namespace stack correctly when recursing to inspect an outer-level  
Var.  In this case the likely result was a "bogus varno" error  
while deparsing a view.  
  
Per bug #18077 from Jingzhou Fu.  Back-patch to all supported  
branches.  
  
Richard Guo, with some adjustments by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 479b99125dcce0d625846efd333ccc5aa48411bb    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Sep 2023 16:39:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Sep 2023 16:39:27 -0400    

This is a back-patch of commit d57534740 ("Fix EXPLAIN of SEARCH  
BREADTH FIRST with a constant initial value") into pre-v14 branches.  
At the time I'd thought it was not needed in branches that lack the  
SEARCH/CYCLE feature, but that was just a failure of imagination.  
It's possible to demonstrate "record type has not been registered"  
failures in older branches too, during deparsing of views that contain  
references to fields of composite constants.  
  
Back-patch only the code changes, as the test cases added by d57534740  
all require SEARCH/CYCLE syntax.  A suitable test case will be added  
in the upcoming fix for bug #18077.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : ece1154f4c892585ee824a2bde764ff85169b021    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Sep 2023 16:20:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Sep 2023 16:20:08 -0400    

Teach get_expr_result_type() to manufacture a tuple descriptor directly  
from a RowExpr node.  If the RowExpr has type RECORD, this is the only  
way to get a tupdesc for its result, since even if the rowtype has been  
blessed, we don't have its typmod available at this point.  (If the  
RowExpr has some named composite type, we continue to let the existing  
code handle it, since the RowExpr might well not have the correct column  
names embedded in it.)  
  
This fixes assorted corner cases illustrated by the added regression  
tests.  
  
This is a back-patch of the v13-era commit 8b7a0f1d1 into previous  
branches.  At the time I'd judged it not important enough to back-patch,  
but the upcoming fix for bug #18077 includes a test case that depends  
on this working correctly; and 8b7a0f1d1 has now aged long enough to  
have good confidence that it won't break anything.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : bddbbdf99b16b4f3abaa05d6e1d8ee209efeaa7a    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 16:00:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 16:00:47 +0900    

This reverts commit a0d87bcd9b57, following a remark from Andres Frend  
that the new error can be triggered with an incorrect SET TRANSACTION  
SNAPSHOT command without being really helpful for the user as it uses  
the internal file name.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : a4cef3384d6de4d60989303e56883a9ff2239608    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 10:30:37 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 10:30:37 +0900    

When a snapshot file fails to be read in ImportSnapshot(), it would  
issue an ERROR as "invalid snapshot identifier" when opening a stream  
for it in read-only mode.  This error message is reworded to be the same  
as all the other messages used in this case on failure, which is useful  
when debugging this area.  
  
Thinko introduced by bb446b689b66 where snapshot imports have been  
added.  A backpatch down to 11 is done as this can improve any work  
related to snapshot imports in older branches.  
  
Author: Bharath Rupireddy  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CALj2ACWmr=3KdxDkm8h7Zn1XxBoF6hdzq8WQyMn2y1OL5RYFrg@mail.gmail.com  
Backpatch-through: 11  

commit   : 6ae57f190e276f46bc2d0b616515bed4b4f664ce    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 13 Sep 2023 14:32:24 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 13 Sep 2023 14:32:24 +1200    

If an out-of-memory error was thrown at an unfortunate time,  
ensure_record_cache_typmod_slot_exists() could leak memory and leave  
behind a global state that produced an infinite loop on the next call.  
  
Fix by merging RecordCacheArray and RecordIdentifierArray into a single  
array.  With only one allocation or re-allocation, there is no  
intermediate state.  
  
Back-patch to all supported releases.  
  
Reported-by: "James Pang (chaolpan)" <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/PH0PR11MB519113E738814BDDA702EDADD6EFA%40PH0PR11MB5191.namprd11.prod.outlook.com  

commit   : feb4e218e5f9d8ec2d0c6f2eac28ad786ea9d79c    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 12 Sep 2023 09:36:56 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 12 Sep 2023 09:36:56 +0530    

The transactions and subtransactions array that was allocated under  
snapshot builder memory context and recorded during decoding was not  
cleared in case of errors. This can result in an assertion failure if we  
attempt to retry logical decoding within the same session. To address this  
issue, we register a callback function under the snapshot builder memory  
context to clear the recorded transactions and subtransactions array along  
with the context.  
  
This problem doesn't exist in PG16 and HEAD as instead of using  
InitialRunningXacts, we added the list of transaction IDs and  
sub-transaction IDs, that have modified catalogs and are running during  
snapshot serialization, to the serialized snapshot (see commit 7f13ac8123).  
  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 11  
Discussion: http://postgr.es/m/[email protected]  

commit   : 0aeadb4f7974189ca057830f8c0e424f70e4cf70    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 8 Sep 2023 17:25:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 8 Sep 2023 17:25:14 -0400    

Reported-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Laurenz Albe  
  
Backpatch-through: 11  

commit   : dbd1a06c97f5a2f0c13b05cee1d1ca292ed77f7f    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 7 Sep 2023 14:12:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 7 Sep 2023 14:12:36 +0900    

pgbouncer can cause PQbackendPID() to return negative values due to it  
filling be_pid with random bytes (even these days pid_max can only be  
set up to 2^22 on 64b machines on Linux, for example, so this cannot  
happen with normal PID numbers).  When this happens, pg_basebackup may  
generate a temporary slot name that may not be accepted by the parser,  
leading to spurious failures, like:  
pg_basebackup: error: could not send replication command  
ERROR:  replication slot name "pg_basebackup_-1201966863" contains  
invalid character  
  
This commit fixes that problem by formatting the result from  
PQbackendPID() as an unsigned integer when creating the temporary  
replication slot name, so as the invalid character is gone and the  
command can be parsed.  
  
Author: Jelte Fennema  
Reviewed-by: Daniel Gustafsson, Nishant Sharma  
Discussion: https://postgr.es/m/CAGECzQQOGvYfp8ziF4fWQ_o8s2K7ppaoWBQnTmdakn3s-4Z=5g@mail.gmail.com  
Backpatch-through: 11  

commit   : 69e22dd38faf0641f27544dc06a7ac25b9682533    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 6 Sep 2023 16:52:24 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 6 Sep 2023 16:52:24 -0400    

Reported-by: [email protected]  
  
Diagnosed-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Laurenz Albe  
  
Backpatch-through: 11  

commit   : 7a7526ab5485fcec14eb7a78bbc0cd253b938bd1    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 5 Sep 2023 13:05:27 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 5 Sep 2023 13:05:27 -0400    

Reported-by: Ryo Matsumura  
  
Discussion: https://postgr.es/m/TYCPR01MB11316B3FB56EE54D70BF0CEF6E8E4A@TYCPR01MB11316.jpnprd01.prod.outlook.com  
  
Backpatch-through: 11  

commit   : 358cd2b25109f50f2d3a9a29ed90fed9dc362df3    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 4 Sep 2023 14:55:58 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 4 Sep 2023 14:55:58 +0900    

This could lead to an imprecise choice when splitting an index page of a  
GiST index on a tsvector, deciding which entries should remain on the  
old page and which entries should move to a new page.  
  
This is wrong since tsearch2 has been moved into core with commit  
140d4ebcb46e, so backpatch all the way down.  This error has been  
spotted by valgrind.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : eafe9c9181a4fd4b68d7e22e979de839cc16930c    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 30 Aug 2023 17:15:10 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Wed, 30 Aug 2023 17:15:10 +0900    

Commit e4106b252 should have updated this test, but did not; back-patch  
to all supported branches.  
  
Reviewed by Richard Guo.  
  
Discussion: http://postgr.es/m/CAPmGK15nR0NXLSCKQAcqbZbTzrzd5MozowWnTnGfPkayndF43Q%40mail.gmail.com  

commit   : dd9779141eacbad08670fc4d55d7e076301ba69a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 27 Aug 2023 07:01:26 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 27 Aug 2023 07:01:26 -0400    

The offending code is not present in later branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b915bf495ff48c4f57a22a90dfddc38be7a9845e    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 24 Aug 2023 16:14:26 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 24 Aug 2023 16:14:26 -0400    

per gripe from Tom Lane.  

commit   : 9c59f3862b182dffa85e7d1ea924187c22ace086    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Aug 2023 12:02:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Aug 2023 12:02:40 -0400    

Revalidation of a plancache entry (after a cache invalidation event)  
requires acquiring a snapshot.  Normally that is harmless, but not  
if the cached statement is one that needs to run without acquiring a  
snapshot.  We were already aware of that for TransactionStmts,  
but for some reason hadn't extrapolated to the other statements that  
PlannedStmtRequiresSnapshot() knows mustn't set a snapshot.  This can  
lead to unexpected failures of commands such as SET TRANSACTION  
ISOLATION LEVEL.  We can fix it in the same way, by excluding those  
command types from revalidation.  
  
However, we can do even better than that: there is no need to  
revalidate for any statement type for which parse analysis, rewrite,  
and plan steps do nothing interesting, which is nearly all utility  
commands.  To mechanize this, invent a parser function  
stmt_requires_parse_analysis() that tells whether parse analysis does  
anything beyond wrapping a CMD_UTILITY Query around the raw parse  
tree.  If that's what it does, then rewrite and plan will just  
skip the Query, so that it is not possible for the same raw parse  
tree to produce a different plan tree after cache invalidation.  
  
stmt_requires_parse_analysis() is basically equivalent to the  
existing function analyze_requires_snapshot(), except that for  
obscure reasons that function omits ReturnStmt and CallStmt.  
It is unclear whether those were oversights or intentional.  
I have not been able to demonstrate a bug from not acquiring a  
snapshot while analyzing these commands, but at best it seems mighty  
fragile.  It seems safer to acquire a snapshot for parse analysis of  
these commands too, which allows making stmt_requires_parse_analysis  
and analyze_requires_snapshot equivalent.  
  
In passing this fixes a second bug, which is that ResetPlanCache  
would exclude ReturnStmts and CallStmts from revalidation.  
That's surely *not* safe, since they contain parsable expressions.  
  
Per bug #18059 from Pavel Kulakov.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2d13dab048a7e0777875529620f81d32ce57dfd8    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 22 Aug 2023 11:57:08 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 22 Aug 2023 11:57:08 -0400    

Attribute missing values might be needed past the lifetime of the tuple  
descriptors from which they are extracted. To avoid possibly using  
pointers for by-reference values which might thus be left dangling, we  
cache a datumCopy'd version of the datum in the TopMemoryContext. Since  
we first search for the value this only needs to be done once per  
session for any such value.  
  
Original complaint from Tom Lane, idea for mitigation by Andrew Dunstan,  
tweaked by Tom Lane.  
  
Backpatch to version 11 where missing values were introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c176d97895be92ceb1454a3b7e14bffe7b7da364    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 23 Aug 2023 14:13:07 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 23 Aug 2023 14:13:07 +0200    

The list of external language drivers and procedural languages was  
never complete or exhaustive, and rather than attempting to manage  
it the content has migrated to the wiki.  This replaces the tables  
altogether with links to the wiki as we regularly get requests for  
adding various projects,  which we reject without any clear policy  
for why or how the content should be managed.  
  
The threads linked to below are the most recent discussions about  
this, the archives contain many more.  
  
Backpatch to all supported branches since the list on the wiki  
applies to all branches.  
  
Author: Jonathan Katz <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v11  

commit   : ae126929500918334a7ff3120da1c7f2f9a0fe53    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 10 Aug 2023 10:16:59 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 10 Aug 2023 10:16:59 -0700    

The fix itself is fine, but the test revealed other problems related  
to parallel query that are not easily fixable. Remove the test for  
now to fix the buildfarm.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 43ba5105a8e0c28e893bd698f76211b5ea757145    
  
author   : Jeff Davis <[email protected]>    
date     : Mon, 7 Aug 2023 15:09:11 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Mon, 7 Aug 2023 15:09:11 -0700    

Renaming a role can affect the meaning of the special string $user, so  
must cause search_path to be recalculated.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Nathan Bossart, Michael Paquier  
Backpatch-through: 11