PostgreSQL 16.1 commit log

commit   : 3edc6580c0e27fb8f13322efd255a88d20dda6c2    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 17:04:27 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Nov 2023 17:04:27 -0500    

commit   : 639a8063ca7da421b34b7a49b2773c3cb2436df1    
  
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   : e24daa94b2a747a95987569ef1899f74dbaf8495    
  
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   : d3d1e25097db05edd0e6b44321516e1dce144047    
  
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   : 2c3c5ec4936a6f20354766612ebd650abbb17817    
  
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   : 78541273156c74ed20acdc141cf2f996098cd794    
  
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   : b1227766a33558405db97505d9e430fd0884685b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 6 Nov 2023 13:10:09 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 6 Nov 2023 13:10:09 +0100    

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

commit   : 1b4e0265c2642e15fbf3cda91089be059f869e4f    
  
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   : f646ac6725672896d424e0ac46b3ba77a4063264    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 3 Nov 2023 11:46:52 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 3 Nov 2023 11:46:52 -0700    

In f13eb16485f I made a mistake leading to only man1 being installed. I will  
report a bug suggesting that meson warn about mistakes of this sort.  
  
Reported-by: Christoph Berg <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson build was introduced  

commit   : 1e774846b870a858f8eb88b3f512562009177f45    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 3 Nov 2023 17:54:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 3 Nov 2023 17:54:08 -0400    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  
  
Also as usual for a .1 release, there are some entries here that  
are not really relevant for v16 because they already appeared in 16.0.  
Those'll be removed later.  

commit   : 7f85099f4b3bf0142b19e87b5596a63c2df96274    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 13:57:59 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 13:57:59 -0400    

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

commit   : d5b1045e672c5a0c12222abf6033916f08caaf6f    
  
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   : 9d4ea0bb3fd461164b061f19885d565cfcf57f93    
  
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   : 8cb1d99f232da51c45ba46d7b14b659a24d6dfdc    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 09:51:53 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 3 Nov 2023 09:51:53 -0400    

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

commit   : 82063edd4ac366161d9afa56221c74032b332c39    
  
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   : e22819a747365facbe8f504dc3a4996a02114e05    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Nov 2023 12:38:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Nov 2023 12:38:23 +0900    

The test missed that custom GUCs need to be ignored from the list of  
parameters that can exist in postgresql.conf.sample.  This caused the  
test to fail on a server where such a module is loaded, when using  
EXTRA_INSTALL and TEMP_CONFIG, for instance.  
  
Author: Anton A. Melnikov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : 354b3ebf17c45ff5037c763cd59b03089c520427    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 2 Nov 2023 07:33:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 2 Nov 2023 07:33:20 +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   : 1155daef60548914e637b039d7b96cd824d0b71f    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Wed, 1 Nov 2023 11:46:30 +0100    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Wed, 1 Nov 2023 11:46:30 +0100    

The name of the function resulting from the macro expansion was  
incorrectly stated.  
  
Backpatch to 16 where it was introduced.  
  
Author: Kyotaro Horiguchi <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v16  

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

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

commit   : 83981bcbace1e0eac599cdac196213e78f6d545a    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 10:13:11 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 10:13:11 -0400    

Reported-by: Jeff Davis  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Jeff Davis, adjustments by me  
  
Backpatch-through: 16  

commit   : 04e5b1d586f2bf9c9e47e529781a6af60166bb02    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 09:23:09 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 09:23:09 -0400    

Also reorder entries and add commas.  
  
Reported-by: David G. Johnston  
  
Discussion: https://postgr.es/m/CAKFQuwYeNPxeocV3_0+Zx=_Xwvg+sNyEMdzyG5s2E2e0hZLQhg@mail.gmail.com  
  
Author: David G. Johnston (partial)  
  
Backpatch-through: 12  

commit   : 350bd6bdc19dc53467ec2013c86fd4466c0f43af    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 09:10:35 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 31 Oct 2023 09:10:35 -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   : a98f01c933ec566c43d92b87a1e90467fed6217e    
  
author   : David Rowley <[email protected]>    
date     : Tue, 31 Oct 2023 16:42:35 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 31 Oct 2023 16:42:35 +1300    

4b8266415 added a precheck to pgrowlocks() to ensure the given object's  
pg_class.relam is HEAP_TABLE_AM_OID, however, that check was put before  
another check which was checking if the given object was a partitioned  
table.  Since the pg_class.relam is always InvalidOid for partitioned  
tables, if pgrowlocks() was called passing a partitioned table, then the  
"only heap AM is supported" error would be raised instead of the intended  
error about the given object being a partitioned table.  
  
Here we simply move the pg_class.relam check to after the check that  
verifies that we are in fact working with a normal (non-partitioned)  
table.  
  
Reported-by: jian he  
Discussion: https://postgr.es/m/CACJufxFaSp_WguFCf0X98951zFVX+dXFnF1mxAb-G3g1HiHOow@mail.gmail.com  
Backpatch-through: 12, where 4b8266415 was introduced.  

commit   : 1a368dd3ecefef041721628baf9564862088c377    
  
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   : 3c6a05b805c750771dc6d3471ca32b27eb25b33e    
  
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   : 67738dbf9c9232c8dc1892f970a0bf89617058a6    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 29 Oct 2023 12:56:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 29 Oct 2023 12:56:24 -0400    

Among numerous other oversights, commit 482675987 neglected to fix  
pg_dump to dump this new subscription option.  Since the new default  
is "false" while the previous behavior corresponds to "true", this  
would cause legacy subscriptions to silently change behavior during  
dump/reload or pg_upgrade.  That seems like a bad idea.  Even if it  
was intended, failing to preserve the option once set in a new  
installation is certainly not OK.  
  
While here, reorder associated stanzas in pg_dump to match the  
field order in pg_subscription, in hopes of reducing the impression  
that all this code was written with the aid of a dartboard.  
  
Back-patch to v16 where this new field was added.  
  
Philip Warner (cosmetic tweaks by me)  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ab73a37e9e1e5308f4dbb81902125b484f9c5432    
  
author   : Dean Rasheed <[email protected]>    
date     : Sun, 29 Oct 2023 11:14:36 +0000    
  
committer: Dean Rasheed <[email protected]>    
date     : Sun, 29 Oct 2023 11:14:36 +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   : 07494a0df9a66219e5f1029de47ecabc34c9cb55    
  
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   : d1537afe3e6e3fe279dbee6d505292d6e38fef5f    
  
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   : 924e0e2ee058d8dfeae6218dba9419a3ddf1c755    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:57:44 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:57:44 +0200    

When calculating distance for interval values, the code mostly mimicked  
interval_mi, i.e. it built a new interval value for the difference.  
That however does not work for sufficiently distant interval values,  
when the difference overflows the interval range.  
  
Instead, we can calculate the distance directly, without constructing  
the intermediate (and unnecessary) interval value.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Reported-by: Dean Rasheed  
Reviewed-by: Ashutosh Bapat, Dean Rasheed  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : 497fc92086f85ea2ec139b8eab493e750f559ff9    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:57:28 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:57:28 +0200    

Make sure that infinite values in date/timestamp columns are treated as  
if in infinite distance. Infinite values should not be merged with other  
values, leaving them as outliers. The code however returned distance 0  
in this case, so that infinite values were merged first. While this does  
not break the index (i.e. it still produces correct query results), it  
may make it much less efficient.  
  
We don't need explicit handling of infinite date/timestamp values when  
calculating distances, because those values are represented as extreme  
but regular values (e.g. INT64_MIN/MAX for the timestamp type).  
  
We don't need an exact distance, just a value that is much larger than  
distanced between regular values. With the added cast to double values,  
we can simply subtract the values.  
  
The regression test queries a value in the "gap" and checks the range  
was properly eliminated by the BRIN index.  
  
This only affects minmax-multi indexes on timestamp/date columns with  
infinite values, which is not very common in practice. The affected  
indexes may need to be rebuilt.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Reported-by: Ashutosh Bapat  
Reviewed-by: Ashutosh Bapat, Dean Rasheed  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : e7965226d5518796cb2c1a48635ae92b5fe4e6ef    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:57:11 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:57:11 +0200    

