PostgreSQL 15.0 commit log

commit   : 2a7ce2e2ce474504a707ec03e128fde66cfb8b48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:57:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:57:37 -0400    

Drat, forgot this ...  

commit   : 957d1993c13d8477a3db5e319ece845fb3e0e5a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:28:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2022 16:28:16 -0400    

commit   : 77d500abb8a112df81486b1a717d3dd09479070e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 12:03:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 12:03:38 +0200    

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

commit   : 48c81b57e942075f40702787f14acb2451871b4f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 08:15:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 10 Oct 2022 08:15:29 +0200    

current through c3b5992b91c4b0d2c4f4eab0fb856f34854c129d  

commit   : c3b5992b91c4b0d2c4f4eab0fb856f34854c129d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 8 Oct 2022 09:33:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 8 Oct 2022 09:33:23 -0700    

Previously PgStat_StatReplSlotEntry contained the slotname, which was mainly  
used when writing out the stats during shutdown, to identify the slot in the  
serialized data (at runtime the index in ReplicationSlotCtl->replication_slots  
is used, but that can change during a restart). Unfortunately the slotname was  
overwritten when the slot's stats were reset.  
  
That turned out to only cause "real" problems if the slot was active during  
the reset, triggering an assertion failure at the next  
pgstat_report_replslot(). In other paths the stats were re-initialized during  
pgstat_acquire_replslot().  
  
Fix this by removing slotname from PgStat_StatReplSlotEntry. Instead we can  
get the slot's name from the slot itself. Besides fixing a bug, this also is  
architecturally cleaner (a name is not really statistics). This is safe  
because stats, for a slot removed while shut down, will not be restored at  
startup.  
  
In 15 the slotname is not removed, but renamed, to avoid changing the stats  
format. In master, bump PGSTAT_FILE_FORMAT_ID.  
  
This commit does not contain a test for the fix. I think this can only be  
tested by a tap test starting pg_recvlogical in the background and checking  
pg_recvlogical's output. That type of test is notoriously hard to be reliable,  
so committing it shortly before the release is wrapped seems like a bad idea.  
  
Reported-by: Jaime Casanova <jcasanov@systemguards.com.ec>  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/YxfagaTXUNa9ggLb@ahch-to  
Backpatch: 15-, where the bug was introduced in 5891c7a8ed8f  

commit   : 6083132abdd46462a0eca15412bb35fa3495eab2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Oct 2022 19:37:48 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Oct 2022 19:37:48 +0200    

There are a number of bugs in this area.  Two of them are fixed here,  
namely:  
1. get_relation_idx_constraint_oid does not restrict the type of  
   constraint that's returned, so with sufficient bad luck it can  
   return the OID of a foreign key constraint.  This has the effect that  
   a primary key in a partition can end up as a child of a foreign key,  
   which makes no sense (it needs to be the child of the equivalent  
   primary key.)  
   Change the API contract so that only index-backed constraints are  
   returned, mimicking get_constraint_index().  
  
2. Both CloneFkReferenced and CloneFkReferencing clone a  
   self-referencing foreign key, so the partition ends up with  
   a duplicate foreign key.  Change the former function to ignore such  
   constraints.  
  