When calculating the distance between date values, make sure to subtract  
them in the right order, i.e. (larger - smaller).  
  
The distance is used to determine which values to merge, and is expected  
to be a positive value. The code unfortunately did the subtraction in  
the opposite order, i.e. (smaller - larger), thus producing negative  
values and merging values the most distant values first.  
  
The resulting index is correct (i.e. produces correct results), but may  
be significantly less efficient. This affects all minmax-multi indexes  
on date columns.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Reported-by: Ashutosh Bapat  
Reviewed-by: Ashutosh Bapat, Dean Rasheed  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0635fe02b426573d62e2389cf90b688c285f072a    
  
author   : Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:56:27 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Fri, 27 Oct 2023 17:56:27 +0200    

When calculating distances for timestamp values for BRIN minmax-multi  
indexes, we need to be careful about overflows for extreme values. If  
the value overflows into a negative value, the index may be inefficient.  
  
The new regression test checks this for the timestamp type by adding a  
table with enough values to force range compaction/merging. The values  
are close to min/max, which means a risk of overflow.  
  
Fixed by converting the int64 values to double first, before calculating  
the distance. This prevents the overflow. We may lose some precision, of  
course, but that's good enough. In the worst case we build a slightly  
less efficient index, but for large distances this won't matter.  
  
This only affects minmax-multi indexes on timestamp columns, with ranges  
containing values sufficiently distant to cause an overflow. That seems  
like a fairly rare case in practice.  
  
Backpatch to 14, where minmax-multi indexes were introduced.  
  
Reported-by: Ashutosh Bapat  
Reviewed-by: Ashutosh Bapat, Dean Rasheed  
Backpatch-through: 14  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2bf99b48ded8288fa1c5f53a0c3581059a112d0c    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 26 Oct 2023 17:12:24 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 26 Oct 2023 17:12:24 +0900    

After 01575ad788e3, expand_single_inheritance_child()'s parentOID  
variable is read only in an Assert, provoking a compiler warning in  
non-assert builds.  Fix that by marking the variable with  
PG_USED_FOR_ASSERTS_ONLY.  
  
Per report and suggestion from David Rowley  
  
Discussion: https://postgr.es/m/CAApHDvpjA_8Wxu4DCTRVAvPxC9atwMe6N%2ByvrcGsgb7mrfdpJA%40mail.gmail.com  

commit   : 178ee1d858d89f6d86f42a84bd4b8014ddfa7245    
  
author   : Amit Langote <[email protected]>    
date     : Thu, 26 Oct 2023 11:53:41 +0900    
  
committer: Amit Langote <[email protected]>    
date     : Thu, 26 Oct 2023 11:53:41 +0900    

Currently, expand_single_inheritance_child() doesn't reset  
perminfoindex in a plain-inheritance parent's child RTE, because  
prior to 387f9ed0a0, the executor would use the first child RTE to  
locate the parent's RTEPermissionInfo.  That in turn causes  
add_rte_to_flat_rtable() to create an extra RTEPermissionInfo  
belonging to the parent's child RTE with the same content as the one  
belonging to the parent's original ("root") RTE.  
  
In 387f9ed0a0, we changed things so that the executor can now use the  
parent's "root" RTE for locating its RTEPermissionInfo instead of the  
child RTE, so the latter's perminfoindex need not be set anymore, so  
make it so.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : d76606f077c3bd1c0fc161fd4dd8666b2d997164    
  
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   : cf352ddcdd84d959774766347b24f4e800ffdd3c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Oct 2023 09:41:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Oct 2023 09:41:09 +0900    

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

commit   : f76f1ef00d3e6f5789d8fe51dcaf3417208159c6    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 25 Oct 2023 09:27:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 25 Oct 2023 09:27:09 +0900    

This information is useful to know when scanning buildfarm results, and  
it is already displayed in Meson.  The output of `openssl version` is  
logged, with the command retrieved from PATH.  
  
This depends on c8e4030d1bdd, so backpatch down to 16.  
  
Reviewed-by: Peter Eisentraut, Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : b1444a09dcb5dc3c2898ee5f35a4093710dc6be6    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 Oct 2023 14:48:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 Oct 2023 14:48:28 -0400    

When an UPDATE/DELETE/MERGE's target table is an old-style  
inheritance tree, it's possible for the parent to get excluded  
from the plan while some children are not.  (I believe this is  
only possible if we can prove that a CHECK ... NO INHERIT  
constraint on the parent contradicts the query WHERE clause,  
so it's a very unusual case.)  In such a case, ExecInitModifyTable  
mistakenly concluded that the first surviving child is the target  
table, leading to at least two bugs:  
  
1. The wrong table's statement-level triggers would get fired.  
  
2. In v16 and up, it was possible to fail with "invalid perminfoindex  
0 in RTE with relid nnnn" due to the child RTE not having permissions  
data included in the query plan.  This was hard to reproduce reliably  
because it did not occur unless the update triggered some non-HOT  
index updates.  
  
In v14 and up, this is easy to fix by defining ModifyTable.rootRelation  
to be the parent RTE in plain inheritance as well as partitioned cases.  
  
While the wrong-triggers bug also appears in older branches, the  
relevant code in both the planner and executor is quite a bit  
different, so it would take a good deal of effort to develop and  
test a suitable patch.  Given the lack of field complaints about the  
trigger issue, I'll desist for now.  (Patching v11 for this seems  
unwise anyway, given that it will have no more releases after next  
month.)  
  
Per bug #18147 from Hans Buschmann.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cf89d3052d62a5dd82805d157b64cdf493e5e851    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 24 Oct 2023 09:27:26 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 24 Oct 2023 09:27:26 -0700    

Clearly spell out the limitations of aminsert()'s indexUnchanged hinting  
mechanism in the index AM documentation.  
  
Oversight in commit 9dc718bd, which added the "logically unchanged  
index" hint (which is used to trigger bottom-up index deletion).  
  
Author: Peter Geoghegan <[email protected]>  
Reported-By: Tom Lane <[email protected]>  
Reviewed-By: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/CAH2-WzmU_BQ=-H9L+bxTSMQBqHMjp1DSwGypvL0gKs+dTOfkKg@mail.gmail.com  
Backpatch: 14-, where indexUnchanged hinting was introduced.  

commit   : 3b0f20f6ce145b0cd5aefa147a7e425b60601a58    
  
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   : 174ccda5e2874fe33cc29b29dae753c1403288e3    
  
author   : Thomas Munro <[email protected]>    
date     : Sun, 22 Oct 2023 10:04:55 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Sun, 22 Oct 2023 10:04:55 +1300    

When min_dynamic_shared_memory is set above 0, we try to find space in a  
pre-allocated region of the main shared memory area instead of calling  
dsm_impl_XXX() routines to allocate more.  The dsm_pin_segment() and  
dsm_unpin_segment() routines had a bug: they called dsm_impl_XXX()  
routines even for main region segments.  Nobody noticed before now  
because those routines do nothing on Unix, but on Windows they'd fail  
while attempting to duplicate an invalid Windows HANDLE.  Add the  
missing gating.  
  
Back-patch to 14, where commit 84b1c63a added this feature.  Fixes  
pgsql-bugs bug #18165.  
  
Reported-by: Maxime Boyer <[email protected]>  
Tested-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/18165-bf4f525cea6e51de%40postgresql.org  

commit   : b62a3fa1cc66ab0d3356c0262b743909d2066504    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 20 Oct 2023 22:52:15 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 20 Oct 2023 22:52:15 +0200    

It's undesirable to have SQL commands or configuration options in a  
translatable error string, so take some of these out.  

commit   : c79ca0485a62b2abefabd538ac896cd64f4e7a01    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 20 Oct 2023 11:11:36 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 20 Oct 2023 11:11:36 -0700    

Previously we errored out if no python installation could be found (but we did  
handle not having enough of python installed to build plpython  
against). Presumably nobody hit this so far, as python is likely installed due  
to meson requiring python.  
  
Author: Tristan Partin <[email protected]>  
Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po  
Backpatch: 16-, where meson support was added  

commit   : 1ad3a7bd396a802566239fa37e3435df20603d8b    
  
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   : 1856a0ee0e967431ee52b6e3f2a95a0050fb9ca4    
  
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   : 8405068f3eb39fb7f4682838b1040c40ce51833f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 19 Oct 2023 10:37:46 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 19 Oct 2023 10:37:46 +0200    

Reported-by: Alvaro Herrera <[email protected]>  

commit   : cfa4eba02c878d69e7f2c7bf8895a393521bc013    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 18 Oct 2023 20:43:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 18 Oct 2023 20:43:17 -0400    

When processing a match tag, check to see if the claimed "off"  
is more than the distance back to the output buffer start.  
If it is, then the data is corrupt, and what's more we would  
fetch from outside the buffer boundaries and potentially incur  
a SIGSEGV.  (Although the odds of that seem relatively low, given  
that "off" can't be more than 4K.)  
  
Back-patch to v13; before that, this function wasn't really  
trying to protect against bad data.  
  
Report and fix by Flavien Guedez.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 418d6b4430a5dbfbe4dd9c10ada367f0aee88b52    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 18 Oct 2023 13:40:44 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 18 Oct 2023 13:40:44 -0400    

Reported-by: Lele Gaifax  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 774185056834eef7702f6afb37731c583fa51a1a    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 18 Oct 2023 22:15:54 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 18 Oct 2023 22:15:54 +1300    

Changes required by https://llvm.org/docs/NewPassManager.html.  
  
Back-patch to 12, leaving the final release of 11 unchanged, consistent  
with earlier decision not to back-patch LLVM 16 support either.  
  
Author: Dmitry Dolgov <[email protected]>  
Reviewed-by: Andres Freund <[email protected]>  
Reviewed-by: Thomas Munro <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKG%2BWXznXCyTgCADd%3DHWkP9Qksa6chd7L%3DGCnZo-MBgg9Lg%40mail.gmail.com  

commit   : 60596f148a661e0fd1d7c1f13a72b55124511e3a    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 19 Oct 2023 03:01:55 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 19 Oct 2023 03:01:55 +1300    

Commit 37d5babb used this C API function while adding support for LLVM  
16 and opaque pointers, but it's not available in LLVM 7 and older.  
Provide it in our own llvmjit_wrap.cpp.  It just calls a C++ function  
that pre-dates LLVM 3.9, our minimum target.  
  
Back-patch to 12, like 37d5babb.  
  
Discussion: https://postgr.es/m/CA%2BhUKGKnLnJnWrkr%3D4mSGhE5FuTK55FY15uULR7%3Dzzc%3DwX4Nqw%40mail.gmail.com  

commit   : 74d19ec096dfbda5782e62892de7e86a104f8265    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 18 Oct 2023 22:09:05 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 18 Oct 2023 22:09:05 +1300    

Remove use of LLVMGetElementType() and provide the type of all pointers  
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM  
versions[1].  
  
 * For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.  
 * For LLVM == 15, we'll continue to do the same, explicitly opting  
   out of opaque pointer mode.  
 * For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take  
   the extra type argument.  
  
The difference is hidden behind some new IR emitting wrapper functions  
l_load(), l_gep(), l_call() etc.  The change is mostly mechanical,  
except that at each site the correct type had to be provided.  
  
In some places we needed to do some extra work to get functions types,  
including some new wrappers for C++ APIs that are not yet exposed by in  
LLVM's C API, and some new "example" functions in llvmjit_types.c  
because it's no longer possible to start from the function pointer type  
and ask for the function type.  
  
Back-patch to 12, because it's a little tricker in 11 and we agreed not  
to put the latest LLVM support into the upcoming final release of 11.  
  
[1] https://llvm.org/docs/OpaquePointers.html  
  
Reviewed-by: Dmitry Dolgov <[email protected]>  
Reviewed-by: Ronan Dunklau <[email protected]>  
Reviewed-by: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com  

commit   : 4277bcb30129dcf61e355ae97509c002f82c674e    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Oct 2023 18:23:43 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Oct 2023 18:23:43 +0900    

Author: Hou Zhijie  
Discussion: https://postgr.es/m/TYAPR01MB5724A40D47E71F4717357EC694D5A@TYAPR01MB5724.jpnprd01.prod.outlook.com  
Backpatch-through: 15  

commit   : 2308f18c073333babdcc45139d691a74fae87863    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 18 Oct 2023 14:54:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 18 Oct 2023 14:54:39 +0900    

Relation files extended multiple blocks at a time have been counting the  
number of blocks written, but forgot that to increment the write time in  
this case, as write and relation extension are treated as two different  
I/O operations in the shared stats: IOOP_EXTEND vs IOOP_WRITE.  In this  
case IOOP_EXTEND was forgotten for normal (non-temporary) relations.  
  
Write times are tracked when track_io_timing is enabled, which is not  
the case by default.  
  
Author: Nazir Bilal Yavuz  
Reviewed-by: Robert Haas, Melanie Plageman  
Discussion: https://postgr.es/m/CAN55FZ19Ss279mZuqGbuUNxka0iPbLgYuOQXqAKewrjNrp27VA@mail.gmail.com  
Backpatch-through: 16  

commit   : 4a427b82cf19f1b05ca9e26704f8f924af758ded    
  
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   : ee06199fcb0a38abbb0f0745e66e6aa7150ee6ef    
  
author   : Nathan Bossart <[email protected]>    
date     : Tue, 17 Oct 2023 10:41:58 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Tue, 17 Oct 2023 10:41:58 -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   : 57e6e861d437dc6bfd1d21393a7542e513789d18    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 16 Oct 2023 14:06:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 16 Oct 2023 14:06:11 -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   : d1c56ad37b9676df23cb12bdabfffce2a5fc01a7    
  
author   : Nathan Bossart <[email protected]>    
date     : Mon, 16 Oct 2023 12:42:17 -0500    
  
committer: Nathan Bossart <[email protected]>    
date     : Mon, 16 Oct 2023 12:42:17 -0500    

If SIGTERM is received within this section, the startup process  
will immediately proc_exit() in the signal handler, so it is  
inadvisable to include any more code than is required there (as  
such code is unlikely to be compatible with doing proc_exit() in a  
signal handler).  This commit moves the code recently added to this  
section (see 1b06d7bac9 and 7fed801135) to outside of the section.  
This ensures that the startup process only calls proc_exit() in its  
SIGTERM handler for the duration of the system() call, which is how  
this code worked from v8.4 to v14.  
  
Reported-by: Michael Paquier, Thomas Munro  
Analyzed-by: Andres Freund  
Suggested-by: Tom Lane  
Reviewed-by: Michael Paquier, Robert Haas, Thomas Munro, Andres Freund  
Discussion: https://postgr.es/m/Y9nGDSgIm83FHcad%40paquier.xyz  
Discussion: https://postgr.es/m/20230223231503.GA743455%40nathanxps13  
Backpatch-through: 15  

commit   : 08c1795c52b8504e2f5c148454db84f73aa02e40    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 16 Oct 2023 12:57:39 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 16 Oct 2023 12:57:39 -0400    

The old documentation encourages entering single-user mode for no  
reason, which is a bad plan in most cases. Instead, discourage users  
from doing that, and explain the limited cases in which it may be  
desirable.  
  
The old documentation claims that running VACUUM as anyone but the  
superuser can't possibly work, which is not really true, because it  
might be that some other user has enough permissions to VACUUM all  
the tables that matter. Weaken the language just a bit.  
  
The old documentation claims that you can't run any commands  
when near XID exhaustion, which is false because you can still  
run commands that don't require an XID, like a SELECT without a  
locking clause.  
  
The old documentation doesn't clearly explain that it's a good idea  
to get rid of prepared transactons, long-running transactions, and  
replication slots that are preventing (M)XID horizon advancement.  
Spell out the steps to do that.  
  
Also, discourage the use of VACUUM FULL and VACUUM FREEZE in  
this type of scenario.  
  
Back-patch to v14. Much of this is good advice on all supported  
versions, but before 60f1f09ff44308667ef6c72fbafd68235e55ae27  
the chances of VACUUM failing in multi-user mode were much higher.  
  
Alexander Alekseev, John Naylor, Robert Haas, reviewed at various  
times by Peter Geoghegan, Hannu Krosing, and Andres Freund.  
  
Discussion: http://postgr.es/m/CA+TgmoYtsUDrzaHcmjFhLzTk1VEv29mO_u-MT+XWHrBJ_4nD8A@mail.gmail.com  

commit   : 5725e4ebe7a936f724f21e7ee1e84e54a70bfd83    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 16 Oct 2023 17:10:13 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 16 Oct 2023 17:10:13 +1300    

Some of our src/bin tools read the control file without any kind of  
interlocking against concurrent writes from the server.  At least ext4  
and ntfs can expose partially modified contents when you do that.  
  
For now, we'll try to tolerate this by retrying up to 10 times if the  
checksum doesn't match, until we get two reads in a row with the same  
bad checksum.  This is not guaranteed to reach the right conclusion, but  
it seems very likely to.  Thanks to Tom Lane for this suggestion.  
  
Various ideas for interlocking or atomicity were considered too  
complicated, unportable or expensive given the lack of field reports,  
but remain open for future reconsideration.  
  
Back-patch as far as 12.  It doesn't seem like a good idea to put a  
heuristic change for a very rare problem into the final release of 11.  
  
Reviewed-by: Anton A. Melnikov <[email protected]>  
Reviewed-by: David Steele <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de  

commit   : 3090213690bd69dd46dae865a2021982e7309208    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 16 Oct 2023 13:23:51 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 16 Oct 2023 13:23:51 +1300    

Per automated complaint from BF animal koel this needed to be  
re-indented, but there was also a typo.  Back-patch to 16.  

commit   : 2371432cd6b93415ef99e7ef35598f4f85436163    
  
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   : bf1c21c4fad033414a99d6205118fbc4d75efa62    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 14 Oct 2023 16:33:51 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 14 Oct 2023 16:33:51 -0700    

Under interval_ops, some equal values are distinguishable.  One such  
pair is '24:00:00' and '1 day'.  With that being so, btequalimage()  
breaches the documented contract for the "equalimage" btree support  
function.  This can cause incorrect results from index-only scans.  
Users should REINDEX any btree indexes having interval-type columns.  
After updating, pg_amcheck will report an error for almost all such  
indexes.  This fix makes interval_ops simply omit the support function,  
like numeric_ops does.  Back-pack to v13, where btequalimage() first  
appeared.  In back branches, for the benefit of old catalog content,  
btequalimage() code will return false for type "interval".  Going  
forward, back-branch initdb will include the catalog change.  
  
Reviewed by Peter Geoghegan.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 06ff064842832187fce7474e866010d2764a066a    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 14 Oct 2023 15:54:46 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 14 Oct 2023 15:54:46 -0700    

Starting on 2023-08-03, this intermittently terminated a "pgbench -C"  
test in CI.  It could affect a high-client-count "pgbench" without "-C".  
While parallel reindexdb and vacuumdb reach the same problematic check,  
sufficient client count and/or connection turnover is less plausible for  
them.  Given the lack of examples from the buildfarm or from manual  
builds, reproducing this must entail rare operating system  
configurations.  Also correct the associated error message, which was  
wrong for non-Windows.  Back-patch to v12, where the pgbench check first  
appeared.  While v11 vacuumdb has the problematic check, reaching it  
with typical vacuumdb usage is implausible.  
  
Reviewed by Thomas Munro.  
  
Discussion: https://postgr.es/m/CA+hUKG+JwvTNdcyJTriy9BbtzF1veSRQ=9M_ZKFn9_LqE7Kp7Q@mail.gmail.com  

commit   : 0002feb8209618e5a9e23e03fe4aa31bc4006f01    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 13 Oct 2023 19:06:19 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 13 Oct 2023 19:06:19 -0700    

When COPYing into a partitioned table that does now permit the use of  
table_multi_insert(), we could error out with  
  ERROR: could not read block NN in file "base/...": read only 0 of 8192 bytes  
  
because BulkInsertState->next_free was not reset between partitions. This  
problem occurred only when not able to use table_multi_insert(), as a  
dedicated BulkInsertState for each partition is used in that case.  
  
The bug was introduced in 00d1e02be24, but it was hard to hit at that point,  
as commonly bulk relation extension is not used when not using  
table_multi_insert(). It became more likely after 82a4edabd27, which expanded  
the use of bulk extension.  
  
To fix the bug, reset the bulk relation extension state in BulkInsertState in  
ReleaseBulkInsertStatePin(). That was added (in b1ecb9b3fcf) to tackle a very  
similar issue.  Obviously the name is not quite correct, but there might be  
external callers, and bulk insert state needs to be reset in precisely in the  
situations that ReleaseBulkInsertStatePin() already needed to be called.  
  
Medium term the better fix likely is to disallow reusing BulkInsertState  
across relations.  
  
Add a test that, without the fix, reproduces #18130 in most  
configurations. The test also catches the problem fixed in b1ecb9b3fcf when  
run with small shared_buffers.  
  
Reported-by: Ivan Kolombet <[email protected]>  
Analyzed-by: Tom Lane <[email protected]>  
Analyzed-by: Andres Freund <[email protected]>  
Bug: #18130  
Discussion: https://postgr.es/m/18130-7a86a7356a75209d%40postgresql.org  
Discussion: https://postgr.es/m/257696.1695670946%40sss.pgh.pa.us  
Backpatch: 16-  

commit   : 595db9e9cc41a59c43e1c63bf4a4d4b9862d893c    
  
author   : David Rowley <[email protected]>    
date     : Fri, 13 Oct 2023 01:13:07 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 13 Oct 2023 01:13:07 +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   : f114e16f6ce8792d35ffae937325e0f2bb4f6609    
  
author   : David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 21:15:58 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 21:15:58 +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   : 6352f1627641025f90423b44716b6ad5f2adb7b6    
  
author   : David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 19:51:26 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 12 Oct 2023 19:51:26 +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   : 4ac7635fdbb7dce58898161a1cc5caf40426335f    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 17:12:00 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 17:12:00 -0400    

Also update docs to use more recent old version numbers  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16  

commit   : 608ccdbe250a39e21727a05d9f6f6ba0e20476d9    
  
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   : 17fff5a6eff3de0b4fe4f43d9939fb8c3d480256    
  
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   : 61fcc9d440cb85a6799fa309ef9c61e658215a11    
  
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   : b01a5e71d89e8bc674d609bf52702008e73c0859    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 15:27:26 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Oct 2023 15:27:26 -0400    

Discussion: https://postgr.es/m/167931662853.3349090.18217722739345182859@wrigleys.postgresql.org  
  
Backpatch-through: 16  

commit   : 63e7cac0199d0a5088c8ba2410656fabea44e5e3    
  
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   : b8963e8a28545275c4d3288aa9bf50ce73f537af    
  
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   : e943cff33d6bc6db3011a243d9b7ccd1a0472e62    
  
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   : 9154ededfc99e7637cd61b4ca10f28796125ece2    
  
author   : David Rowley <[email protected]>    
date     : Mon, 9 Oct 2023 16:37:33 +1300    
  
committer: David Rowley <[email protected]>    
date     : Mon, 9 Oct 2023 16:37:33 +1300    

1349d2790 added code to adjust the PlannerInfo.group_pathkeys so that  
ORDER BY / DISTINCT aggregate functions could obtain pre-sorted inputs  
to allow faster execution.  That commit forgot to adjust the pathkeys in  
create_agg_path().  Some code in there assumed that it was always fine  
to make the AggPath's pathkeys the same as its subpath's.  That seems to  
have been ok up until 1349d2790, but since that commit adds pathkeys for  
columns which are within the aggregate function, those columns won't be  
available above the aggregate node.  This can result in "could not find  
pathkey item to sort" during create_plan().  
  
The fix here is to strip off the additional pathkeys added by  
adjust_group_pathkeys_for_groupagg().  It seems that the pathkeys here  
will only ever be group_pathkeys, so all we need to do is check if the  
length of the pathkey list is longer than the num_groupby_pathkeys and  
get rid of the additional ones only if we see extras.  
  
Reported-by: Justin Pryzby  
Reviewed-by: Richard Guo  
Discussion: https://postgr.es/m/ZQhYYRhUxpW3PSf9%40telsasoft.com  
Backpatch-through: 16, where 1349d2790 was introduced  

commit   : 3ed98ed88a06f368c700d2ce03ff46d6d415dde3    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 6 Oct 2023 18:30:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 6 Oct 2023 18:30:01 +0900    

commit   : 31b2b2d72d9c50be415c6340ebf4ad83a472590c    
  
author   : David Rowley <[email protected]>    
date     : Thu, 5 Oct 2023 20:31:25 +1300    
  
committer: David Rowley <[email protected]>    
date     : Thu, 5 Oct 2023 20:31:25 +1300    

Ensure we switch to the per-tuple memory context to prevent any memory  
leaks of detoasted Datums in MemoizeHash_hash() and MemoizeHash_equal().  
  
Reported-by: Orlov Aleksej  
Author: Orlov Aleksej, David Rowley  
Discussion: https://postgr.es/m/83281eed63c74e4f940317186372abfd%40cft.ru  
Backpatch-through: 14, where Memoize was added  

commit   : 75f31a3f26744ca71a4214d4ab0c7f6cac4a0421    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 3 Oct 2023 15:37:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 3 Oct 2023 15:37:18 +0900    

The code in charge of copying the contents of PgBackendStatus to local  
memory could fail on memory allocation because of an overflow on the  
amount of memory to use.  The overflow can happen when combining a high  
value track_activity_query_size (max at 1MB) with a large  
max_connections, when both multiplied get higher than INT32_MAX as both  
parameters treated as signed integers.  This could for example trigger  
with the following functions, all calling pgstat_read_current_status():  
- pg_stat_get_backend_subxact()  
- pg_stat_get_backend_idset()  
- pg_stat_get_progress_info()  
- pg_stat_get_activity()  
- pg_stat_get_db_numbackends()  
  
The change to use MemoryContextAllocHuge() has been introduced in  
8d0ddccec636, so backpatch down to 12.  
  
Author: Jakub Wartak  
Discussion: https://postgr.es/m/CAKZiRmw8QSNVw2qNK-dznsatQqz+9DkCquxP0GHbbv1jMkGHMA@mail.gmail.com  
Backpatch-through: 12  

commit   : a06efbc3ac72a455a63635c9cbc56ad3338988cc    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 3 Oct 2023 10:25:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 3 Oct 2023 10:25:12 +0900    

This commit changes the WAL reader routines so as a FATAL for the  
backend or exit(FAILURE) for the frontend is triggered if an allocation  
for a WAL record decode fails in walreader.c, rather than treating this  
case as bogus data, which would be equivalent to the end of WAL.  The  
key is to avoid palloc_extended(MCXT_ALLOC_NO_OOM) in walreader.c,  
relying on plain palloc() calls.  
  
The previous behavior could make WAL replay finish too early than it  
should.  For example, crash recovery finishing earlier may corrupt  
clusters because not all the WAL available locally was replayed to  
ensure a consistent state.  Out-of-memory failures would show up  
randomly depending on the memory pressure on the host, but one simple  
case would be to generate a large record, then replay this record after  
downsizing a host, as Ethan Mertz originally reported.  
  
This relies on bae868caf222, as the WAL reader routines now do the  
memory allocation required for a record only once its header has been  
fully read and validated, making xl_tot_len trustable.  Making the WAL  
reader react differently on out-of-memory or bogus record data would  
require ABI changes, so this is the safest choice for stable branches.  
Also, it is worth noting that 3f1ce973467a has been using a plain  
palloc() in this code for some time now.  
  
Thanks to Noah Misch and Thomas Munro for the discussion.  
  
Like the other commit, backpatch down to 12, leaving out v11 that will  
be EOL'd soon.  The behavior of considering a failed allocation as bogus  
data comes originally from 0ffe11abd3a0, where the record length  
retrieved from its header was not entirely trustable.  
  
Reported-by: Ethan Mertz  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : aaaf8fbb67f844cd0b20648697320d940b4b8eb9    
  
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   : 4a97a43a73cbdb883b61161df35454696b96b336    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 2 Oct 2023 12:39:35 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 2 Oct 2023 12:39:35 +0300    

bgwriter can write out WAL, but did not flush the WAL pgstat counters,  
so the writes were not seen in pg_stat_wal.  
  
Back-patch to v14, where pg_stat_wal was introduced.  
  
Author: Nazir Bilal Yavuz  
Reviewed-by: Matthias van de Meent, Kyotaro Horiguchi  
Discussion: https://www.postgresql.org/message-id/CAN55FZ2FPYngovZstr%3D3w1KSEHe6toiZwrurbhspfkXe5UDocg%40mail.gmail.com  

commit   : 5c34a7374c4dff8065096edcae4cd425a54babd6    
  
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   : ea0e7cd6b87fe16937604ac1829d6d94bd99065d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2023 12:09:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Oct 2023 12:09:26 -0400    

In recent releases, such cases fail with "cache lookup failed for  
function 0" rather than complaining that the conversion function  
doesn't exist as prior versions did.  Seems to be a consequence of  
sloppy refactoring in commit f82de5c46.  Add the missing error check.  
  
Per report from Pierre Fortin.  Back-patch to v14 where the  
oversight crept in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 910eb61b2bbdb729c242ed20d5f6e0a392eb62da    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 1 Oct 2023 10:18:41 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 1 Oct 2023 10:18:41 -0400    

Commit 9f8377f7a2 was a little too eager in fetching default values.  
Normally this would not matter, but if the default value is not valid  
for the type (e.g. a varchar that's too long) it caused an unnecessary  
error.  
  
Complaint and fix from Laurenz Albe  
  
Backpatch to release 16.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d5c5312dc8b66b4ad652ec54ed32029d621e1e93    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 30 Sep 2023 12:10:15 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 30 Sep 2023 12:10:15 -0700    

-exported_symbols_list=... works on Ventura and earlier, but not on  
Sonoma. The easiest way to fix it is to -Wl,-exported_symbols_list,@0@ which  
actually seems more appropriate anyway, it's obviously a linker argument. It  
is easier to use the -Wl,, syntax than passing multiple arguments, due to the  
way the export_fmt is used (a single string that's formatted), but if it turns  
out to be necessary, we can go for multiple arguments as well.  
  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-, where the meson based buildsystem was added  

commit   : 992d2ca81d2b846e253d4394dac8cd2509fd071a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sat, 30 Sep 2023 17:07:24 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sat, 30 Sep 2023 17:07:24 +0300    

ANALYZE on a table with inheritance children analyzes all the child  
tables in a loop. When stepping to next child table, it updated the  
child rel ID value in the command progress stats, but did not reset  
the 'sample_blks_total' and 'sample_blks_scanned' counters.  
acquire_sample_rows() updates 'sample_blks_total' as soon as the scan  
starts and 'sample_blks_scanned' after processing the first block, but  
until then, pg_stat_progress_analyze would display a bogus combination  
of the new child table relid with old counter values from the  
previously processed child table. Fix by resetting 'sample_blks_total'  
and 'sample_blks_scanned' to zero at the same time that  
'current_child_table_relid' is updated.  
  
Backpatch to v13, where pg_stat_progress_analyze view was introduced.  
  
Reported-by: Justin Pryzby  
Discussion: https://www.postgresql.org/message-id/20230122162345.GP13860%40telsasoft.com  

commit   : 6d2de076cbf078cd1d6d0df2136fe5b1da96d1fe    
  
author   : Dean Rasheed <[email protected]>    
date     : Sat, 30 Sep 2023 10:54:29 +0100    
  
committer: Dean Rasheed <[email protected]>    
date     : Sat, 30 Sep 2023 10:54:29 +0100    

Under some circumstances, concurrent MERGE operations could lead to  
inconsistent results, that varied according the plan chosen. This was  
caused by a lack of rowmarks on the source relation, which meant that  
EvalPlanQual rechecking was not guaranteed to return the same source  
tuples when re-running the join query.  
  
Fix by ensuring that preprocess_rowmarks() sets up PlanRowMarks for  
all non-target relations used in MERGE, in the same way that it does  
for UPDATE and DELETE.  
  
Per bug #18103. Back-patch to v15, where MERGE was introduced.  
  
Dean Rasheed, reviewed by Richard Guo.  
  
Discussion: https://postgr.es/m/18103-c4386baab8e355e3%40postgresql.org  

commit   : 594866421433c5ca54e7110b149f8a13458abd59    
  
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   : 527c3c1bec65634135e2b1707ebc1a3c737f9458    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 29 Sep 2023 14:32:16 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 29 Sep 2023 14:32:16 -0400    

Fix for commit 2882d1f31a.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 2882d1f31a92552b5e0df3ab8ccfb4f9c75ab2e6    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 29 Sep 2023 14:15:57 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 29 Sep 2023 14:15:57 -0400    

Reported-by: TAKATSUKA Haruka  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 16 only  

commit   : 75c562653cbe0e658b8448307c575fb070685a80    
  
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   : 19bc6fda8bc3b7ab8117f8f7622066121de9ca6a    
  
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   : 2e5cc553a881ac0d49357b02d3c092edbe8ca05c    
  
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   : 950e236e50691d80e50d0aa18b66d1f459105558    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 29 Sep 2023 10:34:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 29 Sep 2023 10:34:18 +0900    

Since 45b1a67a0fcb, non-printable ASCII characters do not show up in  
various configuration paths as question marks, but as hexadecimal  
escapes.  The documentation was not updated to reflect that.  
  
Author: Hayato Kuroda  
Reviewed-by: Jian He, Tom Lane, Karl O. Pinc, Peter Smith  
Discussion: https://postgr.es/m/TYAPR01MB586631D0961BF9C44893FAB1F523A@TYAPR01MB5866.jpnprd01.prod.outlook.com  
Backpatch-through: 16  

commit   : 3fa81b62e09befc0e839b2e1ef9ea92ef854a77d    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 28 Sep 2023 16:29:35 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 28 Sep 2023 16:29:35 -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   : 12402b93117be733985418c6fdeda5f09877469e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Sep 2023 14:05:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Sep 2023 14:05:25 -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   : 7e00466a78be71a440ea683b971b1a19c34074ca    
  
author   : David Rowley <[email protected]>    
date     : Fri, 29 Sep 2023 00:02:56 +1300    
  
committer: David Rowley <[email protected]>    
date     : Fri, 29 Sep 2023 00:02:56 +1300    

Tid Range scans were added back in bb437f995.  That commit forgot to add  
handling for TidRangePaths in print_path().  
  
Only people building with OPTIMIZER_DEBUG might have noticed this, which  
likely is the reason it's taken 4 years for anyone to notice.  
  
Author: Andrey Lepikhov  
Reported-by: Andrey Lepikhov  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 14, where bb437f995 was introduced  

commit   : 8bdfc53be48ae99109a05df1dfd203d35207733f    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 28 Sep 2023 19:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 28 Sep 2023 19:45:01 +0900    

commit   : 8d05be93197cd37ef232bd367bb46fa932a557b9    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 27 Sep 2023 14:20:57 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 27 Sep 2023 14:20:57 +0530    

The pgoutput module uses a global variable (publish_no_origin) to cache  
the action for the origin filter, but we didn't reset the flag when  
shutting down the output plugin, so subsequent retries may access the  
previous publish_no_origin value.  
  
We fix this by storing the flag in the output plugin's private data.  
Additionally, the patch removes the currently unused origin string from the  
structure.  
  
For the back branch, to avoid changing the exposed structure, we eliminated the  
global variable and instead directly used the origin string for change  
filtering.  
  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila, Michael Paquier  
Backpatch-through: 16  
Discussion: http://postgr.es/m/OS0PR01MB571690EF24F51F51EFFCBB0E94FAA@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 641db601b72fc501b10e02ce1a018d9d103d355c    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 27 Sep 2023 14:41:15 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 27 Sep 2023 14:41:15 +0900    

As coded, the module's Makefile would fail to set a value for PYTHON as  
it checked if the variable is defined.  When compiling without  
--with-python, PYTHON is defined and set to an empty value, so the  
existing check is not able to do its work.  
  
This commit switches the rule to check if the value is empty rather than  
defined, allowing the generation of unaccent.rules even if --with-python  
is not used as long as "python" exists.  BISON and FLEX do the same in  
pgxs.mk, for instance.  
  
Thinko in f85a485f89e2.  
  
Author: Japin Li  
Discussion: https://postgr.es/m/MEYP282MB1669F86C0DC7B4DC48489CB0B6C3A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  
Backpatch-through: 13  

commit   : e73d6a0df42c39509141140ca227013092ad846b    
  
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   : 2ef5c5e736b8b13d777d5ecc66099a785ca108ad    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:44:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:44:22 -0400    

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

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

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

commit   : 362b94d02aa55d5800cd1acdf217a3520af4a577    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:02:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 19:02:18 -0400    

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

commit   : b21ec201c0526d61ce22cb1f5e97df2c02279347    
  
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   : 17cd48de3ce3061059257b56b4ae689e45137668    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 17:31:06 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 17:31:06 -0400    

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

commit   : e391939b76f941544fdb512b147950b71e8ee358    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 12:08:49 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 26 Sep 2023 12:08:49 -0400    

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

commit   : d7f521325f5db13c62749adc991cd16038385219    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 26 Sep 2023 14:14:49 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 26 Sep 2023 14:14:49 +0300    

Yet another bug in the ilk of commits a7ee7c851 and 741b88435. In  
741b88435, we took care to clear the memorized location of the  
downlink when we split the parent page, because splitting the parent  
page can move the downlink. But we missed that even *updating* a tuple  
on the parent can move it, because updating a tuple on a gist page is  
implemented as a delete+insert, so the updated tuple gets moved to the  
end of the page.  
  
This commit fixes the bug in two different ways (belt and suspenders):  
  
1. Clear the downlink when we update a tuple on the parent page, even  
   if it's not split. This the same approach as in commits a7ee7c851  
   and 741b88435.  
  
   I also noticed that gistFindCorrectParent did not clear the  
   'downlinkoffnum' when it stepped to the right sibling. Fix that  
   too, as it seems like a clear bug even though I haven't been able  
   to find a test case to hit that.  
  
2. Change gistFindCorrectParent so that it treats 'downlinkoffnum'  
   merely as a hint. It now always first checks if the downlink is  
   still at that location, and if not, it scans the page like before.  
   That's more robust if there are still more cases where we fail to  
   clear 'downlinkoffnum' that we haven't yet uncovered. With this,  
   it's no longer necessary to meticulously clear 'downlinkoffnum',  
   so this makes the previous fixes unnecessary, but I didn't revert  
   them because it still seems nice to clear it when we know that the  
   downlink has moved.  
  
Also add the test case using the same test data that Alexander  
posted. I tried to reduce it to a smaller test, and I also tried to  
reproduce this with different test data, but I was not able to, so  
let's just include what we have.  
  
Backpatch to v12, like the previous fixes.  
  
Reported-by: Alexander Lakhin  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 280f70221ba5b5fbba7db3d0bff4391ca7c54540    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 26 Sep 2023 09:30:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 26 Sep 2023 09:30:36 +0900    

As implemented in 5891c7a8ed8f, setting "force" to true in  
pgstat_report_wal() causes the routine to not wait for the pgstat  
shmem lock if it cannot be acquired, in which case the WAL and I/O  
statistics finish by not being flushed.  The origin of the confusion  
comes from pgstat_flush_wal() and pgstat_flush_io(), that use "nowait"  
as sole argument.  The I/O stats are new in v16.  
  
This is the opposite behavior of what has been used in  
pgstat_report_stat(), where "force" is the opposite of "nowait".  In  
this case, when "force" is true, the routine sets "nowait" to false,  
which would cause the routine to wait for the pgstat shmem lock,  
ensuring that the stats are always flushed.  When "force" is false,  
"nowait" is set to true, and the stats would only not be flushed if the  
pgstat shmem lock can be acquired, returning immediately without  
flushing the stats if the lock cannot be acquired.  
  
This commit changes pgstat_report_wal() so as "force" has the same  
behavior as in pgstat_report_stat().  There are currently three callers  
of pgstat_report_wal():  
- Two in the checkpointer where force=true during a shutdown and the  
main checkpointer loop.  Now the code behaves so as the stats are always  
flushed.  
- One in the main loop of the bgwriter, where force=false.  Now the code  
behaves so as the stats would not be flushed if the pgstat shmem lock  
could not be acquired.  
  
Before this commit, some stats on WAL and I/O could have been lost after  
a shutdown, for example.  
  
Reported-by: Ryoga Yoshida  
Author: Ryoga Yoshida, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15  

commit   : b7f92b1150d1fadfda13d7a2ca9138e7400d6e40    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 26 Sep 2023 08:16:41 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 26 Sep 2023 08:16:41 +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   : 10d0591ea2274e5a471a1a489f7714303b88c329    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 26 Sep 2023 09:07:26 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 26 Sep 2023 09:07:26 +1300    

bae868ca removed a check that was still needed.  If you had an  
xl_tot_len at the end of a page that was too small for a record header,  
but not big enough to span onto the next page, we'd immediately perform  
the CRC check using a bogus large length.  Because of arbitrary coding  
differences between the CRC implementations on different platforms,  
nothing very bad happened on common modern systems.  On systems using  
the _sb8.c fallback we could segfault.  
  
Restore that check, add a new assertion and supply a test for that case.  
Back-patch to 12, like bae868ca.  
  
Tested-by: Tom Lane <[email protected]>  
Tested-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLCkTT7zYjzOxuLGahBdQ%3DMcF%3Dz5ZvrjSOnW4EDhVjT-g%40mail.gmail.com  

commit   : 881defde944c07d821d9658b1943d5ad5ef5bf37    
  
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   : 055f786ea6a8e17058a55f0b0b5dc976e2de03b0    
  
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   : 72bf3f0877fe7ae9a22c23f461d0fdafb6af5c4b    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 25 Sep 2023 10:36:04 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 25 Sep 2023 10:36:04 -0700    

Without the added "relation" it's not immediately clear that the option  
relates to the relation segment size and not e.g. the WAL segment size.  
  
The option was added in d3b111e32.  
  
Reported-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 16-  

commit   : 8465efc1a0e721a070221c4aa83695422922b620    
  
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   : 9aa3881b2d61a50052d2f5e26a1d941d2d500bd6    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 25 Sep 2023 16:03:32 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 25 Sep 2023 16:03:32 +0200    

The --help output stated that schemas were specified using PATTERN  
when they in fact aren't pattern matched but are required to be  
exact matches. This changes to SCHEMA to make that clear.  
  
Backpatch through v16 where this was introduced.  
  
Author: Kuwamura Masaki <[email protected]>  
Discussion: https://postgr.es/m/CAMyC8qp9mXPQd5D6s6CJxvmignsbTqGZwDDB6VYJOn1A8WG38w@mail.gmail.com  
Backpatch-through: 16  

commit   : 2143d96dc7b72b62166d711283d5925b7180bf85    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Mon, 25 Sep 2023 16:03:17 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Mon, 25 Sep 2023 16:03:17 +0200    

When specifying multiple schemas to exclude with -N parameters, none  
of the schemas are actually excluded (a single -N worked as expected).  
This fixes the catalog query to handle multiple exclusions and adds a  
test for this case.  
  
Backpatch to v16 where this was introduced.  
  
Author: Nathan Bossart <[email protected]>  
Author: Kuwamura Masaki <[email protected]>  
Reported-by: Kuwamura Masaki <[email protected]>  
Discussion: https://postgr.es/m/CAMyC8qp9mXPQd5D6s6CJxvmignsbTqGZwDDB6VYJOn1A8WG38w@mail.gmail.com  
Backpatch-through: 16  

commit   : fb9ddd0fafeaacb8d382c66ae545cba1a4ed7886    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 25 Sep 2023 14:34:06 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 25 Sep 2023 14:34:06 +0200    

Commit cda6a8d01d39 removed a few datatypes, but didn't update  
pg_upgrade --check to throw error if these types are used.  So the users  
find that pg_upgrade --check tells them that everything is fine, only to  
fail when the real upgrade is attempted.  
  
Reviewed-by: Tristan Partin <[email protected]>  
Reviewed-by: Suraj Kharage <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : cc58607b019ad6dd3231e54c597e6c1bc07a8132    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 23 Sep 2023 14:13:06 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 23 Sep 2023 14:13:06 +1200    

'Q' for 64 bit integers turns out not to work on 32 bit Perl, as  
revealed by the build farm.  Use 'II' instead, and deal with endianness.  
  
Back-patch to 12, like bae868ca.  
  
Discussion: https://postgr.es/m/ZQ4r1vHcryBsSi_V%40paquier.xyz  

commit   : ce497f648e2dea12cd232d7bf13ad7f7a4f244aa    
  
author   : Thomas Munro <[email protected]>    
date     : Sat, 23 Sep 2023 10:26:24 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Sat, 23 Sep 2023 10:26:24 +1200    

xl_tot_len comes first in a WAL record.  Usually we don't trust it to be  
the true length until we've validated the record header.  If the record  
header was split across two pages, previously we wouldn't do the  
validation until after we'd already tried to allocate enough memory to  
hold the record, which was bad because it might actually be garbage  
bytes from a recycled WAL file, so we could try to allocate a lot of  
memory.  Release 15 made it worse.  
  
Since 70b4f82a4b5, we'd at least generate an end-of-WAL condition if the  
garbage 4 byte value happened to be > 1GB, but we'd still try to  
allocate up to 1GB of memory bogusly otherwise.  That was an  
improvement, but unfortunately release 15 tries to allocate another  
object before that, so you could get a FATAL error and recovery could  
fail.  
  
We can fix both variants of the problem more fundamentally using  
pre-existing page-level validation, if we just re-order some logic.  
  
The new order of operations in the split-header case defers all memory  
allocation based on xl_tot_len until we've read the following page.  At  
that point we know that its first few bytes are not recycled data, by  
checking its xlp_pageaddr, and that its xlp_rem_len agrees with  
xl_tot_len on the preceding page.  That is strong evidence that  
xl_tot_len was truly the start of a record that was logged.  
  
This problem was most likely to occur on a standby, because  
walreceiver.c recycles WAL files without zeroing out trailing regions of  
each page.  We could fix that too, but it wouldn't protect us from rare  
crash scenarios where the trailing zeroes don't make it to disk.  
  
With reliable xl_tot_len validation in place, the ancient policy of  
considering malloc failure to indicate corruption at end-of-WAL seems  
quite surprising, but changing that is left for later work.  
  
Also included is a new TAP test to exercise various cases of end-of-WAL  
detection by writing contrived data into the WAL from Perl.  
  
Back-patch to 12.  We decided not to put this change into the final  
release of 11.  
  
Author: Thomas Munro <[email protected]>  
Author: Michael Paquier <[email protected]>  
Reported-by: Alexander Lakhin <[email protected]>  
Reviewed-by: Noah Misch <[email protected]> (the idea, not the code)  
Reviewed-by: Michael Paquier <[email protected]>  
Reviewed-by: Sergei Kornilov <[email protected]>  
Reviewed-by: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/17928-aa92416a70ff44a2%40postgresql.org  

commit   : 2290a13827dc3a8c558280b9d3f9f929e4fd9885    
  
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   : f720875a4670f94c6d8acd288a2a62c7cabb92dd    
  
author   : Daniel Gustafsson <[email protected]>    
date     : Fri, 22 Sep 2023 11:18:25 +0200    
  
committer: Daniel Gustafsson <[email protected]>    
date     : Fri, 22 Sep 2023 11:18:25 +0200    

Guard against the pointer being NULL before pfreeing upon an error  
returned from OpenSSL.  Also handle errors from X509_NAME_print_ex  
which also can return -1 on memory allocation errors.  
  
Backpatch down to v15 where the code was added.  
  
Author: Sergey Shinderuk <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: v15  

commit   : 227c7cf15602fa21af7eea1bd11375b7572649e3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Sep 2023 23:11:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Sep 2023 23:11:30 -0400    

In older branches, COMMIT/ROLLBACK AND CHAIN failed to propagate  
the current transaction's properties to the new transaction if  
there was any open subtransaction (unreleased savepoint).  
Instead, some previous transaction's properties would be restored.  
This is because the "if (s->chain)" check in CommitTransactionCommand  
examined the wrong instance of the "chain" flag and falsely  
concluded that it didn't need to save transaction properties.  
  
Our regression tests would have noticed this, except they used  
identical transaction properties for multiple tests in a row,  
so that the faulty behavior was not distinguishable from correct  
behavior.  
  
Commit 12d768e70 fixed the problem in v15 and later, but only rather  
accidentally, because I removed the "if (s->chain)" test to avoid a  
compiler warning, while not realizing that the warning was flagging a  
real bug.  
  
In v14 and before, remove the if-test and save transaction properties  
unconditionally; just as in the newer branches, that's not expensive  
enough to justify thinking harder.  
  
Add the comment and extra regression test to v15 and later to  
forestall any future recurrence, but there's no live bug in those  
branches.  
  
Patch by me, per bug #18118 from Liu Xiang.  Back-patch to v12 where  
the AND CHAIN feature was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dce4544414bda6738fbec501b504d831d918defa    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 21 Sep 2023 11:27:29 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 21 Sep 2023 11:27:29 -0400    

Reported-by: Dave Page  
  
Author: Dave Page  
  
Backpatch-through: 16 only  

commit   : 3e2fe325526279086e7c1cc080d9152185b936a3    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 21 Sep 2023 19:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 21 Sep 2023 19:45:01 +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   : f7dbdab051d08b1b728b17dbc2b18b7e4f16734c    
  
author   : David Rowley <[email protected]>    
date     : Thu, 21 Sep 2023 17:15:02 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 21 Sep 2023 17:15:02 +1200    

ae78cae3b added the --buffer-usage-limit to vacuumdb to allow it to  
include the BUFFER_USAGE_LIMIT option in the VACUUM command.  
Unfortunately, that commit forgot to adjust the code so the option was  
added to the ANALYZE command when the -Z command line argument was  
specified.  
  
There were no issues with the -z command as that option just adds  
ANALYZE to the VACUUM command.  
  
In passing adjust the code to escape the --buffer-usage-limit option  
before passing it to the server.  It seems nothing beyond a confusing  
error message could become this lack of escaping as VACUUM cannot be  
specified in a multi-command string.  
  
Reported-by: Ryoga Yoshida  
Author: Ryoga Yoshida, David Rowley  
Discussion: https://postgr.es/m/08930c0b541700a5264e5fbf3a685f5a%40oss.nttdata.com  
Backpatch-through: 16, where ae78cae3b was introduced.  

commit   : 3701db77a08ecbd28c6f600de81f53d3712568fe    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 20 Sep 2023 13:37:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 20 Sep 2023 13:37:02 +0900    

BUFFER_USAGE_LIMIT requires a parameter, and 'B' is a supported unit.  
  
Author: Ryoga Yoshida  
Reviewed-by: Shinya Kato  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 64276c7e45e602e82da24798e5d1b272c639e8bd    
  
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   : f171430f089a349cb5694fb43a64579d6a9c2a2b    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 19 Sep 2023 08:31:22 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 19 Sep 2023 08:31:22 +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   : ec693a3f304cf91c717c0fe07abcd4185952fde5    
  
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   : 53630f12d39b9c5d98abb7bae4818715306422ed    
  
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   : 3f94dfc00870129051ed507461ba1c8a693e60b3    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 16:00:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 16:00:36 +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   : c4758649b4db7d0c4b681985d24cc3e1e938047d    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 13 Sep 2023 19:14:11 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 13 Sep 2023 19:14:11 -0700    

Karina figured out that I (Andres) confused BufferUsage.temp_blks_written with  
BufferUsage.local_blks_written in fcdda1e4b5.  
  
Tests in core PG can't easily test this, as BufferUsage is just used for  
EXPLAIN (ANALYZE, BUFFERS) and pg_stat_statements. Thus this commit adds tests  
for this to pg_stat_statements.  
  
Reported-by: Karina Litskevich <[email protected]>  
Author: Karina Litskevich <[email protected]>  
Author: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/CACiT8ibxXA6+0amGikbeFhm8B84XdQVo6D0Qfd1pQ1s8zpsnxQ@mail.gmail.com  
Backpatch: 16-, where fcdda1e4b5 was merged  

commit   : be3dfd3dff03b56ad283f14640440972c60c0588    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 10:30:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 10:30:23 +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   : 800d5bcb982b096a71438f36b8b22a3b5b557aa9    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 08:35:06 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 14 Sep 2023 08:35:06 +0900    

These code paths should not be reached normally, but if they are an  
error with "(null)" as information for the collation provider would show  
up if no locale is set, while we can assume that we are referring to  
libc.  
  
This refactors the code so as the provider is always reported even if no  
locale is set.  The name of the function where the error happens is  
added, while on it, as it can be helpful for debugging.  
  
Issue introduced by d87d548cd030, so backpatch down to 16.  
  
Author: Michael Paquier, Ranier Vilela  
Reviewed-by: Jeff Davis, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 16  

commit   : 1a6900e58ae2c61b84b516901985e405b9d457b7    
  
author   : David Rowley <[email protected]>    
date     : Thu, 14 Sep 2023 11:27:16 +1200    
  
committer: David Rowley <[email protected]>    
date     : Thu, 14 Sep 2023 11:27:16 +1200    

Both 50e17ad28 and 29f45e299 mistakenly tried to record a plan dependency  
on a function but mistakenly inverted the OidIsValid test.  This meant  
that we'd record a dependency only when the function's Oid was  
InvalidOid.  Clearly this was meant to *not* record the dependency in  
that case.  
  
50e17ad28 made this mistake first, then in v15 29f45e299 copied the same  
mistake.  
  
Reported-by: Tom Lane  
Backpatch-through: 14, where 50e17ad28 first made this mistake  
Discussion: https://postgr.es/m/[email protected]  

commit   : a81e5516fa4bc53e332cb35eefe231147c0e1749    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 13 Sep 2023 09:48:31 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 13 Sep 2023 09:48:31 +0530    

Reported-by: Jeff Davis  
Author: Hou Zhijie  
Reviewed-by: Amit Kapila  
Backpatch-through: 16  
Discussion: http://postgr.es/m/[email protected]  

commit   : f899c7f1eae43a95ae5d221e754283d8fcfe8bc1    
  
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   : 3f7b7d9df2dc7aa14add615c7af8fbc1092509b9    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 13 Sep 2023 09:53:52 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 13 Sep 2023 09:53:52 +0900    

This changes 020_cancel.pl so as the test is entirely skipped on  
Windows.  This test was already doing nothing under WIN32, except  
initializing and starting a node without using it so this shaves a few  
test cycles.  
  
Author: Yugo NAGATA  
Reviewed-by: Fabien Coelho  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 15