Add some tests to verify that things are better now.  (However, these  
new tests show some additional misbehavior that will be fixed later --  
namely that there's a constraint marked NOT VALID.)  
  
Backpatch to 12, where these constraints are possible at all.  
  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://postgr.es/m/20220603154232.1715b14c@karst  

commit   : be5cf460817b54c31dcf84f8e9b947c902327ae9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 16:17:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 16:17:30 -0400    

Reported-by: Elena Indrupskaya  
  
Discussion: https://postgr.es/m/0af43b49-1646-93d0-ccf1-bb3c635c8c6f@postgrespro.ru  
  
Author: Elena Indrupskaya  
  
Backpatch-through: 15 only  

commit   : d2d67949f5ca95cf4bd66d849e947f3bbe065e0d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 15:53:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Oct 2022 15:53:40 -0400    

Reported-by: Elena Indrupskaya  
  
Discussion: https://postgr.es/m/0af43b49-1646-93d0-ccf1-bb3c635c8c6f@postgrespro.ru  
  
Author: Elena Indrupskaya  
  
Backpatch-through: 15  

commit   : 2a40d040c924b1707cd03a9c66c80fcc4795c2d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 17:03:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 17:03:12 -0400    

commit   : 595580aa1243df5f199516ff11a27ba9680e6904    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 15:07:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 15:07:10 -0400    

The pre-v15 behavior was to discard all but the last result,  
but with the new behavior of printing all results by default,  
we will send each such result to the \g file.  However,  
we're still opening and closing the \g file for each result,  
so you lose all but the last result anyway.  Move the output-file  
state up to ExecQueryAndProcessResults so that we open/close the  
\g file only once per command string.  
  
To support this without changing other behavior, we must  
adjust PrintQueryResult to have separate FILE * arguments  
for query and status output (since status output has never  
gone to the \g file).  That in turn makes it a good idea  
to push the responsibility for fflush'ing output down to  
PrintQueryTuples and PrintQueryStatus.  
  
Also fix an infinite loop if COPY IN/OUT is attempted in \watch.  
We used to reject that, but that error exit path got broken  
somewhere along the line in v15.  There seems no real reason  
to reject it anyway as the code now stands, so just remove  
the error exit and make sure that COPY OUT data goes to the  
right place.  
  
Also remove PrintQueryResult's unused is_watch parameter,  
and make some other cosmetic cleanups (adjust obsolete  
comments, break some overly-long lines).  
  
Daniel Vérité and Tom Lane  
  
Discussion: https://postgr.es/m/4333844c-2244-4d6e-a49a-1d483fbe304f@manitou-mail.org  

commit   : b1c73e1cf1ffdfedeed4f2cd7f34247dcad308bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 11:06:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 11:06:33 -0400    

commit   : 443df6e2db932a7cd6d85ddfb67e11a43345130d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 10:56:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Oct 2022 10:56:16 -0400    

This reverts commit db0d67db2401eb6238ccc04c6407a4fd4f985832 and  
several follow-on fixes.  The idea of making a cost-based choice  
of the order of the sorting columns is not fundamentally unsound,  
but it requires cost information and data statistics that we don't  
really have.  For example, relying on procost to distinguish the  
relative costs of different sort comparators is pretty pointless  
so long as most such comparator functions are labeled with cost 1.0.  
Moreover, estimating the number of comparisons done by Quicksort  
requires more than just an estimate of the number of distinct values  
in the input: you also need some idea of the sizes of the larger  
groups, if you want an estimate that's good to better than a factor of  
three or so.  That's data that's often unknown or not very reliable.  
Worse, to arrive at estimates of the number of calls made to the  
lower-order-column comparison functions, the code needs to make  
estimates of the numbers of distinct values of multiple columns,  
which are necessarily even less trustworthy than per-column stats.  
Even if all the inputs are perfectly reliable, the cost algorithm  
as-implemented cannot offer useful information about how to order  
sorting columns beyond the point at which the average group size  
is estimated to drop to 1.  
  
Close inspection of the code added by db0d67db2 shows that there  
are also multiple small bugs.  These could have been fixed, but  
there's not much point if we don't trust the estimates to be  
accurate in-principle.  
  
Finally, the changes in cost_sort's behavior made for very large  
changes (often a factor of 2 or so) in the cost estimates for all  
sorting operations, not only those for multi-column GROUP BY.  
That naturally changes plan choices in many situations, and there's  
precious little evidence to show that the changes are for the better.  
Given the above doubts about whether the new estimates are really  
trustworthy, it's hard to summon much confidence that these changes  
are better on the average.  
  
Since we're hard up against the release deadline for v15, let's  
revert these changes for now.  We can always try again later.  
  
Note: in v15, I left T_PathKeyInfo in place in nodes.h even though  
it's unreferenced.  Removing it would be an ABI break, and it seems  
a bit late in the release cycle for that.  
  
Discussion: https://postgr.es/m/TYAPR01MB586665EB5FB2C3807E893941F5579@TYAPR01MB5866.jpnprd01.prod.outlook.com  

commit   : b507a7a19b5d9a8ed2500c5a7159353e02846901    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 1 Oct 2022 16:55:16 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 1 Oct 2022 16:55:16 -0700    

Test performance regresses noticably when using all cores. This is more  
pronounced with meson than with autoconf, presumably because meson will  
schedule the "full number" of tests more consistently.  8 seems to work  
OK.  
  
Discussion: https://postgr.es/m/20220927040208.l3shfcidovpzqxfh@awork3.anarazel.de  
Backpatch: 15-, where CI was introduced  

commit   : 64b431d15c49ce39a12dcaec78a60b884be1efba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Oct 2022 15:28:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Oct 2022 15:28:11 +0900    

This fixes some areas related to logical replication and custom RMGRs.  
  
Author: Ekaterina Kiryanova  
Discussion: https://postgr.es/m/fa4773f1-1396-384a-bcd7-85b5e013f399@postgrespro.ru  
Backpatch-through: 15  

commit   : 2267085c168899b43dadc4ca52fb516773068228    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Sep 2022 19:36:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Sep 2022 19:36:46 -0400    

Commit 34f581c39 intended to ensure that RelationGetBufferForTuple  
would acquire a visibility-map page pin in case the otherBuffer's  
all-visible bit had become set since we last had lock on that page.  
But I missed a case: when we're extending the relation, VM concerns  
were dealt with only in the relatively-less-likely case that we  
fail to conditionally lock the otherBuffer.  I think I'd believed  
that we couldn't need to worry about it if the conditional lock  
succeeds, which is true for the target buffer; but the otherBuffer  
was unlocked for awhile so its bit might be set anyway.  So we need  
to do the GetVisibilityMapPins dance, and then also recheck the  
page's free space, in both cases.  
  
Per report from Jaime Casanova.  Back-patch to v12 as the previous  
patch was (although there's still no evidence that the bug is  
reachable pre-v14).  
  
Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org  

commit   : d8e6ae9f38984ca16dc0e18924cc26568bb75960    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Sep 2022 12:53:31 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 30 Sep 2022 12:53:31 +0200    

I (Álvaro) broke tab-completion for GRANT .. ALL TABLES IN SCHEMA while  
removing ALL from the publication syntax for schemas in the  
aforementioned commit.  I also missed to update a bunch of  
tab-completion rules for ALTER/CREATE PUBLICATION that match each  
individual piece of ALL TABLES IN SCHEMA.  Repair those bugs.  
  
While fixing up that commit, update a couple of outdated comments  
related to the same change.  
  
Backpatch to 15.  
  
Author: Shi yu <shiy.fnst@fujitsu.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/OSZPR01MB6310FCE8609185A56344EED2FD559@OSZPR01MB6310.jpnprd01.prod.outlook.com  

commit   : a613474411e690947fbf869ef519da13a35d993d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 30 Sep 2022 12:03:48 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 30 Sep 2022 12:03:48 +0200    

The compression parameter to PQsslAttribute has never returned the  
compression method used, it has always returned "on" or "off since  
it was added in commit 91fa7b4719ac. Backpatch through v10.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/B9EC60EC-F665-47E8-A221-398C76E382C9@yesql.se  
Backpatch-through: v10  

commit   : cae4688ce81b8449aa6e1e7bfa384d53520a81fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Sep 2022 17:28:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Sep 2022 17:28:09 -0400    

Commit ebc8b7d44 intended to change the behavior of  
PQsslAttribute(NULL, "library"), but accidentally also changed  
what happens with a non-NULL conn pointer.  Undo that so that  
only the intended behavior change happens.  Clarify some  
associated documentation.  
  
Per bug #17625 from Heath Lord.  Back-patch to v15.  
  
Discussion: https://postgr.es/m/17625-fc47c78b7d71b534@postgresql.org  

commit   : d460faf00285fd99d3c80e890c8f6fe798233b48    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Sep 2022 16:55:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Sep 2022 16:55:01 +0900    

Remove the stale text that is a leftover from an earlier version of the  
patch to add support for batch insertion, and adjust the wording in the  
remaining text.  
  
Back-patch to v14 where batch insertion came in.  
  
Review and wording adjustment by Tom Lane.  
  
Discussion: https://postgr.es/m/CAPmGK14goatHPHQv2Aeu_UTKqZ%2BBO%2BP%2Bzd3HKv5D%2BdyyfWKDSw%40mail.gmail.com  

commit   : f7ae8a2e186ca27f4ea64fddc21bfabaf0618507    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Sep 2022 11:43:40 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 29 Sep 2022 11:43:40 +1300    

91e9e89dc modified nodeSort.c so that it used datum sorts when the  
targetlist of the outer node contained only a single column.  That commit  
failed to recognise that the Datum returned by tuplesort_getdatum() must  
be pfree'd when the type is a byref type.  Ronan Dunklau did originally  
propose the patch with that restriction, but that, probably through my own  
fault, got lost during further development work.  
  
Due to the timing of this report (PG15 RC1 is almost out the door), let's  
just restrict the datum sort optimization to apply for byval types only.  
We might want to look harder into making this work for byref types in  
PG16.  
  
Reported-by: Önder Kalacı  
Diagnosis-by: Tom Lane  
Discussion: https://postgr.es/m/CACawEhVxe0ufR26UcqtU7GYGRuubq3p6ZWPGXL4cxy_uexpAAQ@mail.gmail.com  
Backpatch-through: 15, where 91e9e89dc was introduced.  

commit   : 517fab6a405628a7e4d2aad4cb19ab652adea720    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:14:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:14:38 -0400    

Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/3976627.1662651004@sss.pgh.pa.us  
  
Backpatch-through: 10  

commit   : 9bb5412885d12fd8598e0aacc29c3d9afdce857d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:05:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 Sep 2022 13:05:20 -0400    

doc revert of commit 1703726488.  Change was applied to irrelevant  
branches, and was not detailed enough to be helpful in relevant  
branches.  
  
Reported-by: Peter Eisentraut, Noah Misch  
  
Discussion: https://postgr.es/m/a2dc9de4-24fc-3222-87d3-0def8057d7d8@enterprisedb.com  
  
Backpatch-through: 10  

commit   : 1eeac95dc4a639c51ff6cc6e2ac6ae52dab32b32    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 17:14:53 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 17:14:53 +0200    

This prevents marking the argument string for translation for gettext,  
and it also prevents the given string (which is already translated) from  
being translated at runtime.  
  
Also, mark the strings used as arguments to check_rolespec_name for  
translation.  
  
Backpatch all the way back as appropriate.  None of this is caught by  
any tests (necessarily so), so I verified it manually.  

commit   : a60b11327bbd4ae9f661563644a15b0c324f3d9d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 13:47:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 28 Sep 2022 13:47:25 +0200    

Its API is quite strange, and since there's only one caller, there's no  
reason for it to be a separate function in the first place.  Inline it  
instead.  
  
Discussion: https://postgr.es/m/20220927124249.4zdzzlz6had7k3x2@alvherre.pgsql  

commit   : f5441b912493e14fc2ca904971aeb000ceddca4e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 14:11:31 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 14:11:31 +0200    

While at it, remove an unused queryString parameter from  
CheckPubRelationColumnList() and make other minor stylistic changes.  
  
Backpatch to 15.  
  
Reported by Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Co-authored-by: Hou zj <houzj.fnst@fujitsu.com>  
Discussion: https://postgr.es/m/20220926.160426.454497059203258582.horikyota.ntt@gmail.com  

commit   : 72abf03b6491a8df880e1fea45798797bcc86c47    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 10:44:42 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2022 10:44:42 +0200    

We weren't jumbling the merge action list, so wildly different commands  
would be considered to use the same query ID.  Add that, mention it in  
the docs, and some test lines.  
  
Backpatch to 15.  
  
Author: Tatsu <bt22nakamorit@oss.nttdata.com>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/d87e391694db75a038abc3b2597828e8@oss.nttdata.com  

commit   : d1f95fa2476bcf427a3e3677f67ceee26552e23e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 26 Sep 2022 20:02:26 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 26 Sep 2022 20:02:26 -0700    

I (Andres) chose to backpatch this to 15, as it seems better to keep the  
README the same.  
  
Author: James Coleman <jtc331@gmail.com>  
Discussion: https://postgr.es/m/CAAaqYe_7BXDjpk0Ks_eqf1r6LZpC_rfB7kjhb_T3+eC4t6yiGQ@mail.gmail.com  
Backpatch: 15-, where CI came in  

commit   : bb76510a07f3705a28d93e065ebe4261d6ddf54d    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 27 Sep 2022 10:57:07 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 27 Sep 2022 10:57:07 +1300    

The change made in 9d9c02ccd also affects the dense_rank() function.  
Mention this in the release notes.  
  
Author: Jonathan S. Katz  
Discussion: https://postgr.es/m/5c6d3f50-e9b5-f62d-d58a-7b22eb91d8b8@postgresql.org  

commit   : 6abbd212b2828717fb3b10ed2925edf8f212e38d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 16:36:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 16:36:49 -0400    

commit   : 780add2c32a7577f1eab81ae3d8802cd02c4f8fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:32:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:32:51 -0400    

Per suggestions from Justin Pryzby.  
  
Discussion: https://postgr.es/m/20220925215009.GC21938@telsasoft.com  

commit   : 796aa20a11b4060e07b0864081e6977eb66b64bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:19:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2022 14:19:21 -0400    

I'd misunderstood how it worked in 5f1048881.  
  
Discussion: https://postgr.es/m/20220925215009.GC21938@telsasoft.com  

commit   : 0570eba3dcf8c819a6b100b14e25290eaedb4b5a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 13:16:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 13:16:06 +0200    

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

commit   : 5483649cd6875c219beb10465b515ba096dc7f34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 12:57:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Sep 2022 12:57:12 +0200    

current through 15113bfb467a84688744b57b74a14550878d0224  

commit   : 15113bfb467a84688744b57b74a14550878d0224    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Sep 2022 09:26:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 26 Sep 2022 09:26:47 +0530    

This has been removed in HEAD by commit a234177906, so doing just backpatch  
to 15 where it was introduced in commit 860ea46ba7.  
  
Author: Zhang Mingli  
Discussion: https://postgr.es/m/OS0PR01MB57162559C01FE2848C12E8F7944D9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : c82766c0298a6c73b1e768b9239288d96879286e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 17:10:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 17:10:58 -0400    

Commit 25936fd46 adjusted things so that the "storeslot" we use  
for remapping trigger tuples would have adequate lifespan, but it  
neglected to consider the lifespan of the tuple descriptor that  
the slot depends on.  It turns out that in at least some cases, the  
tupdesc we are passing is a refcounted tupdesc, and the refcount for  
the slot's reference can get assigned to a resource owner having  
different lifespan than the slot does.  That leads to an error like  
"tupdesc reference 0x7fdef236a1b8 is not owned by resource owner  
SubTransaction".  Worse, because of a second oversight in the same  
commit, we'd try to free the same tupdesc refcount again while  
cleaning up after that error, leading to recursive errors and an  
"ERRORDATA_STACK_SIZE exceeded" PANIC.  
  
To fix the initial problem, let's just make a non-refcounted copy  
of the tupdesc we're supposed to use.  That seems likely to guard  
against additional problems, since there's no strong reason for  
this code to assume that what it's given is a refcounted tupdesc;  
in which case there's an independent hazard of the tupdesc having  
shorter lifespan than the slot does.  (I didn't bother trying to  
free said copy, since it should go away anyway when the (sub)  
transaction context is cleaned up.)  
  
The other issue can be fixed by making the code added to  
AfterTriggerFreeQuery work like the rest of that function, ie be  
sure that it doesn't try to free the same slot twice in the event  
of recursive error cleanup.  
  
While here, also clean up minor stylistic issues in the test case  
added by 25936fd46: don't use "create or replace function", as any  
name collision within the tests is likely to have ill effects  
that that won't mask; and don't use function names as generic as  
trigger_function1, especially if you're not going to drop them  
at the end of the test stanza.  
  
Per bug #17607 from Thomas Mc Kay.  Back-patch to v12, as the  
previous fix was.  
  
Discussion: https://postgr.es/m/17607-bd8ccc81226f7f80@postgresql.org  

commit   : 7a84c35fe6dcec62c95d023ad057e5717d9304a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 13:10:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Sep 2022 13:10:10 -0400    

Commit 4fb5c794e intended to add coverage of some ambuildempty  
methods that were not getting reached, without removing any  
test coverage.  However, by changing a temp table to unlogged  
it managed to negate the intent of 4c51a2d1e, which means that  
we didn't have reliable test coverage of ginvacuum.c anymore.  
As things stand, much of that file might or might not get reached  
depending on timing, which seems pretty undesirable.  
  
Although this is only clearly broken for the GIN test, it seems  
best to revert 4fb5c794e altogether and instead add bespoke test  
cases covering unlogged indexes for these four AMs.  We don't  
need to do very much with them, so the extra tests are cheap.  
(Note that btree, hash, and bloom already have similar test cases,  
so they need no additional work.)  
  
We can also undo dec8ad367.  Since the testing deficiency that that  
hacked around was later fixed by 2f2e24d90, let's intentionally leave  
an unlogged table behind to improve test coverage in the modules that  
use the regression database for other test purposes.  (The case I used  
also leaves an unlogged sequence behind.)  
  
Per report from Alex Kozhemyakin.  Back-patch to v15 where the  
faulty test came in.  
  
Discussion: https://postgr.es/m/b00c8ee096ee46cd25c183125562a1a7@postgrespro.ru  

commit   : 7a41e34e68a9be767279d17e051555b9cb9477c9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 25 Sep 2022 17:48:03 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 25 Sep 2022 17:48:03 +0200    

commit   : 517484b5820e9e20057ff066b5df7d09cbb5f464    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 24 Sep 2022 18:38:35 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 24 Sep 2022 18:38:35 -0400    

commit   : 8d985560fc1de6197323d4397d2a2bf762657463    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Sep 2022 21:16:08 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 23 Sep 2022 21:16:08 -0400    

Use "prepared transaction" instead of "two-phrase transaction".  This  
is in line with c5d67881d343a507269bde124a49df19e0296157.  

commit   : 2b14b5b5d9d5cf2f039a90a670abaf7b2f37bbe6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:22:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:22:33 -0400    

Rearrange, reword, clarify, fix markup, etc etc.  
  
Also include commit bd8ac900d.  

commit   : cea5aa988ea84182f61b1b84d7dafe06e4d90a9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:20:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 18:20:11 -0400    

Improve a couple of things I noticed while working on v15  
release notes.  

commit   : 43e496e242984320efcf42c51c1e2b379aa03344    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 23 Sep 2022 13:00:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 23 Sep 2022 13:00:55 -0700    

Because index creation does not go through heap_create_with_catalog() we  
didn't call pgstat_create_relation(), leading to index stats of a newly  
created realtion not getting dropped during rollback. To fix, move the  
pgstat_create_relation() to heap_create(), which indexes do use.  
  
Similarly, because dropping an index does not go through  
heap_drop_with_catalog(), we didn't drop index stats when the transaction  
dropping an index committed. Here there's no convenient common path for  
indexes and relations, so index_drop() now calls pgstat_drop_relation().  
  
Add tests for transactional index stats handling.  
  
Author: "Drouvot, Bertrand" <bdrouvot@amazon.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/51bbf286-2b4a-8998-bd12-eaae4b765d99@amazon.com  
Backpatch: 15-, like 8b1dccd37c71, which introduced the bug  

commit   : e956325c8bc8c7257b04c322bf996fff2d81b514    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 13:59:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 13:59:29 -0400    

Account for commits since 2022-06-11.  

commit   : bd8ac900df4d2824f50ce4b1674754685aeaed56    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:21:22 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:21:22 +0200    

The extended query protocol implementation I added in commit  
acb7e4eb6b1c has bugs when used in pipeline mode.  Rather than spend  
more time trying to fix it, remove that code and make the function rely  
on simple query protocol only, meaning it can no longer be used in  
pipeline mode.  
  
Users can easily change their applications to use PQsendQueryParams  
instead.  We leave PQsendQuery in place for Postgres 14, just in case  
somebody is using it and has not hit the mentioned bugs; but we should  
recommend that it not be used.  
  
Backpatch to 15.  
  
Per bug report from Gabriele Varrazzo.  
Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com  

commit   : 27e04412c9c3c3c3b2d182821c759f95693c0039    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:11:48 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 23 Sep 2022 18:11:48 +0200    

The "emulation" I wrote for PQsendQuery in pipeline mode to use extended  
query protocol, in commit acb7e4eb6b1c, is problematic.  Due to numerous  
bugs we'll soon remove it.  As a first step and for all branches back to  
14, stop using PQsendQuery in libpq_pipeline.  Also remove a few test  
lines that will no longer be relevant.  
  
Backpatch to 14.  
  
Discussion: https://postgr.es/m/CA+mi_8ZGSQNmW6-mk_iSR4JZB_LJ4ww3suOF+1vGNs3MrLsv4g@mail.gmail.com  

commit   : a2ab0ad88cf87e0dcd9fc4c7fcfac132a4e88d2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 11:24:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2022 11:24:12 -0400    

Jonathan Katz (word-smithed a bit by me)  
  
Discussion: https://postgr.es/m/a6661e2c-72e0-b4bd-9301-9225bdddda4c@postgresql.org  

commit   : b7256753ec251fd6a1f6bd205dbe62ccbb3261c4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 23 Sep 2022 08:08:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 23 Sep 2022 08:08:24 +0530    

We previously thought that allowing such cases can confuse users when they  
specify DROP TABLES IN SCHEMA but that doesn't seem to be the case based  
on discussion. This helps to uplift the restriction during  
ALTER TABLE ... SET SCHEMA which used to ensure that we couldn't end up  
with a publication having both a schema and the same schema's table.  
  
To allow this, we need to forbid having any schema on a publication if  
column lists on a table are specified (and vice versa). This is because  
otherwise we still need a restriction during ALTER TABLE ... SET SCHEMA to  
forbid cases where it could lead to a publication having both a schema and  
the same schema's table with column list.  
  
Based on suggestions by Peter Eisentraut.  
  
Author: Hou Zhijie and Vignesh C  
Reviewed-By: Peter Smith, Amit Kapila  
Backpatch-through: 15, where it was introduced  
Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e@enterprisedb.com  

commit   : dd6070bc81733c3174f2e257d43908f98b0255fb    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 22 Sep 2022 10:58:49 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 22 Sep 2022 10:58:49 -0700    

Similar to 5f12bc94dc, the code must re-check PageIsAllVisible() after  
buffer lock is re-acquired. Backpatching to the same version, 12.  
  
Discussion: https://postgr.es/m/CAEP4nAw9jYQDKd_5Y+-s2E4YiUJq1vqiikFjYGpLShtp-K3gag@mail.gmail.com  
Reported-by: Robins Tharakan  
Reviewed-by: Robins Tharakan  
Backpatch-through: 12  

commit   : f256236fb1b00e9d05f889a53e93feeecbd50991    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Sep 2022 19:02:25 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 22 Sep 2022 19:02:25 +0200    

This may be a bit too subtle, but removing that word from there makes  
this clause no longer a perfect parallel of the GRANT variant "ALL  
TABLES IN SCHEMA": indeed, for publications what we record is the schema  
itself, not the tables therein, which means that any tables added to the  
schema in the future are also published.  This is completely different  
to what GRANT does, which is affect only the tables that exist when the  
command is executed.  
  
There isn't resounding support for this change, but there are a few  
positive votes and no opposition.  Because the time to 15 RC1 is very  
short, let's get this out now.  
  
Backpatch to 15.  
  
Discussion: https://postgr.es/m/2729c9e2-9aac-8cda-f2f4-34f2bcc18f4e  

commit   : 5f56933ea5d5b0b1a0bbe4c7b8f5110f8fe256ed    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Sep 2022 11:34:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Sep 2022 11:34:20 +0200    

Commit 5ef1eefd76f404ddc59b885d50340e602b70f05f, which added  
archive_library, purged most mentions of archive_command from the  
documentation.  This is inappropriate, since archive_command is still  
a feature in use and users will want to see information about it.  
  
This restores all the removed mentions and rephrases things so that  
archive_command and archive_library are presented as alternatives of  
each other.  
  
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>  
Discussion: https://www.postgresql.org/message-id/9366d634-a917-85a9-4991-b2a4859edaf9@enterprisedb.com  

commit   : ade925e1693a595ef1c278583fa699ca6fc1ff45    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 20:03:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 20:03:30 +0900    

The bounds hardcoded in compression.c since ffd5365 (minimum at 1 and  
maximum at 22) do not match the reality of what zstd is able to  
handle, these values being available via ZSTD_maxCLevel() and  
ZSTD_minCLevel() at run-time.  The maximum of 22 is actually correct  
in recent versions, but the minimum was not as the library can go down  
to -131720 by design.  This commit changes the code to use the run-time  
values in the code instead of some hardcoded ones.  
  
Zstd seems to assume that these bounds could change in the future, and  
Postgres will be able to adapt automatically to such changes thanks to  
what's being done in this commit.  
  
Reported-by: Justin Prysby  
Discussion: https://postgr.es/m/20220922033716.GL31833@telsasoft.com  
Backpatch-through: 15  

commit   : 901ef14afe981065a0c5c61b1759d36482869d98    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 22 Sep 2022 15:55:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 22 Sep 2022 15:55:01 +0900    

This comment has been wrong since its introduction in commit 0d5f05cde;  
backpatch to v12 where that came in.  
  
Discussion: https://postgr.es/m/CAPmGK14VGf-xQjGQN4o1QyAbXAaxugU5%3DqfcmTDh1iufUDnV_w%40mail.gmail.com  

commit   : 848c323c1295dd724587d9c91275414db15e2772    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 14:25:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Sep 2022 14:25:12 +0900    

If the ps display is not cleared at this point, the process could  
continue displaying "recovering NNN" even if handling end-of-recovery  
steps.  df9274a has tackled that by providing some information with the  
end-of-recovery checkpoint but 7ff23c6 has nullified the effect of the  
first commit.  
  
Per a suggestion from Justin, just clear the ps display when we are done  
with recovery, so as no incorrect information is displayed.  This may  
get extended in the future, but for now restore the pre-7ff23c6  
behavior.  
  
Author: Justin Prysby  
Discussion: https://postgr.es/m/20220913223954.GU31833@telsasoft.com  
Backpatch-through: 15  

commit   : 4230279f357602bd99c038e0aec8087a7076522b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 12:54:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 12:54:26 +0900    

Commit 6c2003f8a1 changed the snapshot names mentioned in  
SET TRANSACTION docs, however, there was one place that  
the commit missed updating the name.  
  
Back-patch to all supported versions.  
  
Author: Japin Li  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/MEYP282MB1669BD4280044501165F8B07B64F9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : f80919df950ab05cbe79c7ab34fb359aa79641d4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 09:25:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 Sep 2022 09:25:29 +0900    

Commit 7103ebb7aa added the tab-completion for MERGE accidentally  
in the middle of that for LOCK TABLE. This commit fixes this issue.  
  
This also adds some tab-completion for MERGE.  
  
Back-patch to v15 where MERGE was introduced.  
  
Author: Kotaro Kawamoto, Fujii Masao  
Reviewed-by: Shinya Kato, Álvaro Herrera  
Discussion: https://postgr.es/m/9f1ad2a87a58cd5e7d64f3993130958d@oss.nttdata.com  

commit   : 0c400445dbe316d67d19f79fdd096f0b77458b86    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 21 Sep 2022 17:15:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 21 Sep 2022 17:15:54 -0700    

Cirrus defaults to SetErrorMode(SEM_NOGPFAULTERRORBOX | ...). That prevents  
crash reporting from working unless binaries do SetErrorMode()  
themselves. Furthermore, it appears that either python or, more likely, the C  
runtime has a bug where SEM_NOGPFAULTERRORBOX can very occasionally *trigger*  
a crash on process exit - which is hard to debug, given that it explicitly  
prevents crash dumps from working...  
  
Discussion: https://postgr.es/m/20220909235836.lz3igxtkcjb5w7zb%40awork3.anarazel.de  
Backpatch: 15-, where CI was added  

commit   : 08ddb3c0852d87394b44eea45709b9d9b8154f68    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Sep 2022 11:35:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Sep 2022 11:35:46 +1200    

CI builds recently started failing with:  
  
"Memory size for 4.0 vCPU instance should be between 3840MiB and  
26624MiB, while 2048MiB is requested."  
  
Ok then, let's ask for 4G instead of 2G.  
  
This may be due to a change in the type of instance used to work around  
an outage, per:  
  
https://twitter.com/cirrus_labs/status/1572657320093712384  

commit   : 865b52af61049719e0a289419a0eceded6ea7bae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 10:28:40 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 10:28:40 -0400    

We check that the ICU locale is only specified if the ICU locale  
provider is selected.  But we did that too early.  We need to wait  
until we load the settings of the template database, since that could  
also set what the locale provider is.  
  
Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru>  
Discussion: https://www.postgresql.org/message-id/9ba4cd1ea6ed6b7b15c0ff15e6f540cd@postgrespro.ru  

commit   : ab7032b3a8fec281db71acfc37c5c92fc65b08ae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 09:34:22 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Sep 2022 09:34:22 -0400    

For publication schemas (OBJECT_PUBLICATION_NAMESPACE) and user  
mappings (OBJECT_USER_MAPPING), pg_get_object_address() checked the  
array length of the second argument, but not of the first argument.  
If the first argument was too long, it would just silently ignore  
everything but the first argument.  Fix that by checking the length of  
the first argument as well.  
  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/caaef70b-a874-1088-92ef-5ac38269c33b%40enterprisedb.com  

commit   : 1d3955266a5d9e71dc002634926210ccab8b15dc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Sep 2022 12:29:38 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Sep 2022 12:29:38 +0200    

It is not our usual style to use "we" in messages.  Also, remove some  
noise words.  Backpatch to 15.  
  
Noted by Kyotaro Horiguchi.  
  
Discussion: https://postgr.es/m/20220914.111507.13049297635620898.horikyota.ntt@gmail.com  

commit   : f9a56e726334e4776ac0e5b2ead282793c1d9857    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Sep 2022 18:59:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Sep 2022 18:59:53 -0400    

There doesn't seem to be any good ABI-preserving way to silence  
clang 15's -Wdeprecated-non-prototype warnings about our tree-walk  
APIs.  While we've fixed it properly in HEAD, the only way to not  
see hundreds of these in the back branches is to disable the  
warnings.  We're not going to do anything about them, so we might  
as well disable them.  
  
I noticed that we also get some of these warnings about fmgr.c's  
support for V0 function call convention, in branches before v10  
where we removed that.  That's another area we aren't going to  
change, so turning off the warning seems fine for that too.  
  
Per project policy, this is a candidate for back-patching into  
out-of-support branches: it suppresses annoying compiler warnings  
but changes no behavior.  Hence, back-patch all the way to 9.2.  
  
Discussion: https://postgr.es/m/CA+hUKGKpHPDTv67Y+s6yiC8KH5OXeDg6a-twWo_xznKTcG0kSA@mail.gmail.com  

commit   : b7d9b0c2667e823404552e968431198288aee55e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Sep 2022 12:04:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Sep 2022 12:04:37 -0400    

clang 15+ will issue a set-but-not-used warning when the only  
use of a variable is in autoincrements (e.g., "foo++;").  
That's perfectly sensible, but it detects a few more cases that  
we'd not noticed before.  Silence the warnings with our usual  
methods, such as PG_USED_FOR_ASSERTS_ONLY, or in one case by  
actually removing a useless variable.  
  
One thing that we can't nicely get rid of is that with %pure-parser,  
Bison emits "yynerrs" as a local variable that falls foul of this  
warning.  To silence those, I inserted "(void) yynerrs;" in the  
top-level productions of affected grammars.  
  
Per recently-established project policy, this is a candidate  
for back-patching into out-of-support branches: it suppresses  
annoying compiler warnings but changes no behavior.  Hence,  
back-patch to 9.5, which is as far as these patches go without  
issues.  (A preliminary check shows that the prior branches  
need some other set-but-not-used cleanups too, so I'll leave  
them for another day.)  
  
Discussion: https://postgr.es/m/514615.1663615243@sss.pgh.pa.us  

commit   : c922f924d348254f2d03d2949d1085084aafc480    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Sep 2022 12:38:48 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Sep 2022 12:38:48 +0200    

Otherwise, it can fail given sufficient bad luck.  
  
Backpatch to 15.  
  
Discussion: https://postgr.es/m/537759.1663625579@sss.pgh.pa.us  

commit   : 05af876267b7673f5ccaa1479ed6ea12fc303343    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Sep 2022 19:28:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Sep 2022 19:28:43 +0900    

The parameter controlling if two-phase transactions can be decoded was  
named "two_phase" in the documentation while its procedure defines  
"twophase".  
  
Author: Florin Irion  
Discussion: https://postgr.es/m/5eeabd10-1aff-ea61-f92d-9fa0d9a7e207@gmail.com  
Backpatch-through: 14  

commit   : 449f1d05416e8df79e25c433a603af1b18fd7147    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Sep 2022 18:13:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Sep 2022 18:13:39 +0900    

These variables used XLogRecPtr instead of RepOriginId.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoBm-vNyBSXGp4bmJGvhr=S-EGc5q1dtV70cFTcJvLhC=Q@mail.gmail.com  
Backpatch-through: 14  

commit   : 1ec2d0bc68db9ddffeeaa7f8a9f79ac2620d52e1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Sep 2022 10:04:13 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Sep 2022 10:04:13 +1200    

The header comment for get_cheapest_group_keys_order() claimed that the  
output arguments were set to a newly allocated list which may be freed by  
the calling function, however, this was not always true as the function  
would simply leave these arguments untouched in some cases.  
  
This tripped me up when working on 1349d2790 as I mistakenly assumed I  
could perform a list_concat with the output parameters.  That turned out  
bad due to list_concat modifying the original input lists.  
  
In passing, make it more clear that the number of distinct values is  
important to reduce tiebreaks during sorts.  Also, explain what the  
n_preordered parameter means.  
  
Backpatch-through: 15, where get_cheapest_group_keys_order was introduced.  

commit   : f6c70b81802a869303be9916d1a64a15f4dd29d1    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Sep 2022 09:15:04 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 20 Sep 2022 09:15:04 +1200    

The comment claimed we don't consider other orders of the GROUP BY clause,  
but this is no longer true as of db0d67db2.  
  
Discussion: https://postgr.es/m/CAApHDvq65=9Ro+hLX1i9ugWEiNDvHrBibAO7ARcTnf38_JE+UQ@mail.gmail.com  
Backpatch-through: 15, where db0d67db2 was introduced.  

commit   : 7fbf9b1b07dcfb656d9c389c76ae74dd35542c21    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Sep 2022 15:22:43 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Sep 2022 15:22:43 -0400    

Similar to 1e08576691bf1a25c0e28745e5e800c44f2a1c76, but for the icu  
test suite.  
  
Reported-by: Christoph Berg <myon@debian.org>  
Discussion: https://www.postgresql.org/message-id/YyWeU61YMFwjVdxE@msg.df7cb.de  

commit   : c403f97b4eabbfec90ab195a664b7aec3ad58004    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Sep 2022 12:16:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Sep 2022 12:16:02 -0400    

The API contract for planstate_tree_walker() callbacks is that they  
take a PlanState pointer and a context pointer.  Somebody figured  
they could save a couple lines of code by ignoring that, and passing  
ExecShutdownNode itself as the walker even though it has but one  
argument.  Somewhat remarkably, we've gotten away with that so far.  
However, it seems clear that the upcoming C2x standard means to  
forbid such cases, and compilers that actively break such code  
likely won't be far behind.  So spend the extra few lines of code  
to do it honestly with a separate walker function.  
  
In HEAD, we might as well go further and remove ExecShutdownNode's  
useless return value.  I left that as-is in back branches though,  
to forestall complaints about ABI breakage.  
  
Back-patch, with the thought that this might become of practical  
importance before our stable branches are all out of service.  
It doesn't seem to be fixing any live bug on any currently known  
platform, however.  
  
Discussion: https://postgr.es/m/208054.1663534665@sss.pgh.pa.us  

commit   : e4861b2322b74619a1124cd72d4987be0f2815e8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Sep 2022 06:45:23 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Sep 2022 06:45:23 -0400    

partial backpatch of 0b039e3a8489c08ec61b4d40382047c389af91ad  

commit   : cacf12e92f7854547b8125f8a9d58694a05d1479    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Sep 2022 06:35:01 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Sep 2022 06:35:01 -0400    

commit   : 1ef00afe2e457161421dc61f6bc329af3aa6cc4b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 17 Sep 2022 16:54:16 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 17 Sep 2022 16:54:16 -0700    

The function has a bool argument named "case_insensitive", but that was  
spelled "case_sensitive" in the declaration.  Make them consistent now  
to avoid confusion in the future.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Michael Paquiër <michael@paquier.xyz>  
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com  
Backpatch: 10-  

commit   : 940c1c7ed3d14ae132c9b96643be6901b2d92993    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 17 Sep 2022 09:21:59 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 17 Sep 2022 09:21:59 -0700    

Frontend code shouldn't include postgres.h. Some files in src/port/ need to  
include postgres.h/postgres_fe.h, but these files don't.  
  
Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de  
Backpatch: 12-, where 3fd2a7932ef introduced (some) of these files  

commit   : fb503793ef50eb16eb1924251d2ed58e1621eeb3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Sep 2022 14:08:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Sep 2022 14:08:40 -0700    

So far they were created below CacheMemoryContext. However, that's not  
guaranteed to exist in all situations, leading to memory contexts created as  
top-level contexts. There isn't actually a good reason anymore to create them  
below CacheMemoryContext, so just creating them below TopMemoryContext seems  
the best approach.  
  
Reported-by: Reid Thompson <reid.thompson@crunchydata.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Author: "Drouvot, Bertrand" <bdrouvot@amazon.com>  
Discussion: https://postgr.es/m/b948b729-42fe-f88c-2f4a-0e65d84c049b@amazon.com  
Backpatch: 15-  

commit   : 23bcc8d877efde5cbbfe50bbbf12a96434e41f36    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Sep 2022 08:10:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Sep 2022 08:10:59 +0200    

commit   : 885826f95d1c7803d3ff97bde64078b257543266    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Sep 2022 10:07:12 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Sep 2022 10:07:12 -0700    

Very occasionally the stats test failed due to the number of sessions not  
being updated yet. Likely this requires that there is contention on the  
database's stats entry. Solve this by forcing pending stats to be flushed  
before fetching the stats.  
  
I verified that there are no other test failures after making  
pgstat_report_stat() only flush stats when force = true.  
  
Per message from Tom Lane and buildfarm member crake.  
  
Discussion: https://postgr.es/m/3428246.1663271992@sss.pgh.pa.us  
Backpatch: 15-, where 5264add7847 added the test  

commit   : b759bb6714f03e91071b8fe6d29c28a1f87ea4bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Sep 2022 13:23:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Sep 2022 13:23:01 -0400    

Treat arguments declared as RECORD as if that were a polymorphic type  
(which it is, sort of), in that we substitute the actual argument type  
while forming the function cache lookup key.  This allows the specific  
composite type to be known in some cases where it was not before,  
at the cost of making a separate function cache entry for each named  
composite type that's passed to the function during a session.  The  
particular symptom discussed in bug #17610 could be solved in other  
more-efficient ways, but only at the cost of considerable development  
work, and there are other cases where we'd still fail without this.  
  
Per bug #17610 from Martin Jurča.  Back-patch to v11 where we first  
allowed plpgsql functions to be declared as taking type RECORD.  
  
Discussion: https://postgr.es/m/17610-fb1eef75bf6c2364@postgresql.org  

commit   : c946425176f39e4656718a684a53e8dde5cc641a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Sep 2022 16:37:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Sep 2022 16:37:53 +0200    

commit   : 8135d0bd455217bd345090bae085b2bbcf62bdb0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Sep 2022 11:10:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Sep 2022 11:10:41 +0200    

If the createdb tests run under the C locale, the database cluster  
will be initialized with encoding SQL_ASCII.  With the checks added in  
c7db01e325a530ec38ec7ba57cd3ed32e123e33c, this will cause several  
ICU-related tests to fail because SQL_ASCII is not supported by ICU.  
To work around that, use initdb option -E UTF8 for those tests to get  
past that check.  

commit   : 148f66d59e2c2fa8bc79918973874e2803892664    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Sep 2022 09:37:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Sep 2022 09:37:54 +0200    

Check in CREATE DATABASE and initdb that the selected encoding is  
supported by ICU.  Before, they would pass but users would later get  
an error from the server when they tried to use the database.  
  
Also document that initdb sets the encoding to UTF8 by default if the  
ICU locale provider is chosen.  
  
Author: Marina Polyakova <m.polyakova@postgrespro.ru>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/6dd6db0984d86a51b7255ba79f111971@postgrespro.ru  

commit   : 4e2a88905d7c05066a3caddc1f6ee76864e24c38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Sep 2022 17:17:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Sep 2022 17:17:53 -0400    

I happened to notice that libpq_pipeline's private implementation  
of pg_fatal lacked any pg_attribute_printf decoration.  Indeed,  
adding that turned up a mistake!  We'd likely never have noticed  
because the error exits in this code are unlikely to get hit,  
but still, it's a bug.  
  
We're so used to having the compiler check this stuff for us that  
a printf-like function without pg_attribute_printf is a land mine.  
I wonder if there is a way to detect such omissions.  
  
Back-patch to v14 where this code came in.  

commit   : bfa58a679a577bffa58cd122b77483f508ed5933    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Sep 2022 18:04:00 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Sep 2022 18:04:00 +0200    

There was a excessive structure, leading to somewhat disorganized  
presentation of the information. Remove a few tags and reorder  
paragraphs to make the text flow more easily.  Also, reword some of it  
to be more concise.  
  
The bit about column list combination is not modified, other than to  
remove an uninteresting (and IMO confusing and wrong) paragraph; I  
intend to deal with it differently afterwards.  
  
Backpatch to 15.  
  
Discussion: https://postgr.es/m/20220913121138.yn7ekkfysxzhkm2u@alvherre.pgsql  

commit   : e36cbef04bd59f5e2e56a180475d64b0dc06d069    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 15 Sep 2022 06:45:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 15 Sep 2022 06:45:23 -0700    

After commit cc2c7d65fc27e877c9f407587b0b92d46cd6dd16 added this flag,  
failure to reset it caused assertion failures.  In non-assert builds, it  
made the system fail to achieve the objectives listed in that commit;  
chiefly, we might emit a spurious log message.  Back-patch to v15, where  
that commit first appeared.  
  
Bharath Rupireddy and Kyotaro Horiguchi.  Reviewed by Dilip Kumar,  
Nathan Bossart and Michael Paquier.  Reported by Dilip Kumar.  
  
Discussion: https://postgr.es/m/CAFiTN-sE3ry=ycMPVtC+Djw4Fd7gbUGVv_qqw6qfzp=JLvqT3g@mail.gmail.com  

commit   : eed548822ca23d3a35dfda7f559b1b7e443ac056    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 15 Sep 2022 11:40:17 +0700    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 15 Sep 2022 11:40:17 +0700    

While at it, make ellipses formatting consistent when describing SQL statements.  
  
Ekaterina Kiryanova and Alexander Lakhin  
  
Reviewed by myself and Álvaro Herrera  
Discussion: https://www.postgresql.org/message-id/eed5cec0-a542-53da-6a5e-7789c6ed9817%40postgrespro.ru  
Backpatch only the grammar fix to v15  

commit   : d068b4108c2e8eda9dbc9fffb7055334c62c4f6a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 15 Sep 2022 09:41:32 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 15 Sep 2022 09:41:32 +1200    

In 29f45e299, we added support for optimizing the execution of NOT  
IN(values) by using a hash table instead of a linear search over the  
array.  That commit neglected to update the header comment for  
convert_saop_to_hashed_saop() to mention this fact.  Here we fix that.  
  
Author: James Coleman  
Discussion: https://postgr.es/m/CAAaqYe99NUpAPcxgchGstgM23fmiGjqQPot8627YgkBgNt=BfA@mail.gmail.com  
Backpatch-through: 15, where 29f45e299 was added.  

commit   : 12a5214df4b784e793958c931c07836606efac9b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Sep 2022 22:30:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Sep 2022 22:30:51 +0200    

commit   : ef81b7f8697807e57363d22b1e80389cd1efc4f8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Sep 2022 15:36:21 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 14 Sep 2022 15:36:21 +0200    

This appears to be a merge mistake in 96ef3237bf74.  We could put it  
back the way it was before JSON_TABLE and it'd be two lines shorter, but  
it's likely that JSON_TABLE will be back and will prefer things this  
way.  It makes no other difference in practice.  
  
Backpatch to 15.  
  
Reported by Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQAr4nOcNQskC4oBEZN4S+4heJ=1ch_ZKOxU+_Ef-FQSf-g@mail.gmail.com  

commit   : 64387c540805e392d051cf484ebcf937a9bd8b1b    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 14 Sep 2022 18:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 14 Sep 2022 18:45:01 +0900    

The tlist of the EvalPlanQual outer plan for a ForeignScan node is  
adjusted to produce a tuple whose descriptor matches the scan tuple slot  
for the ForeignScan node.  But in the case where the outer plan contains  
an extra Sort node, if the new tlist contained columns required only for  
evaluating PlaceHolderVars or columns required only for evaluating local  
conditions, this would cause setrefs.c to fail with the error.  
  
The cause of this is that when creating the outer plan by injecting the  
Sort node into an alternative local join plan that could emit such extra  
columns as well, we fail to arrange for the outer plan to propagate them  
up through the Sort node, causing setrefs.c to fail to match up them in  
the new tlist to what is available from the outer plan.  Repair.  
  
Per report from Alexander Pyhalov.  
  
Richard Guo and Etsuro Fujita, reviewed by Alexander Pyhalov and Tom Lane.  
Backpatch to all supported versions.  
  
Discussion: http://postgr.es/m/cfb17bf6dfdf876467bd5ef533852d18%40postgrespro.ru  

commit   : b3c630cc9230ef1ead0dab0ec1498fb4fd2d0de6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Sep 2022 14:52:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Sep 2022 14:52:26 +0900    

The zlib documentation mentions the values supported for the compression  
strategy, but this code has been using a hardcoded value of 0 rather  
than Z_DEFAULT_STRATEGY.  This commit adjusts the code to use  
Z_DEFAULT_STRATEGY.  
  
Backpatch down to where this code has been added to ease the backport of  
any future patch touching this area.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us  
Backpatch-through: 10  

commit   : 7fe55d5e12b66c7807d8af1f45946d7d48f5d6db    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Sep 2022 06:04:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Sep 2022 06:04:24 +0200    

This adds additional variants of palloc, pg_malloc, etc. that  
encapsulate common usage patterns and provide more type safety.  
  
Specifically, this adds palloc_object(), palloc_array(), and  
repalloc_array(), which take the type name of the object to be  
allocated as its first argument and cast the return as a pointer to  
that type.  There are also palloc0_object() and palloc0_array()  
variants for initializing with zero, and pg_malloc_*() variants of all  
of the above.  
  
Inspired by the talloc library.  
  
This is backpatched from master so that future backpatchable code can  
make use of these APIs.  This patch by itself does not contain any  
users of these APIs.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com  

commit   : 53332eacaff6a391f79294193d0c39bff9d14b43    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Sep 2022 12:17:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Sep 2022 12:17:03 +0900    

PG_COMPRESSION_OPTION_LEVEL is removed from the compression  
specification logic, and instead the compression level is always  
assigned with each library's default if nothing is directly given.  This  
centralizes the checks on the compression methods supported by a given  
build, and always assigns a default compression level when parsing a  
compression specification.  This results in complaining at an earlier  
stage than previously if a build supports a compression method or not,  
aka when parsing a specification in the backend or the frontend, and not  
when processing it.  zstd, lz4 and zlib are able to handle in their  
respective routines setting up the compression level the case of a  
default value, hence the backend or frontend code (pg_receivewal or  
pg_basebackup) has now no need to know what the default compression  
level should be if nothing is specified: the logic is now done so as the  
specification parsing assigns it.  It can also be enforced by passing  
down a "level" set to the default value, that the backend will accept  
(the replication protocol is for example able to handle a command like  
BASE_BACKUP (COMPRESSION_DETAIL 'gzip:level=-1')).  
  
This code simplification fixes an issue with pg_basebackup --gzip  
introduced by ffd5365, where the tarball of the streamed WAL segments  
would be created as of pg_wal.tar.gz with uncompressed contents, while  
the intention is to compress the segments with gzip at a default level.  
The origin of the confusion comes from the handling of the default  
compression level of gzip (-1 or Z_DEFAULT_COMPRESSION) and the value of  
0 was getting assigned, which is what walmethods.c would consider  
as equivalent to no compression when streaming WAL segments with its tar  
methods.  Assigning always the compression level removes the confusion  
of some code paths considering a value of 0 set in a specification as  
either no compression or a default compression level.  
  
Note that 010_pg_basebackup.pl has to be adjusted to skip a few tests  
where the shape of the compression detail string for client and  
server-side compression was checked using gzip.  This is a result of the  
code simplification, as gzip specifications cannot be used if a build  
does not support it.  
  
Reported-by: Tom Lane  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/1400032.1662217889@sss.pgh.pa.us  
Backpatch-through: 15  

commit   : 3e694b318d20c876a3fd64f8e44d2ba5eab7a022    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Sep 2022 14:18:45 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Sep 2022 14:18:45 +0200    

Locale options can be specified for initdb, createdb, and CREATE  
DATABASE.  In initdb, it has always been possible to specify --locale  
and then some --lc-* option to override a category.  CREATE DATABASE  
and createdb didn't allow that, requiring either the all-categories  
option or only per-category options.  In  
f2553d43060edb210b36c63187d52a632448e1d2, this was changed in CREATE  
DATABASE (perhaps by accident?) to be more like the initdb behavior,  
but createdb still had the old behavior.  
  
Now we change createdb to match the behavior of CREATE DATABASE and  
initdb, and also update the documentation of CREATE DATABASE to match  
the new behavior, which was not done in the above commit.  
  
Author: Marina Polyakova <m.polyakova@postgrespro.ru>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://www.postgresql.org/message-id/7c99c132dc9c0ac630e0127f032ac480@postgrespro.ru  

commit   : 892cac91249921af73cfe5a7209b64a16589ae18    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 13 Sep 2022 12:02:56 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 13 Sep 2022 12:02:56 +0200    

Per Thomas Munro  
  
Discussion: https://postgr.es/m/CA+hUKGJ9wP9kpvgoxHvqA=4g1d9-y_w3LhhdhFVU=mFiqjwHww@mail.gmail.com  

commit   : f5047c1293acce3c6c3802b06825aa3a9f9aa55a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Sep 2022 10:38:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Sep 2022 10:38:59 +0900    

This change concerns a couple of .txt files (for internal state checks)  
that were still written in the path where the binary is executed, and  
not in the subdirectory located in the target cluster.  Like the other  
.txt files doing already so (like loadable_libraries.txt), these are  
saved in the base output directory.  Note that on failure, the logs  
report the full path to the .txt file generated, so these are easy to  
find.  
  
Oversight in 38bfae3.  
  
Author: Daniel Gustafsson  
Reviewed-by: Michael Paquier, Justin Prysby  
Discussion: https://postgr.es/m/181A6DA8-3B7F-4B71-82D5-363FF0146820@yesql.se  
Backpatch-through: 15  

commit   : 4d5d35858c898a64a96cdff62d6d1ff9f08f9fa5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Sep 2022 11:04:37 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Sep 2022 11:04:37 +1200    

The primary fix here is to fix has_matching_range() so it does not  
reference ranges->values[-1] when nranges == 0.  Similar problems existed  
in AssertCheckRanges() too.  It does not look like any of these problems  
could lead to a crash as the array in question is at the end of the Ranges  
struct, and values[-1] is memory that belongs to other fields in the  
struct.  However, let's get rid of these rather unsafe coding practices.  
  
In passing, I (David) adjusted some comments to try to make it more clear  
what some of the fields are for in the Ranges struct.  I had to study the  
code to find out what nsorted was for as I couldn't tell from the  
comments.  
  
Author: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQAqJQzPitufX-jR=YUbJafpCDAKUnwgdbX_MzSc93wuvdw@mail.gmail.com  
Backpatch-through: 14, where multi-range brin was added.  

commit   : 7d7d72c195e89b3eb9f9c9a03f70f9d238207c59    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 12 Sep 2022 22:17:17 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 12 Sep 2022 22:17:17 +0200    

The FreeBSD site was changed with a redirect, which in turn seems to  
lead to a 404. Replace with the working link.  
  
Author: James Coleman <jtc331@gmail.com>  
Discussion: https://postgr.es/m/CAAaqYe_JZRj+KPn=hACtwsg1iLRYs=jYvxG1NW4AnDeUL1GD-Q@mail.gmail.com  

commit   : cb49042b58f8ca42da1cd7f2baf56bf52d92cd69    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Sep 2022 16:51:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Sep 2022 16:51:00 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 15 development.  
  
current through REL_15_BETA4  

commit   : 56d238846fe6e1772c8652cd4945da6c0a42534a    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 12 Sep 2022 12:59:06 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Mon, 12 Sep 2022 12:59:06 +0200    

Commit c4c340088 changed geometric operators to use float4 and float8  
functions, and handle NaN's in a better way. The circle sameness test  
had a typo in the code which resulted in all comparisons with the left  
circle having a NaN radius considered same.  
  
  postgres=# select '<(0,0),NaN>'::circle ~= '<(0,0),1>'::circle;  
  ?column?  
  ----------  
  t  
  (1 row)  
  
This fixes the sameness test to consider the radius of both the left  
and right circle.  
  
Backpatch to v12 where this was introduced.  
  
Author: Ranier Vilela <ranier.vf@gmail.com>  
Discussion: https://postgr.es/m/CAEudQAo8dK=yctg2ZzjJuzV4zgOPBxRU5+Kb+yatFiddtQk6Rw@mail.gmail.com  
Backpatch-through: v12  

commit   : c8a1bc01c6b05d394d5b6d0e0f594ccf9b46bbcb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Sep 2022 09:38:07 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Sep 2022 09:38:07 +0200    

pg_walinspect uses datatype double (double precision floating point  
number) for WAL stats percentile calculations and expose them via  
float4 (single precision floating point number), which an unnecessary  
loss of precision and confusing. Even though, it's harmless that way,  
let's use float8 (double precision floating-point number) to be in  
sync with what pg_walinspect does internally and what it exposes to  
the users. This seems to be the pattern used elsewhere in the code.  
  
Reported-by: Peter Eisentraut  
Author: Bharath Rupireddy  
Reviewed-by: Peter Eisentraut  
Discussion: https://www.postgresql.org/message-id/36ee692b-232f-0484-ce94-dc39d82021ad%40enterprisedb.com  

commit   : 44a51dc990cc39fcd5ae6359bf1e27bd6699449b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2022 16:42:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2022 16:42:25 -0400    

Be more clear about when and how an extension-defined GUC comes to be  
visible in pg_settings.  (Move the para to the bottom of the page, too;  
whoever thought this point was more important than the para about the  
view being updatable had odd priorities IMNSHO.)  
  
Back-patch to v15 where archive modules were added, since that seems  
to have made this more of a sore spot than it was before.  
  
Benoit Lobréau, Nathan Bossart  
  
Discussion: https://postgr.es/m/CAPE8EZ7KHaXMHKwT=HOim23tDVKYA1PruRuTfeYdCrYWwPGhag@mail.gmail.com  

commit   : fbb54d742ac888370e3221c556c5f336a1f4e888    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Sep 2022 15:34:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Sep 2022 15:34:04 -0400    

The ECPG preprocessor converted code such as  
  
static varchar str1[10], str2[20], str3[30];  
  
into  
  
static  struct varchar_1  { int len; char arr[ 10 ]; }  str1 ;  
        struct varchar_2  { int len; char arr[ 20 ]; }  str2 ;  
        struct varchar_3  { int len; char arr[ 30 ]; }  str3 ;  
  
thus losing the storage attribute for the later variables.  
Repeat the declaration for each such variable.  
  
(Note that this occurred only for variables declared "varchar"  
or "bytea", which may help explain how it escaped detection  
for so long.)  
  
Andrey Sokolov  
  
Discussion: https://postgr.es/m/942241662288242@mail.yandex.ru  

commit   : e0636ca90b819d7ca2e6e6dd35cf84d7032d473b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Sep 2022 13:50:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Sep 2022 13:50:42 -0400    

Remove no-longer-accurate claim that Windows lacks home directories.  
Clarify the text by more clearly distinguishing which statements  
reflect hard-wired choices versus which ones reflect overridable  
defaults.  Update the examples of version-specific file names,  
and make them track future version changes by using "&majorversion;"  
and "&version;".  (BTW, in devel and beta releases this method  
correctly says that you can use strings like "16devel" and "15beta4"  
as minor version identifiers.)  
  
Back-patch to v15, but not further, with the thought that in older  
releases the examples with three-part version numbers still had  
some historical relevance.  v15 will be the first major release after  
the last 9.x branch went out of support.  
  
Robert Treat and Tom Lane, reviewed by Julien Rouhaud  
  
Discussion: https://postgr.es/m/CAJSLCQ07F-WCYYYOY8+dWhHcVeJ1Pb01cWc-c0Hu=M3EjKT2Eg@mail.gmail.com  

commit   : 100a8ca2c2852a990135f6de4268b89f6ab19449    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Sep 2022 12:41:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Sep 2022 12:41:36 -0400    

When using the BSD UUID functions, contrib/uuid-ossp expects  
uuid_create() to produce a version-1 UUID.  FreeBSD still does so,  
but in recent NetBSD releases that function produces a version-4  
(random) UUID instead.  That's not acceptable for our purposes:  
if the user wanted v4 she would have asked for v4, not v1.  
Hence, check the version digit and complain if it's not '1'.  
  
Also drop the documentation's claim that the NetBSD implementation  
is usable.  It might be, depending on which OS version you're using,  
but we're not going to get into that kind of detail.  
  
(Maybe someday we should ditch all these external libraries  
and just write our own UUID code, but today is not that day.)  
  
Nazir Bilal Yavuz, with cosmetic adjustments and docs by me.  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/3848059.1661038772@sss.pgh.pa.us  
Discussion: https://postgr.es/m/17358-89806e7420797025@postgresql.org  

commit   : 5bb88967ed5cdfda05969557068229196d171276    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2022 13:51:45 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2022 13:51:45 +0200    

In commit 3d895bc846f2 I introduced a bogus semicolon mid-statement by  
careless cut-n-paste; move it.  This had already been reported by Justin  
Pryzby.  
  
Also, change the styling a bit by avoiding names in CamelCase.  This is  
more consistent with the style we use elsewhere.  
  
Backpatch to 15.  
  
Author: Vitaly Burovoy <vitaly.burovoy@gmail.com>  
Reviewed-by: Vik Fearing <vik@postgresfriends.org>  
Discussion: https://postgr.es/m/9afe5766-5a61-7860-598c-136867fad065@gmail.com  
Discussion: https://postgr.es/m/20220819133016.GV26426@telsasoft.com  

commit   : 68b0da67794e62df53d07956482770cbfbc5e786    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2022 12:22:20 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2022 12:22:20 +0200    

Because of inadequate filtering, the check triggers were confusing the  
search for action triggers in GetForeignKeyActionTriggers and vice-versa  
in GetForeignKeyCheckTriggers; this confusion results in seemingly  
random assertion failures, and can have real impact in non-asserting  
builds depending on catalog order.  Change these functions so that they  
correctly ignore triggers that are not relevant to each side.  
  
To reduce the odds of further problems, do not break out of the  
searching loop in assertion builds.  This break is likely to hide bugs;  
without it, we would have detected this bug immediately.  
  
This problem was introduced by f4566345cf40, so backpatch to 15 where  
that commit first appeared.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://postgr.es/m/20220908172029.sejft2ppckbo6oh5@awork3.anarazel.de  
Discussion: https://postgr.es/m/4104619.1662663056@sss.pgh.pa.us  

commit   : 0a7c9ee50062e0f48cdd89b9c0e166ff59caabc8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Sep 2022 10:01:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Sep 2022 10:01:14 +0900    

On failure in restoring a block image, no details were provided, while  
it is possible to see failure with an inconsistent record state, a  
failure in processing decompression or a failure in decompression  
because a build does not support this option.  
  
RestoreBlockImage() is used in two code paths in the backend code,  
during recovery and when checking a page consistency after applying  
masking, and both places are changed to consume the error message  
produced by the internal routine when it returns a false status.  All  
the error messages are reported under ERRCODE_INTERNAL_ERROR, that gets  
used also when attempting to access a page compressed by a method  
not supported by the build attempting the decompression.  This is  
something that can happen in core when doing physical replication with  
primary and standby using inconsistent build options, for example.  
  
This routine is available since 2c03216d and it has never provided any  
context about the error happening when it failed.  This change is  
justified even more after 57aa5b2, that introduced compression of FPWs  
in WAL.  
  
Reported-by: Justin Prysby  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20220905002320.GD31833@telsasoft.com  
Backpatch-through: 15  

commit   : ade2409b18e9c5d68afb13831da69198d06e5062    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Sep 2022 13:17:02 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Sep 2022 13:17:02 +0200    

During ALTER TABLE ATTACH PARTITION, if the name of a parent's foreign  
key constraint is already used on the partition, the code tries to  
choose another one before the FK attributes list has been populated,  
so the resulting constraint name was "<relname>__fkey" instead of  
"<relname>_<attrs>_fkey".  Repair, and add a test case.  
  
Backpatch to 12.  In 11, the code to attach a partition was not smart  
enough to cope with conflicting constraint names, so the problem doesn't  
exist there.  
  
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://postgr.es/m/20220901184156.738ebee5@karst  

commit   : dd38ff28addc13594c0f9e2a62ef2ffa59230598    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Sep 2022 20:25:20 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 8 Sep 2022 20:25:20 +1200    

We should process completed IOs *before* trying to start more, so that  
it is always possible to decode one more record when the decoded record  
queue is empty, even if maintenance_io_concurrency is set so low that a  
single earlier WAL record might have saturated the IO queue.  
  
That bug was hidden because the effect of maintenance_io_concurrency was  
arbitrarily clamped to be at least 2.  Fix the ordering, and also remove  
that clamp.  We need a special case for 0, which is now treated the same  
as recovery_prefetch=off, but otherwise the number is used directly.  
This allows for testing with 1, which would have made the problem  
obvious in simple test scenarios.  
  
Also add an explicit error message for missing contrecords.  It was a  
bit strange that we didn't report an error already, and became a latent  
bug with prefetching, since the internal state that tracks aborted  
contrecords would not survive retrying, as revealed by  
026_overwrite_contrecord.pl with this adjustment.  Reporting an error  
prevents that.  
  
Back-patch to 15.  
  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20220831140128.GS31833%40telsasoft.com  

commit   : 144cefac92644f338c35b77f6d9b4a9456c80563    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Sep 2022 17:33:49 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Sep 2022 17:33:49 +0200    

commit   : 25996a82a44629bdedeae73b36c37ee35b37e9fe    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 7 Sep 2022 08:46:32 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 7 Sep 2022 08:46:32 +0530    

Add a new logical replication section for "Column Lists" (analogous to the  
Row Filters page). This explains how the feature can be used and the  
caveats in it.  
  
Author: Peter Smith  
Reviewed-by: Shi yu, Vignesh C, Erik Rijkers, Amit Kapila  
Backpatch-through: 15, where it was introduced  
Discussion: https://postgr.es/m/CAHut+PvOuc9=_4TbASc5=VUqh16UWtFO3GzcKQK_5m1hrW3vqg@mail.gmail.com  

commit   : e25631265a233e0c315458b206e419eca69fdb22    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2022 18:00:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2022 18:00:32 -0400    

The addition of published column names forgot to filter on attisdropped,  
leading to cases where you could see "........pg.dropped.1........"  
or the like as a reportedly-published column.  
  
While we're here, rewrite the new subquery to get a more efficient plan  
for it.  
  
Hou Zhijie, per report from Jaime Casanova.  Back-patch to v15 where  
the bug was introduced.  (Sadly, this means we need a post-beta4  
catversion bump before beta4 has even hit the streets.  I see no  
good alternative though.)  
  
Discussion: https://postgr.es/m/Yxa1SU4nH2HfN3/i@ahch-to  

commit   : 6e55ea79faa56db85a2b6c5bf94cee8acf8bfdb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Sep 2022 17:12:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Sep 2022 17:12:45 -0400    

commit   : 77ce482e9efb9f1eaf62cd77ad1e5f17b6cc9d16    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Sep 2022 14:37:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Sep 2022 14:37:22 +0200    

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

commit   : 6ce4c4d83101886e0a9fea026faa3480a572bc84    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 5 Sep 2022 18:43:36 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 5 Sep 2022 18:43:36 +1200    

Improve documentation regarding the limitations of unique and primary key  
constraints on partitioned tables.  The existing documentation didn't make  
it clear that the constraint columns had to be present in the partition  
key as bare columns.  The reader could be led to believe that it was ok to  
include the constraint columns as part of a function call's parameters or  
as part of an expression.  Additionally, the documentation didn't mention  
anything about the fact that we disallow unique and primary key  
constraints if the partition keys contain *any* function calls or  
expressions, regardless of if the constraint columns appear as columns  
elsewhere in the partition key.  
  
The confusion here was highlighted by a report on the general mailing list  
by James Vanns.  
  
Discussion: https://postgr.es/m/CAH7vdhNF0EdYZz3GLpgE3RSJLwWLhEk7A_fiKS9dPBT3Dz_3eA@mail.gmail.com  
Discussion: https://postgr.es/m/CAApHDvoU-u9iTqKjteYRFfi+UNEk7dbSAcyxEQD==vZt9B1KnA@mail.gmail.com  
Reviewed-by: Erik Rijkers  
Backpatch-through: 11  

commit   : 46b588afcdc6891bb0972bdeb6bc36bad5c01033    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 5 Sep 2022 00:06:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 5 Sep 2022 00:06:39 +0200    

Commit e3fcca0d0d24 reverted modifications to HOT for BRIN, but it also  
removed a couple unrelated tests from stats.sql. Reinstate those tests.  
  
Reported-by: Peter Eisentraut  

commit   : 01474f56981a4b27fe5e304a61b0fce2ac025c69    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Sep 2022 23:37:42 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Sep 2022 23:37:42 +0200    

Commit db0d67db2 tweaked sort costing, which however resulted in a  
couple plan changes in our regression tests. Most of the new plans were  
fine, but partition_aggregate were meant to test parallel plans and the  
new plans were serial.  
  
Fix that by lowering parallel_setup_cost to 0, which is enough to switch  
to the parallel plan again.  
  
Report and patch by David Rowley.  
  
Author: David Rowley  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/CAApHDvpVFgWzXdtUQkjyOPhNrNvumRi_=ftgS79KeAZ92tnHKQ@mail.gmail.com  

commit   : 4209126655ccac68fe582c5fea3e638a4a1c503c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 3 Sep 2022 20:57:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 3 Sep 2022 20:57:23 +0900    

These have been updated by the revert done in 2f2b18b, but the  
pre-revert state was correct.  Note that the result was incorrectly  
formatted in the first case.  
  
Author: Erik Rijkers  
Discussion: https://postgr.es/m/13777e96-24b6-396b-cb16-8ad01b6ac130@xs4all.nl  
Backpatch-through: 13  

commit   : a3e88e5a099eed5577771110b6824b376d5a44ae    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Sep 2022 23:32:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Sep 2022 23:32:19 -0400    

Discussion: https://postgr.es/m/YxAqYijOsLzgLQgy@momjian.us  
  
Backpatch-through: 10  

commit   : 170704da68c5150776c0ee4ed51350acde47b4a5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Sep 2022 21:57:41 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Sep 2022 21:57:41 -0400    

Reported-by: Drew DeVault  
  
Discussion: https://postgr.es/m/20211018091720.31299-1-sir@cmpwn.com  
  
Backpatch-through: 10  

commit   : 4ddcb20592270ac3aa1082531d8057ca3d229951    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Sep 2022 21:47:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Sep 2022 21:47:30 -0400    

Reported-by: Matthias van de Meent  
  
Discussion: https://postgr.es/m/CAEze2WhrNAT2g8upDUhfqt1nWfV_JdUgXAQu7oT4rY2L68O-HQ@mail.gmail.com  
  
Backpatch-through: 15 only  

commit   : d0d934490020f9311662da8cdba4ccc2070e420d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 3 Sep 2022 12:58:16 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 3 Sep 2022 12:58:16 +1200    

XLogPageRead() can retry internally after a pread() system call has  
succeeded, in the case of short reads, and page validation failures  
while in standby mode (see commit 0668719801).  Due to an oversight in  
commit 3f1ce973, these cases could leave stale data in the internal  
cache of xlogreader.c without marking it invalid.  The main defense  
against stale cached data on failure to read a page was in the error  
handling path of the calling function ReadPageInternal(), but that  
wasn't quite enough for errors handled internally by XLogPageRead()'s  
retry loop if we then exited with XLREAD_WOULDBLOCK.  
  
1.  ReadPageInternal() now marks the cache invalid before calling the  
    page_read callback, by setting state->readLen to 0.  It'll be set to  
    a non-zero value only after a successful read.  It'll stay valid as  
    long as the caller requests data in the cached range.  
  
2.  XLogPageRead() no long performs internal retries while reading  
    ahead.  While such retries should work, the general philosophy is  
    that we should give up prefetching if anything unusual happens so we  
    can handle it when recovery catches up, to reduce the complexity of  
    the system.  Let's do that here too.  
  
3.  While here, a new function XLogReaderResetError() improves the  
    separation between xlogrecovery.c and xlogreader.c, where the former  
    previously clobbered the latter's internal error buffer directly.  
    The new function makes this more explicit, and also clears a related  
    flag, without which a standby would needlessly retry in the outer  
    function.  
  
Thanks to Noah Misch for tracking down the conditions required for a  
rare build farm failure in src/bin/pg_ctl/t/003_promote.pl, and  
providing a reproducer.  
  
Back-patch to 15.  
  
Reported-by: Noah Misch <noah@leadboat.com>  
Discussion: https://postgr.es/m/20220807003627.GA4168930%40rfd.leadboat.com  

commit   : ab3131880d8ada5bd03ede38e9d8c0c545997b69    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 2 Sep 2022 16:33:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 2 Sep 2022 16:33:18 +0530    

It was not strictly correct to say that a column list must always include  
replica identity columns because that is true for only updates and  
deletes.  
  
Author: Peter Smith  
Reviwed-by: Vignesh C, Amit Kapila  
Backpatch-through: 15, where it was introduced  
Discussion: https://postgr.es/m/CAHut+PvOuc9=_4TbASc5=VUqh16UWtFO3GzcKQK_5m1hrW3vqg@mail.gmail.com  

commit   : ea4a066e5f15f0c8b721845dc7ecbe3b206e1991    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 2 Sep 2022 16:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 2 Sep 2022 16:45:01 +0900    

Commit 487e9861d added a new field to struct Trigger, but failed to  
update the documentation to match; backpatch to v13 where that came in.  
  
Reviewed by Richard Guo.  
  
Discussion: https://postgr.es/m/CAPmGK17NY92CyxJ%2BBG7A3JZurmng4jfRfzPiBTtNupGMF0xW1g%40mail.gmail.com  

commit   : 96ef3237bf741c12390003e90a4d7115c0c854b7    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Sep 2022 17:09:46 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Sep 2022 17:09:46 -0400    

The reverts the following and makes some associated cleanups:  
  
    commit f79b803dc: Common SQL/JSON clauses  
    commit f4fb45d15: SQL/JSON constructors  
    commit 5f0adec25: Make STRING an unreserved_keyword.  
    commit 33a377608: IS JSON predicate  
    commit 1a36bc9db: SQL/JSON query functions  
    commit 606948b05: SQL JSON functions  
    commit 49082c2cc: RETURNING clause for JSON() and JSON_SCALAR()  
    commit 4e34747c8: JSON_TABLE  
    commit fadb48b00: PLAN clauses for JSON_TABLE  
    commit 2ef6f11b0: Reduce running time of jsonb_sqljson test  
    commit 14d3f24fa: Further improve jsonb_sqljson parallel test  
    commit a6baa4bad: Documentation for SQL/JSON features  
    commit b46bcf7a4: Improve readability of SQL/JSON documentation.  
    commit 112fdb352: Fix finalization for json_objectagg and friends  
    commit fcdb35c32: Fix transformJsonBehavior  
    commit 4cd8717af: Improve a couple of sql/json error messages  
    commit f7a605f63: Small cleanups in SQL/JSON code  
    commit 9c3d25e17: Fix JSON_OBJECTAGG uniquefying bug  
    commit a79153b7a: Claim SQL standard compliance for SQL/JSON features  
    commit a1e7616d6: Rework SQL/JSON documentation  
    commit 8d9f9634e: Fix errors in copyfuncs/equalfuncs support for JSON node types.  
    commit 3c633f32b: Only allow returning string types or bytea from json_serialize  
    commit 67b26703b: expression eval: Fix EEOP_JSON_CONSTRUCTOR and EEOP_JSONEXPR size.  
  
The release notes are also adjusted.  
  
Backpatch to release 15.  
  
Discussion: https://postgr.es/m/40d2c882-bcac-19a9-754d-4299e1d87ac7@postgresql.org  

commit   : c4e861b7bba3c4766beac53239c5435b9abe1275    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Sep 2022 19:21:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 1 Sep 2022 19:21:58 +1200    

Primarily, this fixes an incorrect calculation in SlabCheck which was  
looking in the wrong byte for the sentinel check.  The reason that we've  
never noticed this before in the form of a failing sentinel check is  
because the pre-check to this always fails because all current core users  
of slab contexts have a chunk size which is already MAXALIGNed, therefore  
there's never any space for the sentinel byte.  It is possible that an  
extension needs to use a slab context and if they do with a chunk size  
that's not MAXALIGNed, then they'll likely get errors about overwritten  
sentinel bytes.  
  
Additionally, this patch changes various calculations which are being done  
based on the sizeof(SlabBlock).  Currently, sizeof(SlabBlock) is a  
multiple of 8, therefore sizeof(SlabBlock) is the same as  
MAXALIGN(sizeof(SlabBlock)), however, if we were to ever have to add any  
fields to that struct as part of a bug fix, then SlabAlloc could end up  
returning a non-MAXALIGNed pointer.  To be safe, let's ensure we always  
MAXALIGN sizeof(SlabBlock) before using it in any calculations.  
  
This patch has already been applied to master in d5ee4db0e.  
  
Diagnosed-by: Tomas Vondra, Tom Lane  
Author: Tomas Vondra, David Rowley  
Discussion: https://postgr.es/m/CAA4eK1%2B1JyW5TiL%3DyV-3Uq1CrfnTyn0Xrk5uArt31Z%3D8rgPhXQ%40mail.gmail.com  
Backpatch-through: 10  

commit   : 974299a808554a0983e92923a06e14e899cb2b55    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 23:11:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 23:11:46 -0400    

Discussion: https://postgr.es/m/Yv1Bw8J+1pYfHiRl@momjian.us  
  
Backpatch-through: 10  

commit   : 7d78fdb5f0618a38a0b34a541c328c80e9e37766    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 22:35:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 22:35:09 -0400    

Also remove USING erroneously added recently.  
  
Reported-by: Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1zhCpC7hottyMWM5Pimr9vRLprSwzLg+7PgajWhKZqRzw@mail.gmail.com  
  
Backpatch-through: 10  

commit   : 6a27e2f5339479debb6ac79c2dfcdbf7f8bc695c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 22:19:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 22:19:06 -0400    

Reported-by: michal.palenik@freemap.sk  
  
Discussion: https://postgr.es/m/163499710897.684.7420075366995883688@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 8dc12a9b64e9e2f49bcbc52fd69e7296529ff315    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 22:04:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 22:04:36 -0400    

Previously it was just marked as a duplicate of the core function.  
  
Reported-by: Andreas Dijkman  
  
Discussion: https://postgr.es/m/17349-24d61e214429e8c1@postgresql.org  
  
Backpatch-through: 13  

commit   : 8d489a30c0da319b24f9d22a0267c3c7f26564a7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 21:46:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 21:46:14 -0400    

This allows the syntax to be more accurate about what clauses are  
supported.  Also switch an example query to use the ANSI join syntax.  
  
Reported-by: Joel Jacobson  
  
Discussion: https://postgr.es/m/67b71d3e-0c22-44df-a223-351f14418319@www.fastmail.com  
  
Backpatch-through: 11  

commit   : a2039b1f8e90d26a7e2a115ad5784476bd6deaa2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 21:10:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 21:10:37 -0400    

Non-sql_body functions are evaluated at runtime.  
  
Reported-by: Erki Eessaar  
  
Discussion: https://postgr.es/m/AM9PR01MB8268BF5E74E119828251FD34FE409@AM9PR01MB8268.eurprd01.prod.exchangelabs.com  
  
Backpatch-through: 10  

commit   : 0b16ee7e6fc79738bbd9ac6629276acee642d24a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 20:27:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 20:27:27 -0400    

Also mention that time zone abbreviations are not supported.  
  
Reported-by: philippe.godfrin@nov.com  
  
Discussion: https://postgr.es/m/163888728952.1269.5167822676466793158@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : e40707c0e752822189de2f15ab955b87ca60ecd3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 19:43:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 19:43:06 -0400    

Reported-by: Japin Li  
  
Discussion: https://postgr.es/m/MEYP282MB1669B13E98AE531617CB1386B6979@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  
  
Backpatch-through: 10  

commit   : 27e8fc4bcc33e94cd0016b81464bbb7b13d47775    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 19:28:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 19:28:42 -0400    

It used to show direction was required for FROM/IN.  
  
Reported-by: Rob <rirans@comcast.net>  
  
Discussion: https://postgr.es/m/20211015165248.isqjceyilelhnu3k@localhost  
  
Author: Rob <rirans@comcast.net>  
  
Backpatch-through: 10  

commit   : 3da5ecb98c80be0a5c8064b7e4b8f147862f1581    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 17:08:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2022 17:08:44 -0400    

Reported-by: Rob <rirans@comcast.net>  
  
Discussion: https://postgr.es/m/20211016171149.yaouvlw5kvux6dvk@localhost  
  
Author: Rob <rirans@comcast.net>  
  
Backpatch-through: 10  

commit   : 0c599e748f2c81e415bb39567c4fd40a6bc64815    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2022 16:23:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2022 16:23:20 -0400    

get_database_list() failed to restore the caller's memory context,  
instead leaving current context set to TopMemoryContext which is  
how CommitTransactionCommand() leaves it.  The callers both think  
they are using short-lived contexts, for the express purpose of  
not having to worry about cleaning up individual allocations.  
The net effect therefore is that supposedly short-lived allocations  
could accumulate indefinitely in the launcher's TopMemoryContext.  
  
Although this has been broken for a long time, it seems we didn't  
have any obvious memory leak here until v15's rearrangement of the  
stats logic.  I (tgl) am not entirely convinced that there's no  
other leak at all, though, and we're surely at risk of adding one  
in future back-patched fixes.  So back-patch to all supported  
branches, even though this may be only a latent bug in pre-v15.  
  
Reid Thompson  
  
Discussion: https://postgr.es/m/972a4e12b68b0f96db514777a150ceef7dcd2e0f.camel@crunchydata.com  

commit   : 61f6e5c2360382be99846be904af33e3406c938a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2022 10:42:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2022 10:42:05 -0400    

If the input word exceeds 1000 bytes, don't pass it to the stemmer;  
just return it as-is after case folding.  Such an input is surely  
not a word in any human language, so whatever the stemmer might  
do to it would be pretty dubious in the first place.  Adding this  
restriction protects us against a known recursion-to-stack-overflow  
problem in the Turkish stemmer, and it seems like good insurance  
against any other safety or performance issues that may exist in  
the Snowball stemmers.  (I note, for example, that they contain no  
CHECK_FOR_INTERRUPTS calls, so we really don't want them running  
for a long time.)  The threshold of 1000 bytes is arbitrary.  
  
An alternative definition could have been to treat such words as  
stopwords, but that seems like a bigger break from the old behavior.  
  
Per report from Egor Chindyaskin and Alexander Lakhin.  
Thanks to Olly Betts for the recommendation to fix it this way.  
  
Discussion: https://postgr.es/m/1661334672.728714027@f473.i.mail.ru  

commit   : fe9d009e3e945945e1e3bb0f65514217fc8566e5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Aug 2022 07:42:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Aug 2022 07:42:01 +0200    

As of db23464715f4792298c639153dda7bfd9ad9d602, we don't install  
anything there anymore from plpython, so we don't need to create the  
installation directory anymore.  

commit   : 529d8f3736a1c62dc00ee272e04a6decaacc300b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2022 17:28:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2022 17:28:32 -0400    

The default of lazy symbol resolution means that when the postmaster  
first reaches the select() call in ServerLoop, it'll need to resolve  
the link to that libc entry point.  NetBSD's dynamic loader takes  
an internal lock while doing that, and if a signal interrupts the  
operation then there is a risk of self-deadlock should the signal  
handler do anything that requires that lock, as several of the  
postmaster signal handlers do.  The window for this is pretty narrow,  
and timing considerations make it unlikely that a signal would arrive  
right then anyway.  But it's semi-repeatable on slow single-CPU  
machines, and in principle the race could happen with any hardware.  
  
The least messy solution to this is to force binding of dynamic  
symbols at postmaster start, using the "-z now" linker option.  
While we're at it, also use "-z relro" so as to provide a small  
security gain.  
  
It's not entirely clear whether any other platforms share this  
issue, but for now we'll assume it's NetBSD-specific.  (We might  
later try to use "-z now" on more platforms for performance  
reasons, but that would not likely be something to back-patch.)  
  
Report and patch by me; the idea to fix it this way is from  
Andres Freund.  
  
Discussion: https://postgr.es/m/3384826.1661802235@sss.pgh.pa.us  

commit   : eb29fa38895c06814c30f758161a905e67f02ed1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 29 Aug 2022 10:47:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 29 Aug 2022 10:47:12 -0400    

When a PostgreSQL instance performing archive recovery but not using  
standby mode is promoted, and the last WAL segment that it attempted  
to read ended in a partial record, the previous code would create  
invalid WAL on the new timeline. The WAL from the previously timeline  
would be copied to the new timeline up until the end of the last valid  
record, but instead of beginning to write WAL at immediately  
afterwards, the promoted server would write an overwrite contrecord at  
the beginning of the next segment. The end of the previous segment  
would be left as all-zeroes, resulting in failures if anything tried  
to read WAL from that file.  
  
The root of the issue is that ReadRecord() decides whether to set  
abortedRecPtr and missingContrecPtr based on the value of StandbyMode,  
but ReadRecord() switches to a new timeline based on the value of  
ArchiveRecoveryRequested. We shouldn't try to write an overwrite  
contrecord if we're switching to a new timeline, so change the test in  
ReadRecod() to check ArchiveRecoveryRequested instead.  
  
Code fix by Dilip Kumar. Comments by me incorporating suggested  
language from Álvaro Herrera. Further review from Kyotaro Horiguchi  
and Sami Imseih.  
  
Discussion: http://postgr.es/m/CAFiTN-t7umki=PK8dT1tcPV=mOUe2vNhHML6b3T7W7qqvvajjg@mail.gmail.com  
Discussion: http://postgr.es/m/FB0DEA0B-E14E-43A0-811F-C1AE93D00FF3%40amazon.com  

commit   : ebe2b4097b5a5ce069a60358b1361d2702cac67f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2022 10:44:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2022 10:44:52 -0400    

Compute total number of sub-parts correctly, per jason@banfelder.net  
  
Simon Riggs  
  
Discussion: https://postgr.es/m/166161184718.1235920.6304070286124217754@wrigleys.postgresql.org  

commit   : 73cbdb7f1944b2ad847fb62d71011b96cd96c8fd    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Tue, 23 Aug 2022 09:55:05 +0700    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Aug 2022 09:55:05 +0700    

Using %u with uint16 causes warnings with -Wformat-signedness. There are many  
other warnings, but for now change only these since c920fe4818 already changed  
the message string for most of them.  
  
Per report from Peter Eisentraut  
Discussion: https://www.postgresql.org/message-id/31e63649-0355-7088-831e-b07d5f908a8c%40enterprisedb.com  

commit   : 44817d97bca361f2be7fac64afa50715f959c11c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Aug 2022 15:22:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Aug 2022 15:22:07 +0900    

While waiting for slots to become available in wait_on_slots() in  
parallel_slot.c, the cancellation always relied on the first connection  
in the set to do the job.  This could cause problems when this slot's  
socket is gone as PQgetCancel() would return NULL in this case.  Rather  
than always using the first connection, this changes the logic to use  
the first valid connection for the cancellation.  
  
Author: Ranier Vilela  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/CAEudQAokk1h_pUwGXsYS4oVOuf35s1O2o3TXGHpV8=AWikvgHA@mail.gmail.com  
Backpatch-through: 14  

commit   : d4e9bca40309fff78c1a585cdb3dabf6fabfb6f1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 26 Aug 2022 10:33:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 26 Aug 2022 10:33:55 +0200    

The comment in basebackup.c updated by 33bd4698c11 was actually  
obsolete to begin with, since the symbols it was referring to haven't  
existed in that header file for quite some time.  The header file is  
still needed for other reasons, though, so keep the #include, just  
drop the comment.  

commit   : 2829cfaf78b6b9d1909ce1dbbdb2839be9697853    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 26 Aug 2022 16:55:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 26 Aug 2022 16:55:01 +0900    

commit   : c742eb36b1eb516166cdcb307a37dded51fa6089    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Aug 2022 20:46:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Aug 2022 20:46:58 +0200    

Fix some wrong use and install a safeguard against future mistakes.  

commit   : 01b23daa9bab9648457935e0c24376637eecd2e4    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 25 Aug 2022 10:26:31 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 25 Aug 2022 10:26:31 -0700    

Reported-by: Bharath Rupireddy  
Backpatch-through: 15  
Discussion: https://postgr.es/m/CALj2ACU+at7RqnWEzS59QsFg3ZOF4C4GSp7pt+PWiLEp0zrEKg@mail.gmail.com  

commit   : 19c4de8289bedf90ac10d496e3896f8838937a83    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Aug 2022 15:04:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Aug 2022 15:04:38 +0200    

commit   : f2dcf1acfbd8d23e1651293cd3c83c0443b45143    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Aug 2022 06:35:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Aug 2022 06:35:16 +0200    

ICU doesn't support some server encodings, so we need to exclude them  
if a non-supported encoding was set up.  

commit   : 36a8881c4bfe578e94ba97a5140d7850ffa87bed    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Jul 2022 09:37:17 +0900    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 Jul 2022 09:37:17 +0900    

pg_start_backup() and pg_stop_backup() have been respectively renamed to  
pg_backup_start() and pg_backup_stop() as of 39969e2, but a few comments  
did not get the call.  
  
Reviewed-by: Kyotaro Horiguchi, David Steele  
Discussion: https://postgr.es/m/YrqGlj1+4DF3dbZ/@paquier.xyz  

commit   : 72b6828da3f72bdcf87f680fe37a90ce964793cc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Aug 2022 20:13:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Aug 2022 20:13:52 +0200    

This was forgotten when the new column was introduced.  
  
Author: Marina Polyakova <m.polyakova@postgrespro.ru>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/7ad26354e75259f59c4a6c6997b8ee32%40postgrespro.ru  

commit   : 3d3c05c70fc7c1ce7794ebff55aa251a589de851    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2022 13:01:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2022 13:01:40 -0400    

SplitToVariants() in the ispell code, lseg_inside_poly() in geo_ops.c,  
and regex_selectivity_sub() in selectivity estimation could recurse  
until stack overflow; fix by adding check_stack_depth() calls.  
So could next() in the regex compiler, but that case is better fixed by  
converting its tail recursion to a loop.  (We probably get better code  
that way too, since next() can now be inlined into its sole caller.)  
  
There remains a reachable stack overrun in the Turkish stemmer, but  
we'll need some advice from the Snowball people about how to fix that.  
  
Per report from Egor Chindyaskin and Alexander Lakhin.  These mistakes  
are old, so back-patch to all supported branches.  
  
Richard Guo and Tom Lane  
  
Discussion: https://postgr.es/m/1661334672.728714027@f473.i.mail.ru  

commit   : e6828053d9d62aab68f74d0f3a024db10a4ce5fd    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 24 Aug 2022 23:46:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 24 Aug 2022 23:46:40 +1200    

Author: Shinya Kato  
Discussion: https://postgr.es/m/76c01275776749a167f49379ebec57f1@oss.nttdata.com  
Backpatch-through: 15, where that change was introduced  

commit   : f02147bd237eb59d908ed3166895081ba17df4a1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Aug 2022 13:27:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 24 Aug 2022 13:27:34 +0200    

The code took the LOCALE option as the default/fallback for  
ICU_LOCALE, but this was neither documented nor intended, so remove  
it.  (It was probably left in from an earlier patch version.)  
  
Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru>  
Discussion: https://www.postgresql.org/message-id/flat/f385ba25e7f8be427b8c582e5cca7d79%40postgrespro.ru#515a31c5429d6d37ad1d5c9d66962a1e  

commit   : dfe2eb7633f53c26cac6d31d1cb5736113d16349    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Aug 2022 21:50:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Aug 2022 21:50:12 +0200    

commit   : 2c63b0930aee1bb5c265fad4a65c9d0b62b1f9da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2022 09:55:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2022 09:55:37 -0400    

On fast machines, it's possible for applications such as pgbench  
to issue connection requests so quickly that the postmaster's  
listen queue overflows in the kernel, resulting in unexpected  
failures (with not-very-helpful error messages).  Most modern OSes  
allow the queue size to be increased, so document how to do that.  
  
Per report from Kevin McKibbin.  
  
Discussion: https://postgr.es/m/CADc_NKg2d+oZY9mg4DdQdoUcGzN2kOYXBu-3--RW_hEe0tUV=g@mail.gmail.com  

commit   : d53ff6a44b32c15dd150c383ffbe4b0f5dd13037    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2022 09:41:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2022 09:41:37 -0400    

sysctl is more portable than Linux's /proc/sys file tree, and  
often easier to use too.  That's why most of our docs refer to  
sysctl when talking about how to adjust kernel parameters.  
Bring the few stragglers into line.  
  
Discussion: https://postgr.es/m/361175.1661187463@sss.pgh.pa.us  

commit   : 42681dffafa2f9dea3e034d0c29a3f1a7b3b07e8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 23 Aug 2022 10:08:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 23 Aug 2022 10:08:43 +0530    

While decoding changes in a loop, if we skip all the changes there is no  
CFI making the loop uninterruptible.  
  
Reported-by: Whale Song and Andrey Borodin  
Bug: 17580  
Author: Masahiko Sawada  
Reviwed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/17580-849c1d5b6d7eb422@postgresql.org  
Discussion: https://postgr.es/m/B319ECD6-9A28-4CDF-A8F4-3591E0BF2369@yandex-team.ru  

commit   : 045ec347857b66e8a494b2c12126a6d476702065    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 22 Aug 2022 20:16:50 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 22 Aug 2022 20:16:50 -0700    

Somewhere during the development of the patch acquiring a lock during read  
access to variable-numbered stats got lost. The missing lock acquisition won't  
cause corruption, but can lead to reading torn values when accessing  
stats. Add the missing lock acquisitions.  
  
Reported-by: Greg Stark <stark@mit.edu>  
Reviewed-by: "Drouvot, Bertrand" <bdrouvot@amazon.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/CAM-w4HMYkM_DkYhWtUGV+qE_rrBxKOzOF0+5faozxO3vXrc9wA@mail.gmail.com  
Backpatch: 15-  

commit   : a2caf182a2edcee7b1c00036b7dba6762941473c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Aug 2022 15:31:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Aug 2022 15:31:50 +0200    

An assertion would fail when creating a database with libc locale  
provider from a template database with icu locale provider.  
  
Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/f385ba25e7f8be427b8c582e5cca7d79%40postgrespro.ru#515a31c5429d6d37ad1d5c9d66962a1e  

commit   : 3725b7f3c93eac3148fe36cffbb7db47d4a9fae0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Aug 2022 13:26:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Aug 2022 13:26:52 +0200    

When checking whether the major version supports per-database locale  
providers, it was always looking at the version of the old cluster  
instead of the cluster that was passed in.  This would lead to  
failures to detect locale provider mismatches.  
  
Reported-by: Marina Polyakova <m.polyakova@postgrespro.ru>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/f385ba25e7f8be427b8c582e5cca7d79%40postgrespro.ru#515a31c5429d6d37ad1d5c9d66962a1e  

commit   : 254d79f0b23dfe107594c90ee8375165422db2c4    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 22 Aug 2022 08:51:25 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 22 Aug 2022 08:51:25 +0530    

As such the current usage of & won't produce incorrect results but it  
would be better to use && to short-circuit the evaluation of second  
condition when the same is not required.  
  
Author: Ranier Vilela  
Reviewed-by: Tom Lane, Bharath Rupireddy  
Backpatch-through: 15, where it was introduced  
Discussion: https://postgr.es/m/CAEudQApL8QcoYwQuutkWKY_h7gBY8F0Xs34YKfc7-G0i83K_pw@mail.gmail.com  

commit   : 24f457aa2b7006e4b427a3ac1e7ce0f248b55ba3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 20 Aug 2022 11:40:59 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 20 Aug 2022 11:40:59 +1200    

Compiling with -Wshadow=compatible-local yields quite a few warnings about  
local variables being shadowed by compatible local variables in an inner  
scope.  Of course, this is perfectly valid in C, but we have had bugs in  
the past as a result of developers failing to notice this.  af7d270dd is a  
recent example.  
  
Here we do a cleanup of warnings we receive from -Wshadow=compatible-local  
for code which is new to PostgreSQL 15.  We've yet to have the discussion  
about if we actually ever want to run that as a standard compilation flag.  
We'll need to at least get the number of warnings down to something easier  
to manage before we can realistically consider if we want this or not.  
This commit is the first step towards reducing the warnings.  
  
The changes being made here are all fairly trivial.  Because of that, and  
the fact that v15 is still in beta, this is being back-patched into 15.  
It seems more risky not to do this as the risk of future bugs is increased  
by the additional conflicts that this commit could cause for any future  
bug fixes touching the same areas as this commit.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20220817145434.GC26426%40telsasoft.com  
Backpatch-through: 15  

commit   : 4496020e6dfaffe8217e4d3f85567bb2b6927b45    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 19 Aug 2022 09:26:06 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 19 Aug 2022 09:26:06 -0700