PostgreSQL 14.0 (upcoming) commit log

commit   : 9e84f6a7213314f6f6dcb66651525d1b7eda8591    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 21 Oct 2021 09:24:59 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 21 Oct 2021 09:24:59 +0530    

This was originally done in commit 5e77625b26 for 15 only, as a  
troubleshooting aid but multiple people showed interest in back-patching  
this.  
  
Author: Jeremy Schneider  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/808ed65b-994c-915a-361c-577f088b837f@amazon.com  

commit   : 671eb8f34404d24c8f16ae40e94becb38afd93bb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 21 Oct 2021 08:07:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 21 Oct 2021 08:07:08 +0530    

Commit 464824323e introduced the wait events which were neither used by  
that commit nor by follow-up commits for that work.  
  
Author: Masahiro Ikeda  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/ff077840-3ab2-04dd-bbe4-4f5dfd2ad481@oss.nttdata.com  

commit   : 5040c96415a062a1016e0a6b9a4dc9f26a7f356e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Oct 2021 10:39:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Oct 2021 10:39:07 +0900    

Using for a new database a template database with shared dependencies  
that need to be copied over was causing a corruption of pg_shdepend  
because of an off-by-one computation error of the index number used for  
the values inserted with a slot.  
  
Issue introduced by e3931d0.  Monitoring the rest of the code, there are  
no similar mistakes.  
  
Reported-by: Sven Klemm  
Author: Aleksander Alekseev  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/CAJ7c6TP0AowkUgNL6zcAK-s5HYsVHVBRWfu69FRubPpfwZGM9A@mail.gmail.com  
Backpatch-through: 14  

commit   : 7182788552b7b7d7fca226af2ec281789b1abff3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Oct 2021 13:05:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Oct 2021 13:05:42 -0300    

Discussion: https://postgr.es/m/YW/MYdSRQZtPFBWR@paquier.xyz  

commit   : 81aefaea82934e577e9d81fcb1f809a8d75bbf5c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Oct 2021 16:48:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Oct 2021 16:48:57 +0900    

The build scripts of Visual Studio would fail to detect properly a 3.0.0  
build as the check on the second digit was failing.  This is adjusted  
where needed, allowing the builds to complete.  Note that the MSIs of  
OpenSSL mentioned in the documentation have not changed any library  
names for Win32 and Win64, making this change straight-forward.  
  
Reported-by: htalaco, via github  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/YW5XKYkq6k7OtrFq@paquier.xyz  
Backpatch-through: 9.6  

commit   : 3ce3fb2f7dc66fef67c8184b96245d74372b729e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 19 Oct 2021 19:08:45 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 19 Oct 2021 19:08:45 -0300    

Commit 1b5d797cd4f7 intended to relax the lock level used to rename  
indexes, but inadvertently allowed *any* relation to be renamed with a  
lowered lock level, as long as the command is spelled ALTER INDEX.  
That's undesirable for other relation types, so retry the operation with  
the higher lock if the relation turns out not to be an index.  
  
After this fix, ALTER INDEX <sometable> RENAME will require access  
exclusive lock, which it didn't before.  
  
Author: Nathan Bossart <bossartn@amazon.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Onder Kalaci <onderk@microsoft.com>  
Discussion: https://postgr.es/m/PH0PR21MB1328189E2821CDEC646F8178D8AE9@PH0PR21MB1328.namprd21.prod.outlook.com  

commit   : 533315b68f8a00784686500f29ee780244341bc2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 19 Oct 2021 10:14:49 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 19 Oct 2021 10:14:49 -0700    

ldapsearch's deprecated -h/-p arguments were removed, need to use -H now -  
which has been around for over 20 years.  
  
As perltidy insists on reflowing the parameters anyway, change order and  
"phrasing" to yield a less confusing layout (per suggestion from Tom Lane).  
  
Discussion: https://postgr.es/m/20211009233850.wvr6apcrw2ai6cnj@alap3.anarazel.de  
Backpatch: 11-, where the tests were added.  

commit   : 04dae19f4d5067b35b421dcd43175a5059747800    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 13:54:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 13:54:45 -0400    

An update such as "UPDATE ... SET fld[n].subfld = whatever"  
failed if the array elements were domains rather than plain  
composites.  That's because isAssignmentIndirectionExpr()  
failed to cope with the CoerceToDomain node that would appear  
in the expression tree in this case.  The result would typically  
be a crash, and even if we accidentally didn't crash, we'd not  
correctly preserve other fields of the same array element.  
  
Per report from Onder Kalaci.  Back-patch to v11 where arrays of  
domains came in.  
  
Discussion: https://postgr.es/m/PH0PR21MB132823A46AA36F0685B7A29AD8BD9@PH0PR21MB1328.namprd21.prod.outlook.com  

commit   : f627fd547a34bb3ffba5763a1ab404c2777debe4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 11:35:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Oct 2021 11:35:15 -0400    

I think when I added this assertion (in commit 8f889b108), I was only  
thinking of the use of transformExpressionList at top level of INSERT  
and VALUES.  But it's also called by transformRowExpr(), which can  
certainly occur in an UPDATE targetlist, so it's inappropriate to  
suppose that p_multiassign_exprs must be empty.  Besides, since the  
input is not expected to contain ResTargets, there's no reason it  
should contain MultiAssignRefs either.  Hence this code need not  
be concerned about the state of p_multiassign_exprs, and we should  
just drop the assertion.  
  
Per bug #17236 from ocean_li_996.  It's been wrong for years,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17236-3210de9bcba1d7ca@postgresql.org  

commit   : 3e2f32b01d3b6868022c8381b28e8fc5399baeb9    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:54 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:54 +0200    

If the blob TOC file cannot be parsed, the error message was failing  
to print the filename as the variable holding it was shadowed by the  
destination buffer for parsing.  When the filename fails to parse,  
the error will print an empty string:  
  
 ./pg_restore -d foo -F d dump  
 pg_restore: error: invalid line in large object TOC file "": ..  
  
..instead of the intended error message:  
  
 ./pg_restore -d foo -F d dump  
 pg_restore: error: invalid line in large object TOC file "dump/blobs.toc": ..  
  
Fix by renaming both variables as the shared name was too generic to  
store either and still convey what the variable held.  
  
Backpatch all the way down to 9.6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/A2B151F5-B32B-4F2C-BA4A-6870856D9BDE@yesql.se  
Backpatch-through: 9.6  

commit   : 121be6a665aaf64e0fe45b424cd26b53b384dc31    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:50 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 19 Oct 2021 12:59:50 +0200    

Make sure that the string parsing is limited by the size of the  
destination buffer.  
  
In pg_basebackup the available values sent from the server  
is limited to two characters so there was no risk of overflow.  
  
In pg_dump the buffer is bounded by MAXPGPATH, and thus the limit  
must be inserted via preprocessor expansion and the buffer increased  
by one to account for the terminator. There is no risk of overflow  
here, since in this case, the buffer scanned is smaller than the  
destination buffer.  
  
Backpatch the pg_basebackup fix to 11 where it was introduced, and  
the pg_dump fix all the way down to 9.6.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/B14D3D7B-F98C-4E20-9459-C122C67647FB@yesql.se  
Backpatch-through: 11 and 9.6  

commit   : b1b797ec71a1a8cc6bb500313f4373bcb5aac1ff    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Oct 2021 11:04:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Oct 2021 11:04:00 +0900    

The grammar of this command run on indexes with column names has always  
been authorized by the parser, and it has never been documented.  
  
Since 911e702, it is possible to define opclass parameters as of CREATE  
INDEX, which actually broke the old case of ALTER INDEX/TABLE where  
relation-level parameters n_distinct and n_distinct_inherited could be  
defined for an index (see 76a47c0 and its thread where this point has  
been touched, still remained unused).  Attempting to do that in v13~  
would cause the index to become unusable, as there is a new dedicated  
code path to load opclass parameters instead of the relation-level ones  
previously available.  Note that it is possible to fix things with a  
manual catalog update to bring the relation back online.  
  
This commit disables this command for now as the use of column names for  
indexes does not make sense anyway, particularly when it comes to index  
expressions where names are automatically computed.  One way to properly  
support this case properly in the future would be to use column numbers  
when it comes to indexes, in the same way as ALTER INDEX .. ALTER COLUMN  
.. SET STATISTICS.  
  
Partitioned indexes were already blocked, but not indexes.  Some tests  
are added for both cases.  
  
There was some code in ANALYZE to enforce n_distinct to be used for an  
index expression if the parameter was defined, but just remove it for  
now until/if there is support for this (note that index-level parameters  
never had support in pg_dump either, previously), so this was just dead  
code.  
  
Reported-by: Matthijs van der Vleuten  
Author: Nathan Bossart, Michael Paquier  
Reviewed-by: Vik Fearing, Dilip Kumar  
Discussion: https://postgr.es/m/17220-15d684c6c2171a83@postgresql.org  
Backpatch-through: 13  

commit   : 72d0642172571be7b44d54728deb609d7285d9d0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 Oct 2021 19:08:25 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 Oct 2021 19:08:25 -0300    

Failing to do that, any direct inserts/updates of those partitions  
would fail to enforce the correct constraint, that is, one that  
considers the new partition constraint of their parent table.  
  
Backpatch to 10.  
  
Reported by: Hou Zhijie <houzj.fnst@fujitsu.com>  
Author: Amit Langote <amitlangote09@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Nitin Jadhav <nitinjadhavpostgres@gmail.com>  
Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com>  
  
Discussion: https://postgr.es/m/OS3PR01MB5718DA1C4609A25186D1FBF194089%40OS3PR01MB5718.jpnprd01.prod.outlook.com  

commit   : 5b353aaff69c6099aebd45f1a63cb38b9a7ef75c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Oct 2021 11:56:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Oct 2021 11:56:48 +0900    

During a replication slot creation, an ERROR generated in the same  
transaction as the one creating a to-be-exported snapshot would have  
left the backend in an inconsistent state, as the associated static  
export snapshot state was not being reset on transaction abort, but only  
on the follow-up command received by the WAL sender that created this  
snapshot on replication slot creation.  This would trigger inconsistency  
failures if this session tried to export again a snapshot, like during  
the creation of a replication slot.  
  
Note that a snapshot export cannot happen in a transaction block, so  
there is no need to worry resetting this state for subtransaction  
aborts.  Also, this inconsistent state would very unlikely show up to  
users.  For example, one case where this could happen is an  
out-of-memory error when building the initial snapshot to-be-exported.  
Dilip found this problem while poking at a different patch, that caused  
an error in this code path for reasons unrelated to HEAD.  
  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier, Zhihong Yu  
Discussion: https://postgr.es/m/CAFiTN-s0zA1Kj0ozGHwkYkHwa5U0zUE94RSc_g81WrpcETB5=w@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 3e4c8db931e1a9b760b22382f7c9e0e28e732a2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 15:02:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 15:02:55 -0400    

Commit f0e21f2f6 missed adding a tgisinternal output column  
to getTriggers' query for pre-8.3 servers.  Back-patch to v11,  
like that commit.  

commit   : b5152e3ba688e7023f0e5f1a1b82b77bedadaafa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 12:23:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Oct 2021 12:23:57 -0400    

It was clearly the intent to do so all along, but the original coding  
fat-fingered this by checking the wrong array element.  We fixed it  
in passing in 403a3d91c, but that later got reverted, and we forgot  
to keep this bug fix.  
  
Most of the time this'd be relatively harmless, since once we lock  
any of the partitioned table's leaf partitions, that would suffice  
to prevent major DDL on the partitioned table itself.  However, a  
childless partitioned table would get dumped with no relevant lock  
whatsoever, possibly allowing dump failure or inconsistent output.  
  
Unlike 403a3d91c, there are no versioning concerns, since every server  
version that has partitioned tables will allow you to lock one.  
  
Back-patch to v10 where partitioned tables were introduced.  
  
Discussion: https://postgr.es/m/1018205.1634346327@sss.pgh.pa.us  

commit   : c697d8a39b9001281aa62249afb01d4ab5e63703    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 15 Oct 2021 12:56:29 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 15 Oct 2021 12:56:29 -0400    

Backpatch to 14 where install_path was introduced.  

commit   : 5863115e4cb16bd905ed78a481457c5ff92ebef4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 14 Oct 2021 14:50:25 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 14 Oct 2021 14:50:25 -0700    

Recent pg_amcheck bugfix commit d2bf06db added a test case that the  
buildfarm has shown to be non-portable.  It doesn't particularly seem  
worth keeping anyway.  Remove it.  
  
Discussion: https://postgr.es/m/CAH2-Wz=7HKJ9WzAh7+M0JfwJ1yfT9qoE+KPa3P7iGToPOtGhXg@mail.gmail.com  
Backpatch: 14-, just like the original commit.  

commit   : 0b90f1c4c329f2be8ede10722a99a856020c0169    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 14 Oct 2021 12:24:22 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 14 Oct 2021 12:24:22 -0700    

An extension may want to call GetSecurityLabel() on a shared object  
before the shared relcaches are fully initialized. For instance, a  
ClientAuthentication_hook might want to retrieve the security label on  
a role.  
  
Discussion: https://postgr.es/m/ecb7af0b26e3be1d96d291c8453a86f1f82d9061.camel@j-davis.com  
Backpatch-through: 9.6  

commit   : fd059ac2e461af922c7a18a7ac1cab8ad56c6353    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Oct 2021 12:43:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Oct 2021 12:43:43 -0400    

If a function-in-FROM laterally references the output of some sub-SELECT  
earlier in the FROM clause, and we are able to flatten that sub-SELECT  
into the outer query, the expression(s) copied into the function RTE  
missed being processed by eval_const_expressions.  This'd lead to trouble  
and probable crashes at execution if such expressions contained  
named-argument function call syntax or functions with defaulted arguments.  
The bug is masked if the query contains any explicit JOIN syntax, which  
may help explain why we'd not noticed.  
  
Per bug #17227 from Bernd Dorn.  This is an oversight in commit 7266d0997,  
so back-patch to v13 where that came in.  
  
Discussion: https://postgr.es/m/17227-5a28ed1512189fa4@postgresql.org  

commit   : 79c7fe1af82d42211baf37e8dc865288b251cc6d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 Oct 2021 18:49:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 Oct 2021 18:49:27 -0300    

The test code added with ff9f111bce24 fails under valgrind, and probably  
other slow cases too, because if (say) autovacuum runs in between and  
produces WAL of its own, the large INSERT fails to account for that in  
the LSN calculations.  Rewrite to use a DO loop.  
  
Per complaint from Andres Freund  
  
Backpatch to all branches.  
  
Discussion: https://postgr.es/m/20211013180338.5guyqzpkcisqugrl@alap3.anarazel.de  

commit   : dd58194cf563c9d69821162861506d5d9acceddd    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 13 Oct 2021 14:08:11 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 13 Oct 2021 14:08:11 -0700    

Avoid calling contrib/amcheck functions with relations that are  
unsuitable for checking.  Specifically, don't attempt verification of  
temporary relations, or indexes whose pg_index entry indicates that the  
index is invalid, or not ready.  
  
These relations are not supported by any of the contrib/amcheck  
functions, for reasons that are pretty fundamental.  For example, the  
implementation of REINDEX CONCURRENTLY can add its own "transient"  
pg_index entries, which has rather unclear implications for the B-Tree  
verification functions, at least in the general case -- so they just  
treat it as an error.  It falls to the amcheck caller (in this case  
pg_amcheck) to deal with the situation at a higher level.  
  
pg_amcheck now simply treats these conditions as additional "visibility  
concerns" when it queries system catalogs.  This is a little arbitrary.  
It seems to have the least problems among any of the available  
alternatives.  
  
Author: Mark Dilger <mark.dilger@enterprisedb.com>  
Reported-By: Alexander Lakhin <exclusion@gmail.com>  
Reviewed-By: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Robert Haas <robertmhaas@gmail.com>  
Bug: #17212  
Discussion: https://postgr.es/m/17212-34dd4a1d6bba98bf@postgresql.org  
Backpatch: 14-, where pg_amcheck was introduced.  

commit   : 419d27b1a28ae0b8ebb465610bcc67f36e78adfd    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 13 Oct 2021 19:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 13 Oct 2021 19:00:01 +0900    

The comments were misplaced when adding postgres_fdw.  Fix that by  
moving the comments to more appropriate functions.  
  
Author: Etsuro Fujita  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CAPmGK164sAXQtC46mDFyu6d-T25Mzvh5qaRNkit06VMmecYnOA%40mail.gmail.com  

commit   : 922e15c47647af1b15af0a92742c8af69e83c823    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Oct 2021 16:38:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Oct 2021 16:38:15 +0900    

The code was freeing the name of the multirange type function stored in  
the parse tree but it should not do that.  Event triggers could for  
example look at such a corrupted parsed tree with a ddl_command_end  
event.  
  
Author: Alex Kozhemyakin, Sergey Shinderuk  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/d5042d46-b9cd-6efb-219a-71ed0cf45bc8@postgrespro.ru  
Backpatch-through: 14  

commit   : f4e1c8892b9e90a9d3ccae21db04a1215b9312a5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Oct 2021 09:22:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Oct 2021 09:22:00 +0900    

This fixes a set of issues that cause different breakages or annoyances  
when using pg_upgrade's test.sh to do upgrades across different major  
versions:  
- test.sh is completely broken when using v14 as new version because of  
the removal of testtablespace/ as Makefile rule.  Older versions of  
pg_regress don't support --make-tablespacedir, blocking the creation of  
the tablespace.  In order to fix that, it is simple enough to create  
those directories in the script itself, but only do that when an old  
version is involved.  This fix is needed on HEAD and REL_14_STABLE.  
- The script would fail when using PG <= v11 as old version because of  
WITH OIDS relations not supported in v12.  In order to fix this, this  
steals a method from the buildfarm that uses a DO block to change all  
the relations marked as WITH OIDS, allowing pg_upgrade to pass.  This is  
more portable than using ALTER TABLE queries on the relations causing  
issues.  This is fixed down to v12, and authored originally by Andrew  
Dunstan.  
- Not using --extra-float-digits=0 with v11 as old version causes  
a lot of diffs in the dumps, making the whole unreadable.  This gets  
only done when using v11 as old version.  This is fixed down to v12.  
The buildfarm code uses that already.  
  
Note that the addition of --wal-segsize and --allow-group-access breaks  
the script when using v10 or older at initdb time as these got added in  
11.  10 would be EOL'd next year and nobody has complained about those  
problems yet, so nothing is done about that.  This means that this  
commit fixes upgrade tests using test.sh with v11 as minimum older  
version, up to HEAD, and that it is enough to apply this change down to  
12.  The old and new dumps still generate diffs, still require manual  
checks, and more could be done to reduce the noise, but this allows the  
tests to run with a rather minimal amount of them.  
  
I have tested this commit and test.sh with v11 as minimum across all the  
branches where this is applied.  Note that this commit has no impact on  
the normal pg_upgrade test run with a simple "make check".  
  
Author:  Justin Pryzby, Andrew Dunstan, Michael Paquier  
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com  
Backpatch-through: 12  

commit   : 070c402b4a5d3cc40b3551d42763aea9afb6288d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 12 Oct 2021 10:59:22 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 12 Oct 2021 10:59:22 -0700    

Author: Pavel Luzanov <p.luzanov@postgrespro.ru>  
Discussion: https://postgr.es/m/c71a3cfc-a267-3d9f-1b44-fbd668d0ab10@postgrespro.ru  
Backpatch: 14-, where the failsafe was introduced.  

commit   : d834ebcf23208b3ae2109c0cae9af077202a27a4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Oct 2021 11:16:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Oct 2021 11:16:20 +0900    

Incrementing the level of the call stack reported is useful for  
debugging purposes as it allows to control which part of the test is  
exactly failing, especially if a test is structured with subroutines  
that call routines from Test::More.  
  
This adds more incrementations of $Test::Builder::Level where debugging  
gets improved (for example it does not make sense for some paths like  
pg_rewind where long subroutines are used).  
  
A note is added to src/test/perl/README about that, based on a  
suggestion from Andrew Dunstan and a wording coming from both of us.  
  
Usage of Test::Builder::Level has spread in 12, so a backpatch down to  
this version is done.  
  
Reviewed-by: Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson  
Discussion: https://postgr.es/m/YV1CCFwgM1RV1LeS@paquier.xyz  
Backpatch-through: 12  

commit   : 62e821ad28e1f08ea9734d7338bdebd783228a1c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 Oct 2021 09:50:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 Oct 2021 09:50:17 +0900    

Previously when pg_log_backend_memory_contexts() sent the request to  
the autovacuum launcher, it could take more than several seconds to  
log its memory contexts. Because the function (HandleAutoVacLauncherInterrupts)  
to process any new interrupts that autovacuum launcher received  
didn't handle the request for logging of memory contexts. This commit changes  
the function so that it handles the request, to make autovacuum launcher  
more responsitve to pg_log_backend_memory_contexts().  
  
Back-patch to v14 where pg_log_backend_memory_contexts() was added.  
  
Author: Koyu Tanigawa  
Reviewed-by: Bharath Rupireddy, Atsushi Torikoshi  
Discussion: https://postgr.es/m/0aae3e074face409b35153451be5cc11@oss.nttdata.com  

commit   : e7712155ea08c2f86dc32dccb5df2b230733be31    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 11 Oct 2021 17:21:46 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 11 Oct 2021 17:21:46 -0700    

Have verify_heapam.c treat unlogged relations as if they were simply  
empty when in Hot Standby mode.  This brings it in line with  
verify_nbtree.c, which has handled unlogged relations in the same way  
since bugfix commit 6754fe65a4.  This was an oversight in commit  
866e24d47d, which extended contrib/amcheck to check heap relations.  
  
In passing, lower the verbosity used when reporting that a relation has  
been skipped like this, from NOTICE to DEBUG1.  This is appropriate  
because the skipping behavior is only an implementation detail, needed  
to work around the fact that unlogged tables don't have smgr-level  
storage for their main fork when in Hot Standby mode.  
  
Affected unlogged relations should be considered "trivially verified",  
not skipped over.  They are verified in the same sense that a totally  
empty relation can be verified.  This behavior seems least surprising  
overall, since unlogged relations on a replica will initially be empty  
if and when the replica is promoted and Hot Standby ends.  
  
Author: Mark Dilger <mark.dilger@enterprisedb.com>  
Reviewed-By: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-Wzk_pukOFY7JmdiFLsrz+Pd3V8OwgC1TH2Vd5BH5ZgK4bA@mail.gmail.com  
Backpatch: 14-, where heapam verification was introduced.  

commit   : 2c25db32eedb9696c4b900c70ebef03683babf24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Oct 2021 11:56:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Oct 2021 11:56:52 -0400    

Commit 3f50b8263 had an oversight: formerly, to deparse expressions  
attached to a plan node, it was only necessary to update the  
deparse_namespace ancestors list alongside calling set_deparse_plan.  
Now it's necessary to update the ancestors list *first*, because  
set_deparse_plan consults it, and one call site got that wrong.  
  
This error was masked in most cases because explain.c uses just one  
List object for the ancestors list, updating it in-place as the plan  
is scanned, so that we accidentally had the right List assigned to  
dpns->ancestors before it was needed.  It would fail only if a  
WorkTableScan node were the first one that we tried to deparse a  
subexpression of.  
  
Per report from Markus Winand.  Like the previous patch,  
back-patch to v14.  
  
Discussion: https://postgr.es/m/648B0505-AA57-42C2-A2DA-E551DE46FA15@winand.at  

commit   : 2051fd30a4fa3b62cdb244f5b9748c1cb3b39845    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 7 Oct 2021 18:15:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 7 Oct 2021 18:15:01 +0900    

Commit 27e1f1456 missed updating some comments.  
  
Reviewed-by: Bharath Rupireddy  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAPmGK15Q2Nm6U%2Ba_GwskrWFEVBZ9_3VKOvRrprGufpx91M_3Sw%40mail.gmail.com  

commit   : ef2e107f548cfbd22060e92c0f435616cac2f57c    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 7 Oct 2021 17:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 7 Oct 2021 17:45:01 +0900    

Author: Amit Langote  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CA%2BHiwqGQNbtamQ_9DU3osR1XiWR4wxWFZurPmN6zgbdSZDeWmw%40mail.gmail.com  

commit   : 12ff678e1d657fc94a1cfa90f1b85dd9bd79e1e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Oct 2021 15:50:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Oct 2021 15:50:24 -0400    

Commit c7b7311f6 adjusted conversion_error_callback to always use  
information from the query's rangetable, to avoid doing catalog lookups  
in an already-failed transaction.  However, as a result of the utterly  
inadequate documentation for make_tuple_from_result_row, I failed to  
realize that fsstate could be NULL in some contexts.  That led to a  
crash if we got a conversion error in such a context.  Fix by falling  
back to the previous coding when fsstate is NULL.  Improve the  
commentary, too.  
  
Per report from Andrey Borodin.  Back-patch to 9.6, like the previous  
patch.  
  
Discussion: https://postgr.es/m/08916396-55E4-4D68-AB3A-BD6066F9E5C0@yandex-team.ru  

commit   : 8e26b868d5cfe9c746578aa3b172b6f24a5a310c    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 6 Oct 2021 13:19:25 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 6 Oct 2021 13:19:25 +0100    

This fixes a loss of precision that occurs when the first input is  
very close to 1, so that its logarithm is very small.  
  
Formerly, during the initial low-precision calculation to estimate the  
result weight, the logarithm was computed to a local rscale that was  
capped to NUMERIC_MAX_DISPLAY_SCALE (1000). However, the base may be  
as close as 1e-16383 to 1, hence its logarithm may be as small as  
1e-16383, and so the local rscale needs to be allowed to exceed 16383,  
otherwise all precision is lost, leading to a poor choice of rscale  
for the full-precision calculation.  
  
Fix this by removing the cap on the local rscale during the initial  
low-precision calculation, as we already do in the full-precision  
calculation. This doesn't change the fact that the initial calculation  
is a low-precision approximation, computing the logarithm to around 8  
significant digits, which is very fast, especially when the base is  
very close to 1.  
  
Patch by me, reviewed by Alvaro Herrera.  
  
Discussion: https://postgr.es/m/CAEZATCV-Ceu%2BHpRMf416yUe4KKFv%3DtdgXQAe5-7S9tD%3D5E-T1g%40mail.gmail.com  

commit   : ae254356f94af220841f3c59dcd4d820449ca0fc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 Oct 2021 13:28:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 Oct 2021 13:28:30 +0900    

Oversight in a3fcbcd.  
  
Reported-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGKnajZEwe91OTjro9kQLCMGGFHh2vvFn8tgHgbyn4bF9w@mail.gmail.com  
Backpatch-through: 13  

commit   : cb8a5a588eb7325d17780a7a8871ae3b49adc497    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Oct 2021 10:24:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Oct 2021 10:24:14 -0400    

queries.sgml failed to mention the rather important point that  
INTERSECT binds more tightly than UNION or EXCEPT.  I thought  
it could also use more discussion of the role of parentheses  
in these constructs.  
  
Per gripe from Christopher Painter-Wakefield.  
  
Discussion: https://postgr.es/m/163338891727.12510.3939775743980651160@wrigleys.postgresql.org  

commit   : 1f00a2902bf422cb15fc66145f1e349fdb97689b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 Oct 2021 17:10:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 Oct 2021 17:10:59 -0400    

The old URL was HTTP 404 and the git link didn't build.  Also update two  
other ICU links.  If we ever get a good link we will add it back.  
  
Reported-by: Anton Voloshin  
  
Author: Laurenz Albe  
  
Backpatch-through: 10  

commit   : c4465cd09e3ab034ced25e623d5760e9ce437f6c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 4 Oct 2021 13:28:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 4 Oct 2021 13:28:06 -0700    

3c5b0685b921 used setFilePointer() to set the position of the filehandle, but  
passed the wrong filehandle, always leaving the position at 0. Instead of just  
fixing that, remove use of setFilePointer(), we have a perl fd at this point,  
so we can just use perl's seek().  
  
Additionally, the perl filehandle wasn't closed, just the windows filehandle.  
  
Reviewed-By: Andrew Dunstan <andrew@dunslane.net>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20211003173038.64mmhgxctfqn7wl6@alap3.anarazel.de  
Backpatch: 9.6-, like 3c5b0685b921  

commit   : 919c08d909f766bb51c5c617714364a91bb90d9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Oct 2021 14:52:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Oct 2021 14:52:17 -0400    

Per discussion, let's just follow CLDR's default zone mappings  
faithfully.  There are two changes here that are clear improvements:  
  
* Mapping "Greenwich Standard Time" to Atlantic/Reykjavik is actually  
a better fit than using London, because Iceland hasn't observed DST  
since 1968, so this is more nearly what people might expect.  
  
* Since the "Samoa" zone is specified to be UTC+13:00, we must map  
it to Pacific/Apia not Pacific/Samoa; the latter refers to American  
Samoa which is now on the other side of the date line.  
  
The rest of these changes look like they're choosing the most populous  
IANA zone as representative.  Whatever the details, we're just going  
to say "if you don't like this mapping, complain to CLDR".  
  
Discussion: https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us  

commit   : 5f46180070d108f2f2aec6a9d3d488d3ef55b42e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Oct 2021 13:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Oct 2021 13:34:31 -0400    

gist.sgml and xindex.sgml hadn't been fully updated for the  
addition of a sortsupport support function (commit 16fa9b2b3).  
xindex.sgml also missed that the compress and decompress support  
functions are optional, an apparently far older oversight.  
  
In passing, fix gratuitous inconsistencies in wording and  
capitalization.  
  
Noted by E. Rogov.  Back-patch to v14; the residual issues  
before that aren't significant enough to bother with.  
  
Discussion: https://postgr.es/m/163335322905.12519.5711557029494638051@wrigleys.postgresql.org  

commit   : 828f7f0009edda3f78dd789102cd02a394f94938    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Oct 2021 14:05:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Oct 2021 14:05:48 +0900    

Some specific logic is done at the end of recovery when involving 2PC  
transactions:  
1) Call RecoverPreparedTransactions(), to recover the state of 2PC  
transactions into memory (re-acquire locks, etc.).  
2) ShutdownRecoveryTransactionEnvironment(), to move back to normal  
operations, mainly cleaning up recovery locks and KnownAssignedXids  
(including any 2PC transaction tracked previously).  
3) Switch XLogCtl->SharedRecoveryState to RECOVERY_STATE_DONE, which is  
the tipping point for any process calling RecoveryInProgress() to check  
if the cluster is still in recovery or not.  
  
Any snapshot taken between steps 2) and 3) would be empty, causing any  
transaction relying on a snapshot at this point to potentially corrupt  
data as there could still be some 2PC transactions to track, with  
RecentXmin moving backwards on successive calls to GetSnapshotData() in  
the same transaction.  
  
As SharedRecoveryState is the point to take into account to know if it  
is safe to discard KnownAssignedXids, this commit moves step 2) after  
step 3), so as we can never finish with empty snapshots.  
  
This exists since the introduction of hot standby, so backpatch all the  
way down.  The window with incorrect snapshots is extremely small, but I  
have seen it when running 023_pitr_prepared_xact.pl, as did buildfarm  
member fairywren.  Thomas Munro also found it independently.  Special  
thanks to Andres Freund for taking the time to analyze this issue.  
  
Reported-by: Thomas Munro, Michael Paquier  
Analyzed-by: Andres Freund  
Discussion: https://postgr.es/m/20210422203603.fdnh3fu2mmfp2iov@alap3.anarazel.de  
Backpatch-through: 9.6  

commit   : e0eba586b1b8448639ab4170fe39270d73dc2e2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Oct 2021 13:21:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Oct 2021 13:21:20 -0400    

Prior to v14, we insisted that the query in RETURN QUERY be of a type  
that returns tuples.  (For instance, INSERT RETURNING was allowed,  
but not plain INSERT.)  That happened indirectly because we opened a  
cursor for the query, so spi.c checked SPI_is_cursor_plan().  As a  
consequence, the error message wasn't terribly on-point, but at least  
it was there.  
  
Commit 2f48ede08 lost this detail.  Instead, plain RETURN QUERY  
insisted that the query be a SELECT (by checking for SPI_OK_SELECT)  
while RETURN QUERY EXECUTE failed to check the query type at all.  
Neither of these changes was intended.  
  
The only convenient place to check this in the EXECUTE case is inside  
_SPI_execute_plan, because we haven't done parse analysis until then.  
So we need to pass down a flag saying whether to enforce that the  
query returns tuples.  Fortunately, we can squeeze another boolean  
into struct SPIExecuteOptions without an ABI break, since there's  
padding space there.  (It's unlikely that any extensions would  
already be using this new struct, but preserving ABI in v14 seems  
like a smart idea anyway.)  
  
Within spi.c, it seemed like _SPI_execute_plan's parameter list  
was already ridiculously long, and I didn't want to make it longer.  
So I thought of passing SPIExecuteOptions down as-is, allowing that  
parameter list to become much shorter.  This makes the patch a bit  
more invasive than it might otherwise be, but it's all internal to  
spi.c, so that seems fine.  
  
Per report from Marc Bachmann.  Back-patch to v14 where the  
faulty code came in.  
  
Discussion: https://postgr.es/m/1F2F75F0-27DF-406F-848D-8B50C7EEF06A@gmail.com  

commit   : fa8db48791c58444ab35d6f2419074a717fbb9b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:42 -0400    

This corrects a bunch of entries in win32_tzmap[], and adds a few  
new ones, based on the CLDR project's windowsZones.xml file.  
Non-cosmetic changes fall into four main categories:  
  
* Flat-out errors:  
  
US/Aleutan doesn't exist  
America/Salvador doesn't exist  
Asia/Baku is wrong for Yerevan  
Asia/Dhaka (Bangladesh) is wrong for Astana (Kazakhstan)  
Europe/Bucharest is wrong for Chisinau  
America/Mexico_City is wrong for Chetumal  
America/Buenos_Aires is wrong for Cayenne  
America/Caracas has its own zone, so poor fit for La Paz  
US/Eastern is wrong for Haiti  
US/Eastern is wrong for Indiana (East)  
Asia/Karachi is wrong for Tashkent  
Etc/UTC+12 doesn't exist  
Signs of Etc/GMT zones were backwards  
  
* Judgment calls:  
  
(These changes follow CLDR's choices, except for the first one)  
  
Use Europe/London for "Greenwich Standard Time", since that seems much  
more likely than Africa/Casablanca to be what people will think that  
zone name means.  CLDR has Atlantic/Reykjavik here, but that's no better.  
  
Asia/Shanghai seems a better fit than Hong Kong for "China Standard  
Time".  
  
Europe/Sarajevo is now a link to Belgrade, ie "Central Europe Standard  
Time"; so use Warsaw for "Central European Standard Time".  
  
America/Sao_Paulo seems more representative than Araguaina for  
"E. South America Standard Time".  
  
Africa/Johannesburg seems more representative than Harare for  
"South Africa Standard Time".  
  
* New Windows zone names:  
  
"Israel Standard Time"  
"Kaliningrad Standard Time"  
"Russia Time Zone N" for various N  
"Singapore Standard Time"  
"South Sudan Standard Time"  
"W. Central Africa Standard Time"  
"West Bank Standard Time"  
"Yukon Standard Time"  
  
Some of these replace older spellings, but I kept the older spellings  
too in case our code runs on a machine with the older data.  
  
* Replace aliases (tzdb Links) with underlying city-named zones:  
  
(This tracks tzdb's longstanding practice, and reduces inconsistency  
with the rest of the entries, as well as with CLDR.)  
  
US/Alaska  
Asia/Kuwait  
Asia/Muscat  
Canada/Atlantic  
Australia/Canberra  
Canada/Saskatchewan  
US/Central  
US/Eastern  
US/Hawaii  
US/Mountain  
Canada/Newfoundland  
US/Pacific  
  
Back-patch to all supported branches, as is our usual practice for  
time zone data updates.  
  
Discussion: https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us  

commit   : 81464999bc92ebf9b813e1c7bd8b333e29511fb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Oct 2021 16:05:10 -0400    

The original intent seems to have been to sort case-insensitively  
by the Windows zone name, but various changes over the years did  
not get that memo.  This commit just moves a few entries to  
restore exact alphabetic order, to ease comparison to the outputs  
of processing scripts.  
  
Back-patch to all supported branches, as is our usual practice for  
time zone data updates.  
  
Discussion: https://postgr.es/m/3266414.1633045628@sss.pgh.pa.us  

commit   : 0baa33da0fd123aff215c505116dc60bc04dae90    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 29 Sep 2021 18:02:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 29 Sep 2021 18:02:32 -0700    

The previous approach didn't really work on windows, due to the PATH separator  
being ';' not ':'. Instead of making the PATH change more complicated,  
reference the binary using the TESTDIR environment.  
  
Reported-By: Andres Freund <andres@anarazel.de>  
Suggested-By: Andrew Dunstan <andrew@dunslane.net>  
Discussion: https://postgr.es/m/20210930214040.odkdd42vknvzifm6@alap3.anarazel.de  
Backpatch: 14-, where the test was introduced.  

commit   : 20047609d39cc4d30d6b266ed3a8b418b3ce5f78    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Oct 2021 18:29:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Oct 2021 18:29:18 -0300    

Both bugs #16676[1] and #17141[2] illustrate that the combination of  
SKIP LOCKED and FETCH FIRST WITH TIES break expectations when it comes  
to rows returned to other sessions accessing the same row.  Since this  
situation is detectable from the syntax and hard to fix otherwise,  
forbid for now, with the potential to fix in the future.  
  
[1] https://postgr.es/m/16676-fd62c3c835880da6@postgresql.org  
[2] https://postgr.es/m/17141-913d78b9675aac8e@postgresql.org  
  
Backpatch-through: 13, where WITH TIES was introduced  
Author: David Christensen <david.christensen@crunchydata.com>  
Discussion: https://postgr.es/m/CAOxo6XLPccCKru3xPMaYDpa+AXyPeWFs+SskrrL+HKwDjJnLhg@mail.gmail.com  

commit   : 0ce67bce00717d8934b599ab4409e28b33c612ea    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Oct 2021 18:03:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Oct 2021 18:03:11 -0300    

Commit ff9f111bce24 added some test code that's unportable and doesn't  
add meaningful coverage.  Remove it rather than try and get it to work  
everywhere.  
  
While at it, fix a typo in a log message added by the aforementioned  
commit.  
  
Backpatch to 14.  
  
Discussion: https://postgr.es/m/3000074.1632947632@sss.pgh.pa.us  

commit   : a5e83ad79c282421f32224c5152d6182de34da35    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 1 Oct 2021 22:47:05 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 1 Oct 2021 22:47:05 +0200    

The intermittent h buffer was not freed, causing it to leak. Backpatch  
through 14 where HMAC was refactored to the current API.  
  
Author: Sergey Shinderuk <s.shinderuk@postgrespro.ru>  
Discussion: https://postgr.es/m/af07e620-7e28-a742-4637-2bc44aa7c2be@postgrespro.ru  
Backpatch-through: 14  

commit   : a54509bfd952085a24224480ff74d5cbd558c407    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 14:59:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 14:59:35 -0400    

get_variable_range() would incautiously believe that statistics  
containing only an MCV list are sufficient to derive a range estimate.  
That's okay for an enum-like column that contains only MCVs, but  
otherwise the estimate could be pretty bad.  Make it report that the  
range is indeterminate unless the MCVs plus nullfrac account for  
the whole table.  
  
I don't think this needs a dedicated test case, since a quick code  
coverage check verifies that the existing regression tests traverse  
all the alternatives.  There is room to doubt that a future-proof  
test case could be built anyway, given that the submitted example  
accidentally doesn't fail before v11.  
  
Per bug #17207 from Simon Perepelitsa.  Back-patch to v10.  
In principle this has been broken all along, but I'm hesitant to  
make such changes in 9.6, since if anyone is unhappy with 9.6.24's  
behavior there will be no second chance to fix it.  
  
Discussion: https://postgr.es/m/17207-5265aefa79e333b4@postgresql.org  

commit   : e6adaa1795d593edd616b9541fff0920637f9721    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 11:10:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Oct 2021 11:10:12 -0400    

Commit 84f5c2908 forgot to consider the possibility that  
EnsurePortalSnapshotExists could run inside a subtransaction with  
lifespan shorter than the Portal's.  In that case, the new active  
snapshot would be popped at the end of the subtransaction, leaving  
a dangling pointer in the Portal, with mayhem ensuing.  
  
To fix, make sure the ActiveSnapshot stack entry is marked with  
the same subtransaction nesting level as the associated Portal.  
It's certainly safe to do so since we won't be here at all unless  
the stack is empty; hence we can't create an out-of-order stack.  
  
Let's also apply this logic in the case where PortalRunUtility  
sets portalSnapshot, just to be sure that path can't cause similar  
problems.  It's slightly less clear that that path can't create  
an out-of-order stack, so add an assertion guarding it.  
  
Report and patch by Bertrand Drouvot (with kibitzing by me).  
Back-patch to v11, like the previous commit.  
  
Discussion: https://postgr.es/m/ff82b8c5-77f4-3fe7-6028-fcf3303e82dd@amazon.com  

commit   : 8de4a31720c2c2ce55f73f4af4b3cdc6cdcca225    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Oct 2021 08:31:41 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 1 Oct 2021 08:31:41 +0530    

Commit 9868167500 added pg_stat_replication_slots view to monitor  
ReorderBuffer stats but mistakenly added it under  
"Dynamic Statistics Views" section in the docs whereas it belongs to  
"Collected Statistics Views" section.  
  
Author: Amit Kapila  
Reviewed-by: Masahiko Sawada  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/CAA4eK1Kb5ur=OC-G4cAsqPOjoVe+S8LNw1WmUY8Owasjk8o5WQ@mail.gmail.com  

commit   : afc6081f6ea8fa053dafe14e609d1d8e885410f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Sep 2021 16:23:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Sep 2021 16:23:10 -0400    

Computing related timestamps by subtracting "N days" is sensitive  
to the prevailing timezone, since we interpret that as "same local  
time on the N'th prior day".  Even though the intervals in question  
are only two to four days, through remarkable bad luck they managed  
to cross the end of Ramadan in 2014, causing the test's output to  
change if timezone is set to Africa/Casablanca.  (Maybe in other  
Muslim areas as well; I didn't check.)  There's absolutely no reason  
for this test to exercise interval subtraction, so just get rid of  
that and use plain timestamptz constants representing the intended  
values.  
  
Per report from Andres Freund.  Back-patch to v10 where this test  
script came in.  
  
Discussion: https://postgr.es/m/20210930183641.7lh4jhvpipvromca@alap3.anarazel.de  

commit   : e3731bac52cf049bed965aa4f96cb073ed044b68    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Sep 2021 10:01:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Sep 2021 10:01:03 -0300    

First, as pointed out by Tom Lane and Michael Paquier, I failed to  
realize that Windows' PostgresNode needs an extra pg_hba.conf line  
(added by PostgresNode->set_replication_conf, called internally by  
->init() when 'allows_streaming=>1' is given -- but I purposefully  
omitted that).  I think a good fix should be to have nodes with only  
'has_archiving=>1' set up for replication too, but that's a bigger  
discussion.  Fix it by calling ->set_replication_conf, which is not  
unprecedented, as pointed out by Andrew Dunstan.  
  
I also forgot to uncomment a ->finish() call for a pumpable IPC::Run  
file descriptor.  Apparently this is innocuous in almost all platforms.  
  
Backpatch to 14.  The older branches were added this file too, but not  
this particular part of the test.  
  
Discussion: https://postgr.es/m/3000074.1632947632@sss.pgh.pa.us  
Discussion: https://postgr.es/m/YVT7qwhR8JmC2kfz@paquier.xyz  

commit   : 64a8687a68914aa3f5a0867885777a1294eceb1c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Sep 2021 11:21:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Sep 2021 11:21:51 -0300    

Physical replication always ships WAL segment files to replicas once  
they are complete.  This is a problem if one WAL record is split across  
a segment boundary and the primary server crashes before writing down  
the segment with the next portion of the WAL record: WAL writing after  
crash recovery would happily resume at the point where the broken record  
started, overwriting that record ... but any standby or backup may have  
already received a copy of that segment, and they are not rewinding.  
This causes standbys to stop following the primary after the latter  
crashes:  
  LOG:  invalid contrecord length 7262 at A8/D9FFFBC8  
because the standby is still trying to read the continuation record  
(contrecord) for the original long WAL record, but it is not there and  
it will never be.  A workaround is to stop the replica, delete the WAL  
file, and restart it -- at which point a fresh copy is brought over from  
the primary.  But that's pretty labor intensive, and I bet many users  
would just give up and re-clone the standby instead.  
  
A fix for this problem was already attempted in commit 515e3d84a0b5, but  
it only addressed the case for the scenario of WAL archiving, so  
streaming replication would still be a problem (as well as other things  
such as taking a filesystem-level backup while the server is down after  
having crashed), and it had performance scalability problems too; so it  
had to be reverted.  
  
This commit fixes the problem using an approach suggested by Andres  
Freund, whereby the initial portion(s) of the split-up WAL record are  
kept, and a special type of WAL record is written where the contrecord  
was lost, so that WAL replay in the replica knows to skip the broken  
parts.  With this approach, we can continue to stream/archive segment  
files as soon as they are complete, and replay of the broken records  
will proceed across the crash point without a hitch.  
  
Because a new type of WAL record is added, users should be careful to  
upgrade standbys first, primaries later. Otherwise they risk the standby  
being unable to start if the primary happens to write such a record.  
  
A new TAP test that exercises this is added, but the portability of it  
is yet to be seen.  
  
This has been wrong since the introduction of physical replication, so  
backpatch all the way back.  In stable branches, keep the new  
XLogReaderState members at the end of the struct, to avoid an ABI  
break.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Nathan Bossart <bossartn@amazon.com>  
Discussion: https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql  

commit   : 4f2c75316b2b767a838aa9fefb6e4944ace34f23    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 29 Sep 2021 10:27:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 29 Sep 2021 10:27:53 -0400    

Reported-by: Simon Riggs (privately)  
  
Backpatch-through: 14 only  

commit   : 8231c500ed742431263052cd48fbb859d7f7d7ea    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 21:01:10 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 21:01:10 +0900    

Previously socket errors such as invalid socket or socket wait method failures  
during benchmark caused pgbench to exit with status 0. Instead, errors during  
the run should result in exit status 2.  
  
Back-patch to v12 where pgbench started reporting exit status.  
  
Original complaint and patch by Hayato Kuroda.  
  
Author: Yugo Nagata, Fabien COELHO  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com  

commit   : 8021334d3710cb030ed1b6de764a0bb2233e5265    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 20:35:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 29 Sep 2021 20:35:00 +0900    

The failure of socket wait method like "select()" doesn't terminate pgbench.  
So the log level of error message when that failure happens should be ERROR.  
But previously FATAL was used in that case.  
  
Back-patch to v13 where pgbench started using common logging API.  
  
Author: Yugo Nagata, Fabien COELHO  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/20210617005934.8bd37bf72efd5f1b38e6f482@sraoss.co.jp  

commit   : 2cf9cf5d7b5e66202389618a4c08945da352b35c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Sep 2021 15:29:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Sep 2021 15:29:45 +0900    

The code inconsistently used "statistic object" or "statistics" where  
the correct term, as discussed, is actually "statistics object".  This  
improves the state of the code to be more consistent.  
  
While on it, fix an incorrect error message introduced in a4d75c8.  This  
error should never happen, as the code states, but it would be  
misleading.  
  
Author: Justin Pryzby  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/20210924215827.GS831@telsasoft.com  
Backpatch-through: 14  

commit   : 2a27dbaeb9088718baa25bc97f2e049e063412db    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Sep 2021 11:56:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Sep 2021 11:56:36 +0900    

Author: Ekaterina Kiryanova  
Discussion: https://postgr.es/m/8a14e78f-6991-7a6e-4711-fe376635f2ad@postgrespro.ru  
Backpatch-through: 14  

commit   : cea5624f6a23a100fb93aee8b40bdc3a8cb52081    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Sep 2021 17:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Sep 2021 17:34:31 -0400    

It turns out that the instability complained of in commit d3c09b9b1  
has an embarrassingly simple explanation.  The test script waits for  
the standby to flush incoming WAL to disk, but it should wait for  
the WAL to be replayed, since we are testing for the effects of that  
to be visible.  
  
While at it, use wait_for_catchup instead of reinventing that logic,  
and adjust $Test::Builder::Level to improve future error reports.  
  
Back-patch to v12 where the necessary infrastructure came in  
(cf. aforesaid commit).  Also back-patch 7d1aa6bf1 so that the  
test will actually get run.  
  
Discussion: https://postgr.es/m/2854602.1632852664@sss.pgh.pa.us  

commit   : 2f283d036da8e4c74fd07022cb685efee4e345bd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Sep 2021 14:15:39 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Sep 2021 14:15:39 -0400    

Backpatch-through: 14 only  

commit   : febbb2f52c99b16261387daba4931d621dfbef0f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 28 Sep 2021 16:23:18 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 28 Sep 2021 16:23:18 +0200    

Author: Tatsuro Yamada  
Backpatch-through: 14  
Discussion: https://www.postgresql.org/message-id/7ad8cd13-db5b-5cf6-8561-dccad1a934cb@nttcom.co.jp  

commit   : 86a4dc1e6f29d1992a2afa3fac1a0b0a6e84568c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Sep 2021 16:57:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Sep 2021 16:57:41 -0400    

commit   : 9f535e4aeafc4e427355760178ecc89055f96942    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 Sep 2021 09:22:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 Sep 2021 09:22:27 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 941ca560d0b36a8bace8432b06302ca003829f42  

commit   : 3cc51338438acb38ea14cebe6fd979f00ad5bebf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 Sep 2021 08:59:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 Sep 2021 08:59:03 +0200    

current through e8b39cebdaf042dfeeb31d2f48f0fe7b33886210  

commit   : e8b39cebdaf042dfeeb31d2f48f0fe7b33886210    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Sep 2021 19:18:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 26 Sep 2021 19:18:23 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20210924215827.GS831@telsasoft.com  
Backpatch-through: 9.6  

commit   : 765f677f364100072160e7af37288eb1df2ff355    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Sep 2021 11:36:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Sep 2021 11:36:43 -0400    

Add the customary short list of major features.  Set release date.  
  
Discussion: https://postgr.es/m/1489855.1631986639@sss.pgh.pa.us  

commit   : 02c4e3533926f4e7398611b6349d7c438b86c63b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Sep 2021 10:53:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Sep 2021 10:53:54 -0400    

Be a little more vocal about the risks of remote collations not  
matching local ones.  Actually fixing these risks seems hard,  
and I've given up on the idea that it might be back-patchable.  
So the best we can do for the back branches is add documentation.  
  
Per discussion of bug #16583 from Jiří Fejfar.  
  
Discussion: https://postgr.es/m/2438715.1632510693@sss.pgh.pa.us  

commit   : 6d0001aabf2a49180a236d9c2a7ecdf24e0cdb37    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:28 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:28 +0200    

OpenSSL 3 introduced the concept of providers to support modularization,  
and moved the outdated ciphers to the new legacy provider. In case it's  
not loaded in the users openssl.cnf file there will be a lot of regress  
test failures, so add alternative outputs covering those.  
  
Also document the need to load the legacy provider in order to use older  
ciphers with OpenSSL-enabled pgcrypto.  
  
This will be backpatched to all supported version once there is sufficient  
testing in the buildfarm of OpenSSL 3.  
  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se  

commit   : 4fa2b15e1c9cae79afe17c14591074111b0d4093    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:20 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Sat, 25 Sep 2021 11:27:20 +0200    

The PX layer in pgcrypto is handling digest padding on its own uniformly  
for all backend implementations. Starting with OpenSSL 3.0.0, DecryptUpdate  
doesn't flush the last block in case padding is enabled so explicitly  
disable it as we don't use it.  
  
This will be backpatched to all supported version once there is sufficient  
testing in the buildfarm of OpenSSL 3.  
  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se  

commit   : bfe1ead94488986008771c0d295c2725bab952cb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 15:11:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 15:11:52 +0900    

Index vacuums may happen multiple times depending on the number of dead  
tuples stored, as of maintenance_work_mem for a manual VACUUM.  For  
autovacuum, this is controlled by autovacuum_work_mem instead, if set.  
The documentation mentioned the former, but not the latter in the  
context of autovacuum.  
  
Reported-by: Nikolai Berkoff  
Author: Laurenz Albe, Euler Taveira  
Discussion: https://postgr.es/m/161545365522.10134.12195402324485546870@wrigleys.postgresql.org  
Backpatch-through: 9.6  

commit   : 3eea9139ee46124746e942293d57e3fb1d3c0e09    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 14:48:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 25 Sep 2021 14:48:09 +0900    

Reported-by: rir  
Discussion: https://postgr.es/m/20210924183658.3syyitp3yuxjv2fp@localhost  
Backpatch-through: 9.6  

commit   : e536a2683439c3dd4ea6d339a878fa4430e3174d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 23 Sep 2021 22:49:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 23 Sep 2021 22:49:20 +0200    

One of these was accidentally removed by c50624c.  The others are  
added by analogy.  
  
Discussion: https://www.postgresql.org/message-id/ae1143fb-455c-c80f-ed66-78d45bd93303@enterprisedb.com  

commit   : 7186f07189baf069c54718315b81e65d87f4c0c1    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 23 Sep 2021 19:59:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 23 Sep 2021 19:59:03 +0300    

That allows to include just visibilitymapdefs.h from file.c, and in turn,  
remove include of postgres.h from relcache.h.  
  
Reported-by: Andres Freund  
Discussion: https://postgr.es/m/20210913232614.czafiubr435l6egi%40alap3.anarazel.de  
Author: Alexander Korotkov  
Reviewed-by: Andres Freund, Tom Lane, Alvaro Herrera  
Backpatch-through: 13  

commit   : abb2f9144ba1b7ac806f3779f53ae2f6174cd2d9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:13:11 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:13:11 +0200    

Calculating degree of a functional dependency may allocate a lot of  
memory - we have released mot of the explicitly allocated memory, but  
e.g. detoasted varlena values were left behind. That may be an issue,  
because we consider a lot of dependencies (all combinations), and the  
detoasting may happen for each one again.  
  
Fixed by calling dependency_degree() in a dedicated context, and  
resetting it after each call. We only need the calculated dependency  
degree, so we don't need to copy anything.  
  
Backpatch to PostgreSQL 10, where extended statistics were introduced.  
  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/20210915200928.GP831%40telsasoft.com  

commit   : bb7628e55eda6f450f0f824d11c9a34b11f6bb12    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:14:11 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 21 Sep 2021 01:14:11 +0200    

Until now, all extended statistics on a given relation were built in the  
same memory context, without resetting. Some of the memory was released  
explicitly, but not all of it - for example memory allocated while  
detoasting values is hard to free. This is how it worked since extended  
statistics were introduced in PostgreSQL 10, but adding support for  
extended stats on expressions made the issue somewhat worse as it  
increases the number of statistics to build.  
  
Fixed by adding a memory context which gets reset after building each  
statistics object (all the statistics kinds included in it). Resetting  
it after building each statistics kind would be even better, but it  
would require more invasive changes and copying of results, making it  
harder to backpatch.  
  
Backpatch to PostgreSQL 10, where extended statistics were introduced.  
  
Author: Justin Pryzby  
Reported-by: Justin Pryzby  
Reviewed-by: Tomas Vondra  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/20210915200928.GP831%40telsasoft.com  

commit   : 9eff8593265929d3a1fcdee375bd0a801c12b367    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 22 Sep 2021 08:13:37 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 22 Sep 2021 08:13:37 +0530    

Updates/Deletes on a partition were allowed even without replica identity  
after the parent table was added to a publication. This would later lead  
to an error on subscribers. The reason was that we were not invalidating  
the partition's relcache and the publication information for partitions  
was not getting rebuilt. Similarly, we were not invalidating the  
partitions' relcache after dropping a partitioned table from a publication  
which will prohibit Updates/Deletes on its partition without replica  
identity even without any publication.  
  
Reported-by: Haiying Tang  
Author: Hou Zhijie and Vignesh C  
Reviewed-by: Vignesh C and Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/OS0PR01MB6113D77F583C922F1CEAA1C3FBD29@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : e665129c4727004e7a7c12c86d077abc750b3307    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 21 Sep 2021 18:57:31 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 21 Sep 2021 18:57:31 -0700    

It is not appropriate for deduplication to apply single value strategy  
when triggered by a bottom-up index deletion pass.  This wastes cycles  
because later bottom-up deletion passes will overinterpret older  
duplicate tuples that deduplication actually just skipped over "by  
design".  It also makes bottom-up deletion much less effective for low  
cardinality indexes that happen to cross a meaningless "index has single  
key value per leaf page" threshold.  
  
To fix, slightly narrow the conditions under which deduplication's  
single value strategy is considered.  We already avoided the strategy  
for a unique index, since our high level goal must just be to buy time  
for VACUUM to run (not to buy space).  We'll now also avoid it when we  
just had a bottom-up pass that reported failure.  The two cases share  
the same high level goal, and already overlapped significantly, so this  
approach is quite natural.  
  
Oversight in commit d168b666, which added bottom-up index deletion.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-WznaOvM+Gyj-JQ0X=JxoMDxctDTYjiEuETdAGbF5EUc3MA@mail.gmail.com  
Backpatch: 14-, where bottom-up deletion was introduced.  

commit   : 90251ff199858844fa450ba9614092c06c67fc4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Sep 2021 08:43:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Sep 2021 08:43:00 +0900    

Contrary to the output of native perl, Msys perl generates outputs with  
CRLFs characters.  There are already places in the TAP code where CRLFs  
(\r\n) are automatically converted to LF (\n) on Msys, but we missed a  
couple of places when running commands and using their output for  
comparison, that would lead to failures.  
  
This problem has been found thanks to the test added in 5adb067 using  
TestLib::command_checks_all(), but after a closer look more code paths  
were missing a filter.  
  
This is backpatched all the way down to prevent any surprises if a new  
test is introduced in stable branches.  
  
Reviewed-by: Andrew Dunstan, Álvaro Herrera  
Discussion: https://postgr.es/m/1252480.1631829409@sss.pgh.pa.us  
Backpatch-through: 9.6  

commit   : 2ad5f963e1306aa6f4cf96076a230e96529d2237    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Sep 2021 19:06:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Sep 2021 19:06:33 -0400    

Before commit 84f5c2908, a STABLE function in a plpgsql CALL  
statement's argument list would see an up-to-date snapshot,  
because exec_stmt_call would push a new snapshot.  I got rid of  
that because the possibility of the snapshot disappearing within  
COMMIT made it too hard to manage a snapshot across the CALL  
statement.  That's fine so far as the procedure itself goes,  
but I forgot to think about the possibility of STABLE functions  
within the CALL argument list.  As things now stand, those'll  
be executed with the Portal's snapshot as ActiveSnapshot,  
keeping them from seeing updates more recent than Portal startup.  
  
(VOLATILE functions don't have a problem because they take their  
own snapshots; which indeed is also why the procedure itself  
doesn't have a problem.  There are no STABLE procedures.)  
  
We can fix this by pushing a new snapshot transiently within  
ExecuteCallStmt itself.  Popping the snapshot before we get  
into the procedure proper eliminates the management problem.  
The possibly-useless extra snapshot-grab is slightly annoying,  
but it's no worse than what happened before 84f5c2908.  
  
Per bug #17199 from Alexander Nawratil.  Back-patch to v11,  
like the previous patch.  
  
Discussion: https://postgr.es/m/17199-1ab2561f0d94af92@postgresql.org  

commit   : c1d1ae1db23796e4d1b04f5c087944722cf1446a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Sep 2021 19:47:53 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Sep 2021 19:47:53 -0300    

I noticed that commit 0bead9af484c left this flag undocumented in  
XLogSetRecordFlags, which led me to discover that the flag doesn't  
actually do what the one comment on it said it does.  Improve the  
situation by adding some more comments.  
  
Backpatch to 14, where the aforementioned commit appears.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202109212119.c3nhfp64t2ql@alvherre.pgsql  

commit   : 8aed7f7a2ec46ad60c84c3c97300210850c3fbc8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Sep 2021 17:33:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Sep 2021 17:33:01 -0400    

commit   : 955a6a893498a5d3af544d9c0b1c292b19ec1690    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 20 Sep 2021 14:26:24 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 20 Sep 2021 14:26:24 -0700    

A broken HOT chain is not an unexpected condition, even when the offset  
number points past the end of the page's line pointer array.  
heap_prune_chain() does not (and never has) treated this condition as  
unexpected, so derivative code in heap_index_delete_tuples() shouldn't  
do so either.  
  
Oversight in commit 4228817449.  
  
The assertion can probably only fail on Postgres 14 and master.  Earlier  
releases don't have commit 3c3b8a4b, which taught VACUUM to truncate the  
line pointer array of heap pages.  Backpatch all the same, just to be  
consistent.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Alexander Lakhin <exclusion@gmail.com>  
Discussion: https://postgr.es/m/17197-9438f31f46705182@postgresql.org  
Backpatch: 12-, just like commit 4228817449.  

commit   : 3e8525aab86e78593844c9b395be40938582ebaf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 Sep 2021 16:23:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 Sep 2021 16:23:13 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 10b675b81a3a04bac460cb049e0b7b6e17fb4795  

commit   : 89a967e9b5262db1cea62a5725dd7bd7489d240d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 Sep 2021 10:05:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 Sep 2021 10:05:46 +0200    

A few characters in the acknowledgments list cannot be handled by the  
PDF build, so replace with a similar ASCII character.  

commit   : 3609b453cd655060562f8750ce0ce4bdddf43a57    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 Sep 2021 09:18:17 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 Sep 2021 09:18:17 +0200    

current through 66061077155d68463ec00604ba7d6f0ae69716e8  

commit   : 66061077155d68463ec00604ba7d6f0ae69716e8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 20 Sep 2021 00:34:57 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 20 Sep 2021 00:34:57 +0200    

Since introduction of extended statistics, we've disallowed references  
to system columns. So for example  
  
    CREATE STATISTICS s ON ctid FROM t;  
  
would fail. But with extended statistics on expressions, it was possible  
to work around this limitation quite easily  
  
    CREATE STATISTICS s ON (ctid::text) FROM t;  
  
This is an oversight in a4d75c86bf, fixed by adding a simple check.  
Backpatch to PostgreSQL 14, where support for extended statistics on  
expressions was introduced.  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/20210816013255.GS10479%40telsasoft.com  

commit   : 2a9a34c3100d8c0311c63baaa435be38a7d7aae5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Sep 2021 12:10:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Sep 2021 12:10:34 -0400    

A recent question reminded me that the notes' description of  
commit 86dc90056 rather undersold its benefits.  
  
Discussion: https://postgr.es/m/4a3115d4-0fb2-e214-93e3-9a9d0974b883@deepbluecap.com  

commit   : 55abb37506e9af4bbc4d8410ac8469b9d38e84e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Sep 2021 11:36:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Sep 2021 11:36:53 -0400    

"PGcon" should be "PGconn".  Noted by D. Frey.  
  
Discussion: https://postgr.es/m/163191739352.4680.16994248583642672629@wrigleys.postgresql.org  

commit   : f8dacf125db42547579629be1936fa613bad8070    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Sep 2021 17:09:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Sep 2021 17:09:46 -0400    

Improve various item descriptions.  Rearrange some things into  
(IMO) more logical order.  Fix missing markup and dubious  
choices of link destinations.  Drop a couple of items that  
were later back-patched or otherwise don't seem to need  
to be documented here.  

commit   : 68b6ed42e69f920c67902e33d4a648bd39e0a19b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Sep 2021 13:46:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Sep 2021 13:46:07 -0400    

Account for recent commits, notably reversion of 0827e8af7.  
Strip trailing spaces.  

commit   : 55934416d2c50cdc9fba044a97fb14da1c779589    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Sep 2021 14:19:50 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 17 Sep 2021 14:19:50 -0700    

An elog that reports the value of a transaction ID stored on a deleted  
nbtree page was added by commit e5d8a999, which taught page deletion to  
store full 64-bit XIDs.  It seems very chatty on further reflection, so  
lower its elevel from NOTICE to DEBUG2.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Backpatch: 14-, just like the nbtree XID enhancement.  

commit   : 4d5b4483db1c6370861ca968edd753ab4dc03f9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Sep 2021 15:41:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Sep 2021 15:41:16 -0400    

Commit 55dc86eca changed pull_varnos to use (if possible) the associated  
ph_eval_at for a PlaceHolderVar.  I missed a fine point though: we might  
be looking at a PHV in the quals or tlist of a child appendrel, in which  
case we need to compute a ph_eval_at value that's been translated in the  
same way that the PHV itself has been (cf. adjust_appendrel_attrs).  
Fortunately, enough info is available in the PlaceHolderInfo to make  
such translation possible without additional outside data, so we don't  
need another round of uglification of planner APIs.  This is a little  
bit complicated, but since it's a hard-to-hit corner case, I'm not much  
worried about adding cycles here.  
  
Per report from Jaime Casanova.  Back-patch to v12, like the previous  
commit.  
  
Discussion: https://postgr.es/m/20210915230959.GB17635@ahch-to  

commit   : 388726753b638fb9938883bdd057b2ffe6f950f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Sep 2021 10:45:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Sep 2021 10:45:42 -0400    

The rewriter transformation for SEARCH BREADTH FIRST produces a  
FieldSelect on a Var of type RECORD, where the Var references the  
recursive union's worktable output.  EXPLAIN VERBOSE failed to handle  
this case, because it only expected such Vars to appear in CteScans  
not WorkTableScans.  Fix that, and add some test cases exercising  
EXPLAIN on SEARCH and CYCLE queries.  
  
In principle this oversight is an old bug, but it seems that the  
case is unreachable without SEARCH BREADTH FIRST, because the  
parser fails when attempting to create such a reference manually.  
So for today I'll just patch HEAD/v14.  Someday we might find that  
the code portion of this patch needs to be back-patched further.  
  
Per report from Atsushi Torikoshi.  
  
Discussion: https://postgr.es/m/5bafa66ad529e11860339565c9e7c166@oss.nttdata.com  

commit   : f46dc96fcc652d5c29343e0eb4fa8e86a9468c36    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Sep 2021 14:48:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 16 Sep 2021 14:48:52 +0200    

commit   : 7890a423470b3a763aa22faf69a44cb6a2df8f0e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Sep 2021 02:02:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 16 Sep 2021 02:02:40 -0700    

Session statistics, as introduced by 960869da08, had several shortcomings:  
  
- an additional GetCurrentTimestamp() call that also impaired the accuracy of  
  the data collected  
  
  This can be avoided by passing the current timestamp we already have in  
  pgstat_report_stat().  
  
- an additional statistics UDP packet sent every 500ms  
  
  This is solved by adding the new statistics to PgStat_MsgTabstat.  
  This is conceptually ugly, because session statistics are not  
  table statistics.  But the struct already contains data unrelated  
  to tables, so there is not much damage done.  
  
  Connection and disconnection are reported in separate messages, which  
  reduces the number of additional messages to two messages per session and a  
  slight increase in PgStat_MsgTabstat size (but the same number of table  
  stats fit).  
  
- Session time computation could overflow on systems where long is 32 bit.  
  
Reported-By: Andres Freund <andres@anarazel.de>  
Author: Andres Freund <andres@anarazel.de>  
Author: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/20210801205501.nyxzxoelqoo4x2qc%40alap3.anarazel.de  
Backpatch: 14-, where the feature was introduced.  

commit   : 92a8d7610ea0f440a80328ced342b782180a3f43    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Sep 2021 13:06:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Sep 2021 13:06:21 +0900    

ProcArrayGroupClearXid function has a parameter named "proc",  
but the same name was used for its local variables. This commit fixes  
this variable shadowing, to improve code readability.  
  
Back-patch to all supported versions, to make future back-patching  
easy though this patch is classified as refactoring only.  
  
Reported-by: Ranier Vilela  
Author: Ranier Vilela, Aleksander Alekseev  
https://postgr.es/m/CAEudQAqyoTZC670xWi6w-Oe2_Bk1bfu2JzXz6xRfiOUzm7xbyQ@mail.gmail.com  

commit   : fe8821ca7da4bc1f72688cece0b7f2c3076d813d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Sep 2021 12:52:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 16 Sep 2021 12:52:30 +0900    

All size_t variables declared in procarray.c are actually int ones.  
Let's use int instead of size_t for those variables. Which would  
reduce Wsign-compare compiler warnings.  
  
Back-patch to v14 where commit 941697c3c1 added size_t variables  
in procarray.c, to make future back-patching easy though  
this patch is classified as refactoring only.  
  
Reported-by: Ranier Vilela  
Author: Ranier Vilela, Aleksander Alekseev  
https://postgr.es/m/CAEudQAqyoTZC670xWi6w-Oe2_Bk1bfu2JzXz6xRfiOUzm7xbyQ@mail.gmail.com  

commit   : d84d62b6225b4af86cd9837b71f6fd2cf33fe80c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Sep 2021 12:31:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Sep 2021 12:31:56 -0400    

It's possible to execute user-defined SQL in some background processes;  
for example, logical replication workers can fire triggers.  This opens  
the possibility that someone would try to execute LISTEN in such a  
context.  But since only regular backends ever call  
ProcessNotifyInterrupt, no messages would actually be received, and  
thus the registered listener would simply prevent the message queue  
from being cleaned.  Eventually NOTIFY would stop working, which is bad.  
  
Perhaps someday somebody will invent infrastructure to make listening  
in a background worker actually useful.  In the meantime, forbid it.  
  
Back-patch to v13, which is where we introduced the MyBackendType  
variable.  It'd be a lot harder to implement the check without that,  
and it doesn't seem worth the trouble.  
  
Discussion: https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org  

commit   : 9b2fd490577bc957429f337cfd72869eb8ef08c9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Sep 2021 11:59:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Sep 2021 11:59:34 +0200    

Commit 054adca641ac1279dc8d9b74fda41948ac35e9a9 neglected to  
initialize the type_id field of the synthesized type cache entry, so  
it would make a new one on every call.  
  
Also, better use the per-function memory context for this; otherwise  
it leaks memory.  
  
Discussion: https://www.postgresql.org/message-id/flat/17158-8a2ba823982537a4%40postgresql.org  

commit   : 6e6adbddbce1391ffb676ce9779f24c25a6a9f09    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 15 Sep 2021 09:54:45 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 15 Sep 2021 09:54:45 +0200    

The available refresh options are specified as refresh_options under  
REFRESH PUBLICATION, and DROP PUBLICATION itself has an option named  
refresh. Clarify what we mean by refresh options to avoid confusion.  
  
Backpatch through v14 where ALTER SUBSCRIPTION ... DROP PUBLICATION  
was introduced.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>  
Reviewed-by: Peter Smith <smithpb2250@gmail.com>  
Discussion: https://postgr.es/m/CAD21AoCm1wJ3A8Q9EmBjRbShYkJ+o+Oa_z9O0hvwhvhUa2BSyg@mail.gmail.com  
Backpatch-through: 14  

commit   : 0eff10a008447bc6f6594547e2fc04756849eaed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Sep 2021 17:18:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Sep 2021 17:18:25 -0400    

Formerly, we sent signals for outgoing NOTIFY messages within  
ProcessCompletedNotifies, which was also responsible for sending  
relevant ones of those messages to our connected client.  It therefore  
had to run during the main-loop processing that occurs just before  
going idle.  This arrangement had two big disadvantages:  
  
* Now that procedures allow intra-command COMMITs, it would be  
useful to send NOTIFYs to other sessions immediately at COMMIT  
(though, for reasons of wire-protocol stability, we still shouldn't  
forward them to our client until end of command).  
  
* Background processes such as replication workers would not send  
NOTIFYs at all, since they never execute the client communication  
loop.  We've had requests to allow triggers running in replication  
workers to send NOTIFYs, so that's a problem.  
  
To fix these things, move transmission of outgoing NOTIFY signals  
into AtCommit_Notify, where it will happen during CommitTransaction.  
Also move the possible call of asyncQueueAdvanceTail there, to  
ensure we don't bloat the async SLRU if a background worker sends  
many NOTIFYs with no one listening.  
  
We can also drop the call of asyncQueueReadAllNotifications,  
allowing ProcessCompletedNotifies to go away entirely.  That's  
because commit 790026972 added a call of ProcessNotifyInterrupt  
adjacent to PostgresMain's call of ProcessCompletedNotifies,  
and that does its own call of asyncQueueReadAllNotifications,  
meaning that we were uselessly doing two such calls (inside two  
separate transactions) whenever inbound notify signals coincided  
with an outbound notify.  We need only set notifyInterruptPending  
to ensure that ProcessNotifyInterrupt runs, and we're done.  
  
The existing documentation suggests that custom background workers  
should call ProcessCompletedNotifies if they want to send NOTIFY  
messages.  To avoid an ABI break in the back branches, reduce it  
to an empty routine rather than removing it entirely.  Removal  
will occur in v15.  
  
Although the problems mentioned above have existed for awhile,  
I don't feel comfortable back-patching this any further than v13.  
There was quite a bit of churn in adjacent code between 12 and 13.  
At minimum we'd have to also backpatch 51004c717, and a good deal  
of other adjustment would also be needed, so the benefit-to-risk  
ratio doesn't look attractive.  
  
Per bug #15293 from Michael Powers (and similar gripes from others).  
  
Artur Zakirov and Tom Lane  
  
Discussion: https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org  

commit   : 29aa0ce361d16a79e4ebf7561cbb16ed1d0e2211    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Sep 2021 15:11:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Sep 2021 15:11:21 -0400    

It's possible for us to copy an AlternativeSubPlan expression node  
into multiple places, for example the scan quals of several  
partition children.  Then it's possible that we choose a different  
one of the alternatives as optimal in each place.  Commit 41efb8340  
failed to consider this scenario, so its attempt to remove "unused"  
subplans could remove subplans that were still used elsewhere.  
  
Fix by delaying the removal logic until we've examined all the  
AlternativeSubPlans in a given query level.  (This does assume that  
AlternativeSubPlans couldn't get copied to other query levels, but  
for the foreseeable future that's fine; cf qual_is_pushdown_safe.)  
  
Per report from Rajkumar Raghuwanshi.  Back-patch to v14  
where the faulty logic came in.  
  
Discussion: https://postgr.es/m/CAKcux6==O3NNZC3bZ2prRYv3cjm3_Zw1GfzmOjEVqYN4jub2+Q@mail.gmail.com  

commit   : 4e86887e0922f20add67e2473c7baae8c7f05d5e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Sep 2021 18:07:19 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Sep 2021 18:07:19 -0700    

If an allocation failed within LLVM it is not safe to call back into LLVM as  
LLVM is not generally safe against exceptions / stack-unwinding. Thus errors  
while in LLVM code are promoted to FATAL. However llvm_shutdown() did call  
back into LLVM even in such cases, while llvm_release_context() was careful  
not to do so.  
  
We cannot generally skip shutting down LLVM, as that can break profiling. But  
it's OK to do so if there was an error from within LLVM.  
  
Reported-By: Jelte Fennema <Jelte.Fennema@microsoft.com>  
Author: Andres Freund <andres@anarazel.de>  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/AM5PR83MB0178C52CCA0A8DEA0207DC14F7FF9@AM5PR83MB0178.EURPRD83.prod.outlook.com  
Backpatch: 11-, where jit was introduced  

commit   : 0d0bbee5e3ee2eabe3a1f6081cbc4226520764c0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Sep 2021 16:50:10 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Sep 2021 16:50:10 -0700    

In d9d8aa9bb9a I added a defensive NULL assignment to protect against a  
not-too-smart compiler warning about unitialized variable use after the  
switch. Unfortunately I only did so on master and forgot to adjust that for  
14.  
  
Stephen noticed that there actually is a compiler warning :(.  
  
Reported-By: Stephen Frost <sfrost@snowman.net>  
Discussion: https://postgr.es/m/20210827224639.GX17906@tamriel.snowman.net  

commit   : 896a0c44f93b0b449fdf7e6c3973deab5fdfed4f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Sep 2021 16:53:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Sep 2021 16:53:11 -0400    

Commits ffa2e4670 and 52a10224e caused libpq's connection-establishment  
functions to usually leave a nonempty string in the connection's  
errorMessage buffer, even after a successful connection.  While that  
was intentional on my part, more sober reflection says that it wasn't  
a great idea: the string would be a bit confusing.  Also this broke at  
least one application that checked for connection success by examining  
the errorMessage, instead of using PQstatus() as documented.  Let's  
clear the buffer at success exit, restoring the pre-v14 behavior.  
  
Discussion: https://postgr.es/m/4170264.1620321747@sss.pgh.pa.us  

commit   : 4ffd3fe4d6ccc9ff36271e5a21ea3b065621b982    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Sep 2021 12:42:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Sep 2021 12:42:03 -0400    

Ordinarily, using EXIT this way would draw "control reached end of  
function without RETURN".  However, if the function is one where we  
don't require an explicit RETURN (such as a DO block), that should  
not happen.  It did anyway, because add_dummy_return() neglected to  
account for the case.  
  
Per report from Herwig Goemans.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/868ae948-e3ca-c7ec-95a6-83cfc08ef750@gmail.com  

commit   : 10faeb7ed5049afb70d26561e9991d52c363bd8e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 Sep 2021 10:42:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 Sep 2021 10:42:16 -0400    

Reported-by: Robert Haas  
  
Backpatch-through: 14 only  

commit   : 749945c2425b7c83d95b0359733f4839049fdcb8    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 13 Sep 2021 17:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 13 Sep 2021 17:30:00 +0900    

The type information for FDW options is only added to HEAD; remove this  
from back branches.  Oversight in commit aa769f80e.  
  
Apply the patch to v12, v13, and v14.  
  
Discussion: https://postgr.es/m/CAPmGK14z92twaKwRoccHbbh5Va5vbRDZcTYYTx50+0JTQ8xx_g@mail.gmail.com  

commit   : f5e0ff4631b5402950db69c989c88c4c6295504b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Sep 2021 10:35:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Sep 2021 10:35:00 +0530    

While processing toast changes in logical decoding, we rejigger the  
tuple change to point to in-memory toast tuples instead to on-disk toast  
tuples. And, to make sure the memory accounting is correct, we were  
subtracting the old change size and then after re-computing the new tuple,  
re-adding its size at the end. Now, if there is any error before we add  
the new size, we will release the changes and that will update the  
accounting info (subtracting the size from the counters). And we were  
underflowing there which leads to an assertion failure in assert enabled  
builds and wrong memory accounting in reorder buffer otherwise.  
  
Author: Bertrand Drouvot  
Reviewed-by: Amit Kapila  
Backpatch-through: 13, where memory accounting was introduced  
Discussion: https://postgr.es/m/92b0ee65-b8bd-e42d-c082-4f3f4bf12d34@amazon.com  

commit   : cc057fb315e24b78552f5b7ac05792418042e71b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Sep 2021 13:24:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Sep 2021 13:24:04 +0900    

An out-of-memory failure happening when allocating the structures to  
store the connection parameter keywords and values would mess up with  
the set of connections saved, as on failure the pthread mutex would  
still be hold with the new connection object listed but free()'d.  
  
Rather than just unlocking the mutex, which would leave the static list  
of connections into an inconsistent state, move the allocation for the  
structures of the connection parameters before beginning the test  
manipulation.  This ensures that the list of connections and the  
connection mutex remain consistent all the time in this code path.  
  
This error is unlikely going to happen, but this could mess up badly  
with ECPG clients in surprising ways, so backpatch all the way down.  
  
Reported-by: ryancaicse  
Discussion: https://postgr.es/m/17186-b4cfd8f0eb4d1dee@postgresql.org  
Backpatch-through: 9.6  

commit   : b33283cbd336adbf982c21aac1399130c8ffaaa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Sep 2021 15:19:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Sep 2021 15:19:31 -0400    

If search_start is greater than the length of the string, we should just  
return REG_NOMATCH immediately.  (Note that the equality case should  
*not* be rejected, since the pattern might be able to match zero  
characters.)  This guards various internal assumptions that the min of a  
range of string positions is not more than the max.  Violation of those  
assumptions could allow an attempt to fetch string[search_start-1],  
possibly causing a crash.  
  
Jaime Casanova pointed out that this situation is reachable with the  
new regexp_xxx functions that accept a user-specified start position.  
I don't believe it's reachable via any in-core call site in v14 and  
below.  However, extensions could possibly call pg_regexec with an  
out-of-range search_start, so let's back-patch the fix anyway.  
  
Discussion: https://postgr.es/m/20210911180357.GA6870@ahch-to  

commit   : d844cd75a6764a1dd2d8b3410144df9ebf8a0f04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Sep 2021 13:18:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Sep 2021 13:18:32 -0400    

We have long forbidden fetching backwards from a NO SCROLL cursor,  
but the prohibition didn't extend to cases in which we rewind the  
query altogether and then re-fetch forwards.  I think the reason is  
that this logic was mainly meant to protect plan nodes that can't  
be run in the reverse direction.  However, re-reading the query output  
is problematic if the query is volatile (which includes SELECT FOR  
UPDATE, not just queries with volatile functions): the re-read can  
produce different results, which confuses the cursor navigation logic  
completely.  Another reason for disliking this approach is that some  
code paths will either fetch backwards or rewind-and-fetch-forwards  
depending on the distance to the target row; so that seemingly  
identical use-cases may or may not draw the "cursor can only scan  
forward" error.  Hence, let's clean things up by disallowing rewind  
as well as fetch-backwards in a NO SCROLL cursor.  
  
Ordinarily we'd only make such a definitional change in HEAD, but  
there is a third reason to consider this change now.  Commit ba2c6d6ce  
created some new user-visible anomalies for non-scrollable cursors  
WITH HOLD, in that navigation in the cursor result got confused if the  
cursor had been partially read before committing.  The only good way  
to resolve those anomalies is to forbid rewinding such a cursor, which  
allows removal of the incorrect cursor state manipulations that  
ba2c6d6ce added to PersistHoldablePortal.  
  
To minimize the behavioral change in the back branches (including  
v14), refuse to rewind a NO SCROLL cursor only when it has a holdStore,  
ie has been held over from a previous transaction due to WITH HOLD.  
This should avoid breaking most applications that have been sloppy  
about whether to declare cursors as scrollable.  We'll enforce the  
prohibition across-the-board beginning in v15.  
  
Back-patch to v11, as ba2c6d6ce was.  
  
Discussion: https://postgr.es/m/3712911.1631207435@sss.pgh.pa.us  

commit   : b7056c0a25e545f4c1efcc1e2a6118e4626e377b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 13:36:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 13:36:31 -0400    

Some plan node types don't react well to being called again after  
they've already returned NULL.  PortalRunSelect() has long dealt  
with this by calling the executor with NoMovementScanDirection  
if it sees that we've already run the portal to the end.  However,  
commit ba2c6d6ce overlooked this point, so that persisting an  
already-fully-fetched cursor would fail if it had such a plan.  
  
Per report from Tomas Barton.  Back-patch to v11, as the faulty  
commit was.  (I've omitted a test case because the type of plan  
that causes a problem isn't all that stable.)  
  
Discussion: https://postgr.es/m/CAPV2KRjd=ErgVGbvO2Ty20tKTEZZr6cYsYLxgN_W3eAo9pf5sw@mail.gmail.com  

commit   : b27d0cd3147e2a0215253f61944c392a30265db8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Sep 2021 01:28:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Sep 2021 01:28:17 +0900    

When throttling is used, transactions that lag behind schedule by  
more than the latency limit are counted and reported as skipped.  
Previously, there was the case where pgbench counted all skipped  
transactions even if the timer specified in -T option was exceeded.  
This could take a very long time to do that especially when unrealistically  
high rate setting in -R option caused quite a lot of transactions that  
lagged behind schedule. This could prevent pgbench from ending  
immediately, and so pgbench could look like it got stuck to users.  
  
To fix the issue, this commit changes pgbench so that it stops counting  
skipped transactions as soon as the timer is exceeded. The timer can  
make pgbench end soon even when there are lots of skipped transactions  
that have not been counted yet.  
  
Note that there is no guarantee that all skipped transactions are  
counted under -T though there is under -t. This is OK in practice  
because it's very unlikely to happen with realistic setting. Also this is  
not the issue that this commit newly introdues. There used to be  
the case where pgbench ended without counting all skipped  
transactions since before.  
  
Back-patch to v14. Per discussion, we decided not to bother  
back-patch to the stable branches because it's hard to imagine  
the issue happens in practice (with realistic setting).  
  
Author: Yugo Nagata, Fabien COELHO  
Reviewed-by: Greg Sabino Mullane, Fujii Masao  
Discussion: https://postgr.es/m/20210613040151.265ff59d832f835bbcf8b3ba@sraoss.co.jp  

commit   : 7430c774209cd98bbc33076cc3c07497c1086d9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 11:45:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Sep 2021 11:45:48 -0400    

We don't allow relations to exceed 2^32-1 blocks, because block  
numbers are 32 bits and the last possible block number is reserved  
to mean InvalidBlockNumber.  There is a check for this in mdextend,  
but that's really way too late, because the smgr API requires us to  
create a buffer for the block-to-be-added, and we do not want to  
have any buffer with blocknum InvalidBlockNumber.  (Such a case  
can trigger assertions in bufmgr.c, plus I think it might confuse  
ReadBuffer's logic for data-past-EOF later on.)  So put the check  
into ReadBuffer.  
  
Per report from Christoph Berg.  It's been like this forever,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/YTn1iTkUYBZfcODk@msg.credativ.de  

commit   : b5ec22bf5e8f19964f7c7d7ef357ff947a38c7fc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Sep 2021 23:58:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Sep 2021 23:58:05 +0900    

Previously, walreceiver always closed the currently-opened WAL segment  
and created its archive notification file, after it finished writing  
the current segment up and received any WAL data that should be  
written into the next segment. If walreceiver exited just before  
any WAL data in the next segment arrived at standby, it did not  
create the archive notification file of the current segment  
even though that's known completed. This behavior could cause  
WAL archiving of the segment to be delayed until subsequent  
restartpoints or checkpoints created its notification file.  
  
To fix the issue, this commit changes walreceiver so that it creates  
an archive notification file of a current WAL segment immediately  
if that's known completed before receiving next WAL data.  
  
Back-patch to all supported branches.  
  
Reported-by: Kyotaro Horiguchi  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200630.165503.1465894182551545886.horikyota.ntt@gmail.com  

commit   : 52c300df323e8ebb3d0613baa4711179d9f342f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 15:09:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 15:09:42 -0400    

Coverity complained that one caller of getFormattedTypeName() failed  
to free the returned string.  Which is true, but rather than fixing  
that one, let's get rid of this tedious and error-prone requirement.  
Now that getFormattedTypeName() caches its result, strdup'ing that  
result and expecting the caller to free it accomplishes little except  
to waste cycles.  We do create a leak in the case where getTypes didn't  
make a TypeInfo for the type, but that basically shouldn't ever happen.  
  
Back-patch, as commit 6c450a861 was.  This isn't a particularly  
interesting bug fix, but the API change seems like a hazard for  
future back-patching activity if we don't back-patch it.  

commit   : 67948a433e18a8561daf89dcc53e591a3fac659a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 14:11:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 14:11:35 -0400    

Seems to have been my error in commit aeb1631ed.  
Noted by Christoph Berg.  
  
Discussion: https://postgr.es/m/YTeLipdnSOg4NNcI@msg.df7cb.de  

commit   : 03d01d746b9338dd1568d37d26b344928f82c5ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 12:05:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Sep 2021 12:05:43 -0400    

If we copy data-modifying CTEs from the original query to a replacement  
query (from a DO INSTEAD rule), we must set hasModifyingCTE properly  
in the replacement query.  Failure to do this can cause various  
unpleasantness, such as unsafe usage of parallel plans.  The code also  
neglected to propagate hasRecursive, though that's only cosmetic at  
the moment.  
  
A difficulty arises if the rule action is an INSERT...SELECT.  We  
attach the original query's RTEs and CTEs to the sub-SELECT Query, but  
data-modifying CTEs are only allowed to appear in the topmost Query.  
For the moment, throw an error in such cases.  It would probably be  
possible to avoid this error by attaching the CTEs to the top INSERT  
Query instead; but that would require a bunch of new code to adjust  
ctelevelsup references.  Given the narrowness of the use-case, and  
the need to back-patch this fix, it does not seem worth the trouble  
for now.  We can revisit this if we get field complaints.  
  
Per report from Greg Nancarrow.  Back-patch to all supported branches.  
(The test case added here does not fail before v10, but there are  
plenty of places checking top-level hasModifyingCTE in 9.6, so I have  
no doubt that this code change is necessary there too.)  
  
Greg Nancarrow and Tom Lane  
  
Discussion: https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com  
Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com  

commit   : 054adca641ac1279dc8d9b74fda41948ac35e9a9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Sep 2021 09:25:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Sep 2021 09:25:46 +0200    

Commit 01e658fa74 added hash support for row types.  This also added  
support for hashing anonymous record types, using the same approach  
that the type cache uses for comparison support for record types: It  
just reports that it works, but it might fail at run time if a  
component type doesn't actually support the operation.  We get away  
with that for comparison because most types support that.  But some  
types don't support hashing, so the current state can result in  
failures at run time where the planner chooses hashing over sorting,  
whereas that previously worked if only sorting was an option.  
  
We do, however, want the record hashing support for path tracking in  
recursive unions, and the SEARCH and CYCLE clauses built on that.  In  
that case, hashing is the only plan option.  So enable that, this  
commit implements the following approach: The type cache does not  
report that hashing is available for the record type.  This undoes  
that part of 01e658fa74.  Instead, callers that require hashing no  
matter what can override that result themselves.  This patch only  
touches the callers to make the aforementioned recursive query cases  
work, namely the parse analysis of unions, as well as the hash_array()  
function.  
  
Reported-by: Sait Talha Nisanci <sait.nisanci@microsoft.com>  
Bug: #17158  
Discussion: https://www.postgresql.org/message-id/flat/17158-8a2ba823982537a4%40postgresql.org  

commit   : 8db27fbc11974ef491fec97be3365277ed4fab20    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 8 Sep 2021 09:58:28 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 8 Sep 2021 09:58:28 +0530    

Updates/Deletes on a relation were allowed even without replica identity  
after we define the publication for all tables. This would later lead to  
an error on subscribers. The reason was that for such publications we were  
not invalidating the relcache and the publication information for  
relations was not getting rebuilt. Similarly, we were not invalidating the  
relcache after dropping of such publications which will prohibit  
Updates/Deletes without replica identity even without any publication.  
  
Author: Vignesh C and Hou Zhijie  
Reviewed-by: Hou Zhijie, Kyotaro Horiguchi, Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/CALDaNm0pF6zeWqCA8TCe2sDuwFAy8fCqba=nHampCKag-qLixg@mail.gmail.com  

commit   : b7fd291042a846b04439f122cb81a41d3cd2e8de    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Sep 2021 21:59:25 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Sep 2021 21:59:25 +0200    

This affects one message and some documentation that used the format  
"read only", unlike everything else that used read-only.  
  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CABUevExuxKwn0YM3+wdSeQSvK6CRrJ-hewocGVX3R4-xVX4eMw@mail.gmail.com  

commit   : 8b895374cd9cf6989bcee5b6f70f65f2d3520224    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Sep 2021 10:52:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Sep 2021 10:52:25 -0400    

Commit 67c33a114 should have set v14's catversion back to what it was  
before 3eda9fc09, to avoid forcing a useless pg_upgrade cycle on users  
of 14beta3.  Do that now.  
  
Discussion: https://postgr.es/m/2598498.1630702074@sss.pgh.pa.us  

commit   : e66add755df2eae5e874dc96743f3faaf4bced83    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Sep 2021 10:28:55 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Sep 2021 10:28:55 +0300    

Introduced by commit c3928b467a, backpatch to v14 like that one.  
  
Author: Amit Langote  
Discussion: https://www.postgresql.org/message-id/CA+HiwqFQgNLS6VGntMcuJV6erBFV425xA6wBVnY=41GK4zC0Bw@mail.gmail.com  

commit   : 47d54b6ba2749f5da72b7ab612e53e7f7b45b819    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 6 Sep 2021 11:27:59 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 6 Sep 2021 11:27:59 -0700    

We make each AIX shared library export all globals found in .o files  
that originate in the library.  That doesn't include symbols acquired by  
-lpgcommon_shlib.  That is good on average, but it became a problem for  
libpq when commit e6afa8918c461c1dd80c5063a950518fa4e950cd moved five  
official libpq API symbols into src/common.  Fix this by implementing  
the SHLIB_EXPORTS mechanism for AIX, so affected libraries export the  
same symbols that they export on Linux.  This reintroduces symbols  
pg_encoding_to_char, pg_utf_mblen, pg_char_to_encoding,  
pg_valid_server_encoding, and pg_valid_server_encoding_id.  Back-patch  
to v13, where the aforementioned commit first appeared.  While a minor  
release is usually the wrong time to add or remove symbol exports in  
libpq or libecpg, we should expect users to want each documented symbol.  
  
Tony Reix  
  
Discussion: https://postgr.es/m/PR3PR02MB6396742E2FC3E77D37A920BC86C79@PR3PR02MB6396.eurprd02.prod.outlook.com  

commit   : 599c73a91a0471465a84f12fe6a2e7236a825721    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Sep 2021 11:29:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Sep 2021 11:29:52 -0400    

timetz_zone() delivered completely wrong answers if the zone was  
specified by a dynamic TZ abbreviation, because it failed to account  
for the difference between the POSIX conventions for field values in  
struct pg_tm and the conventions used in PG-specific datetime code.  
  
As a stopgap fix, just adjust the tm_year and tm_mon fields to match  
PG conventions.  This is fixed in a different way in HEAD (388e71af8)  
but I don't want to back-patch the change of reference point.  
  
Discussion: https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com  

commit   : 1e9afc868eb5a3b2f50629c2724d9fcdbe0afee2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Sep 2021 09:41:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Sep 2021 09:41:03 +0200    

Since ea53100d5 (PostgreSQL 12), the shipped pkg-config files have  
been broken for statically linking libpq because libpgcommon and  
libpgport are missing.  This patch adds those two missing private  
dependencies (in a non-hardcoded way).  
  
Reported-by: Filip Gospodinov <f@gospodinov.ch>  
Discussion: https://www.postgresql.org/message-id/flat/c7108bde-e051-11d5-a234-99beec01ce2a@gospodinov.ch  

commit   : 718978d9daa7128e0f5e4e06c0fd402cdd63704f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Sep 2021 16:29:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Sep 2021 16:29:08 -0400    

Attempting to make hashfloat4() look as much as possible like  
hashfloat8(), I'd figured I could replace NaNs with get_float4_nan()  
before widening to float8.  However, results from protosciurus  
and topminnow show that on some platforms that produces a different  
bit-pattern from get_float8_nan(), breaking the intent of ce773f230.  
Rearrange so that we use the result of get_float8_nan() for all NaN  
cases.  As before, back-patch.  

commit   : 5edbcbd5b94c696526e18bbb490ab2e9f4282826    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Sep 2021 13:27:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Sep 2021 13:27:55 -0400    

Fix alphabetization of the output of "\?", and improve one description.  
  
Update PageOutput counts where needed, fixing breakage from previous  
patches.  
  
Haiying Tang (PageOutput fixes by me)  
  
Discussion: https://postgr.es/m/OS0PR01MB61136018064660F095CB57A8FB129@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : aa8bd0890bb29356a465d235dee59c1b08fa5fc5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 4 Sep 2021 12:14:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 4 Sep 2021 12:14:30 -0400    

This reverts commit 515e3d84a0b5 and equivalent commits in back  
branches.  This solution to the problem has a number of problems, so  
we'll try again with a different approach.  
  
Per note from Andres Freund  
  
Discussion: https://postgr.es/m/20210831042949.52eqp5xwbxgrfank@alap3.anarazel.de  

commit   : 69d670e68ec9bd00b71ddc528274746790d7b6bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 21:04:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 21:04:44 -0400    

Replace fixed-length command buffers with psprintf() calls.  We didn't  
have anything as convenient as psprintf() when this code was written,  
but now that we do, there's little reason for the limitation to  
stand.  Removing it eliminates some corner cases where (for example)  
starting the postmaster with a whole lot of options fails.  
  
Most individual file names that pg_ctl deals with are still restricted  
to MAXPGPATH, but we've seldom had complaints about that limitation  
so long as it only applies to one filename.  
  
Back-patch to all supported branches.  
  
Phil Krylov  
  
Discussion: https://postgr.es/m/567e199c6b97ee19deee600311515b86@krylov.eu  

commit   : 2cc018ba8f80a5236faf2c58dfcd18fee581dbbc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 16:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 16:38:55 -0400    

Previously this was allowed, but the collation effectively vanished  
into the ether because of the way lookup_collation() works: you could  
not use the collation, nor even drop it.  Seems better to give an  
error up front than to leave the user wondering why it doesn't work.  
  
(Because this test is in DefineCollation not CreateCollation, it does  
not prevent pg_import_system_collations from creating ICU collations,  
regardless of the initially-chosen encoding.)  
  
Per bug #17170 from Andrew Bille.  Back-patch to v10 where ICU support  
was added.  
  
Discussion: https://postgr.es/m/17170-95845cf3f0a9c36d@postgresql.org  

commit   : 67c33a114f38edbd66f68d7b2c0cb7b03611ec48    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 3 Sep 2021 13:38:15 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 3 Sep 2021 13:38:15 -0400    

543f36b43d was too hasty in thinking that the volatility of date_bin()  
had to match date_trunc(), since only the latter references  
session_timezone.  
  
Bump catversion  
  
Per feedback from Aleksander Alekseev  
Backpatch to v14, as the former commit was  

commit   : 08b96a2b5243957acd3f7c3105af8b5b2d0da3ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 10:01:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Sep 2021 10:01:02 -0400    

Modern POSIX seems to require strtod() to accept "-NaN", but there's  
nothing about NaN in SUSv2, and some of our oldest buildfarm members  
don't like it.  Let's try writing it as -'NaN' instead; that seems  
to produce the same result, at least on Intel hardware.  
  
Per buildfarm.  

commit   : 6b54f12332a184bfd03524c012795678ddc992f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Sep 2021 18:53:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Sep 2021 18:53:10 -0400    

We had a complaint that the postmaster fails to start if the invoking  
program closes stdin.  That happens because count_usable_fds expects  
to be able to dup(0), and if it can't, we conclude there are no free  
FDs and go belly-up.  So far as I can find, though, there is no other  
place in the server that touches stdin, and it's not unreasonable to  
expect that a daemon wouldn't use that file.  
  
As a simple improvement, let's dup FD 2 (stderr) instead.  Unlike stdin,  
it *is* reasonable for us to expect that stderr be open; even if we are  
configured not to touch it, common libraries such as libc might try to  
write error messages there.  
  
Per gripe from Mario Emmenlauer.  Given the lack of previous complaints,  
I'm not excited about pushing this into stable branches, but it seems  
OK to squeeze it into v14.  
  
Discussion: https://postgr.es/m/48bafc63-c30f-3962-2ded-f2e985d93e86@emmenlauer.de  

commit   : 23c6bc581dc90d08421a13494f135681504ee4e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Sep 2021 17:24:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Sep 2021 17:24:42 -0400    

The IEEE 754 standard allows a wide variety of bit patterns for NaNs,  
of which at least two ("NaN" and "-NaN") are pretty easy to produce  
from SQL on most machines.  This is problematic because our btree  
comparison functions deem all NaNs to be equal, but our float hash  
functions know nothing about NaNs and will happily produce varying  
hash codes for them.  That causes unexpected results from queries  
that hash a column containing different NaN values.  It could also  
produce unexpected lookup failures when using a hash index on a  
float column, i.e. "WHERE x = 'NaN'" will not find all the rows  
it should.  
  
To fix, special-case NaN in the float hash functions, not too much  
unlike the existing special case that forces zero and minus zero  
to hash the same.  I arranged for the most vanilla sort of NaN  
(that coming from the C99 NAN constant) to still have the same  
hash code as before, to reduce the risk to existing hash indexes.  
  
I dithered about whether to back-patch this into stable branches,  
but ultimately decided to do so.  It's a clear improvement for  
queries that hash internally.  If there is anybody who has -NaN  
in a hash index, they'd be well advised to re-index after applying  
this patch ... but the misbehavior if they don't will not be much  
worse than the misbehavior they had before.  
  
Per bug #17172 from Ma Liangzhu.  
  
Discussion: https://postgr.es/m/17172-7505bea9e04e230f@postgresql.org  

commit   : 2c1981ec3c8e1c5a52a8e9513a832d362f4fb4c1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Sep 2021 11:35:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 2 Sep 2021 11:35:56 +0900    

This makes the documentation more accurate grammatically.  
  
Author: Elena Indrupskaya  
Discussion: https://postgr.es/m/1c994b3d-951e-59bb-1ac2-7b9221c0e4cf@postgrespro.ru  
Backpatch-through: 9.6  

commit   : 95bc40f880a68dc092ca34c4813f2b27962f233d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Sep 2021 17:24:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Sep 2021 17:24:59 -0400    

Laurenz Albe, per gripe from Nathan Long.  
  
Discussion: https://postgr.es/m/161953360822.695.15805897835151971142@wrigleys.postgresql.org  

commit   : 50ba70a957f9e018495a111fc4b5e5eb2ea62044    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 1 Sep 2021 17:41:54 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 1 Sep 2021 17:41:54 +0200    

Until now, when defining extended statistics, everything except a plain  
column reference was treated as complex expression. So for example "a"  
was a column reference, but "(a)" would be an expression. In most cases  
this does not matter much, but there were a couple strange consequences.  
For example  
  
    CREATE STATISTICS s ON a FROM t;  
  
would fail, because extended stats require at least two columns. But  
  
    CREATE STATISTICS s ON (a) FROM t;  
  
would succeed, because that requirement does not apply to expressions.  
Moreover, that statistics object is useless - the optimizer will always  
use the regular statistics collected for attribute "a".  
  
So do a bit more work to identify those expressions referencing a single  
column, and translate them to a simple column reference. Backpatch to  
14, where support for extended statistics on expressions was introduced.  
  
Reported-by: Justin Pryzby  
Backpatch-through: 14  
Discussion: https://postgr.es/m/20210816013255.GS10479%40telsasoft.com  

commit   : d760d942c73c9a161feefb7dc4a0004b9b4e7787    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Sep 2021 17:05:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Sep 2021 17:05:13 +0900    

When -C/--connect option is specified, pgbench establishes and closes  
the connection for each transaction. In this case pgbench needs to  
measure the times taken for all those connections and disconnections,  
to include the average connection time in the benchmark result.  
But previously pgbench could not measure those disconnection delays.  
To fix the bug, this commit makes pgbench measure the disconnection  
delays whenever the connection is closed at the end of transaction,  
if -C/--connect option is specified.  
  
Back-patch to v14. Per discussion, we concluded not to back-patch to v13  
or before because changing that behavior in stable branches would  
surprise users rather than providing benefits.  
  
Author: Yugo Nagata  
Reviewed-by: Fabien COELHO, Tatsuo Ishii, Asif Rehman, Fujii Masao  
Discussion: https://postgr.es/m/20210614151155.a393bc7d8fed183e38c9f52a@sraoss.co.jp  

commit   : b7ad093d50e13aadfffb1662f53cd16a1c59e09d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Sep 2021 10:00:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Sep 2021 10:00:12 +0530    

The check to test whether the subscription workers were restarting after a  
change in the subscription was failing. The reason was that the test was  
assuming the walsender started before it reaches the 'streaming' state and  
the walsender was exiting due to an error before that. Now, the walsender  
was erroring out before reaching the 'streaming' state because it tries to  
acquire the slot before the previous walsender has exited.  
  
In passing, improve the die messages so that it is easier to investigate  
the failures in the future if any.  
  
Reported-by: Michael Paquier, as per buildfarm  
Author: Ajin Cherian  
Reviewed-by: Masahiko Sawada, Amit Kapila  
Backpatch-through: 10, where this test was introduced  
Discussion: https://postgr.es/m/YRnhFxa9bo73wfpV@paquier.xyz  

commit   : 0d892cf73a13b3a32af438a059a168e711aa0a7f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 31 Aug 2021 20:37:17 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 31 Aug 2021 20:37:17 -0700    

It doesn't make any sense to report this information, since VACUUM  
VERBOSE reports on heap relation truncation directly.  This was an  
oversight in commit 7ab96cf6, which made VACUUM VERBOSE output a little  
more consistent with nearby autovacuum-specific log output.  Adjust  
comments that describe how this is supposed to work in passing.  
  
Also bring truncation-related VACUUM VERBOSE output in line with the  
convention established for VACUUM VERBOSE output by commit f4f4a649.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Backpatch: 14-, where VACUUM VERBOSE's output changed.  

commit   : 4d1816ec26e877297608a850736afed962527d70    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 1 Sep 2021 00:42:32 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 1 Sep 2021 00:42:32 +0200    

The code printing expressions for extended statistics doubled the  
parens, producing results like ((a+1)), which is unnecessary and not  
consistent with how we print expressions elsewhere.  
  
Fixed by tweaking the code to produce just a single set of parens.  
  
Reported by Mark Dilger, fix by me. Backpatch to 14, where support for  
extended statistics on expressions was added.  
  
Reported-by: Mark Dilger  
Discussion: https://postgr.es/m/20210122040101.GF27167%40telsasoft.com  

commit   : 3eda9fc09fd6b9a1aec2d0113c633c69c3214b4d    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Tue, 31 Aug 2021 14:15:22 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Tue, 31 Aug 2021 14:15:22 -0400    

Previously, it was immutable by lack of marking. This is not  
correct, since the time zone could change.  
  
Bump catversion  
  
Discussion: https://www.postgresql.org/message-id/CAFBsxsG2UHk8mOWL0tca%3D_cg%2B_oA5mVRNLhDF0TBw980iOg5NQ%40mail.gmail.com  
Backpatch to v14, when this function came in  

commit   : a20a9f26cefcf4e35ba7bb3d9e8672cb4ce1cf32    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 15:04:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 15:04:05 -0400    

For no particularly good reason, getPolicies() queried pg_policy  
separately for each table.  We can collect all the policies in  
a single query instead, and attach them to the correct TableInfo  
objects using findTableByOid() lookups.  On the regression  
database, this reduces the number of queries substantially, and  
provides a visible savings even when running against a local  
server.  
  
Per complaint from Hubert Depesz Lubaczewski.  Since this is such  
a simple fix and can have a visible performance benefit, back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/20210826084430.GA26282@depesz.com  

commit   : 9407dbbcb5b587cbefc4af14d1612b49abcb143b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 13:53:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 13:53:33 -0400    

There's long been a "TODO: there might be some value in caching  
the results" annotation on pg_dump's getFormattedTypeName function;  
but we hadn't gotten around to checking what it was costing us to  
repetitively look up type names.  It turns out that when dumping the  
current regression database, about 10% of the total number of queries  
issued are duplicative format_type() queries.  However, Hubert Depesz  
Lubaczewski reported a not-unusual case where these account for over  
half of the queries issued by pg_dump.  Individually these queries  
aren't expensive, but when network lag is a factor, they add up to a  
problem.  We can very easily add some caching to getFormattedTypeName  
to solve it.  
  
Since this is such a simple fix and can have a visible performance  
benefit, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20210826084430.GA26282@depesz.com  

commit   : 4090ff2a99b76b7bd51534fb0f7013aa646d1e24    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 19:21:29 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 19:21:29 +0200    

Commit 5be8ce82e8 added a new role to the stats_ext regression suite,  
but the role name did not start with regress_ causing failures when  
running with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS. Fixed by  
renaming the role to start with the expected regress_ prefix.  
  
Backpatch-through: 10, same as the new regression test  
Discussion: https://postgr.es/m/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com  

commit   : a371a5ba349d9c39e7754f7d0f195ac46ee87b3f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 18:03:05 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 31 Aug 2021 18:03:05 +0200    

When an ownership check on extended statistics object failed, the code  
was calling aclcheck_error_type to report the failure, which is clearly  
wrong, resulting in cache lookup errors. Fix by calling aclcheck_error.  
  
This issue exists since the introduction of extended statistics, so  
backpatch all the way back to PostgreSQL 10. It went unnoticed because  
there were no tests triggering the error, so add one.  
  
Reported-by: Mark Dilger  
Backpatch-through: 10, where extended stats were introduced  
Discussion: https://postgr.es/m/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com  

commit   : 983d7033df6e03134572eb75dd76603fb9245211    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 12:02:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Aug 2021 12:02:36 -0400    

When starting to use a query parsetree loaded from the catalogs,  
we must begin by applying AcquireRewriteLocks(), to obtain the same  
relation locks that the parser would have gotten if the query were  
entered interactively, and to do some other cleanup such as dealing  
with later-dropped columns.  New-style SQL functions are just as  
subject to this rule as other stored parsetrees; however, of the  
places dealing with such functions, only init_sql_fcache had gotten  
the memo.  In particular, if we successfully inlined a new-style  
set-returning SQL function that contained any relation references,  
we'd either get an assertion failure or attempt to use those  
relation(s) sans locks.  
  
I also added AcquireRewriteLocks calls to fmgr_sql_validator and  
print_function_sqlbody.  Desultory experiments didn't demonstrate any  
failures in those, but I suspect that I just didn't try hard enough.  
Certainly we don't expect nearby code paths to operate without locks.  
  
On the same logic of it-ought-to-have-the-same-effects-as-the-old-code,  
call pg_rewrite_query() in fmgr_sql_validator, too.  It's possible  
that neither code path there needs to bother with rewriting, but  
doing the analysis to prove that is beyond my goals for today.  
  
Per bug #17161 from Alexander Lakhin.  
  
Discussion: https://postgr.es/m/17161-048a1cdff8422800@postgresql.org  

commit   : eae08e21653c356f0e9223d26379527d653b71ed    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Aug 2021 16:29:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Aug 2021 16:29:12 -0400    

Most data-corruption reports mention the location of the problem, but  
this one failed to.  Add it.  
  
Backpatch all the way back.  In 12 and older, also assign the  
ERRCODE_DATA_CORRUPTED error code as was done in commit fd6ec93bf890 for  
13 and later.  
  
Discussion: https://postgr.es/m/202108191637.oqyzrdtnheir@alvherre.pgsql  

commit   : ce6b662aae7abc8b533b0cfa8fff50a9001508b1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Aug 2021 14:01:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Aug 2021 14:01:29 -0400    

Per our message style guidelines, for human consumption we quote  
qualified names as a whole rather than each part separately; but commits  
bc085205c8a4 introduced a deviation for extended statistics and  
a4d75c86bf15 copied it.  I don't agree with this policy applying to  
names shown by psql, but that's a poor reason to deviate from the  
practice only in two obscure corners, so make said corners use the same  
style as everywhere else.  
  
Backpatch to 14.  The first of these is older, but I'm not sure we want  
to destabilize the psql output in the older branches for such a small  
thing.  
  
Discussion: https://postgr.es/m/20210828181618.GS26465@telsasoft.com  

commit   : efe2382d5ade2c8d63f2aa1b48cc85691a2bfabd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Aug 2021 21:35:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Aug 2021 21:35:24 +0900    

Commit 547f04e734 changed pgbench so that it used the measurement result  
of connection delays in its benchmark report only when -C/--connect option  
is specified. But previously those delays were unnecessarily measured  
even when that option is not specified. Which was a waste of cycles.  
This commit improves pgbench so that it avoids such unnecessary measurement.  
  
Back-patch to v14 where commit 547f04e734 first appeared.  
  
Author: Yugo Nagata  
Reviewed-by: Fabien COELHO, Asif Rehman, Fujii Masao  
Discussion: https://postgr.es/m/20210614151155.a393bc7d8fed183e38c9f52a@sraoss.co.jp  

commit   : 7af5c38eb9da5b0ae72c1dd3d847f43cd39d1f5a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Aug 2021 08:56:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Aug 2021 08:56:16 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 14 development.  
  
current through ed740b06b18e1a23becd54c97ff229aba4c94349  

commit   : 0a143c33f01257a0670af71205343b505f5bd89b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Aug 2021 09:22:28 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Aug 2021 09:22:28 +0530    

ERRCODE_CONFIGURATION_LIMIT_EXCEEDED was used for checksum failure, use  
ERRCODE_DATA_CORRUPTED instead.  
  
Reported-by: Tatsuhito Kasahara  
Author: Tatsuhito Kasahara  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAP0=ZVLHtYffs8SOWcFJWrBGoRzT9QQbk+_aP+E5AHLNXiOorA@mail.gmail.com  

commit   : e1efc5b465c844969a0ed0d07e1364f3ce424d8c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 15:58:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 15:58:23 -0400    

In the long-going saga for analyze on partitioned tables, one thing I  
missed while reverting 0827e8af70f4 is the maintenance of analyze count  
and last analyze time for partitioned tables.  This is a mostly trivial  
change that enables users assess the need for invoking manual ANALYZE on  
partitioned tables.  
  
This patch, posted by Justin and modified a bit by me (Álvaro), can be  
mostly traced back to Hosoya-san, though any problems introduced with  
the scissors are mine.  
  
Backpatch to 14, in line with 6f8127b73901.  
  
Co-authored-by: Yuzuko Hosoya <yuzukohosoya@gmail.com>  
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20210816222810.GE10479@telsasoft.com  

commit   : 359bcf775550aa577c86ea30a6d071487fcca1ed    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 12:04:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 12:04:15 -0400    

Déjà vu of commit fc40ba1296a7, for another backslash command.  
Strictly speaking this isn't a bug, but since all references to catalog  
objects are schema-qualified, we might as well be consistent.  The  
omission first appeared in commit ad600bba0422 and replicated in  
a4d75c86bf15; backpatch to 14.  
  
Author: Justin Pryzby <pryzbyj@telsasoft.com>  
Discussion: https://postgr.es/m/20210827193151.GN26465@telsasoft.com  

commit   : a32860b88f1ffd6ba5b8bc803aecf6bc0f87cf02    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 11:45:47 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 28 Aug 2021 11:45:47 -0400    

Strictly speaking this isn't a bug, but since all references to catalog  
objects are schema-qualified, we might as well be consistent.  The  
omission first appeared in commit 1c5d9270e339, so backpatch to 12.  
  
Author: Justin Pryzby <pryzbyj@telsasoft.com>  
Discussion: https://postgr.es/m/20210827193151.GN26465@telsasoft.com  

commit   : 5513c09c89993cb0b2c1a4222b15722bcf71844b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 27 Aug 2021 23:33:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 27 Aug 2021 23:33:23 -0700    

If the system crashed between CREATE TABLESPACE and the next checkpoint,  
the result could be some files in the tablespace unexpectedly containing  
no rows.  Affected files would be those for which the system did not  
write WAL; see the wal_skip_threshold documentation.  Before v13, a  
different set of conditions governed the writing of WAL; see v12's  
<sect2 id="populate-pitr">.  (The v12 conditions were broader in some  
ways and narrower in others.)  Users may want to audit non-default  
tablespaces for unexpected short files.  The bug could have truncated an  
index without affecting the associated table, and reindexing the index  
would fix that particular problem.  
  
This fixes the bug by making create_tablespace_directories() more like  
TablespaceCreateDbspace().  create_tablespace_directories() was  
recursively removing tablespace contents, reasoning that WAL redo would  
recreate everything removed that way.  That assumption holds for other  
wal_level values.  Under wal_level=minimal, the old approach could  
delete files for which no other copy existed.  Back-patch to 9.6 (all  
supported versions).  
  
Reviewed by Robert Haas and Prabhat Sahu.  Reported by Robert Haas.  
  
Discussion: https://postgr.es/m/CA+TgmoaLO9ncuwvr2nN-J4VEP5XyAcy=zKiHxQzBbFRxxGxm0w@mail.gmail.com  

commit   : e84d4810cd47d83a6a864fa33db74bcc5570dd76    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Aug 2021 19:42:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Aug 2021 19:42:42 -0400    

Somehow, spgist overlooked the need to call pgstat_count_index_scan().  
Hence, pg_stat_all_indexes.idx_scan and equivalent columns never  
became nonzero for an SP-GiST index, although the related per-tuple  
counters worked fine.  
  
This fix works a bit differently from other index AMs, in that the  
counter increment occurs in spgrescan not spggettuple/spggetbitmap.  
It looks like this won't make the user-visible semantics noticeably  
different, so I won't go to the trouble of introducing an is-this-  
the-first-call flag just to make the counter bumps happen in the  
same places.  
  
Per bug #17163 from Christian Quest.  Back-patch to all supported  
versions.  
  
Discussion: https://postgr.es/m/17163-b8c5cc88322a5e92@postgresql.org  

commit   : 9efa998a6403c5fe973ce5801d09ffa63e706eb6    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 27 Aug 2021 19:23:11 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 27 Aug 2021 19:23:11 -0400    

When prefetching pages for ANALYZE, we should be using  
maintenance_io_concurrenty (by calling  
get_tablespace_maintenance_io_concurrency(), not  
get_tablespace_io_concurrency()).  
  
ANALYZE prefetching was introduced in c6fc50c, so back-patch to 14.  
  
Backpatch-through: 14  
Reported-By: Egor Rogov  
Discussion: https://postgr.es/m/9beada99-34ce-8c95-fadb-451768d08c64%40postgrespro.ru  

commit   : 8f6c110349769e2b6375cd01e632199a104dc4a1    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 27 Aug 2021 18:25:34 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 27 Aug 2021 18:25:34 -0400    

Commit 6c3ffd6 added a couple new predefined roles but didn't properly  
wrap the SQL commands mentioned in the description of those roles with  
command tags, so add them now.  
  
Backpatch-through: 14  
Reported-by: Michael Banck  
Discussion: https://postgr.es/m/606d8b1c.1c69fb81.3df04.1a99@mx.google.com  

commit   : 652804ebde82b6bb04b427becbcb4f6bea02ff90    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 27 Aug 2021 22:50:19 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 27 Aug 2021 22:50:19 +0200    

Author: Dave Cramer <davecramer@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CADK3HHLZmqAQZ2ByPDQQ9yhGqax36kksq6sDkV0yYzsxw6ipvQ@mail.gmail.com  

commit   : 6a1095234e0fcfa5c2f618c7c841e8ffe3c6c712    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Aug 2021 13:33:58 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Aug 2021 13:33:58 -0700    

Adjust track_io_timing related logging code added by commit 94d13d474d.  
Make it consistent with other nearby autovacuum and autoanalyze logging  
code by removing logic that suppressed zero millisecond outputs.  
  
log_autovacuum_min_duration log output now reliably shows "read:" and  
"write:" millisecond-based values in its report (when track_io_timing is  
enabled).  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Stephen Frost <sfrost@snowman.net>  
Discussion: https://postgr.es/m/CAH2-WznW0FNxSVQMSRazAMYNfZ6DR_gr5WE78hc6E1CBkkJpzw@mail.gmail.com  
Backpatch: 14-, where the track_io_timing logging was introduced.  

commit   : fd134f374ef7a8cc0b2d878a92dfe2c7088e084b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Aug 2021 13:08:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Aug 2021 13:08:39 -0700    

This order seems more natural.  It starts with details that are  
particular to heap and index data structures, and ends with system-level  
costs incurred during the autovacuum worker's VACUUM/ANALYZE operation.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Discussion: https://postgr.es/m/CAH2-WzkzxK6ahA9xxsOftRtBX_R0swuHZsvo4QUbak1Bz7hb7Q@mail.gmail.com  
Backpatch: 14-, which enhanced the log output in various ways.  

commit   : 3068e45799327298a3f4c22b03db2aa48e2ab0da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Aug 2021 12:18:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Aug 2021 12:18:58 -0400    

Second thoughts about commit 824bf7190: we apply makesearch() to  
an NFA after having determined whether it is a MATCHALL pattern.  
Prepending ".*" doesn't make it non-MATCHALL, but it does change the  
maximum possible match length, and makesearch() failed to update that.  
This has no ill effects given the stylized usage of search NFAs, but  
it seems like it's better to keep the data structure consistent.  In  
particular, fixing this allows more honest handling of the MATCHALL  
check in matchuntil(): we can now assert that maxmatchall is infinity,  
instead of lamely assuming that it should act that way.  
  
In passing, improve the code in dump[c]nfa so that infinite maxmatchall  
is printed as "inf" not a magic number.  

commit   : ba05dfe943046820312eaa20995ffc626936b8be    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 26 Aug 2021 18:42:18 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 26 Aug 2021 18:42:18 -0700    

Add a CHECK_FOR_INTERRUPTS() call to make heap relation verification  
responsive to query cancellations.  
  
Author: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/CAH2-Wzk-9RtQgb2QiuLv8j2O0j9tSFKPmmch5nWSZhguUxvbrw%40mail.gmail.com  
Backpatch: 14-, where amcheck heap verification was introduced.  

commit   : ed740b06b18e1a23becd54c97ff229aba4c94349    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Aug 2021 11:06:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Aug 2021 11:06:34 -0400    

The condition "context_start < context_end" is strictly weaker  
than "context_end - context_start >= 50", so we don't need both.  
Oversight in commit ffd3944ab, noted by tanghy.fnst.  
  
In passing, line-wrap a nearby test to make it more readable.  
  
Discussion: https://postgr.es/m/OS0PR01MB61137C4054774F44E3A9DC89FBC69@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : 11c1239881b399d1fe87186f1f8a10a505d4a692    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 25 Aug 2021 08:32:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 25 Aug 2021 08:32:04 -0400    

Pengchengliu reported an assertion failure in a parallel woker while  
performing a parallel scan using an overflowed snapshot. The proximate  
cause is that TransactionXmin was set to an incorrect value.  The  
underlying cause is incorrect snapshot handling in parallel.c.  
  
In particular, InitializeParallelDSM() was unconditionally calling  
GetTransactionSnapshot(), because I (rhaas) mistakenly thought that  
was always retrieving an existing snapshot whereas, at isolation  
levels less than REPEATABLE READ, it's actually taking a new one. So  
instead do this only at higher isolation levels where there actually  
is a single snapshot for the whole transaction.  
  
By itself, this is not a sufficient fix, because we still need to  
guarantee that TransactionXmin gets set properly in the workers. The  
easiest way to do that seems to be to install the leader's active  
snapshot as the transaction snapshot if the leader did not serialize a  
transaction snapshot. This doesn't affect the results of future  
GetTrasnactionSnapshot() calls since those have to take a new snapshot  
anyway; what we care about is the side effect of setting TransactionXmin.  
  
Report by Pengchengliu. Patch by Greg Nancarrow, except for some comment  
text which I supplied.  
  
Discussion: https://postgr.es/m/002f01d748ac$eaa781a0$bff684e0$@tju.edu.cn  

commit   : a599109e591426689d5f79041af45525b00ef7b2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Aug 2021 10:14:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Aug 2021 10:14:51 +0200    

commit   : 8ab3452df8d5ff26cf52c089b986256b0c02d555    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Aug 2021 15:16:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Aug 2021 15:16:55 +0900    

The same condition was repeated twice when comparing the connection used  
by existing declared statement with the one coming from a fresh DECLARE  
statement.  This had no consequences, but let's keep the code clean.  
Oversight in f576de1.  
  
Author: Shenhao Wang  
Discussion: https://postgr.es/m/OSBPR01MB42149653BC0AB0A49D23C1B8F2C69@OSBPR01MB4214.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : 9d7a80ce0185bd0c38bd973638bb7e9a854cf9f8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Aug 2021 10:10:50 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 25 Aug 2021 10:10:50 +0530    

Commit 325f2ec555 introduced pg_class.relwrite to skip operations on  
tables created as part of a heap rewrite during DDL. It links such  
transient heaps to the original relation OID via this new field in  
pg_class but forgot to do anything about toast tables. So, logical  
decoding was not able to skip operations on internally created toast  
tables. This leads to an error when we tried to decode the WAL for the  
next operation for which it appeared that there is a toast data where  
actually it didn't have any toast data.  
  
To fix this, we set pg_class.relwrite for internally created toast tables  
as well which allowed skipping operations on them during logical decoding.  
  
Author: Bertrand Drouvot  
Reviewed-by: David Zhang, Amit Kapila  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/b5146fb1-ad9e-7d6e-f980-98ed68744a7c@amazon.com  

commit   : 22583edee7f4c6be6894b03c5cd93fd02e2a826a    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 25 Aug 2021 13:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 25 Aug 2021 13:00:01 +0900    

commit   : d207df71f4af7de8e3e865e2635ae3a6b3a98d51    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 09:56:04 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 09:56:04 +0900    

This commit improves the ecpg's error message that commit f576de1db1 updated,  
so that it gets rid of trailing period and uppercases the command name  
in the error message.  
  
Back-patch to v14 where the error message exists.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com  

commit   : ec619102aa56d3356fb6550a343af01ad477e4a2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:46:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:46:25 +0900    

There are two identical error messages about valid value of modulus for  
hash partition, in PostgreSQL source code. Commit 0e1275fb07 improved  
only one of them so that ambiguous word "positive" was avoided there,  
and forgot to improve the other. This commit improves the other.  
Which would reduce translator burden.  
  
Back-pach to v11 where the error message exists.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com  

commit   : 1d0567ec61fbc429a7717ab8d5027952c806a8fb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:43:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Aug 2021 11:43:56 +0900    

The distance in phrase operator must be an integer value between zero  
and MAXENTRYPOS inclusive. But previously the error message about  
its valid value included the information about its upper limit  
but not lower limit (i.e., zero). This commit improves the error message  
so that it also includes the information about its lower limit.  
  
Back-patch to v9.6 where full-text phrase search was supported.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com  

commit   : 244dd79923a16afcf5f9a8dea53fc3af2ac0f7db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Aug 2021 16:37:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Aug 2021 16:37:27 -0400    

Regexps like "(.){0}...\1" drew an "invalid backreference number".  
That's not unreasonable on its face, since the capture group will  
never be matched if it's iterated zero times.  However, other engines  
such as Perl's don't complain about this, nor do we throw an error for  
related cases such as "(.)|\1", even though that backref can never  
succeed either.  Also, if the zero-iterations case happens at runtime  
rather than compile time --- say, "(x)*...\1" when there's no "x" to  
be found --- that's not an error, we just deem the backref to not  
match.  Making this even less defensible, no error was thrown for  
nested cases such as "((.)){0}...\2"; and to add insult to injury,  
those cases could result in assertion failures instead.  (It seems  
that nothing especially bad happened in non-assert builds, though.)  
  
Let's just fix it so that no error is thrown and instead the backref  
is deemed to never match, so that compile-time detection of no  
iterations behaves the same as run-time detection.  
  
Per report from Mark Dilger.  This appears to be an aboriginal error  
in Spencer's library, so back-patch to all supported versions.  
  
Pre-v14, it turns out to also be necessary to back-patch one aspect of  
commits cb76fbd7e/00116dee5, namely to create capture-node subREs with  
the begin/end states of their subexpressions, not the current lp/rp  
of the outer parseqatom invocation.  Otherwise delsub complains that  
we're trying to disconnect a state from itself.  This is a bit scary  
but code examination shows that it's safe: in the pre-v14 code, if we  
want to wrap iteration around the subexpression, the first thing we do  
is overwrite the atom's begin/end fields with new states.  So the  
bogus values didn't survive long enough to be used for anything, except  
if no iteration is required, in which case it doesn't matter.  
  
Discussion: https://postgr.es/m/A099E4A8-4377-4C64-A98C-3DEDDC075502@enterprisedb.com  

commit   : 5cfcd46e9d297eac627bf3183272713112ac5f60    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Aug 2021 08:38:11 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 24 Aug 2021 08:38:11 +0530    

The current refresh behavior tries to just refresh added/dropped  
publications but that leads to removing wrong tables from subscription. We  
can't refresh just the dropped publication because it is quite possible  
that some of the tables are removed from publication by that time and now  
those will remain as part of the subscription. Also, there is a chance  
that the tables that were part of the publication being dropped are also  
part of another publication, so we can't remove those.  
  
So, we decided that by default, add/drop commands will also act like  
REFRESH PUBLICATION which means they will refresh all the publications. We  
can keep the old behavior for "add publication" but it is better to be  
consistent with "drop publication".  
  
Author: Hou Zhijie  
Reviewed-by: Masahiko Sawada, Amit Kapila  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/OS0PR01MB5716935D4C2CC85A6143073F94EF9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 779557bd22895420b48eba409d2286f1dea08c06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Aug 2021 17:41:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Aug 2021 17:41:07 -0400    

The recursion in cdissect() was careless about clearing match data  
for capturing parentheses after rejecting a partial match.  This  
could allow a later back-reference to succeed when by rights it  
should fail for lack of a defined referent.  
  
To fix, think a little more rigorously about what the contract  
between different levels of cdissect's recursion needs to be.  
With the right spec, we can fix this using fewer rather than more  
resets of the match data; the key decision being that a failed  
sub-match is now explicitly responsible for clearing any matches  
it may have set.  
  
There are enough other cross-checks and optimizations in the code  
that it's not especially easy to exhibit this problem; usually, the  
match will fail as-expected.  Plus, regexps that are even potentially  
vulnerable are most likely user errors, since there's just not much  
point in writing a back-ref that doesn't always have a referent.  
These facts perhaps explain why the issue hasn't been detected,  
even though it's almost certainly a couple of decades old.  
  
Discussion: https://postgr.es/m/151435.1629733387@sss.pgh.pa.us  

commit   : e3fb6170e58c4325cd1e1eb22f96ef43c3b4152a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 23 Aug 2021 15:50:35 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 23 Aug 2021 15:50:35 -0400    

WAL records may span multiple segments, but XLogWrite() does not  
wait for the entire record to be written out to disk before  
creating archive status files.  Instead, as soon as the last WAL page of  
the segment is written, the archive status file is created, and the  
archiver may process it.  If PostgreSQL crashes before it is able to  
write and flush the rest of the record (in the next WAL segment), the  
wrong version of the first segment file lingers in the archive, which  
causes operations such as point-in-time restores to fail.  
  
To fix this, keep track of records that span across segments and ensure  
that segments are only marked ready-for-archival once such records have  
been completely written to disk.  
  
This has always been wrong, so backpatch all the way back.  
  
Author: Nathan Bossart <bossartn@amazon.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Ryo Matsumura <matsumura.ryo@fujitsu.com>  
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://postgr.es/m/CBDDFA01-6E40-46BB-9F98-9340F4379505@amazon.com  

commit   : 65b649fecb0c0bd2c2c1f075f94f45a74cdc41be    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Aug 2021 11:09:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Aug 2021 11:09:54 +0900    

In a backup manifest, WAL-Ranges stores the range of WAL that is  
required for the backup to be valid.  pg_verifybackup would then  
internally use pg_waldump for the checks based on this data.  
  
When the timeline where the backup started was more than 1 with a  
history file looked at for the manifest data generation, the calculation  
of the WAL range for the first timeline to check was incorrect.  The  
previous logic used as start LSN the start position of the first  
timeline, but it needs to use the start LSN of the backup.  This would  
cause failures with pg_verifybackup, or any tools making use of the  
backup manifests.  
  
This commit adds a test based on a logic using a self-promoted node,  
making it rather cheap.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20210818.143031.1867083699202617521.horikyota.ntt@gmail.com  
Backpatch-through: 13  

commit   : 8f6a52196aceb11a78eb1d673a03ab3ab72da231    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Aug 2021 10:22:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Aug 2021 10:22:14 -0400    

Improve two places in plpgsql, and one in spi.c, where an error  
message would confusingly tell you that you couldn't use a SELECT  
query, when what you had written *was* a SELECT query.  The actual  
problem is that you can't use SELECT ... INTO in these contexts,  
but the messages failed to make that apparent.  Special-case  
SELECT INTO to make these errors more helpful.  
  
Also, fix the same spots in plpgsql, as well as several messages  
in exec_eval_expr(), to not quote the entire complained-of query or  
expression in the primary error message.  That behavior very easily  
led to violating our message style guideline about keeping the primary  
error message short and single-line.  Also, since the important part  
of the message was after the inserted text, it could make the real  
problem very hard to see.  We can report the query or expression as  
the first line of errcontext instead.  
  
Per complaint from Roger Mason.  Back-patch to v14, since (a) some  
of these messages are new in v14 and (b) v14's translatable strings  
are still somewhat in flux.  The problem's older than that of  
course, but I'm hesitant to change the behavior further back.  
  
Discussion: https://postgr.es/m/1914708.1629474624@sss.pgh.pa.us  

commit   : 57a2d4a1b3bb48ec422a2701f8df026123a98a27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Aug 2021 14:19:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Aug 2021 14:19:04 -0400    

After detecting a sub-match "dissect" failure (i.e., a backref match  
failure) in the i'th sub-match of an iteration node, we should proceed  
by adjusting the attempted length of the i'th submatch.  As coded,  
though, these functions changed the attempted length of the *last*  
sub-match, and only after exhausting all possibilities for that would  
they back up to adjust the next-to-last sub-match, and then the  
second-from-last, etc; all of which is wasted effort, since only  
changing the start or length of the i'th sub-match can possibly make  
it succeed.  This oversight creates the possibility for exponentially  
bad performance.  Fortunately the problem is masked in most cases by  
optimizations or constraints applied elsewhere; which explains why  
we'd not noticed it before.  But it is possible to reach the problem  
with fairly simple, if contrived, regexps.  
  
Oversight in my commit 173e29aa5.  That's pretty ancient now,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/1808998.1629412269@sss.pgh.pa.us  

commit   : 92ce7f527960ca672d2ad70e61442f4e5b3bb641    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 20 Aug 2021 12:44:54 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 20 Aug 2021 12:44:54 +0200    

Using --quiet in combination with --no-strict-names didn't work as  
documented, a warning message was still emitted. Since the --quiet  
flag was working in an unconventional way to other utilities, fix  
by removing the functionality instead.  
  
Backpatch through 14 where pg_amcheck was introduced.  
  
Bug: 17148  
Reported-by: Chen Jiaoqian <chenjq.jy@fujitsu.com>  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/17148-b5087318e2b04fc6@postgresql.org  
Backpatch-through: 14  

commit   : 88cfcbb79f8064705362d8cfc0dff23d3c16195f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Aug 2021 07:48:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Aug 2021 07:48:22 +0200    

The previous code wouldn't handle higher block numbers on systems  
where sizeof(long) == 4.  
  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/6a10a211-872b-3c4c-106b-909ae5fefa61%40enterprisedb.com  

commit   : 4649003933522282f03643c5a50fd2eb2a31a783    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Aug 2021 12:12:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Aug 2021 12:12:35 -0400    

transformLockingClause neglected to exclude the pseudo-RTEs for  
OLD/NEW when processing a rule's query.  This led to odd errors  
or even crashes later on.  This bug is very ancient, but it's  
not terribly surprising that nobody noticed, since the use-case  
for SELECT FOR UPDATE in a non-view rule is somewhere between  
thin and non-existent.  Still, crashing is not OK.  
  
Per bug #17151 from Zhiyong Wu.  Thanks to Masahiko Sawada  
for analysis of the problem.  
  
Discussion: https://postgr.es/m/17151-c03a3e6e4ec9aadb@postgresql.org  

commit   : 18914f24ec6e704e81a5528cf09f3d54b23ef12b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Aug 2021 04:59:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Aug 2021 04:59:06 -0700    

Previously log messages late during shutdown could end up using either another  
backend's PgBackendStatus (multi user) or segfault (single user) because  
pgstat_get_my_query_id()'s check for !MyBEEntry didn't filter out use after  
pgstat_beshutdown_hook().  
  
This became a bug in 4f0b0966c86, but was a bit fishy before. But given  
there's no known problematic cases before 14, it doesn't seem worth  
backpatching further.  
  
Also fixes a wrong filename in a comment, introduced in e1025044.  
  
Reported-By: Andres Freund <andres@anarazel.de>  
Reviewed-By: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://postgr.es/m/Julien Rouhaud <rjuju123@gmail.com>  
Backpatch: 14-  

commit   : e1915646658def5dd87331ac77fb9d8d0abd763b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Aug 2021 09:05:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Aug 2021 09:05:54 +0530    

The 'Stream Stop' message is misspelled as 'Stream End' in the docs.  
  
Author: Masahiko Sawada  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com  

commit   : 1900c140554efdcaa94134705e9be7ce1437be9c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Aug 2021 09:20:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Aug 2021 09:20:19 +0900    

This is a combined revert of the following commits:  
- c3826f8, a refactoring piece that moved the hex decoding code to  
src/common/.  This code was cleaned up by aef8948, as it originally  
included no overflow checks in the same way as the base64 routines in  
src/common/ used by SCRAM, making it unsafe for its purpose.  
- aef8948, a more advanced refactoring of the hex encoding/decoding code  
to src/common/ that added sanity checks on the result buffer for hex  
decoding and encoding.  As reported by Hans Buschmann, those overflow  
checks are expensive, and it is possible to see a performance drop in  
the decoding/encoding of bytea or LOs the longer they are.  Simple SQLs  
working on large bytea values show a clear difference in perf profile.  
- ccf4e27, a cleanup made possible by aef8948.  
  
The reverts of all those commits bring back the performance of hex  
decoding and encoding back to what it was in ~13.  Fow now and  
post-beta3, this is the simplest option.  
  
Reported-by: Hans Buschmann  
Discussion: https://postgr.es/m/1629039545467.80333@nidsa.net  
Backpatch-through: 14  

commit   : 61f9dae2ce7680d51035e5bb8668cf5227346eac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Aug 2021 18:12:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Aug 2021 18:12:51 -0400    

Recursion into the FILTER clause was mis-implemented, such that a  
relevant Var or Aggref at the very top of the FILTER clause would  
be ignored.  (Of course, that'd have to be a plain boolean Var or  
boolean-returning aggregate.)  The consequence would be  
mis-identification of the correct semantic level of the aggregate,  
which could lead to not-per-spec query behavior.  If the FILTER  
expression is an aggregate, this could also lead to failure to issue  
an expected "aggregate function calls cannot be nested" error, which  
would likely result in a core dump later on, since the planner and  
executor aren't expecting such cases to appear.  
  
The root cause is that commit b560ec1b0 blindly copied some code  
that assumed it's recursing into a List, and thus didn't examine the  
top-level node.  To forestall questions about why this call doesn't  
look like the others, as well as possible future copy-and-paste  
mistakes, let's change all three check_agg_arguments_walker calls in  
check_agg_arguments, even though only the one for the filter clause  
is really broken.  
  
Per bug #17152 from Zhiyong Wu.  This has been wrong since we  
implemented FILTER, so back-patch to all supported versions.  
(Testing suggests that pre-v11 branches manage to avoid crashing  
in the bad-Aggref case, thanks to "redundant" checks in ExecInitAgg.  
But I'm not sure how thorough that protection is, and anyway the  
wrong-behavior issue remains, so fix 9.6 and 10 too.)  
  
Discussion: https://postgr.es/m/17152-c7f906cc1a88e61b@postgresql.org  

commit   : 5310c61ecc14f23d28429f055c968a97d5e8b39c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 18 Aug 2021 11:23:43 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Wed, 18 Aug 2021 11:23:43 +0200    

The skip options set for all-visible and all-frozen were incorrect  
as they used space rather than hyphen, causing a syntax error when  
invoked. Also, the option for not skipping any pages at all, none,  
was documented but not implemented.  
  
Backpatch through 14 where pg_amcheck was introduced.  
  
Bug: #17149  
Reported-by: Chen Jiaoqian <chenjq.jy@fujitsu.com>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/17149-5918ea748da36b15@postgresql.org  
Backpatch-through: 14  

commit   : 8f51ee63df3a9022cfd07d7482b8f3f21ff8f46d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Aug 2021 14:29:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Aug 2021 14:29:22 -0400    

If recordDependencyOnCurrentExtension is invoked on a pre-existing,  
free-standing object during an extension update script, that object  
will become owned by the extension.  In our current code this is  
possible in three cases:  
  
* Replacing a "shell" type or operator.  
* CREATE OR REPLACE overwriting an existing object.  
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.  
  
The first of these cases is intentional behavior, as noted by the  
existing comments for GenerateTypeDependencies.  It seems like  
appropriate behavior for CREATE OR REPLACE too; at least, the obvious  
alternatives are not better.  However, the fact that it happens during  
ALTER is an artifact of trying to share code (GenerateTypeDependencies  
and makeOperatorDependencies) between the CREATE and ALTER cases.  
Since an extension script would be unlikely to ALTER an object that  
didn't already belong to the extension, this behavior is not very  
troubling for the direct target object ... but ALTER TYPE SET will  
recurse to dependent domains, and it is very uncool for those to  
become owned by the extension if they were not already.  
  
Let's fix this by redefining the ALTER cases to never change extension  
membership, full stop.  We could minimize the behavioral change by  
only changing the behavior when ALTER TYPE SET is recursing to a  
domain, but that would complicate the code and it does not seem like  
a better definition.  
  
Per bug #17144 from Alex Kozhemyakin.  Back-patch to v13 where ALTER  
TYPE SET was added.  (The other cases are older, but since they only  
affect the directly-named object, there's not enough of a problem to  
justify changing the behavior further back.)  
  
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org  

commit   : e2d6da0708df2c2e244d8748c26ebc49c0963ed5    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 17 Aug 2021 14:58:33 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 17 Aug 2021 14:58:33 +0200    

commit   : b88377ad65dfa714e1bd1c041421446065c07c9c    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 17 Aug 2021 14:27:37 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Tue, 17 Aug 2021 14:27:37 +0200    

In OpenSSL there are two types of BIO's (I/O abstractions):  
source/sink and filters. A source/sink BIO is a source and/or  
sink of data, ie one acting on a socket or a file. A filter  
BIO takes a stream of input from another BIO and transforms it.  
In order for BIO_find_type() to be able to traverse the chain  
of BIO's and correctly find all BIO's of a certain type they  
shall have the type bit set accordingly, source/sink BIO's  
(what PostgreSQL implements) use BIO_TYPE_SOURCE_SINK and  
filter BIO's use BIO_TYPE_FILTER. In addition to these, file  
descriptor based BIO's should have the descriptor bit set,  
BIO_TYPE_DESCRIPTOR.  
  
The PostgreSQL implementation didn't set the type bits, which  
went unnoticed for a long time as it's only really relevant  
for code auditing the OpenSSL installation, or doing similar  
tasks. It is required by the API though, so this fixes it.  
  
Backpatch through 9.6 as this has been wrong for a long time.  
  
Author: Itamar Gafni  
Discussion: https://postgr.es/m/SN6PR06MB39665EC10C34BB20956AE4578AF39@SN6PR06MB3966.namprd06.prod.outlook.com  
Backpatch-through: 9.6  

commit   : f90c05959ec3fb712cba889817e0a0689fa6fa89    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 17 Aug 2021 10:00:06 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 17 Aug 2021 10:00:06 +0300    

The backslash sequences, including \123 and \x12 escapes, are interpreted  
after encoding conversion. The docs failed to mention that.  
  
Backpatch to all supported versions.  
  
Reported-by: Andreas Grob  
Discussion: https://www.postgresql.org/message-id/17142-9181542ca1df75ab%40postgresql.org  

commit   : b3d24cc0f0aa882ceec0a74a99f94166c6fc3247    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Aug 2021 17:27:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Aug 2021 17:27:52 -0400    

This reverts the following commits:  
1b5617eb844cd2470a334c1d2eec66cf9b39c41a Describe (auto-)analyze behavior for partitioned tables  
0e69f705cc1a3df273b38c9883fb5765991e04fe Set pg_class.reltuples for partitioned tables  
41badeaba8beee7648ebe7923a41c04f1f3cb302 Document ANALYZE storage parameters for partitioned tables  
0827e8af70f4653ba17ed773f123a60eadd9f9c9 autovacuum: handle analyze for partitioned tables  
  
There are efficiency issues in this code when handling databases with  
large numbers of partitions, and it doesn't look like there isn't any  
trivial way to handle those.  There are some other issues as well.  It's  
now too late in the cycle for nontrivial fixes, so we'll have to let  
Postgres 14 users continue to manually deal with ANALYZE their  
partitioned tables, and hopefully we can fix the issues for Postgres 15.  
  
I kept [most of] be280cdad298 ("Don't reset relhasindex for partitioned  
tables on ANALYZE") because while we added it due to 0827e8af70f4, it is  
a good bugfix in its own right, since it affects manual analyze as well  
as autovacuum-induced analyze, and there's no reason to revert it.  
  
I retained the addition of relkind 'p' to tables included by  
pg_stat_user_tables, because reverting that would require a catversion  
bump.  
Also, in pg14 only, I keep a struct member that was added to  
PgStat_TabStatEntry to avoid breaking compatibility with existing stat  
files.  
  
Backpatch to 14.  
  
Discussion: https://postgr.es/m/20210722205458.f2bug3z6qzxzpx2s@alap3.anarazel.de  

commit   : f83d80ea1e57927471848d901843ddc6fd5ecacc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Aug 2021 12:11:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 16 Aug 2021 12:11:49 +0900    

This commit ensures that the wait interval in the replay delay loop  
waiting for an amount of time defined by recovery_min_apply_delay is  
correctly handled on reload, recalculating the delay if this GUC value  
is updated, based on the timestamp of the commit record being replayed.  
  
The previous behavior would be problematic for example with replay  
still waiting even if the delay got reduced or just cancelled.  If the  
apply delay was increased to a larger value, the wait would have just  
respected the old value set, finishing earlier.  
  
Author: Soumyadeep Chakraborty, Ashwin Agrawal  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 4ffbd55d9346b6a8ba391c6df9a0f692c4b61ace    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Aug 2021 13:58:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Aug 2021 13:58:47 -0400    

Like the ARM case, just use gcc's __sync_lock_test_and_set();  
that will compile into AMOSWAP.W.AQ which does what we need.  
  
At some point it might be worth doing some work on atomic ops  
for RISC-V, but this should be enough for a creditable port.  
  
Back-patch to all supported branches, just in case somebody  
wants to try them on RISC-V.  
  
Marek Szuba  
  
Discussion: https://postgr.es/m/dea97b6d-f55f-1f6d-9109-504aa7dfa421@gentoo.org  

commit   : e546d1d052f220b077cf4d9fee8e6d5bf85911c5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 Aug 2021 17:15:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 13 Aug 2021 17:15:03 +0200    

commit   : a945f5527322d18d02990a9772a893f741e7d8df    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 13 Aug 2021 10:34:04 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 13 Aug 2021 10:34:04 +0200    

After binding a statement to a connection with DECLARE STATEMENT the connection  
was still not used for DEALLOCATE and DESCRIBE statements. This patch fixes  
that, adds a missing warning and cleans up the code.  
  
Author: Hayato Kuroda  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/TYAPR01MB5866BA57688DF2770E2F95C6F5069%40TYAPR01MB5866.jpnprd01.prod.outlook.com  

commit   : ffff00a3556734f859f375b8c76c89f1d2920bcd    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Aug 2021 10:32:16 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Fri, 13 Aug 2021 10:32:16 +0200    

The check for sslsni only checked for existence of the parameter  
but not for the actual value of the param.  This meant that the  
SNI extension was always turned on.  Fix by inspecting the value  
of sslsni and only activate the SNI extension iff sslsni has been  
enabled.  Also update the docs to be more in line with how other  
boolean params are documented.  
  
Backpatch to 14 where sslsni was first implemented.  
  
Reviewed-by: Tom Lane  
Backpatch-through: 14, where sslni was added  

commit   : dc23c77d07af086574124ea5ca65acf9360b8691    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 13 Aug 2021 16:41:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 13 Aug 2021 16:41:56 +1200    

This fixes a bug in simplehash.h which caused an incorrect size mask to be  
used when the hash table grew to SH_MAX_SIZE (2^32).  The code was  
incorrectly setting the size mask to 0 when the hash tables reached the  
maximum possible number of buckets.  This would result always trying to  
use the 0th bucket causing an  infinite loop of trying to grow the hash  
table due to there being too many collisions.  
  
Seemingly it's not that common for simplehash tables to ever grow this big  
as this bug dates back to v10 and nobody seems to have noticed it before.  
However, probably the most likely place that people would notice it would  
be doing a large in-memory Hash Aggregate with something close to at least  
2^31 groups.  
  
After this fix, the code now works correctly with up to within 98% of 2^32  
groups and will fail with the following error when trying to insert any  
more items into the hash table:  
  
ERROR:  hash table size exceeded  
  
However, the work_mem (or hash_mem_multiplier in newer versions) settings  
will generally cause Hash Aggregates to spill to disk long before reaching  
that many groups.  The minimal test case I did took a work_mem setting of  
over 192GB to hit the bug.  
  
simplehash hash tables are used in a few other places such as Bitmap Index  
Scans, however, again the size that the hash table can become there is  
also limited to work_mem and it would take a relation of around 16TB  
(2^31) pages and a very large work_mem setting to hit this.  With smaller  
work_mem values the table would become lossy and never grow large enough  
to hit the problem.  
  
Author: Yura Sokolov  
Reviewed-by: David Rowley, Ranier Vilela  
Discussion: https://postgr.es/m/b1f7f32737c3438136f64b26f4852b96@postgrespro.ru  
Backpatch-through: 10, where simplehash.h was added  

commit   : 8201b60565b8da465e75da4e4c6d2f01bf976a43    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Aug 2021 10:38:22 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 13 Aug 2021 10:38:22 +1200    

It's hard to disable ASLR on current macOS releases, for testing with  
-DEXEC_BACKEND.  You could already set the environment variable  
PG_SHMEM_ADDR to something not likely to collide with mappings created  
earlier in process startup.  Let's also provide a default value that  
works on current releases and architectures, for developer convenience.  
  
As noted in the pre-existing comment, this is a horrible hack, but  
-DEXEC_BACKEND is only used by Unix-based PostgreSQL developers for  
testing some otherwise Windows-only code paths, so it seems excusable.  
  
Back-patch to all supported branches.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de  

commit   : 886531f3f403cae67a4537f0a2a1edc730f6b793    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 12 Aug 2021 21:32:53 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 12 Aug 2021 21:32:53 +0200    

The FDW batching code was using the same tuple descriptor both for all  
slots (regular and plan slots), but that's incorrect - the subplan may  
use a different descriptor. Currently this is benign, because batching  
is used only for INSERTs, and in that case the descriptors always match.  
But that would change if we allow batching UPDATEs.  
  
Fix by copying the appropriate tuple descriptor. Backpatch to 14, where  
the FDW batching was implemented.  
  
Author: Amit Langote  
Backpatch-through: 14, where FDW batching was added  
Discussion: https://postgr.es/m/CA%2BHiwqEWd5B0-e-RvixGGUrNvGkjH2s4m95%3DJcwUnyV%3Df0rAKQ%40mail.gmail.com  

commit   : 6458ed18fe40ac91f29496128dd1a49c0ef2db5b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 12 Aug 2021 11:02:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 12 Aug 2021 11:02:29 +0300    

It's not sensible to re-evaluate a direct-modify Foreign Update or Delete  
during EvalPlanQual. However, ExecInitForeignScan() can still get called  
if a table mixes local and foreign partitions. EvalPlanQualStart() left  
the es_result_relations array uninitialized in the child EPQ EState, but  
ExecInitForeignScan() still expected to find it. That caused a segfault.  
  
Fix by skipping the es_result_relations lookup during EvalPlanQual  
processing. To make things a bit more robust, also skip the  
BeginDirectModify calls, and add a runtime check that ExecForeignScan()  
is not called on direct-modify foreign scans during EvalPlanQual  
processing.  
  
This is new in v14, commit 1375422c782. Before that, EvalPlanQualStart()  
copied the whole ResultRelInfo array to the EPQ EState. Backpatch to v14.  
  
Report and diagnosis by Andrey Lepikhov.  
  
Discussion: https://www.postgresql.org/message-id/cb2b808d-cbaa-4772-76ee-c8809bafcf3d%40postgrespro.ru  

commit   : a4957b5a72dc9e169b78604f67357bb3dc49d826    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Aug 2021 18:10:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Aug 2021 18:10:30 -0400    

As a result of confusion about whether the "char" type is signed or  
unsigned, scans for index searches like "col < 'x'" or "col <= 'x'"  
would start at the middle of the index not the left end, thus missing  
many or all of the entries they should find.  Fortunately, this  
is not a symptom of index corruption.  It's only the search logic  
that is broken, and we can fix it without unpleasant side-effects.  
  
Per report from Jason Kim.  This has been wrong since btree_gin's  
beginning, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20210810001649.htnltbh7c63re42p@jasonk.me  

commit   : 26f5391df63445692c88e4540dcbb558e567044c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Aug 2021 16:47:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Aug 2021 16:47:06 -0400    

commit   : 7f7a9c20621f52867100fa3acfb4d453004ed924    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Aug 2021 11:51:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Aug 2021 11:51:59 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 1234b3cdae465246e534cc4114129f18d3c04c38  

commit   : b5815dd00ad32b413070b088d083754d7ec42d37    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Aug 2021 16:46:49 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Aug 2021 16:46:49 +1200    

In ec34040af I added a mention that there was no point in setting  
maintenance_work_limit to anything higher than 1GB for vacuum, but that  
was incorrect as ginInsertCleanup() also looks at what  
maintenance_work_mem is set to during VACUUM and that's not limited to  
1GB.  
  
Here I attempt to make it more clear that the limitation is only around  
the number of dead tuple identifiers that we can collect during VACUUM.  
  
I've also added a note to autovacuum_work_mem to mention this limitation.  
I didn't do that in ec34040af as I'd had some wrong-headed ideas about  
just limiting the maximum value for that GUC to 1GB.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com  
Backpatch-through: 9.6, same as ec34040af  

commit   : c26552f4fc4fb72c64103ea877ea3c2a251856ad    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Aug 2021 15:46:28 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 9 Aug 2021 15:46:28 +1200    

This saves a few lines of code.  Also add a comment to mention why we use  
ExplainPropertyInteger instead of ExplainPropertyUInteger given that  
queryid is a uint64 type.  
  
Author: David Rowley  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/CAApHDvqhSLYpSU_EqUdN39w9Uvb8ogmHV7_3YhJ0S3aScGBjsg@mail.gmail.com  
Backpatch-through: 14, where this code was originally added  

commit   : 9268fc34526427a48bc27b5ac4727c7fb4cddf7a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 8 Aug 2021 21:05:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 8 Aug 2021 21:05:46 -0400    

Since commit e462856a7a, pg_upgrade automatically creates a script to  
update extensions, so mention that instead of ALTER EXTENSION.  
  
Backpatch-through: 9.6  

commit   : c905e64d42fe0725ab7fe84b70a41b4c381aee07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 15:35:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 15:35:30 -0400    

Copy-and-pasteo in 665c5855e, evidently.  The 9.6 docs toolchain  
whined about duplicate index entries, though our modern toolchain  
doesn't.  In any case, these GUCs surely are not about the  
default settings of these values.  

commit   : 5227d99896726b3c889e388f14a3593e104e36ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 11:56:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Aug 2021 11:56:29 -0400    

I had committer's remorse almost immediately after pushing cb76fbd7e,  
upon finding that removing capturing subexpressions' subREs from the  
data structure broke my proposed patch for REG_NOSUB optimization.  
Revert that data structure change.  Instead, address the concern  
about not changing capturing subREs' endpoints by not changing the  
endpoints.  We don't need to, because the point of that bit was just  
to ensure that the atom has endpoints distinct from the outer state  
pair that we're stringing the branch between.  We already made  
suitable states in the parenthesized-subexpression case, so the  
additional ones were just useless overhead.  This seems more  
understandable than Spencer's original coding, and it ought to be  
a shade faster too by saving a few state creations and arc changes.  
(I actually see a couple percent improvement on Jacobson's web  
corpus, though that's barely above the noise floor so I wouldn't  
put much stock in that result.)  
  
Also, fix the logic added by ea1268f63 to ensure that the subRE  
recorded in v->subs[subno] is exactly the one with capno == subno.  
Spencer's original coding recorded the child subRE of the capture  
node, which is okay so far as having the right endpoint states is  
concerned, but as of cb76fbd7e the capturing subRE itself always  
has those endpoints too.  I think the inconsistency is confusing  
for the REG_NOSUB optimization.  
  
As before, backpatch to v14.  
  
Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com  

commit   : 5e6ad63c6db79a5515e7a4117b5de053530fd7d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 22:27:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 22:27:02 -0400    

Up to now, we remembered the definition of a capturing parenthesis  
subexpression by storing a pointer to the associated subRE node.  
That was okay before, because that subRE didn't get modified anymore  
while parsing the rest of the regexp.  However, in the wake of  
commit ea1268f63, that's no longer true: the outer invocation of  
parseqatom() feels free to scribble on that subRE.  This seems to  
work anyway, because the states we jam into the child atom in the  
"prepare a general-purpose state skeleton" stanza aren't really  
semantically different from the original endpoints of the child atom.  
But that would be mighty easy to break, and it's definitely not how  
things worked before.  
  
Between this and the issue fixed in the prior commit, it seems best  
to get rid of this dependence on subRE nodes entirely.  We don't need  
the whole child subRE for future backrefs, only its starting and ending  
NFA states; so let's just store pointers to those.  
  
Also, in the corner case where we make an extra subRE to handle  
immediately-nested capturing parentheses, it seems like it'd be smart  
to have the extra subRE have the same begin/end states as the original  
child subRE does (s/s2 not lp/rp).  I think that linking it from lp to  
rp might actually be semantically wrong, though since Spencer's original  
code did it that way, I'm not totally certain.  Using s/s2 is certainly  
not wrong, in any case.  
  
Per report from Mark Dilger.  Back-patch to v14 where the problematic  
patches came in.  
  
Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com  

commit   : f42ea8350db22725a251e98a5dafb4d2539c800f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 22:05:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 22:05:27 -0400    

Commit cebc1d34e taught parseqatom() to optimize cases where a branch  
contains only one, "messy", atom by getting rid of excess subRE nodes.  
The way we really should do that is to keep the subRE built for the  
"messy" child atom; but to avoid changing parseqatom's nominal API,  
I made it delete that node after copying its fields to the outer subRE  
made by parsebranch().  It seems that that actually worked at the time;  
but it became dangerous after ea1268f63, because that later commit  
allowed the lower invocation of parse() to return a subRE that was also  
pointed to by some v->subs[] entry.  This meant we could wind up with a  
dangling pointer in v->subs[], allowing a later backref to misbehave,  
but only if that subRE struct had been reused in between.  So the damage  
seems confined to cases like '((...))...(...\2'.  
  
To fix, do what I should have done before and modify parseqatom's API  
to make it possible for it to remove the caller's subRE instead of the  
callee's.  That's safer because we know that subRE isn't complete yet,  
so noplace else will have a pointer to it.  
  
Per report from Mark Dilger.  Back-patch to v14 where the problematic  
patches came in.  
  
Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com  

commit   : 51b95fb257a24aa4186960be8abc277774466218    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Aug 2021 20:34:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Aug 2021 20:34:49 +0200    

commit   : 2c915905e3e82b1db28dce8630f8d20b3db316f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 13:29:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Aug 2021 13:29:32 -0400    

Rather than trying to pick table aliases that won't conflict with  
any possible user-defined matview column name, adjust the queries'  
syntax so that the aliases are only used in places where they can't be  
mistaken for column names.  Mostly this consists of writing "alias.*"  
not just "alias", which adds clarity for humans as well as machines.  
We do have the issue that "SELECT alias.*" acts differently from  
"SELECT alias", but we can use the same hack ruleutils.c uses for  
whole-row variables in SELECT lists: write "alias.*::compositetype".  
  
We might as well revert to the original aliases after doing this;  
they're a bit easier to read.  
  
Like 75d66d10e, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us  

commit   : 9b0d71725eb2ca6ea0aaffdc38be599b90e7dc56    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Aug 2021 13:36:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Aug 2021 13:36:59 +0200    

commit   : d954019f0a60bb989ef6fe8e478b764d0d5f301c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Aug 2021 12:09:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 7 Aug 2021 12:09:22 +0200    

commit   : e5f6493e3584ea7eec1f992f87639e7f186ae03e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Aug 2021 17:32:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Aug 2021 17:32:54 -0400    

Casting a value that's already of a type with a specific typmod  
to an unspecified typmod doesn't do anything so far as run-time  
behavior is concerned.  However, it really ought to change the  
exposed type of the expression to match.  Up to now,  
coerce_type_typmod hasn't bothered with that, which creates gotchas  
in contexts such as recursive unions.  If for example one side of  
the union is numeric(18,3), but it needs to be plain numeric to  
match the other side, there's no direct way to express that.  
  
This is easy enough to fix, by inserting a RelabelType to update the  
exposed type of the expression.  However, it's a bit nervous-making  
to change this behavior, because it's stood for a really long time.  
(I strongly suspect that it's like this in part because the logic  
pre-dates the introduction of RelabelType in 7.0.  The commit log  
message for 57b30e8e2 is interesting reading here.)  As a compromise,  
we'll sneak the change into 14beta3, and consider back-patching to  
stable branches if no complaints emerge in the next three months.  
  
Discussion: https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com  

commit   : 0325565702d8fd18ba66cdeaad4d7f43744525b2    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Aug 2021 21:30:25 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 Aug 2021 21:30:25 +0100    

Formerly, the numeric code tested whether an integer value of a larger  
type would fit in a smaller type by casting it to the smaller type and  
then testing if the reverse conversion produced the original value.  
That's perfectly fine, except that it caused a test failure on  
buildfarm animal castoroides, most likely due to a compiler bug.  
  
Instead, do these tests by comparing against PG_INT16/32_MIN/MAX. That  
matches existing code in other places, such as int84(), which is more  
widely tested, and so is less likely to go wrong.  
  
While at it, add regression tests covering the numeric-to-int8/4/2  
conversions, and adjust the recently added tests to the style of  
434ddfb79a (on the v11 branch) to make failures easier to diagnose.  
  
Per buildfarm via Tom Lane, reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us  

commit   : c3a135b41eed3c719a0c34b8cc072835ff21b129    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Aug 2021 22:11:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Aug 2021 22:11:02 +0200    

commit   : acd6b6e637fb670003d4ac2477212b4d51016f9a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Aug 2021 20:55:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Aug 2021 20:55:59 +0200    

commit   : 64b7a8353214a3fa84942366ffb66b36c7f3d2e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Aug 2021 19:09:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Aug 2021 19:09:24 -0400    

Now that this has been back-patched, it's no longer a new feature  
for v14.  

commit   : 588d3f597c67fac6191658c3befc3b9120772905    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 5 Aug 2021 20:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 5 Aug 2021 20:00:01 +0900    

postgres_fdw imported generated columns from the remote tables as plain  
columns, and caused failures like "ERROR: cannot insert a non-DEFAULT  
value into column "foo"" when inserting into the foreign tables, as it  
tried to insert values into the generated columns.  To fix, we do the  
following under the assumption that generated columns in a postgres_fdw  
foreign table are defined so that they represent generated columns in  
the underlying remote table:  
  
* Send DEFAULT for the generated columns to the foreign server on insert  
  or update, not generated column values computed on the local server.  
* Add to postgresImportForeignSchema() an option "import_generated" to  
  include column generated expressions in the definitions of foreign  
  tables imported from a foreign server.  The option is true by default.  
  
The assumption seems reasonable, because that would make a query of the  
postgres_fdw foreign table return values for the generated columns that  
are consistent with the generated expression.  
  
While here, fix another issue in postgresImportForeignSchema(): it tried  
to include column generated expressions as column default expressions in  
the foreign table definitions when the import_default option was enabled.  
  
Per bug #16631 from Daniel Cherniy.  Back-patch to v12 where generated  
columns were added.  
  
Discussion: https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org  

commit   : ecbdbdfd9056a55e38f7922565c7ce46b1321907    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 5 Aug 2021 09:27:35 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 5 Aug 2021 09:27:35 +0100    

This fixes a long-standing bug when using to_char() to format a  
numeric value in scientific notation -- if the value's exponent is  
less than -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001), it produced a  
division-by-zero error.  
  
The reason for this error was that get_str_from_var_sci() divides its  
input by 10^exp, which it produced using power_var_int(). However, the  
underflow test in power_var_int() causes it to return zero if the  
result scale is too small. That's not a problem for power_var_int()'s  
only other caller, power_var(), since that limits the rscale to 1000,  
but in get_str_from_var_sci() the exponent can be much smaller,  
requiring a much larger rscale. Fix by introducing a new function to  
compute 10^exp directly, with no rscale limit. This also allows 10^exp  
to be computed more efficiently, without any numeric multiplication,  
division or rounding.  
  
Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com  

commit   : fa604e0dd07a39ba34f93d06ded8243280dffdeb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Aug 2021 19:19:44 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Aug 2021 19:19:44 -0700    

Up to now we did a PQconsumeInput() for each pipelined query, asking the OS  
for more input - which it often won't have, as all results might already have  
been sent. That turns out to have a noticeable performance impact.  
  
Alvaro Herrera reviewed the idea to add the PQisBusy() check, but not this  
concrete patch.  
  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/20210720180039.23rivhdft3l4mayn@alap3.anarazel.de  
Backpatch: 14, where libpq/pgbench pipelining was introduced.  

commit   : e8086bd3ba0ab73a18ac2293dd14f488734126ec    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 3 Aug 2021 21:53:40 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 3 Aug 2021 21:53:40 -0700    

Oversight in commit 3499df0d, which generalized the reloption as a way  
of giving users a way to consistently avoid VACUUM's index bypass  
optimization.  
  
Per off-list report from Nikolay Shaplov.  
  
Backpatch: 14-, where index cleanup reloption was extended.  

commit   : 3a0ba31a32f2def545399549c2ace6951f98e47c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:26:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:26:08 -0400    

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com  
  
Backpatch-through: 9.6  

commit   : 2c92bae3e944d7159611e3010c34fd91b696a27f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:17:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 12:17:58 -0400    

Units are _truncated_ to months, but only in back branches since the  
recent commit.  
  
Reported-by: Bryn Llewellyn  
  
Discussion: https://postgr.es/m/BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com  
  
Backpatch-through: 9.6 to 14  

commit   : 4051a7775752bb6643b2fef45f30142b65726b1a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:58:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:58:15 -0400    

Also create a script that can be run to update them.  
  
Reported-by: Dave Cramer  
  
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com  
  
Backpatch-through: 9.6  

commit   : 9f6215b4c9e1f208a520c255eff7c6c1dece93c9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:27:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:27:33 -0400    

The previous wording was unclear about the steps needed to upgrade  
extensions, and how to update them after pg_upgrade.  
  
Reported-by: Dave Cramer  
  
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com  
  
Backpatch-through: 9.6  

commit   : c362570e83ab08e41e18437e158a8542dd8c3556    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:11:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 11:11:51 -0400    

Previously tableoid was not mentioned in the partition doc section.  We  
only had a link to the "all the normal rules" of inheritance section.  
  
Reported-by: michal.palenik@freemap.sk  
  
Discussion: https://postgr.es/m/162627031219.693.11508199541771263335@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 924e1d0da958c82b79b225b43672532f9f36df9b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 10:57:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Aug 2021 10:57:32 -0400    

This is only possible with GNU split, not other versions like BSD split.  
  
Reported-by: jim@jdoherty.net  
  
Discussion: https://postgr.es/m/162653459215.701.6323855956817776386@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : fb234086fe81fb1848934b6e1f6382611fc9ad4f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 2 Aug 2021 12:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 2 Aug 2021 12:45:01 +0900    

I failed to account for the possibility that when  
ExecAppendAsyncEventWait() notifies multiple async-capable nodes using  
postgres_fdw, a preceding node might invoke process_pending_request() to  
process a pending asynchronous request made by a succeeding node.  In  
that case the succeeding node should produce a tuple to return to the  
parent Append node from tuples fetched by process_pending_request() when  
notified.  Repair.  
  
Per buildfarm via Michael Paquier.  Back-patch to v14, like the previous  
commit.  
  
Thanks to Tom Lane for testing.  
  
Discussion: https://postgr.es/m/YQP0UPT8KmPiHTMs%40paquier.xyz  

commit   : ec410c985e6d360f666e39be5609f3c4da5edc8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Jul 2021 11:50:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Jul 2021 11:50:14 -0400    

As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)  
requires having either an active Portal, or a caller-established  
active snapshot.  We were simply Assert'ing that that's the case.  
But we've now had a couple different reports of people testing  
extensions that didn't meet this requirement, and were confused by  
the resulting crash.  Let's convert the Assert to a test-and-elog,  
in hopes of making the issue clearer for extension authors.  
  
Per gripes from Liu Huailing and RekGRpth.  Back-patch to v11,  
like the prior commit.  
  
Discussion: https://postgr.es/m/OSZPR01MB6215671E3C5956A034A080DFBEEC9@OSZPR01MB6215.jpnprd01.prod.outlook.com  
Discussion: https://postgr.es/m/17035-14607d308ac8643c@postgresql.org  

commit   : 0d6b87497e32a5b15be8fa3247b8fae48358bb1b    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 Jul 2021 11:23:48 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 31 Jul 2021 11:23:48 +0100    

This fixes a couple of related problems that arise when raising  
numbers to very large powers.  
  
Firstly, when raising a negative number to a very large integer power,  
the result should be well-defined, but the previous code would only  
cope if the exponent was small enough to go through power_var_int().  
Otherwise it would throw an internal error, attempting to take the  
logarithm of a negative number. Fix this by adding suitable handling  
to the general case in power_var() to cope with negative bases,  
checking for integer powers there.  
  
Next, when raising a (positive or negative) number whose absolute  
value is slightly less than 1 to a very large power, the result should  
approach zero as the power is increased. However, in some cases, for  
sufficiently large powers, this would lose all precision and return 1  
instead of 0. This was due to the way that the local_rscale was being  
calculated for the final full-precision calculation:  
  
  local_rscale = rscale + (int) val - ln_dweight + 8  
  
The first two terms on the right hand side are meant to give the  
number of significant digits required in the result ("val" being the  
estimated result weight). However, this failed to account for the fact  
that rscale is clipped to a maximum of NUMERIC_MAX_DISPLAY_SCALE  
(1000), and the result weight might be less then -1000, causing their  
sum to be negative, leading to a loss of precision. Fix this by  
forcing the number of significant digits calculated to be nonnegative.  
It's OK for it to be zero (when the result weight is less than -1000),  
since the local_rscale value then includes a few extra digits to  
ensure an accurate result.  
  
Finally, add additional underflow checks to exp_var() and power_var(),  
so that they consistently return zero for cases like this where the  
result is indistinguishable from zero. Some paths through this code  
already returned zero in such cases, but others were throwing overflow  
errors.  
  
Dean Rasheed, reviewed by Yugo Nagata.  
  
Discussion: http://postgr.es/m/CAEZATCW6Dvq7+3wN3tt5jLj-FyOcUgT5xNoOqce5=6Su0bCR0w@mail.gmail.com  

commit   : f051b87ace6dda42c191b77858c8d099af0de46a    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Fri, 30 Jul 2021 13:50:23 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Fri, 30 Jul 2021 13:50:23 -0400    

The previous coding guarded against -INT_MAX instead of INT_MIN,  
leading to -2147483648 being rejected as out of range.  
  
Per bug #17128 from Kevin Sweet  
  
Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org  
Reviewed-by: Tom Lane  
Backpatch to all supported branches  

commit   : 99da905d5c4335d2df80f5cf05dad046a10d30fb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 30 Jul 2021 12:52:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 30 Jul 2021 12:52:49 +0300    

CheckpointLock was removed in commit d18e75664a, and commit ce197e91d0  
updated a leftover comment in CreateCheckPoint, but there was another  
copy of it in CreateRestartPoint still.  

commit   : 1cf7fb376acd48710c1c2c5cd97d11cd82e71ae4    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 30 Jul 2021 17:00:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 30 Jul 2021 17:00:01 +0900    

A pending asynchronous request is handled by process_pending_request(),  
which previously not only processed an in-progress remote query but  
performed ExecForeignScan() to produce a tuple to return to the local  
server asynchronously from the result of the remote query.  But that led  
to a server crash when executing a query or led to an "InstrStartNode  
called twice in a row" or "InstrEndLoop called on running node" failure  
when doing EXPLAIN ANALYZE of it, in cases where the plan tree for it  
contained multiple async-capable nodes accessing the same  
initplan/subplan that contained multiple async-capable nodes scanning  
the same foreign tables as for the parent async-capable nodes, as  
reported by Andrey Lepikhov.  The reason is that the second step in  
process_pending_request() invoked when executing the initplan/subplan  
for one of the parent async-capable nodes caused recursive execution of  
the initplan/subplan for another of the parent async-capable nodes.  
  
To fix, split process_pending_request() into the two steps and postpone  
the second step until ForeignAsyncConfigureWait() is called for each of  
the pending asynchronous requests.  Also, in ExecAppendAsyncEventWait()  
we assumed that FDWs would register at least one wait event in a  
WaitEventSet created there when they were called from  
ForeignAsyncConfigureWait() in that function, but allow FDWs to register  
zero wait events in the WaitEventSet; modify ExecAppendAsyncEventWait()  
to just return in that case.  
  
Oversight in commit 27e1f1456.  Back-patch to v14 where that commit went  
in.  
  
Andrey Lepikhov and Etsuro Fujita  
  
Discussion: https://postgr.es/m/fe5eaa19-1704-e4a4-76ee-3b9d37ade399@postgrespro.ru  

commit   : f4b939f1a3720209e1941b88e11e02ea5e671c1b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 30 Jul 2021 08:21:59 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 30 Jul 2021 08:21:59 +0530    

Oversight in commit 0926e96c49.  
  
Author: Masahiko Sawada  
Reviewed-By: Amit Kapila  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com  

commit   : f951f6f69c7e77acdd04776168126f00e269dcfb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Jul 2021 17:09:06 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 29 Jul 2021 17:09:06 -0400    

Buildfarm shows that this test has a further failure mode when a  
checkpoint starts earlier than expected, so we detect a "checkpoint  
completed" line that's not the one we want.  Change the config to try  
and prevent this.  
  
Per buildfarm  
  
While at it, update one comment that was forgotten in commit  
d18e75664a2f.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20210729.162038.534808353849568395.horikyota.ntt@gmail.com  

commit   : c73bba23ef07f88ce3860a06bbf56180e00b185d    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 29 Jul 2021 21:39:40 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 29 Jul 2021 21:39:40 +0200    

The returnvalue for the bit_count(::bytea) example was assuming a  
non-default value of standard_conforming_strings.  This was fixed  
in the tests in commit ebedd0c78.  
  
Author: wangzk.fnstxz@fujitsu.com  
Discussion: https://postgr.es/m/OSZPR01MB6551FFAC1088C82C3D799BE0FAEB9@OSZPR01MB6551.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : 43f1d2ab361ccbd5ba8b53578fd4bcea9a6344a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Jul 2021 13:33:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Jul 2021 13:33:31 -0400    

Commit ffa2e4670 changed libpq so that multiple error reports  
occurring during one operation (a connection attempt or query)  
are accumulated in conn->errorMessage, where before new ones  
usually replaced any prior error.  At least in theory, that makes  
us more vulnerable to running out of memory for the errorMessage  
buffer.  If it did happen, the user would be left with just an  
empty-string error report, which is pretty unhelpful.  
  
We can improve this by relying on pqexpbuffer.c's existing "broken  
buffer" convention to track whether we've hit OOM for the current  
operation's error string, and then substituting a constant "out of  
memory" string in the small number of places where the errorMessage  
is read out.  
  
While at it, apply the same method to similar OOM cases in  
pqInternalNotice and pqGetErrorNotice3.  
  
Back-patch to v14 where ffa2e4670 came in.  In principle this could  
go back further; but in view of the lack of field reports, the  
hazard seems negligible in older branches.  
  
Discussion: https://postgr.es/m/530153.1627425648@sss.pgh.pa.us  

commit   : c42d3d04d7d03782ae179bf92ea0eb9f2fa8f409    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 29 Jul 2021 12:15:03 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 29 Jul 2021 12:15:03 -0400    

Certain versions of msys2/Windows have been observed to resolve symlinks  
in perl2host rather than just follow them. This defeats using a  
symlinked shorter path to a longer path, and makes certain tests fail.  
We therefore call perl2host on the parent directory of the symlink and  
thereafter just use that result.  
  
Apply to release 14 where the problem has been observed.  

commit   : 68011e17d098da66070a2d648a609625241f73f6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 29 Jul 2021 12:15:03 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 29 Jul 2021 12:15:03 -0400    

Sometimes cygpath has been observed to return a path with a trailing  
slash. That can cause problems, Also, make "cygpath" usage  
consistent with "pwd -W" with respect to the use of forward slashes.  
  
Backpatch to release 14 where the current code was introduced.  

commit   : 67445deb7eca32d25721dffb228b009bfbe415d5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jul 2021 10:59:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 29 Jul 2021 10:59:56 +0900    

pg_verifybackup needs by default pg_waldump to check after a range of  
WAL segments required for a backup, except if --no-parse-wal is  
specified.  The code checked for the presence of the binary pg_waldump  
in an installation and reported an error, but it forgot to properly  
exit().  This could lead to confusing errors reported.  
  
Reviewed-by: Robert Haas, Fabien Coelho  
Discussion: https://postgr.es/m/YQDMdB+B68yePFeT@paquier.xyz  
Backpatch-through: 13  

commit   : f2a3d7404e5d4aa17dbdf7299b1f0d548fe59b9d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 29 Jul 2021 01:30:02 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 29 Jul 2021 01:30:02 +0900    

If a file is truncated, we must update minRecoveryPoint. Once a file is  
truncated, there's no going back; it would not be safe to stop recovery  
at a point earlier than that anymore.  
  
Commit 7bffc9b7bf changed xact_redo_commit() so that it updates  
minRecoveryPoint on truncation, but forgot to change xact_redo_abort().  
  
Back-patch to all supported versions.  
  
Reported-by: mengjuan.cmj@alibaba-inc.com  
Author: Fujii Masao  
Reviewed-by: Heikki Linnakangas  
Discussion: https://postgr.es/m/b029fce3-4fac-4265-968e-16f36ff4d075.mengjuan.cmj@alibaba-inc.com  

commit   : fc0d9b8c224ff6b84113cefdca1ba9dde879d863    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 28 Jul 2021 11:22:58 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 28 Jul 2021 11:22:58 -0400    

It's not clear what the semantics of negative strides would be, so throw  
an error instead.  
  
Per report from Bauyrzhan Sakhariyev  
  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://www.postgresql.org/message-id/CAKpL73vZmLuFVuwF26FJ%2BNk11PVHhAnQRoREFcA03x7znRoFvA%40mail.gmail.com  
Backpatch to v14  

commit   : 5a8a9be08307a1c06fbed4510667de6b4f40fe56    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 28 Jul 2021 15:02:12 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 28 Jul 2021 15:02:12 +1200    

It wasn't all that clear which lock levels, if any, would be held on the  
DEFAULT partition during an ATTACH PARTITION operation.  
  
Also, clarify which locks will be taken if the DEFAULT partition or the  
table being attached are themselves partitioned tables.  
  
Here I'm only backpatching to v12 as before then we obtained an ACCESS  
EXCLUSIVE lock on the partitioned table.  It seems much less relevant to  
mention which locks are taken on other tables when the partitioned table  
itself is locked with an ACCESS EXCLUSIVE lock.  
  
Author: Matthias van de Meent, David Rowley  
Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com  
Backpatch-through: 12  

commit   : ad3b40eb26a30d376e8448eb1170421501f0fc6b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Jul 2021 15:44:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Jul 2021 15:44:12 -0400    

This changes the behavior of examining the pg_file_settings view after  
changing a config option that requires restart.  The user needs to know  
that any change of such options does not take effect until a restart,  
and this worked correctly if the line is edited without removing it.  
However, for the case where the line is removed altogether, the flag  
doesn't get set, because a flag was only set in set_config_option, but  
that's not called for lines removed.  Repair.  
  
(Ref.: commits 62d16c7fc561 and a486e35706ea)  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/202107262302.xsfdfc5sb7sh@alvherre.pgsql  

commit   : b7ea0e8c41f1e512923267a57cd08df63115b783    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Jul 2021 15:01:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Jul 2021 15:01:49 -0400    

We failed to deal with an UNKNOWN-type input for  
anycompatiblemultirange; that should throw an error indicating  
that we don't know how to resolve the multirange type.  
  
We also failed to infer the type of an anycompatiblerange output  
from an anycompatiblemultirange input or vice versa.  
  
Per bug #17066 from Alexander Lakhin.  Back-patch to v14  
where multiranges were added.  
  
Discussion: https://postgr.es/m/17066-16a37f6223a8470b@postgresql.org  

commit   : fd90f6ba7a75f51d14dac27219bb3755b893e251    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 28 Jul 2021 01:20:16 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 28 Jul 2021 01:20:16 +0900    

The error messages using the word "non-negative" are confusing  
because it's ambiguous about whether it accepts zero or not.  
This commit improves those error messages by replacing it with  
less ambiguous word like "greater than zero" or  
"greater than or equal to zero".  
  
Also this commit added the note about the word "non-negative" to  
the error message style guide, to help writing the new error messages.  
  
When postgres_fdw option fetch_size was set to zero, previously  
the error message "fetch_size requires a non-negative integer value"  
was reported. This error message was outright buggy. Therefore  
back-patch to all supported versions where such buggy error message  
could be thrown.  
  
Reported-by: Hou Zhijie  
Author: Bharath Rupireddy  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 5a353a2d43eeab7554a6986b04b0a9d98ad55c92    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:54:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:54:35 -0400    

Reported-by: troy@frericks.us  
  
Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org  
  
Backpatch-through: 13  

commit   : 695b4a113abca380fd7aed26cefa039e4e8cd569    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:38:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 26 Jul 2021 22:38:14 -0400    

Add pg_resetxlog -u option to set the oldest xid in pg_control.  
Previously -x set this value be -2 billion less than the -x value.  
However, this causes the server to immediately scan all relation's  
relfrozenxid so it can advance pg_control's oldest xid to be inside the  
autovacuum_freeze_max_age range, which is inefficient and might disrupt  
diagnostic recovery.  pg_upgrade will use this option to better create  
the new cluster to match the old cluster.  
  
Reported-by: Jason Harvey, Floris Van Nee  
  
Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com  
  
Author: Bertrand Drouvot  
  
Backpatch-through: 9.6  

commit   : 611e42444b121370f561d860552beb7d28dacbf8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jul 2021 17:12:28 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 26 Jul 2021 17:12:28 +0200    

Commit ad600bba04 added psql command \dX listing extended statistics  
objects, but it failed to consider search_path when selecting the  
elements so some of the returned elements might be invisible.  
  
The visibility was already considered for tab completion (added by  
commit d99d58cdc8), so adding it to the query is fairly simple.  
  
Reported and fix by Justin Pryzby, regression tests by me. Backpatch  
to PostgreSQL 14, where \dX was introduced.  
  
Batchpatch-through: 14  
Author: Justin Pryzby  
Reviewed-by: Tatsuro Yamada  
Discussion: https://postgr.es/m/c027a541-5856-75a5-0868-341301e1624b%40nttcom.co.jp_1  

commit   : f2a37ddbb10177fd731109df4a63d10150a91c0d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 16:27:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 16:27:01 +0900    

The documentation mentioned the use of log_checkpoints, that cannot be  
used in this context.  This commit replaces log_checkpoints with  
force_parallel_mode, a developer option useful to perform checks related  
to parallelism.  
  
Oversight in 854434c.  
  
Author: Haiying Tang  
Discussion: https://postgr.es/m/OS0PR01MB6113954B883ACEB2DDC973F2FBE59@OS0PR01MB6113.jpnprd01.prod.outlook.com  
Backpatch-through: 14  

commit   : e6d9544681b3f5c66a16c72bfd8dca450ec7536a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 23:25:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 23:25:15 -0400    

Turns out the buildfarm hasn't been testing this, which will soon change.  
  
Julien Rouhaud, per report from me  
  
Discussion: https://postgr.es/m/42557.1627229005@sss.pgh.pa.us  

commit   : dece64a941457686184654968ac1ded58b7d4ee8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 26 Jul 2021 14:56:09 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 26 Jul 2021 14:56:09 +1200    

Adjust the header comment in get_agg_clause_costs so that it matches what  
the function currently does.  No recursive searching has been done ever  
since 0a2bc5d61.  It also does not determine the aggtranstype like the  
comment claimed. That's all done in preprocess_aggref().  
preprocess_aggref also now determines the numOrderedAggs, so remove the  
mention that get_agg_clause_costs also calculates "counts".  
  
Normally, since this is just an adjustment of a comment it might not be  
worth back-patching, but since this code is new to PG14 and that version  
is still in beta, then it seems worth having the comments match.  
  
Discussion: https://postgr.es/m/CAApHDvrrGrTJFPELrjx0CnDtz9B7Jy2XYW3Z2BKifAWLSaJYwQ@mail.gmail.com  
Backpatch-though: 14  

commit   : b0d28671964d61416248789e3cee4508ac6281b4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 11:14:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Jul 2021 11:14:08 +0900    

These have been introduced by 7fbe0c8, and could happen for  
pg_basebackup and pg_receivewal.  
  
Per report from Coverity for the ones in walmethods.c, I have spotted  
the ones in receivelog.c after more review.  
  
Backpatch-through: 10  

commit   : b154ee63bb659ce280d486db6bbbe77ddec105c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 14:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Jul 2021 14:02:27 -0400    

The point of introducing the hash_mem_multiplier GUC was to let users  
reproduce the old behavior of hash aggregation, i.e. that it could use  
more than work_mem at need.  However, the implementation failed to get  
the job done on Win64, where work_mem is clamped to 2GB to protect  
various places that calculate memory sizes using "long int".  As  
written, the same clamp was applied to hash_mem.  This resulted in  
severe performance regressions for queries requiring a bit more than  
2GB for hash aggregation, as they now spill to disk and there's no  
way to stop that.  
  
Getting rid of the work_mem restriction seems like a good idea, but  
it's a big job and could not conceivably be back-patched.  However,  
there's only a fairly small number of places that are concerned with  
the hash_mem value, and it turns out to be possible to remove the  
restriction there without too much code churn or any ABI breaks.  
So, let's do that for now to fix the regression, and leave the  
larger task for another day.  
  
This patch does introduce a bit more infrastructure that should help  
with the larger task, namely pg_bitutils.h support for working with  
size_t values.  
  
Per gripe from Laurent Hasson.  Back-patch to v13 where the  
behavior change came in.  
  
Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us  
Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com  

commit   : 3d0a4636aa4c976e971c05c77e162fc70c61f40b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 24 Jul 2021 20:14:03 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 24 Jul 2021 20:14:03 -0700    

5a1e1d83022 was a minimal bug fix for dc7420c2c92. To avoid future bugs of  
that kind, deduplicate the choice of a relation's horizon into a new helper,  
GlobalVisHorizonKindForRel().  
  
As the code in question was only introduced in dc7420c2c92 it seems worth  
backpatching this change as well, otherwise 14 will look different from all  
other branches.  
  
A different approach to this was suggested by Matthias van de Meent.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20210621122919.2qhu3pfugxxp3cji@alap3.anarazel.de  
Backpatch: 14, like 5a1e1d83022  

commit   : 712ba6b8b73870fa9e3336df8d88f4bc5f824112    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 18:35:52 -0400    

We have an implementation restriction that PREPARE TRANSACTION can't  
handle cases where both session-lifespan and transaction-lifespan locks  
are held on the same lockable object.  (That's because we'd otherwise  
need to acquire a new PROCLOCK entry during post-prepare cleanup, which  
is an operation that might fail.  The situation can only arise with odd  
usages of advisory locks, so removing the restriction is probably not  
worth the amount of effort it would take.)  AtPrepare_Locks attempted  
to enforce this, but its logic was many bricks shy of a load, because  
it only detected cases where the session and transaction locks had the  
same lockmode.  Locks of different modes on the same object would lead  
to the rather unhelpful message "PANIC: we seem to have dropped a bit  
somewhere".  
  
To fix, build a transient hashtable with one entry per locktag,  
not one per locktag + mode, and use that to detect conflicts.  
  
Per bug #17122 from Alexander Pyhalov.  This bug is ancient,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org  

commit   : 89ad14cd7870bce199448c527e3130c36f80d2bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 13:41:17 -0400    

We previously took a hard-line attitude that callers should never print  
a null string pointer, and doing so is worthy of an assertion failure  
or crash.  However, we've long since flushed out any easy-to-find bugs  
of that nature.  What remains is a lot of code that perhaps could fail  
that way in hard-to-reach corner cases.  For example, in something as  
simple as  
    ereport(ERROR,  
            (errcode(ERRCODE_UNDEFINED_OBJECT),  
             errmsg("constraint \"%s\" for table \"%s\" does not exist",  
                    conname, get_rel_name(relid))));  
one must wonder whether it's completely guaranteed that get_rel_name  
cannot return NULL in this context.  If such a situation did occur,  
the existing policy converts what might be a pretty minor bug into  
a server crash condition.  This is not good for robustness.  
  
Hence, let's follow the lead of glibc and print "(null)" instead  
of failing.  We should, of course, still consider it a bug if that  
behavior is reachable in ordinary use; but crashing seems less  
desirable than not crashing.  
  
This fix works across-the-board in v12 and up, where we always use  
src/port/snprintf.c.  Before that, on most platforms we're at the mercy  
of the local libc, but it appears that Solaris 10 is the only supported  
platform where we'd still get a crash.  Most other platforms such as  
*BSD, macOS, and Solaris 11 have adopted glibc's behavior at some  
point.  (AIX and HPUX just print "" not "(null)", but that's close  
enough.)  I've not checked what Windows' native printf would do, but  
it doesn't matter because we've long used snprintf.c on that platform.  
  
In v12 and up, also const-ify related code so that we're not casting  
away const on the constant string.  This is just neatnik-ism, since  
next to no compilers will warn about that.  
  
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org  

commit   : d5e913a81cbab063c53b0a06dc8894da89390676    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 12:16:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Jul 2021 12:16:40 -0400    

This testing was useful when it was written, nigh twenty years ago,  
but it seems fairly pointless for any platform built in the last  
dozen or more years.  (Compare also the comments at 8a2121185.)  
Also we now have reports that the test program itself fails under  
ThreadSanitizer.  Rather than invest effort in fixing it, let's  
just drop it, and assume that the few people who still care  
already know they need to use --disable-thread-safety.  
  
Back-patch into v14, for consistency with 8a2121185.  
  
Discussion: https://postgr.es/m/CADhDkKzPSiNvA3Hyq+wSR_icuPmazG0cFe=YnC3U-CFcYLc8Xw@mail.gmail.com  

commit   : 81322fc409743f9ef169cb7bd89b0d0113a0aaa1    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Thu, 22 Jul 2021 17:34:19 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Thu, 22 Jul 2021 17:34:19 -0400    

Bauyrzhan Sakhariyev, via Github  
  
Backpatch to v14  

commit   : b1c1b7af573bbc9fe9039c82ffb7d3a3c378fe4a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jul 2021 14:11:17 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 22 Jul 2021 14:11:17 +1200    

Code inlined by LLVM can crash or fail with "Relocation type not  
implemented yet!" if it tries to access thread local variables.  Don't  
inline such code.  
  
Back-patch to 11, where LLVM arrived.  Bug #16696.  
  
Author: Dmitry Marakasov <amdmi3@amdmi3.ru>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org  

commit   : 227c4e57d6a70961e015ed4185facfc638afd048    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jul 2021 18:03:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Jul 2021 18:03:33 -0400    

Now that we're not having to wedge this into the straitjacket of  
the old operator table format, we can add another example to  
clarify the point about left-to-right associativity.  
  
Per suggestion from mdione at grulic.org.ar.  
  
https://postgr.es/m/162661954599.693.13700316547731859171@wrigleys.postgresql.org  

commit   : 65cc77c9847022f895a12012085606d8553c5fff    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 10:17:07 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 10:17:07 -0400    

In postgresql.conf, memory and file size GUCs can be specified with "B"  
(bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us"  
(microseconds) as of caf626b2c. Update postgres.conf.sample to reflect  
that fact.  
  
Pavel Luzanov  
  
Backpatch to v12, which is the earliest version that allows both of  
these units. A separate commit will document the "B" case for v11.  
  
Discussion: https://www.postgresql.org/message-id/flat/f10d16fc-8fa0-1b3c-7371-cb3a35a13b7a%40postgrespro.ru  

commit   : e5cebe1ae8895fd9793344e70f58714e0a1742a4    
  
author   : John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 09:09:32 -0400    
  
committer: John Naylor <john.naylor@postgresql.org>    
date     : Wed, 21 Jul 2021 09:09:32 -0400    

Oversight in ea1b99a66  
  
Yukun Wang  
  
Backpatch to v14 where this parameter was introduced  
Discussion: https://www.postgresql.org/message-id/flat/OS0PR01MB6003FCEFF0201EF21685FD33B4E39%40OS0PR01MB6003.jpnprd01.prod.outlook.com  

commit   : 9c1d56a9b08f87303749e60f9df8cf5c26c279eb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 13:52:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 21 Jul 2021 13:52:37 +0900    

Back-patch to v10 where pg_import_system_collations() was added.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/b7f484692a3e283710032e68b7f40617@oss.nttdata.com  

commit   : f8d1333dec312f96673efc6314a0f1df99e38abc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Jul 2021 19:37:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 Jul 2021 19:37:04 -0400    

Reported-by: Elena Indrupskaya  
  
Discussion: https://postgr.es/m/38555778-a56b-4aca-2581-e05582fc9bcf@postgrespro.ru  
  
Author: Elena Indrupskaya  
  
Backpatch-through: 14 only  

commit   : 899564e010abf216a90c48d9a1ce3728b8b00266    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Jul 2021 13:01:48 -0400    

If an error was raised during our initial attempt to check whether  
a successfully-compiled expression is "simple", subsequent calls of  
exec_stmt_execsql would suppose that stmt->mod_stmt was already computed  
when it had not been.  This could lead to assertion failures in debug  
builds; in production builds the effect would typically be to act as  
if INTO STRICT had been specified even when it had not been.  Of course  
that only matters if the subsequent attempt to execute the expression  
succeeds, so that the problem can only be reached by fixing a failure  
in some referenced, inline-able SQL function and then retrying the  
calling plpgsql function in the same session.  
  
(There might be even-more-obscure ways to change the expression's  
behavior without changing the plpgsql function, but that one seems  
like the only one people would be likely to hit in practice.)  
  
The most foolproof way to fix this would be to arrange for  
exec_prepare_plan to not set expr->plan until we've finished the  
subsidiary simple-expression check.  But it seems hard to do that  
without creating reference-count leak issues.  So settle for documenting  
the hazard in a comment and fixing exec_stmt_execsql to test separately  
for whether it's computed stmt->mod_stmt.  (That adds a test-and-branch  
per execution, but hopefully that's negligible in context.)  In v11 and  
up, also fix exec_stmt_call which had a variant of the same issue.  
  
Per bug #17113 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/17113-077605ce00e0e7ec@postgresql.org  

commit   : 3a0d2d0cbaf349a1aba928bb7b14edeaffab5212    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:12:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Jul 2021 12:12:47 +0900    

The logic handling the opening of new WAL segments was fuzzy when using  
--compress if a partial, non-compressed, segment with the same base name  
existed in the repository storing those files.  In this case, using  
--compress would cause the code to first check for the existence and the  
size of a non-compressed segment, followed by the opening of a new  
compressed, partial, segment.  The code was accidentally working  
correctly on most platforms as the buildfarm has proved, except  
bowerbird where gzflush() could fail in this code path.  It is wrong  
anyway to take the code path used pre-padding when creating a new  
partial, non-compressed, segment, so let's fix it.  
  
Note that this issue exists when users mix successive runs of  
pg_receivewal with or without compression, as discovered with the tests  
introduced by ffc9dda.  
  
While on it, this refactors the code so as code paths that need to know  
about the ".gz" suffix are down from four to one in walmethods.c, easing  
a bit the introduction of new compression methods.  This addresses a  
second issue where log messages generated for an unexpected failure  
would not show the compressed segment name involved, which was  
confusing, printing instead the name of the non-compressed equivalent.  
  
Reported-by: Georgios Kokolatos  
Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz  
Backpatch-through: 10  

commit   : e1cdf61726e8d70971cf29d98c7ab5806875ac0e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:20:24 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:20:24 -0700    

Oversight in commit 1e55e7d1, which added a wraparound failsafe  
mechanism to VACUUM.  
  
Backpatch: 14-, where VACUUM failsafe was introduced.  

commit   : 9a3d41a26fbb00c67b1ac00306b21ab83f171e08    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:06:47 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 19 Jul 2021 17:06:47 -0700    

Commit 3499df0d added a comment that incorrectly suggested that  
--force-index-cleanup did not appear in the same major version as the  
similar --no-index-cleanup option.  In fact, both options are new to  
PostgreSQL 14.  
  
Backpatch: 14-, where both options were introduced.  

commit   : 1e8751380836056fdf546433dcf0328bc18c9313    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Jul 2021 17:21:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Jul 2021 17:21:07 -0400    

Further fix the test code in ead9e51e8236, this time by waiting until  
the checkpoint has completed before moving on; this ensures that the  
WAL segment removal has already happened when we create the next slot.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20210719.111318.2042379313472032754.horikyota.ntt@gmail.com  

commit   : 40295d158fd4d462c55e6debae19dcd43ab530a6    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 10:54:21 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 19 Jul 2021 10:54:21 +0530    

We don't allow to create replication slot_name as an empty string ('') via  
SQL API pg_create_logical_replication_slot() but it is allowed to be set  
via Alter Subscription command. This will lead to apply worker repeatedly  
keep trying to stream data via slot_name '' and the user is not allowed to  
create the slot with that name.  
  
Author: Japin Li  
Reviewed-By: Ranier Vilela, Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/MEYP282MB1669CBD98E721C77CA696499B61A9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : 6d0dc1a7da7942915c8160caa379c58dfd1488b8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Jul 2021 12:39:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Jul 2021 12:39:50 +0900    

This grammar has no effect as there are no dependencies on statistics,  
but it is supported by the parser.  This is more consistent with the  
other DROP commands.  
  
Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm1LA=yNmzcSfy+0oe6CEAgsxXRf_-UutE3ZncFi8QkFNQ@mail.gmail.com  
Backpatch-through: 10  

commit   : 244ad5415557812a6ac4dc5d6e2ae908361d82c3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 18 Jul 2021 21:07:24 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 18 Jul 2021 21:07:24 +0300    

It has been spotted that multiranges lack of ability to decompose them into  
individual ranges.  Subscription and proper expanded object representation  
require substantial work, and it's too late for v14.  This commit  
provides the implementation of unnest(multirange), which is quite trivial.  
unnest(multirange) is defined as a polymorphic procedure.  
  
Catversion is bumped.  
  
Reported-by: Jonathan S. Katz  
Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org  
Author: Alexander Korotkov  
Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu, Tom Lane  
Reviewed-by: Alvaro Herrera  

commit   : d8f3b021c618bf58c19f88fb86476793fd650336    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 17 Jul 2021 13:19:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 17 Jul 2021 13:19:17 -0400    

The new test code added in ead9e51e8236 is racy -- it hinges on  
shared-memory state, which changes before the WARNING message is logged.  
Put it the other way around.  
  
Backpatch to 13.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202107161809.zclasccpfcg3@alvherre.pgsql  

commit   : 4466b38ec6ffd4ddea135c5baff978b7b43f8257    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Jul 2021 11:52:54 -0400    

We had documentation of default_transaction_isolation et al,  
but for some reason not of transaction_isolation et al.  
AFAICS this is just an ancient oversight, so repair.  
  
Per bug #17077 from Yanliang Lei.  
  
Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org  

commit   : 3c5b7c6286215de41ba0a327d065876ff8bc26b2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 17:29:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 17:29:22 -0400    

pg_dump failed to preserve the 'enabled' flag (which can be not only  
disabled, but also REPLICA or ALWAYS) for partitions which had it  
changed from their respective parents.  Attempt to handle that by  
including a definition for such triggers in the dump, but replace the  
standard CREATE TRIGGER line with an ALTER TRIGGER line.  
  
Backpatch to 11, where these triggers can exist.  In branches 11 and 12,  
pick up a few test lines from commit b9b408c48724 to verify that  
pg_upgrade is okay with these arrangements.  
  
Co-authored-by: Justin Pryzby <pryzby@telsasoft.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com  

commit   : eef92de11e50837e4a0d02fc7269fdba7c97e583    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 13:01:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 13:01:43 -0400    

When triggers are cloned from partitioned tables to their partitions,  
the 'tgenabled' flag (origin/replica/always/disable) was not propagated.  
Make it so that the flag on the trigger on partition is initially set to  
the same value as on the partitioned table.  
  
Add a test case to verify the behavior.  
  
Backpatch to 11, where this appeared in commit 86f575948c77.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com  

commit   : e5bcbb10707b844471c67d5e5fd8226d1891ee97    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 12:07:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 16 Jul 2021 12:07:30 -0400    

When some slots are invalidated due to the max_slot_wal_keep_size limit,  
the old segment horizon should move forward to stay within the limit.  
However, in commit c6550776394e we forgot to call KeepLogSeg again to  
recompute the horizon after invalidating replication slots.  In cases  
where other slots remained, the limits would be recomputed eventually  
for other reasons, but if all slots were invalidated, the limits would  
not move at all afterwards.  Repair.  
  
Backpatch to 13 where the feature was introduced.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reported-by: Marcin Krupowicz <mk@071.ovh>  
Discussion: https://postgr.es/m/17103-004130e8f27782c9@postgresql.org  

commit   : 525115a332af0fd479503550fd4f82551b797aea    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Jul 2021 10:35:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 16 Jul 2021 10:35:38 +0200    

commit   : 9ffe128a6d616675b559a14a89f8b42a30084323    
  
author   : Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 15 Jul 2021 23:22:59 +0200    
  
committer: Daniel Gustafsson <dgustafsson@postgresql.org>    
date     : Thu, 15 Jul 2021 23:22:59 +0200    

Ensure to properly mark up function parameters in text with <parameter>,  
avoid using <acronym> for terms which aren't acronyms and properly place  
the ", and" in a value list. The acronym removal is a follow-up to commit  
fb72a7b8c3 which removed it for minmax-multi.  In passing, also fix an  
incorrectly cased word.  
  
Author: Ekaterina Kiryanova <e.kiryanova@postgrespro.ru>  
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/c050ecbc-80b2-b360-3c1d-9fe6a6a11bb5@postgrespro.ru  
Backpatch-through: v14  

commit   : 081e86bd9e7e00af3cbf9bcdec8277f02d22e6b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:00:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Jul 2021 11:00:43 -0400    

Autoconf's AC_CHECK_DECLS() always defines HAVE_DECL_whatever  
as 1 or 0, but some of the entries in msvc/Solution.pm showed  
such symbols as "undef" instead of 0.  Fix that for consistency.  
There's no live bug in current usages AFAICS, but it's not hard  
to imagine one creeping in if more-complex #if tests get added.  
  
Back-patch to v13, which is as far back as Solution.pm contains  
this data.  The inconsistency still exists in the manually-filled  
pg_config_ext.h.win32 files of older branches; but as long as the  
problem is only latent, it doesn't seem worth the trouble to  
clean things up there.  
  
Discussion: https://postgr.es/m/3185430.1626133592@sss.pgh.pa.us  

commit   : 4d39d4e639b44503c9950f61ec882113385db7ec    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 15 Jul 2021 14:18:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 15 Jul 2021 14:18:19 +0300    

This commit fixes the description of a couple of multirange operators and  
oprjoin for another multirange operator.  The change of oprjoin is more  
cosmetic since both old and new functions return the same constant.  
  
These cosmetic changes don't worth catalog incompatibility between 14beta2  
and 14beta3.  So, catversion isn't bumped.  
  
Discussion: https://postgr.es/m/CAPpHfdv9OZEuZDqOQoUKpXhq%3Dmc-qa4gKCPmcgG5Vvesu7%3Ds1w%40mail.gmail.com  
Backpatch-throgh: 14  

commit   : b90063511a3ee41d037b2da0d4e0b3bc399140c5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 15:00:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 15 Jul 2021 15:00:52 +0900    

A code path asserted that the archiver was dead, but a check made that  
impossible to happen.  
  
Author: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALj2ACW=CYE1ars+2XyPTEPq0wQvru4c0dPZ=Nrn3EqNBkksvQ@mail.gmail.com  
Backpatch-throgh: 14  

commit   : 3b57d5af7435d0d21bdec392dc1ce7c13871df8b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 14 Jul 2021 11:04:15 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 14 Jul 2021 11:04:15 +0200    

Reported-By: Peter Eisentraut  
Backpatch-through: 14  
Discussion: https://postgr.es/m/8f5e63b8-e8ed-0f80-d8c4-68222624c200@enterprisedb.com  

commit   : 0c83eb2e0edb42f54a37fdeac85fb80eb5de2cca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jul 2021 17:15:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Jul 2021 17:15:01 +0900    

Some commands of ALTER TABLE could fail with the following error:  
ERROR:  "tab" is of the wrong type  
  
This error is unexpected, as all the code paths leading to  
ATWrongRelkindError() should use a supported set of relkinds to generate  
correct error messages.  This commit closes the gap with such mistakes,  
by adding all the missing relkind combinations.  Tests are added to  
check all the problems found.  Note that some combinations are not used,  
but these are left around as it could have an impact on applications  
relying on this code.  
  
2ed532e has done a much larger refactoring on HEAD to make such error  
messages easier to manage in the long-term, so nothing is needed there.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Peter Eisentraut, Ahsan Hadi, Michael Paquier  
Discussion: https://postgr.es/m/20210216.181415.368926598204753659.horikyota.ntt@gmail.com  
Backpatch-through: 11  

commit   : b4842a8d085e970ff24667954c0d861e911e16c1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Jul 2021 09:15:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Jul 2021 09:15:14 +0200    

commit   : 47ca4836441d1c24f75a94d43af8bd72d4c8d057    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 14 Jul 2021 12:45:00 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 14 Jul 2021 12:45:00 +1200    

"Result Cache" was never a great name for this node, but nobody managed  
to come up with another name that anyone liked enough.  That was until  
David Johnston mentioned "Node Memoization", which Tom Lane revised to  
just "Memoize".  People seem to like "Memoize", so let's do the rename.  
  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/20210708165145.GG1176@momjian.us  
Backpatch-through: 14, where Result Cache was introduced  

commit   : 6201fa3c166fe2383dd44a9dd5082bc748c2937a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jul 2021 15:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Jul 2021 15:01:01 -0400    

The name introduced by commit 4656e3d66 was agreed to be unreasonably  
long.  To match this change, rename initdb's recently-added  
--clobber-cache option to --discard-caches.  
  
Discussion: https://postgr.es/m/1374320.1625430433@sss.pgh.pa.us  

commit   : a92709fed63428a711f36270a2b4bee039399d60    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:27:44 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 13:27:44 +1200    

41469253e went to the trouble of removing a theoretical bug from  
free_sort_tuple by checking if the tuple was NULL before freeing it. Let's  
make this a little more robust by also setting the tuple to NULL so that  
should we be called again we won't end up doing a pfree on the already  
pfree'd tuple. Per advice from Tom Lane.  
  
Discussion: https://postgr.es/m/3188192.1626136953@sss.pgh.pa.us  
Backpatch-through: 9.6, same as 41469253e  

commit   : a3b8d91ccd7964e5bec1066c9e598277294efd33    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 12:42:04 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 13 Jul 2021 12:42:04 +1200    

This fixes a theoretical bug in tuplesort.c which, if a bounded sort was  
used in combination with a byval Datum sort (tuplesort_begin_datum), when  
switching the sort to a bounded heap in make_bounded_heap(), we'd call  
free_sort_tuple().  The problem was that when sorting Datums of a byval  
type, the tuple is NULL and free_sort_tuple() would free the memory for it  
regardless of that.  This would result in a crash.  
  
Here we fix that simply by adding a check to see if the tuple is NULL  
before trying to disassociate and free any memory belonging to it.  
  
The reason this bug is only theoretical is that nowhere in the current  
code base do we do tuplesort_set_bound() when performing a Datum sort.  
However, let's backpatch a fix for this as if any extension uses the code  
in this way then it's likely to cause problems.  
  
Author: Ronan Dunklau  
Discussion: https://postgr.es/m/CAApHDvpdoqNC5FjDb3KUTSMs5dg6f+XxH4Bg_dVcLi8UYAG3EQ@mail.gmail.com  
Backpatch-through: 9.6, oldest supported version  

commit   : e75da4f1b6c63523021e550f1a92c67d2b8a92fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jul 2021 19:17:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Jul 2021 19:17:35 -0400    

Apple's mechanism for dealing with functions that are available  
in only some OS versions confuses AC_CHECK_FUNCS, and therefore  
AC_REPLACE_FUNCS.  We can use AC_CHECK_DECLS instead, so long as  
we enable -Werror=unguarded-availability-new.  This allows people  
compiling for macOS to control whether or not preadv/pwritev are  
used by setting MACOSX_DEPLOYMENT_TARGET, rather than supplying  
a back-rev SDK.  (Of course, the latter still works, too.)  
  
James Hilliard  
  
Discussion: https://postgr.es/m/20210122193230.25295-1-james.hilliard1@gmail.com  

commit   : 9b450b1f1e5bbeac414bbb8e6a2f08fa40f470ff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 22:07:35 +0200    

commit   : 233280803cb6b3fe6b905abc1a28913855f40dd6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 Jul 2021 11:13:33 +0300    

This should have been removed in commit 7e30c186da, which split the loop  
into two. Only the first loop uses the 'from' variable; updating it in  
the second loop is bogus. It was never read after the first loop, so this  
was harmless and surely optimized away by the compiler, but let's be tidy.  
  
Backpatch to all supported versions.  
  
Author: Ranier Vilela  
Discussion: https://www.postgresql.org/message-id/CAEudQAoWq%2BAL3BnELHu7gms2GN07k-np6yLbukGaxJ1vY-zeiQ%40mail.gmail.com  

commit   : 166fcf4a6364769501dd8562db927abefdd310b2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 08:45:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Jul 2021 08:45:34 +0200    

Two tsquery-related release note entries had inaccuracies in the  
before and after examples.  Clean that up.  

commit   : 5e60237ad1b4e2d159aec48ffd9914a633d2d6e0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 14:46:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 14:46:40 +0900    

This reverts commit 54fb8c7, as per the issues reported by fairywren  
when it comes to MinGW because of the lack of microsoft_native_stat()  
there.  Using just stat() for MSVC is not sufficient to take care of the  
concurrency problems with files pending on deletion.  It may be possible  
to paint some __MINGW64__ in the code to switch to a different  
implementation of stat() in this build context, but I am not sure either  
if relying on the implementation of stat() in MinGW to take care of the  
problems we are trying to fix is enough or not.  So this needs more  
study.  
  
Discussion: https://postgr.es/m/YOvOlfRrIO0yGtgw@paquier.xyz  
Backpatch-through: 14  

commit   : de1510e2f5a1826890b206253016ebfc592c2f0a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 13:02:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 12 Jul 2021 13:02:45 +0900    

The code introduced by bed9075 to enhance the stat() implementation on  
Windows for file sizes larger than 4GB fails to properly detect files  
pending for deletion with its method based on NtQueryInformationFile()  
or GetFileInformationByHandleEx(), as proved by Alexander Lakhin in a  
custom TAP test of his own.  
  
The method used in the implementation of open() to sleep and loop when  
when failing on ERROR_ACCESS_DENIED (EACCES) is showing much more  
stability, so switch to this method.  This could still lead to issues if  
the permission problem stays around for much longer than the timeout of  
1 second used, but that should (hopefully) never happen in  
performance-critical paths.  Still, there could be a point in increasing  
the timeouts for the sake of machines that handle heavy loads.  
  
Note that WIN32's open() now uses microsoft_native_stat() as it should  
be similar to stat() when working around issues with concurrent file  
deletions.  
  
I have spent some time testing this patch with pgbench in combination  
of the SQL functions from genfile.c, as well as running the TAP test  
provided on the thread with MSVC builds, and this looks much more  
stable than the previous method.  
  
Author: Alexander Lakhin  
Reviewed-by: Tom Lane, Michael Paquier,	Justin Pryzby  
Discussion: https://postgr.es/m/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com  
Backpatch-through: 14  

commit   : 69dfc36fd54d1620209d5d40f3c68006d96b0046    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Jul 2021 12:54:24 -0400    

Although we were careful to lock the object being added or dropped,  
we failed to get any sort of lock on the extension itself.  This  
allowed the ALTER to proceed in parallel with a DROP EXTENSION,  
which is problematic for a couple of reasons.  If both commands  
succeeded we'd be left with a dangling link in pg_depend, which  
would cause problems later.  Also, if the ALTER failed for some  
reason, it might try to print the extension's name, and that could  
result in a crash or (in older branches) a silly error message  
complaining about extension "(null)".  
  
Per bug #17098 from Alexander Lakhin.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org  

commit   : 5614a0f78eaaa51c07bd753ca854de238c730b84    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 11 Jul 2021 19:50:55 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 11 Jul 2021 19:50:55 +1200    

Commit 547f04e changed pgbench to use microsecond accounting, but  
introduced a couple of logging and aggregation bugs:  
  
1.  We print Unix epoch timestamps so that you can correlate them with  
other logs, but these were inadvertently changed to use a  
system-dependent reference epoch.  Compute Unix timestamps, and begin  
aggregation intervals on the boundaries of whole Unix epoch seconds, as  
before.  
  
2.  The user-supplied aggregation interval needed to be scaled.  
  
Back-patch to 14.  
  
Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Author: Yugo NAGATA <nagata@sraoss.co.jp>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reported-by: YoungHwan Joo <rulyox@gmail.com>  
Reported-by: Gregory Smith <gregsmithpgsql@gmail.com>  
Discussion: https://postgr.es/m/CAF7igB1r6wRfSCEAB-iZBKxkowWY6%2BdFF2jObSdd9%2BiVK%2BvHJg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAHLJuCW_8Vpcr0%3Dt6O_gozrg3wXXWXZXDioYJd3NhvKriqgpfQ%40mail.gmail.com  

commit   : 10a07973cf72b32f32f0e05ada16c84580496d93    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 14:15:48 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 9 Jul 2021 14:15:48 -0700    

If an error occurred in the wrong place, it was possible to leave an  
unintialized entry in the hash table, leading to a crash. Fixed.  
  
Also, be more careful about the order of operations so that an  
allocation error doesn't leak memory in CacheMemoryContext or  
unnecessarily advance NextRecordTypmod.  
  
Backpatch through version 11. Earlier versions (prior to 35ea75632a5)  
do not exhibit the problem, because an uninitialized hash entry  
contains a valid empty list.  
  
Author: Sait Talha Nisanci <Sait.Nisanci@microsoft.com>  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/HE1PR8303MB009069D476225B9A9E194B8891779@HE1PR8303MB0090.EURPRD83.prod.outlook.com  
Backpatch-through: 11  

commit   : ebc346e5bb72b2a68258f1be8791f2b90191cd38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Jul 2021 13:19:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Jul 2021 13:19:31 -0400    

Sigh ... I was expecting AC_CHECK_LIB to do something it didn't,  
namely update LIBS.  This led to not finding ldap_initialize.  
Fix by moving the probe for ldap_initialize.  In some sense this  
is more correct anyway, since (at least for now) we care about  
whether ldap_initialize exists in libldap not libldap_r.  
  
Per buildfarm member elver and local testing.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 06883d58ff29cf4fb8c32fd13ce9947796b9fb0f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 10 Jul 2021 12:45:00 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 10 Jul 2021 12:45:00 +0100    

This fixes an overflow error when using the numeric * operator if the  
result has more than 16383 digits after the decimal point by rounding  
the result. Overflow errors should only occur if the result has too  
many digits *before* the decimal point.  
  
Discussion: https://postgr.es/m/CAEZATCUmeFWCrq2dNzZpRj5+6LfN85jYiDoqm+ucSXhb9U2TbA@mail.gmail.com  

commit   : 9ffad7ae7ffc632ff8d3822916c431b7e4a4df38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 16:59:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 16:59:07 -0400    

I incorrectly diagnosed the reason why hoverfly is unhappy.  
Looking closer, it appears that it fails to link libldap  
unless libssl is also present; so the problem was my  
idea of clearing LIBS before making the check.  Revert  
to essentially the original coding, except that instead  
of failing when libldap_r isn't there, use libldap.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 1beaa654da61ee66857a3c5125682b629f62fdf9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Jul 2021 15:57:59 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Jul 2021 15:57:59 -0400    

When sending queries in pipeline mode, we were careless about leaving  
the connection in the right state so that PQgetResult would behave  
correctly; trying to read further results after sending a query after  
having read a result with an error would sometimes hang.  Fix by  
ensuring internal libpq state is changed properly.  All the state  
changes were being done by the callers of pqAppendCmdQueueEntry(); it  
would have become too repetitious to have this logic in each of them, so  
instead put it all in that function and relieve callers of the  
responsibility.  
  
Add a test to verify this case.  Without the code fix, this new test  
hangs sometimes.  
  
Also, document that PQisBusy() would return false when no queries are  
pending result.  This is not intuitively obvious, and NULL would be  
obtained by calling PQgetResult() at that point, which is confusing.  
Wording by Boris Kolpackov.  
  
In passing, fix bogus use of "false" to mean "0", per Ranier Vilela.  
  
Backpatch to 14.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reported-by: Boris Kolpackov <boris@codesynthesis.com>  
Discussion: https://postgr.es/m/boris.20210624103805@codesynthesis.com  

commit   : 7f2eca6f9db6e2227b87d03204e201ee6d759b5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 14:15:41 -0400    

In commit d0a02bdb8, I'd supposed that uniformly probing for  
ldap_bind would make the intent clearer.  However, that seems  
not to work on AIX, for obscure reasons (maybe it's a macro  
there?).  Revert to the former behavior of probing  
ldap_simple_bind for thread-safe cases and ldap_bind otherwise.  
  
Per buildfarm member hoverfly.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 1d98fdaed89c00465ef68fa2804967ea27b03abc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 13:38:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 13:38:24 -0400    

Commit 7266d0997 added code to pull up simple constant function  
results, converting the RTE_FUNCTION RTE to a dummy RTE_RESULT  
RTE since it no longer need be scanned.  But I forgot to clear  
the LATERAL flag if the RTE has it set.  If the function reduced  
to a constant, it surely contains no lateral references so this  
simplification is logically OK.  It's needed because various other  
places will Assert that RESULT RTEs aren't LATERAL.  
  
Per bug #17097 from Yaoguang Chen.  Back-patch to v13 where the  
faulty code came in.  
  
Discussion: https://postgr.es/m/17097-3372ef9f798fc94f@postgresql.org  

commit   : 5620ec83362d08b9f86c90c97c0a70031c4d0b2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 12:38:55 -0400    

The separate libldap_r is gone and libldap itself is now always  
thread-safe.  Unfortunately there seems no easy way to tell by  
inspection whether libldap is thread-safe, so we have to take  
it on faith that libldap is thread-safe if there's no libldap_r.  
That should be okay, as it appears that libldap_r was a standard  
part of the installation going back at least 20 years.  
  
Report and patch by Adrian Ho.  Back-patch to all supported  
branches, since people might try to build any of them with  
a newer OpenLDAP.  
  
Discussion: https://postgr.es/m/17083-a19190d9591946a7@postgresql.org  

commit   : 39b6e85f135f7a1dcf43c0551d7d10e8c57b7fce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Jul 2021 11:02:26 -0400    

Since the executor can't cope with a utility statement appearing  
as a node of a plan tree, we can't support cases where a rewrite  
rule inserts a NOTIFY into an INSERT/UPDATE/DELETE command appearing  
in a WITH clause of a larger query.  (One can imagine ways around  
that, but it'd be a new feature not a bug fix, and so far there's  
been no demand for it.)  RewriteQuery checked for this, but it  
missed the case where the DML command rewrites to *only* a NOTIFY.  
That'd lead to crashes later on in planning.  Add the missed check,  
and improve the level of testing of this area.  
  
Per bug #17094 from Yaoguang Chen.  It's been busted since WITH  
was introduced, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17094-bf15dff55eaf2e28@postgresql.org  

commit   : 8d48a3436dd83f7d6e3cde2d76f91f49f27ba16d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 9 Jul 2021 17:51:48 +1200    

Commit 6753333f stopped using semaphores as the sleep/wake mechanism for  
heavyweight locks, but some obsolete references to that scheme remained  
in comments.  As with similar commit 25b93a29, back-patch all the way.  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Discussion: https://postgr.es/m/CA%2BhUKGLafjB1uzXcy%3D%3D2L3cy7rjHkqOVn7qRYGBjk%3D%3DtMJE7Yg%40mail.gmail.com  

commit   : 6de3a21bbc0601b22cd465311d10978acca7cc0b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 14:04:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 9 Jul 2021 14:04:40 +1200    

Due to how pg_size_pretty(bigint) was implemented, it's possible that when  
given a negative number of bytes that the returning value would not match  
the equivalent positive return value when given the equivalent positive  
number of bytes.  This was due to two separate issues.  
  
1. The function used bit shifting to convert the number of bytes into  
larger units.  The rounding performed by bit shifting is not the same as  
dividing.  For example -3 >> 1 = -2, but -3 / 2 = -1.  These two  
operations are only equivalent with positive numbers.  
  
2. The half_rounded() macro rounded towards positive infinity.  This meant  
that negative numbers rounded towards zero and positive numbers rounded  
away from zero.  
  
Here we fix #1 by dividing the values instead of bit shifting.  We fix #2  
by adjusting the half_rounded macro always to round away from zero.  
  
Additionally, adjust the pg_size_pretty(numeric) function to be more  
explicit that it's using division rather than bit shifting.  A casual  
observer might have believed bit shifting was used due to a static  
function being named numeric_shift_right.  However, that function was  
calculating the divisor from the number of bits and performed division.  
Here we make that more clear.  This change is just cosmetic and does not  
affect the return value of the numeric version of the function.  
  
Here we also add a set of regression tests both versions of  
pg_size_pretty() which test the values directly before and after the  
function switches to the next unit.  
  
This bug was introduced in 8a1fab36a. Prior to that negative values were  
always displayed in bytes.  
  
Author: Dean Rasheed, David Rowley  
Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com  
Backpatch-through: 9.6, where the bug was introduced.  

commit   : 9893d5124b1a0a2d84fb8038bde3bf11491abf7a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Jul 2021 18:59:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Jul 2021 18:59:19 -0400    

Backpatch-through: 14 only  

commit   : 6f566f0e9b1aab41eea1ca1991e04e3d8a79c198    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Jul 2021 13:08:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Jul 2021 13:08:09 -0400    

Backpatch-through: 14 only  

commit   : 049d3617a3bedb2a1d97d1621f36c861f52269a7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Jul 2021 12:27:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 8 Jul 2021 12:27:30 -0400    

Wording confirmed by Peter Geoghegan.  
  
Backpatch-through: 14 only  

commit   : 30a35bca3f9306f87ca8db095ddac2ba62156934    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Jul 2021 15:21:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Jul 2021 15:21:25 -0400    

In 86dc90056, I'd written find_modifytable_subplan with the assumption  
that if the immediate child of a ModifyTable is a Result, it must be  
a projecting Result with a subplan.  However, if the UPDATE or DELETE  
has a provably-constant-false WHERE clause, that's not so: we'll  
generate a dummy subplan with a childless Result.  Add the missing  
null-check so we don't crash on such cases.  
  
Per report from Alexander Pyhalov.  
  
Discussion: https://postgr.es/m/b9a6f53549456b2f3e2fd150dcd79d72@postgrespro.ru  

commit   : e48f2afee631be42739e50fbefd758503e8dcf82    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 21:54:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 21:54:47 +0900    

This commit fixes wrong wording like "a fewer kinds"  
in the description about track_planning option.  
  
Back-patch to v13 where pg_stat_statements.track_planning was added.  
  
Author: Justin Pryzby  
Reviewed-by: Julien Rouhaud, Fujii Masao  
Discussion: https://postgr.es/m/20210418233615.GB7256@telsasoft.com  

commit   : 4173477b3841749ce491c77b54a5940f6f3e9eb6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 11:13:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 7 Jul 2021 11:13:40 +0900    

Previously the values such as '100$%$#$#', '9,223,372,' were accepted and  
treated as valid integers for postgres_fdw options batch_size and fetch_size.  
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options  
for which an error is thrown. This was because endptr was not used  
while converting strings to integers using strtol.  
  
This commit changes the logic so that it uses parse_int function  
instead of strtol as it serves the purpose by returning false in case  
if it is unable to convert the string to integer. Note that  
this function also rounds off the values such as '100.456' to 100 and  
'100.567' or '100.678' to 101.  
  
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.  
  
Since parse_int and parse_real are being used for reloptions and GUCs,  
it is more appropriate to use in postgres_fdw rather than using strtol  
and strtod directly.  
  
Back-patch to v14.  
  
Author: Bharath Rupireddy  
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao  
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com  

commit   : 86d4914210e9e7f8f8c32defacc71744d0222feb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 12:36:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 12:36:12 -0400    

As in 50371df26, this is a bad idea since the callback can't really  
know what error is being thrown and thus whether or not it is safe  
to attempt catalog accesses.  Rather than pushing said accesses into  
the mainline code where they'd usually be a waste of cycles, we can  
look at the query's rangetable instead.  
  
This change does mean that we'll be printing query aliases (if any  
were used) rather than the table or column's true name.  But that  
doesn't seem like a bad thing: it's certainly a more useful definition  
in self-join cases, for instance.  In any case, it seems unlikely that  
any applications would be depending on this detail, so it seems safe  
to change.  
  
Patch by me.  Original complaint by Andres Freund; Bharath Rupireddy  
noted the connection to conversion_error_callback.  
  
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de  

commit   : 94911ec28f01d1babe61053977ca9f057983cb21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Jul 2021 10:34:51 -0400    

Our code has supported fractional-minute UTC offsets for ages, but  
there was no mention of the possibility in the main docs, and only  
a very indirect reference in Appendix B.  Improve that.  
  
Discussion: https://postgr.es/m/162543102827.697.5755498651217979813@wrigleys.postgresql.org  

commit   : 07f1e06964adeec6d79bb24f3b1d50666694213b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 16:51:57 -0400    

Commit 03ffc4d6d added logic to bypass all caching behavior in  
LookupOpclassInfo when CLOBBER_CACHE_ALWAYS is enabled.  It doesn't  
look like I stopped to think much about what that would cost, but  
recent investigation shows that the cost is enormous: it roughly  
doubles the time needed for cache-clobber test runs.  
  
There does seem to be value in this behavior when trying to test  
the opclass-cache loading logic itself, but for other purposes the  
cost is excessive.  Hence, let's back off to doing this only when  
debug_invalidate_system_caches_always is at least 3; or in older  
branches, when CLOBBER_CACHE_RECURSIVELY is defined.  
  
While here, clean up some other minor issues in LookupOpclassInfo.  
Re-order the code so we aren't left with broken cache entries (leading  
to later core dumps) in the unlikely case that we suffer OOM while  
trying to allocate space for a new entry.  (That seems to be my  
oversight in 03ffc4d6d.)  Also, in >= v13, stop allocating one array  
entry too many.  That's evidently left over from sloppy reversion in  
851b14b0c.  
  
Back-patch to all supported branches, mainly to reduce the runtime  
of cache-clobbering buildfarm animals.  
  
Discussion: https://postgr.es/m/1370856.1625428625@sss.pgh.pa.us  

commit   : 9fa6fe466c9d2eaba4fdd8091203ee61e74d71bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 14:34:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Jul 2021 14:34:47 -0400    

In 741d7f104, I tried to make the reports from canceled steps come out  
after the pg_cancel_backend() steps, since that was the most common  
ordering before.  However, that doesn't ensure that a canceled step  
doesn't report even later, as shown in a recent failure on buildfarm  
member idiacanthus.  Rather than complicating things even more with  
additional annotations, let's just force the cancel's effect to be  
reported first.  It's not *that* unnatural-looking.  
  
Back-patch to v14 where these test cases appeared.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2021-07-02%2001%3A40%3A04  

commit   : 1479c5afdce2c57928dc1322bd71106858a0770f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Jul 2021 08:26:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Jul 2021 08:26:00 +0200    

commit   : f3690fbdeac43ab8547c212062ec515a55dd118c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 5 Jul 2021 09:38:17 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 5 Jul 2021 09:38:17 +0530    

A new chapter for Hash Indexes, designed to help users understand how  
they work and when to use them.  
  
Backpatch-through 10 where we have made hash indexes durable.  
  
Author: Simon Riggs  
Reviewed-By: Justin Pryzby, Amit Kapila  
Discussion: https://postgr.es/m/CANbhV-HRjNPYgHo--P1ewBrFJ-GpZPb9_25P7=Wgu7s7hy_sLQ@mail.gmail.com  

commit   : 95e2f925f1443f49b31e861a8d66dabca5528aaa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Jul 2021 20:59:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Jul 2021 20:59:10 +0900    

Author: Greg Sabino Mullane  
Discussion: https://postgr.es/m/CAKAnmmJYH2FBn_+Vwd2FD5SaKn8hjhAXOCHpZc6n4wXaUaW_SA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : b88e5fe60eef5decd3ccfd73566559dc6136cb61    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 22:29:16 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 4 Jul 2021 22:29:16 +1200    

Document that setting maintenance_work_mem to values over 1GB has no  
effect on VACUUM.  
  
Reported-by: Martín Marqués  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A%40mail.gmail.com  
Backpatch-through: 9.6, oldest supported release  

commit   : e033e260b9d0fcba969e5314be967429ade1b9ec    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 20:42:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 20:42:46 -0400    

Reported-by: tom@crystae.net  
  
Discussion: https://postgr.es/m/162345756191.14472.9754568432103008703@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : d54092955690e29656186ff5d4d315a3c56ccb37    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 18:00:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 18:00:30 -0400    

Reported-by: eric.mutta@gmail.com  
  
Discussion: https://postgr.es/m/162395467510.686.11947486273299446208@wrigleys.postgresql.org  
  
Backpatch-through: 14  

commit   : 63a952167092bd2d457691202d71ace943e1b06a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Jul 2021 16:04:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Jul 2021 16:04:54 -0400    

The existing code tried to do syscache lookups in an already-failed  
transaction, which is problematic to say the least.  After some  
consideration of alternatives, the best fix seems to be to just drop  
type names from the error message altogether.  The table and column  
names seem like sufficient localization.  If the user is unsure what  
types are involved, she can check the local and remote table  
definitions.  
  
Having done that, we can also discard the LogicalRepTypMap hash  
table, which had no other use.  Arguably, LOGICAL_REP_MSG_TYPE  
replication messages are now obsolete as well; but we should  
probably keep them in case some other use emerges.  (The complexity  
of removing something from the replication protocol would likely  
outweigh any savings anyhow.)  
  
Masahiko Sawada and Bharath Rupireddy, per complaint from Andres  
Freund.  Back-patch to v10 where this code originated.  
  
Discussion: https://postgr.es/m/20210106020229.ne5xnuu6wlondjpe@alap3.anarazel.de  

commit   : 56d467a07de1c203cfe78fea69cd8326fa297e23    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 14:46:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 2 Jul 2021 14:46:31 -0400    

Add items for vacuum not having to wait for CONCURRENTLY, and  
CONCURRENTLY not having to wait for other CONCURRENTLY operations.  
  
Reported-by: Simon Riggs  
  
Discussion: https://postgr.es/m/CANbhV-EMM4nf7Ys-Yae_kY25dXT_3eiOXke2+yw44jgy+4jNsA@mail.gmail.com  
  
Backpatch-through: 14 only  

commit   : a3a681f8590d9476c8ce94172316d3d339375fe6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Jul 2021 20:33:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 1 Jul 2021 20:33:32 -0400    

Mostly addition of <literal> tags  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210629022547.GF21248@telsasoft.com  
  
Backpatch-through: 14 only  

commit   : fb72a7b8c384e25d752b22a69e77d8227af65b4b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 22:23:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 22:23:37 +0200    

commit   : 1da2ea0cccc7f9ce5eed3d6e62cba785e82a6a0d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 15:38:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 15:38:06 -0400    

commit   : 46bbe5d777722938496f177706cc87ff64512def    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 21:27:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Jul 2021 21:27:39 +0200    

commit   : 100e9ae53f210c9e82671f1cc554aca945c4c180    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 14:21:09 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 14:21:09 -0400    

These are the same as world and install-world respectively, but without  
building or installing the documentation. There are many reasons for  
wanting to be able to do this, including speed, lack of documentation  
building tools, and wanting to build other formats of the documentation.  
Plans for simplifying the buildfarm client code include using these  
targets.  
  
Backpatch to all live branches.  
  
Discussion: https://postgr.es/m/6a421136-d462-b043-a8eb-e75b2861f3df@dunslane.net  

commit   : d0477080174b227e6f5cbe0dd10c4d79abb7f3e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jul 2021 13:33:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Jul 2021 13:33:05 -0400    

Commit 4656e3d66 replaced the "#define CLOBBER_CACHE_ALWAYS"  
testing mechanism with a GUC, which has been a great help for  
doing cache-clobber testing in more efficient ways; but there  
is a gap in the implementation.  The only way to do cache-clobber  
testing during an initdb run is to use the old method with #define,  
because one can't set the GUC from outside.  Improve this by  
adding a switch to initdb for the purpose.  
  
(Perhaps someday we should let initdb pass through arbitrary  
"-c NAME=VALUE" switches.  Quoting difficulties dissuaded me  
from attempting that right now, though.)  
  
Back-patch to v14 where 4656e3d66 came in.  
  
Discussion: https://postgr.es/m/1582507.1624227029@sss.pgh.pa.us  

commit   : be280cdad2985749e558212b0a5c8bdf9abb4e6a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Jul 2021 12:56:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Jul 2021 12:56:30 -0400    

Commit 0e69f705cc1a introduced code to analyze partitioned table;  
however, that code fails to preserve pg_class.relhasindex correctly.  
Fix by observing whether any indexes exist rather than accidentally  
falling through to assuming none do.  
  
Backpatch to 14.  
  
Author: Alexander Pyhalov <a.pyhalov@postgrespro.ru>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Zhihong Yu <zyu@yugabyte.com>  
Discussion: https://postgr.es/m/CALNJ-vS1R3Qoe5t4tbzxrkpBtzRbPq1dDcW4RmA_a+oqweF30w@mail.gmail.com  

commit   : c4774ce339beff4a8968ceecb86bbbfa3335ed2b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 08:29:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 1 Jul 2021 08:29:10 -0400    

The prove_installcheck recipe in src/Makefile.global.in was emitting  
bogus paths for a couple of elements when used with PGXS. Here we create  
a separate recipe for the PGXS case that does it correctly. We also take  
the opportunity to make the make the file more readable by breaking up  
the prove_installcheck and prove_check recipes across several lines, and  
to remove the setting for REGRESS_SHLIB to src/test/recovery/Makefile,  
which is the only set of tests that actually need it.  
  
Backpatch to all live branches  
  
Discussion: https://postgr.es/m/f2401388-936b-f4ef-a07c-a0bcc49b3300@dunslane.net  

commit   : a9cb00a965c6ac0cd434733fae0948218702e501    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 11:40:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 11:40:06 +0530    

A few variables have been using 10 as a magic constant while  
PG_STAT_GET_REPLICATION_SLOT_COLS can be used instead.  
  
Author: Masahiko Sawada  
Reviewed-By: Amit Kapila  
Backpatch-through: 14, where it was introduced  
Discussion: https://postgr.es/m/CAD21AoBvqODDfmD17DkEuPCvV2KbruukXQ2Vwrv5Xi-TsAsTJA@mail.gmail.com  

commit   : dfceed30abc191c097557357dd6db56e875bb7e1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 09:48:07 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 30 Jun 2021 09:48:07 +0530    

Until now, we didn't allow to stream the changes in logical replication  
till we receive speculative confirm or the next DML change record after  
speculative inserts. The reason was that we never use to process  
speculative aborts but after commit 4daa140a2f it is possible to process  
them so we can allow streaming once we receive speculative abort after  
speculative insertion.  
  
We decided to backpatch to 14 where the feature for streaming in progress  
transactions have been introduced as this is a minor change and makes that  
functionality better.  
  
Author: Amit Kapila  
Reviewed-By: Dilip Kumar  
Backpatch-through: 14  
Discussion: https://postgr.es/m/CAA4eK1KdqmTCtrBR6oFfGELrLLbDLDedL6zACcsUOQuTJBj1vw@mail.gmail.com  

commit   : 607a3a43bca573a02570f374fd98c82a0c2e12a1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 11:49:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Jun 2021 11:49:10 +0900    

Reaching PITR on such a transaction would cause the generation of a LOG  
message mentioning a transaction committed, not aborted.  
  
Oversight in 4f1b890.  
  
Author: Simon Riggs  
Discussion: https://postgr.es/m/CANbhV-GJ6KijeCgdOrxqMCQ+C8QiK657EMhCy4csjrPcEUFv_Q@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 322e82b77ef4acb9697c6e4259292f5671cb85bb    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Jun 2021 23:18:09 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 29 Jun 2021 23:18:09 +0300    

 * Fix enumeration of the multirange operators in calc_multirangesel() and  
   calc_multirangesel() switches.  
 * Add more regression tests for matching to empty ranges/multiranges.  
  
Reported-by: Alexander Lakhin  
Discussion: https://postgr.es/m/c5269c65-f967-77c5-ff7c-15e621c47f6a%40gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 14, where multiranges were introduced  

commit   : 690339fcd58759d213523f87071f992c4402e980    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 15:01:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 15:01:29 -0400    

The original coding required that PQpipelineSync had been called before  
the first call to PQgetResult, and failure to do that would result in an  
unexpected NULL result being returned.  Fix by setting the right state  
when a query is sent, rather than leaving it unchanged and having  
PQpipelineSync apply the necessary state change.  
  
A new test case to verify the behavior is added, which relies on the new  
PQsendFlushRequest() function added by commit a7192326c74d.  
  
Backpatch to 14, where pipeline mode was added.  
  
Reported-by: Boris Kolpackov <boris@codesynthesis.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/boris.20210616110321@codesynthesis.com  

commit   : 69cf1d5429d48d030d71d5dd4931084d422413cb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 14:37:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Jun 2021 14:37:39 -0400    

This new libpq function allows the application to send an 'H' message,  
which instructs the server to flush its outgoing buffer.  
  
This hasn't been needed so far because the Sync message already requests  
a buffer; and I failed to realize that this was needed in pipeline mode  
because PQpipelineSync also causes the buffer to be flushed.  However,  
sometimes it is useful to request a flush without establishing a  
synchronization point.  
  
Backpatch to 14, where pipeline mode was introduced in libpq.  
  
Reported-by: Boris Kolpackov <boris@codesynthesis.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106252350.t76x73nt643j@alvherre.pgsql  

commit   : f8b51464c265696c1eab1c896bddc797beb9a13c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 14:34:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Jun 2021 14:34:31 -0400    

Commit efbfb6424 added logic for reporting exactly which existing  
partition conflicts when complaining that a new hash partition's  
modulus isn't compatible with the existing ones.  However, it  
misunderstood the partitioning data structure, and would select  
the wrong partition in some cases, or crash outright due to fetching  
a bogus table OID in other cases.  
  
Per bug #17076 from Alexander Lakhin.  Fix by Amit Langote;  
some further work on the code comments by me.  
  
Discussion: https://postgr.es/m/17076-89a16ae835d329b9@postgresql.org  

commit   : caa0f07d2d4b69cd53b5bf7c847d9d65eadbbfee    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 Jun 2021 20:58:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 28 Jun 2021 20:58:47 -0400    

Mostly markup improvements.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210625230456.GP29179@telsasoft.com  
  
Backpatch-through: 14 only  

commit   : cf1f545bf281d3dcb7b44e6b7f21a9369024fbf0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 14:17:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 14:17:42 -0400    

Causing a core dump on out-of-memory seems pretty unfriendly,  
and surely is far outside the expected behavior of a general-purpose  
library.  Just print an error message (as we did already) and return.  
These functions unfortunately don't have an error return convention,  
but code using them is probably just looking for a quick-n-dirty  
print method and wouldn't bother to check anyway.  
  
Although these functions are semi-deprecated, it still seems  
appropriate to back-patch this.  In passing, also back-patch  
b90e6cef1, just to reduce cosmetic differences between the  
branches.  
  
Discussion: https://postgr.es/m/3122443.1624735363@sss.pgh.pa.us  

commit   : 203c5aaaba56715168c1e80a45d4929120c9281b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 12:40:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jun 2021 12:40:37 -0400    

Instead use the common/int.h functions to check for integer overflow  
in a more C-standard-compliant fashion.  This is motivated by recent  
failures on buildfarm member moonjelly, where it appears that  
development-tip gcc is optimizing without regard to the -fwrapv  
switch.  Presumably that's a gcc bug that will be fixed soon, but  
we might as well install cleaner coding here rather than wait.  
  
(This does not address the question of whether we'll ever be able  
to get rid of using -fwrapv.  Testing shows that this spot is the  
only place where doing so creates visible regression test failures,  
but unfortunately that proves very little.)  
  
Back-patch to v12.  The common/int.h functions exist in v11, but  
that branch doesn't use them in any client-side code.  I judge  
that this case isn't interesting enough in the real world to take  
even a small risk of issues from being the first such use.  
  
Tom Lane and Fabien Coelho  
  
Discussion: https://postgr.es/m/73927.1624815543@sss.pgh.pa.us  

commit   : e1c1c30f635390b6a3ae4993e8cac213a33e6e3f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Jun 2021 11:05:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Jun 2021 11:05:54 -0400    

Along the way make a slight adjustment to  
src/include/utils/queryjumble.h to avoid an unused typedef.  

commit   : c31833779d5a4775d7220be4b9143bec66c9a9fd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 28 Jun 2021 08:36:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 28 Jun 2021 08:36:44 +0200    

commit   : ee3fdb8f3465b3a5937a7fe647b7b6584a600647    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 10:56:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 10:56:53 +0530    

We were using RelationGetIndexList() to update the relation's replica  
identity index but instead, we can directly use RelationGetReplicaIndex()  
which uses the same functionality. This is a minor code readability  
improvement.  
  
Author: Japin Li  
Reviewed-By: Takamichi Osumi, Amit Kapila  
Discussion: https://postgr.es/m/4C99A862-69C8-431F-960A-81B1151F1B89@enterprisedb.com  

commit   : b786304c2904a4e444fe740bbc2e0b69efacc19d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 09:29:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 28 Jun 2021 09:29:38 +0530    

When we cannot immediately acquire XactSLRULock in exclusive mode at  
commit time, we add ourselves to a list of processes that need their XIDs  
status update. We do this if the clog page where we need to update the  
current transaction status is the same as the group leader's clog page,  
otherwise, we allow the caller to clear it by itself. Now, when we can't  
add ourselves to any group, we were not clearing the current proc if it  
has already become a member of some group which was leading to an  
assertion failure when the same proc was assigned to another backend after  
the current backend exits.  
  
Reported-by: Alexander Lakhin  
Bug: 17072  
Author: Amit Kapila  
Tested-By: Alexander Lakhin  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/17072-2f8764857ef2c92a@postgresql.org  

commit   : 34a8b64b4e5f0cd818e5cc7f98846de57938ea57    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 28 Jun 2021 15:17:43 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 28 Jun 2021 15:17:43 +1200    

The setting has no effect except during startup.  It's still nice to be  
able to change it dynamically, which is expected to be pretty useful to  
an admin following crash recovery when restarting the cluster is not so  
appealing.  
  
Per discussions following commits 2941138e6 and 61752afb2.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>  
Discussion: https://postgr.es/m/20210529192321.GM2082%40telsasoft.com  

commit   : 79718c1c6c007c27e9c1b8e92bd96d17067606fa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 12:11:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 12:11:18 +0900    

copy_data is not a supported option with this sub-command of ALTER  
SUBSCRIPTION, which would not make a variable related to it initialized  
after parsing the option set in DefElems.  A refresh could then refer to  
it.  
  
Author: Ranier Vilela  
Reviewed-by: Peter Smith  
Discussion: https://postgr.es/m/CAEudQAp5P8nr=ze2Gv=BMj=DJFZnrvendZCZcC-fos3QiDe2sg@mail.gmail.com  

commit   : 09a69f6e23369847cf11cd03c999a0342d47bbcc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 11:17:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Jun 2021 11:17:05 +0900    

83158f7 has improved index_set_state_flags() so as it is possible to use  
transactional updates when updating pg_index state flags, but there was  
not really a test case which stressed directly the possibility it fixed.  
This commit adds such a test, using a predicate that looks valid in  
appearance but calls a stable function.  
  
Author: Andrey Lepikhov  
Discussion: https://postgr.es/m/9b905019-5297-7372-0ad2-e1a4bb66a719@postgrespro.ru  
Backpatch-through: 9.6  

commit   : 642c0697c96b9c6ba5d194653a329f7820565f01    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Jun 2021 12:45:04 -0400    

specscanner.l leaked a kilobyte of memory per token of the spec file.  
Apparently somebody thought that the introductory code block would be  
executed once; but it's once per yylex() call.  
  
A couple of functions in isolationtester.c leaked small amounts of  
memory due to not bothering to free one-time allocations.  Might  
as well improve these so that valgrind gives this program a clean  
bill of health.  Also get rid of an ugly static variable.  
  
Coverity complained about one of the one-time leaks, which led me  
to try valgrind'ing isolationtester, which led to discovery of the  
larger leak.  

commit   : c302a6139072fed9410204fa9e751d95930e05ff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 27 Jun 2021 09:41:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 27 Jun 2021 09:41:16 +0200    

Take some untranslatable things out of the message and replace by  
format placeholders, to reduce translatable strings and reduce  
translation mistakes.  

commit   : dcffc9ba8a1e0ab1b0a57e9b9d38e3dc9960f83f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 15:45:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 15:45:16 -0400    

commit   : 8ec00dc5cd70e0e579e9fbf8661bc46f5ccd8078    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 14:20:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Jun 2021 14:20:17 -0400    

Commit c0cb87fbb unwisely introduced a dependency on the StringInfo  
machinery in fe-connect.c.  We must not use that in libpq, because  
it will do a summary exit(1) if it hits OOM, and that is not  
appropriate behavior for a general-purpose library.  The goal of  
allowing arbitrary line lengths in service files doesn't seem like  
it's worth a lot of effort, so revert back to the previous method  
of using a stack-allocated buffer and failing on buffer overflow.  
  
This isn't an exact revert though.  I kept that patch's refactoring  
to have a single exit path, as that seems cleaner than having each  
error path know what to do to clean up.  Also, I made the fixed-size  
buffer 1024 bytes not 256, just to push off the need for an expandable  
buffer some more.  
  
There is more to do here; in particular the lack of any mechanical  
check for this type of mistake now seems pretty hazardous.  But this  
fix gets us back to the level of robustness we had in v13, anyway.  
  
Discussion: https://postgr.es/m/daeb22ec6ca8ef61e94d766a9b35fb03cabed38e.camel@vmware.com  

commit   : d5a2c413fcdd187dc16c4fab16610af7d4849cc1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 13:52:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 13:52:48 +0900    

The version string is grabbed from PACKAGE_VERSION in pg_config.h in the  
MSVC build since 8f4fb4c6, but an error message referenced a variable  
that existed before that.  This had no consequences except if one messes  
up enough with the version number of the build.  
  
Author: Anton Voloshin  
Discussion: https://postgr.es/m/af79ee1b-9962-b299-98e1-f90a289e19e6@postgrespro.ru  
Backpatch-through: 13  

commit   : 704e1dbd9aa29a0b46c356f1803ad55cbdef2c20    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 12:39:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 26 Jun 2021 12:39:54 +0900    

002_pgbench_no_server was printing some array pointers instead of the  
actual contents of those arrays for the expected outputs of stdout and  
stderr for a tested command.  This does not add any new information that  
can help with debugging as the test names allow to track failure  
locations, if any.  
  
This commit simply removes those logs as the rest of the printed  
information is redundant with command_checks_all().  
  
Per discussion with Andrew Dunstan and Álvaro Herrera.  
  
Discussion: https://postgr.es/m/YNXNFaG7IgkzZanD@paquier.xyz  
Backpatch-through: 11  

commit   : 5a0f1c8c0193f0dd7fba50c22d96781fa2414007    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 13:59:38 -0400    

It's not really necessary for this function to open or lock the  
relation associated with the pg_policy entry it's modifying.  The  
error checks it's making on the rel are if anything counterproductive  
(e.g., if we don't want to allow installation of policies on system  
catalogs, here is not the place to prevent that).  In particular, it  
seems just wrong to insist on an ownership check.  That has the net  
effect of forcing people to use superuser for DROP OWNED BY, which  
surely is not an effect we want.  Also there is no point in rebuilding  
the dependencies of the policy expressions, which aren't being  
changed.  Lastly, locking the table also seems counterproductive; it's  
not helping to prevent race conditions, since we failed to re-read the  
pg_policy row after acquiring the lock.  That means that concurrent  
DDL would likely result in "tuple concurrently updated/deleted"  
errors; which is the same behavior this code will produce, with less  
overhead.  
  
Per discussion of bug #17062.  Back-patch to all supported versions,  
as the failure cases this eliminates seem just as undesirable in 9.6  
as in HEAD.  
  
Discussion: https://postgr.es/m/1573181.1624220108@sss.pgh.pa.us  

commit   : 8a80562d732c0da1ddcc9fb88dfb976f4b846577    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 11:18:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jun 2021 11:18:15 -0400    

Now that this has been back-patched, it's no longer a new feature  
for v14.  

commit   : 38ff135d9466c35b506b1049fedef73047907be0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 20:15:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 20:15:24 +0900    

This fixes a couple of problems within the so-said code of this commit  
subject:  
- Replace the use of open() with slurp_file(), fixing an issue reported  
by buildfarm member fairywren whose perl installation keep around CRLF  
characters, causing the matching patterns for the logs to fail.  
- Remove the eval block, which is not really necessary.  
  
This set of issues has come into light after fixing a different issue  
with c13585fe, and this is wrong since this code has been introduced.  
  
Reported-by: Andrew Dunstan, and buildfarm member fairywren  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/0f49303e-7784-b3ee-200b-cbf67be2eb9e@dunslane.net  
Backpatch-through: 11  

commit   : 3af10943ce21450e299b3915b9cad47cd90369e9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 11:40:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 11:40:06 +0200    

commit   : e59d428f34297cd0eb67e3b4e4b8c8bc58504921    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 09:51:24 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 09:51:24 +0200    

ALTER SUBSCRIPTION DROP PUBLICATION does not actually support  
copy_data option, so remove it from tab completion.  
  
Also, reword the error message that is thrown when all the  
publications from a subscription are specified to be dropped.  
  
Also, made few doc and cosmetic adjustments.  
  
Author: Vignesh C <vignesh21@gmail.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>  
Reviewed-by: Japin Li <japinli@hotmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CALDaNm21RwsDzs4xj14ApteAF7auyyomHNnp+NEL-sH8m-jMvQ@mail.gmail.com  

commit   : 63e6d05bf34da58eef7cd1ed461b9c8315177a38    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 08:11:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 08:11:10 +0200    

Use "floating point" rather than "float4", like everywhere else in  
this context.  
  
Author: Shinya11.Kato@nttdata.com  
Discussion: https://www.postgresql.org/message-id/flat/TYAPR01MB28965989AF84B57FC351B97BC40F9@TYAPR01MB2896.jpnprd01.prod.outlook.com  

commit   : a60c4c5c1a99746485123ae93fbd3e58c78e5d62    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 07:55:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Jun 2021 07:55:34 +0200    

In gistinitpage, pageSize variable looks redundant, instead just  
pass BLCKSZ. This will be consistent with its peers BloomInitPage,  
brin_page_init and SpGistInitPage.  
  
Author: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>  
Discussion: https://www.postgresql.org/message-id/flat/CALj2ACWj=V1k5591eeZK2sOg2FYuBUp6azFO8tMkBtGfXf8PMQ@mail.gmail.com  

commit   : 847c62ee76cbc237b3a204ca94b1b12811d698e3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Jun 2021 08:22:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Jun 2021 08:22:44 +0530    

Author: Guillaume Lelarge  
Discussion: https://www.postgresql.org/message-id/CAECtzeXf3_oZoU6mgFCOy5+pDZ5n4XtH0Da4a5n_KacraVWiHQ@mail.gmail.com  

commit   : 15ff5401d1719aaf6c9a47e5abea517cc2bcbaf1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 11:29:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 11:29:03 +0900    

This adds MITM and SNI as acronyms, as the documentation already had  
them marked up with <acronym>.  
  
While on it, make sure to spell man-in-the-middle with dashes  
consistently, and add acronyms for those new terms where appropriate.  
  
Author: Daniel Gustafsson  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se  

commit   : 87b2124dfa0782a697ea7b90aff15a6f6117a720    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 09:56:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 09:56:44 +0900    

fairywren is not happy with the pattern checks introduced by c13585f.  
I am not sure if this outlines a bug in pgbench or if the regex patterns  
used in the tests are too restrictive for this buildfarm member's  
environment.  This adds more debugging information to show the log  
entries that do not match with the expected pattern, to help in finding  
out what's happening.  That seems like a good addition in the long-term  
anyway as that may not be the only issue in this area.  
  
Discussion: https://postgr.es/m/YNUad2HvgW+6eXyo@paquier.xyz  

commit   : 797b0fc0b078c7b4c46ef9f2d9e47aa2d98c6c63    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 08:40:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 08:40:16 +0900    

The main goal of this option is to allow inspecting temporary files for  
debugging purposes, so moving the parameter there is natural.  
  
Oversight in cd91de0.  
  
Reported-by: Justin Pryzby  
Author: Euler Taveira  
Discussion: https://postgr.es/m/20210612004347.GP16435@telsasoft.com  

commit   : 9b4e4cfe66ff133717c1b8ba3c2725d525c3e67c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 25 Jun 2021 09:55:26 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 25 Jun 2021 09:55:26 +1200    

LLVM 13 (due out in September) has changed the semantics of  
LLVMOrcAbsoluteSymbols(), so we need to bump some reference counts to  
avoid a double-free that causes crashes and bad query results.  
  
A proactive change seems necessary to avoid having a window of time  
where our respective latest releases would interact badly.  It's  
possible that the situation could change before then, though.  
  
Thanks to Fabien Coelho for monitoring bleeding edge LLVM and Andres  
Freund for tracking down the change.  
  
Back-patch to 11, where the JIT code arrived.  
  
Discussion: https://postgr.es/m/CA%2BhUKGLEy8mgtN7BNp0ooFAjUedDTJj5dME7NxLU-m91b85siA%40mail.gmail.com  

commit   : c13585fe9e55813cf9feac67fe7b65d3a78fff92    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 06:52:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Jun 2021 06:52:36 +0900    

The logic checking for the format of per-thread logs used grep() with  
directly "$re", which would cause the test to consider all the logs as  
a match without caring about their format at all.  Using "/$re/" makes  
grep() perform a regex test, which is what we want here.  
  
While on it, improve some of the tests to be more picky with the  
patterns expected and add more comments to describe the tests.  
  
Issue discovered while digging into a separate patch.  
  
Author: Fabien Coelho, Michael Paquier  
Discussion: https://postgr.es/m/YNPsPAUoVDCpPOGk@paquier.xyz  
Backpatch-through: 11  

commit   : 802177090992511c610804da54a4603d4f50c594    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Jun 2021 15:02:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Jun 2021 15:02:13 -0400    

The queries involving ft1_nopw don't stably return the same row  
anymore.  I surmise that an autovacuum hitting "S 1"."T 1"  
right after the updates introduced by f61db909d/5843659d0 freed  
some space, changing where subsequent insertions get stored.  
It's only by good luck that these results were stable before,  
though, since a LIMIT without ORDER BY isn't well defined,  
and it's not like we've ever treated that table as append-only  
in this test script.  
  
Since we only really care whether these commands succeed or not,  
just replace "SELECT *" with "SELECT 1".  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2021-06-23%2019%3A52%3A08  

commit   : 9b8ed0f52bffceaccf6fa650ffe482e7da20fbf2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 11:19:03 +0300    

In previous commit, I missed that relmap_redo() was also not acquiring the  
RelationMappingLock. Thanks to Thomas Munro for pointing that out.  
  
Backpatch-through: 9.6, like previous commit.  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGLev%3DPpOSaL3WRZgOvgk217et%2BbxeJcRr4eR-NttP1F6Q%40mail.gmail.com  

commit   : b6d8d2073f228d9f7198f1f9826d8f6ab643c219    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 24 Jun 2021 10:45:23 +0300    

Contrary to the comment here, POSIX does not guarantee atomicity of a  
read(), if another process calls write() concurrently. Or at least Linux  
does not. Add locking to load_relmap_file() to avoid the race condition.  
  
Fixes bug #17064. Thanks to Alexander Lakhin for the report and test case.  
  
Backpatch-through: 9.6, all supported versions.  
Discussion: https://www.postgresql.org/message-id/17064-bb0d7904ef72add3@postgresql.org  

commit   : f08722cf83ab1fabee948a4e5754bf6236ad700b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 11:51:58 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 11:51:58 +0530    

Commits 9de77b5453 and ac4645c015 missed to update the logical replication  
message formats section in the docs.  
  
Author: Brar Piening  
Reviewed-by: Amit Kapila  
Discussion: https://www.postgresql.org/message-id/cc70956c-e578-e54f-49e6-b5d68c89576f@gmx.de  

commit   : c66fb78ebb4f473bb4fd8773de3cda9339e14f81    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 09:13:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 24 Jun 2021 09:13:46 +0530    

Reported-by: Simon Riggs  
Author: Takamichi Osumi  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky@alap3.anarazel.de  

commit   : a443c1b2d6a646cf90a8afc193c07ed12a2bf045    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 18:41:39 -0400    

For no obvious reason, isolationtester has always insisted that  
session and step names be written with double quotes.  This is  
fairly tedious and does little for test readability, especially  
since the names that people actually choose almost always look  
like normal identifiers.  Hence, let's tweak the lexer to allow  
SQL-like identifiers not only double-quoted strings.  
  
(They're SQL-like, not exactly SQL, because I didn't add any  
case-folding logic.  Also there's no provision for U&"..." names,  
not that anyone's likely to care.)  
  
There is one incompatibility introduced by this change: if you write  
"foo""bar" with no space, that used to be taken as two identifiers,  
but now it's just one identifier with an embedded quote mark.  
  
I converted all the src/test/isolation/ specfiles to remove  
unnecessary double quotes, but stopped there because my  
eyes were glazing over already.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/759113.1623861959@sss.pgh.pa.us  

commit   : 2031e1668e5577e64cfed29da69a34903d5a5227    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:27:13 -0400    

The syntax summaries for CREATE FUNCTION and allied commands  
made it look like LEAKPROOF is an alternative to  
IMMUTABLE/STABLE/VOLATILE, when of course it is an orthogonal  
option.  Improve that.  
  
Per gripe from aazamrafeeque0.  Thanks to David Johnston for  
suggestions.  
  
Discussion: https://postgr.es/m/162444349581.694.5818572718530259025@wrigleys.postgresql.org  

commit   : 126cdaf47af275f76b2f2ddb023bfdc6f018ae30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:01:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 14:01:32 -0400    

Our uses of gss_display_status() and gss_display_name() assumed  
that the gss_buffer_desc strings returned by those functions are  
null-terminated.  It appears that they generally are, given the  
lack of field complaints up to now.  However, the available  
documentation does not promise this, and some man pages  
for gss_display_status() show examples that rely on the  
gss_buffer_desc.length field instead of expecting null  
termination.  Also, we now have a report that on some  
implementations, clang's address sanitizer is of the opinion  
that the byte after the specified length is undefined.  
  
Hence, change the code to rely on the length field instead.  
  
This might well be cosmetic rather than fixing any real bug, but  
it's hard to be sure, so back-patch to all supported branches.  
While here, also back-patch the v12 changes that made pg_GSS_error  
deal honestly with multiple messages available from  
gss_display_status.  
  
Per report from Sudheer H R.  
  
Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com  

commit   : 4a054069a36032a59afceb07f3b837f09ab1a2e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 11:12:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jun 2021 11:12:31 -0400    

Previously, isolationtester displayed SQL query results using some  
ad-hoc code that clearly hadn't had much effort expended on it.  
Field values longer than 14 characters weren't separated from  
the next field, and usually caused misalignment of the columns  
too.  Also there was no visual separation of a query's result  
from subsequent isolationtester output.  This made test result  
files confusing and hard to read.  
  
To improve matters, let's use libpq's PQprint() function.  Although  
that's long since unused by psql, it's still plenty good enough  
for the purpose here.  
  
Like 741d7f104, back-patch to all supported branches, so that this  
isn't a stumbling block for back-patching isolation test changes.  
  
Discussion: https://postgr.es/m/582362.1623798221@sss.pgh.pa.us  

commit   : 24043c27b46f873211177e3460ab09dc011802a5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 23 Jun 2021 09:53:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 23 Jun 2021 09:53:18 -0400    

The code to signal a running walsender when its reserved WAL size grows  
too large is completely uncovered before this commit; this adds coverage  
for that case.  
  
This test involves sending SIGSTOP to walsender and walreceiver, then  
advancing enough WAL for a checkpoint to trigger, then sending SIGCONT.  
  
There's no precedent for STOP signalling in Perl tests, and my reading  
of relevant manpages says it's likely to fail on Windows.  Because of  
this, this test is always skipped on that platform.  
  
This version fixes a couple of rarely hit race conditions in the  
previous attempt 09126984a263; most notably, both LOG string searches  
are loops, not just the second one; we acquire the start-of-log position  
before STOP-signalling; and reference the correct process name in the  
test description.  All per Tom Lane.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106102202.mjw4huiix7lo@alvherre.pgsql  

commit   : 741d7f1047fe52da7ced6fa9cea661ce9320c8d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 21:43:12 -0400    

We've long contended with isolation test results that aren't entirely  
stable.  Some test scripts insert long delays to try to force stable  
results, which is not terribly desirable; but other erratic failure  
modes remain, causing unrepeatable buildfarm failures.  I've spent a  
fair amount of time trying to solve this by improving the server-side  
support code, without much success: that way is fundamentally unable  
to cope with diffs that stem from chance ordering of arrival of  
messages from different server processes.  
  
We can improve matters on the client side, however, by annotating  
the test scripts themselves to show the desired reporting order  
of events that might occur in different orders.  This patch adds  
three types of annotations to deal with (a) test steps that might or  
might not complete their waits before the isolationtester can see them  
waiting; (b) test steps in different sessions that can legitimately  
complete in either order; and (c) NOTIFY messages that might arrive  
before or after the completion of a step in another session.  We might  
need more annotation types later, but this seems to be enough to deal  
with the instabilities we've seen in the buildfarm.  It also lets us  
get rid of all the long delays that were previously used, cutting more  
than a minute off the runtime of the isolation tests.  
  
Back-patch to all supported branches, because the buildfarm  
instabilities affect all the branches, and because it seems desirable  
to keep isolationtester's capabilities the same across all branches  
to simplify possible future back-patching of tests.  
  
Discussion: https://postgr.es/m/327948.1623725828@sss.pgh.pa.us  

commit   : d102aafb6259a6a412803d4b1d8c4f00aa17f67e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 17:48:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jun 2021 17:48:39 -0400    

Commits 84f5c2908 et al missed the need to cover plpgsql's "simple  
expression" code path.  If the first thing we execute after a  
COMMIT/ROLLBACK is one of those, rather than a full-fledged SPI command,  
we must explicitly do EnsurePortalSnapshotExists() to make sure we have  
an outer snapshot.  Note that it wouldn't be good enough to just push a  
snapshot for the duration of the expression execution: what comes back  
might be toasted, so we'd better have a snapshot protecting it.  
  
The test case demonstrating this fact cheats a bit by marking a SQL  
function immutable even though it fetches from a table.  That's  
nothing that users haven't been seen to do, though.  
  
Per report from Jim Nasby.  Back-patch to v11, like the previous fix.  
  
Discussion: https://postgr.es/m/378885e4-f85f-fc28-6c91-c4d1c080bf26@amazon.com  

commit   : 8e638845ff6bb255ad1dea15831089a234535391    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 22 Jun 2021 09:06:32 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 22 Jun 2021 09:06:32 -0700    

Add a .git-blame-ignore-revs file with a list of pgindent, pgperlyidy,  
and reformat-dat-files commit hashes.  Postgres hackers that configure  
git to use the ignore file will get git-blame output that avoids  
attributing line changes to the ignored indent commits.  This makes  
git-blame output much easier to work with in practice.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAH2-Wz=cVh3GHTP6SdLU-Gnmt2zRdF8vZkcrFdSzXQ=WhbWm9Q@mail.gmail.com  

commit   : bafad2c5b261a1449bed60ebac9e7918ebcc42b4    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 21 Jun 2021 17:07:55 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 21 Jun 2021 17:07:55 -0400    

commit   : 5a1e1d83022b976ebdec5cfa8f255c4278b75b8e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 21 Jun 2021 05:13:46 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 21 Jun 2021 05:13:46 -0700    

In dc7420c2c92 I (Andres) accidentally used  
RelationIsAccessibleInLogicalDecoding() as the sole condition to use the  
non-shared catalog horizon in GetOldestNonRemovableTransactionId(). That is  
incorrect, as RelationIsAccessibleInLogicalDecoding() checks whether wal_level  
is logical.  
  
The correct check, as done e.g. in GlobalVisTestFor(), is to check  
IsCatalogRelation() and RelationIsAccessibleInLogicalDecoding().  
  
The observed misbehavior of this bug was that there could be an endless loop  
in lazy_scan_prune(), because the horizons used in heap_page_prune() and the  
individual tuple liveliness checks did not match. Likely there are other  
potential consequences as well.  
  
A later commit will unify the determination which horizon has to be used, and  
add additional assertions to make it easier to catch a bug like this.  
  
Reported-By: Justin Pryzby <pryzby@telsasoft.com>  
Diagnosed-By: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Discussion: https://postgr.es/m/CAEze2Wg32Y9+WJfw=aofkRx1ZRFt_Ev6bNPc4PSaz7PjSFtZgQ@mail.gmail.com  

commit   : 8d29d45d9b3cab95a866efbcdd9138b3d76741b3    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Jun 2021 23:11:23 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 21 Jun 2021 23:11:23 +1200    

linitial_node() fails in assert enabled builds if the given pointer is  
not of the specified type.  Here the type is IntList.  The code thought  
it should be expecting List, but it was wrong.  
  
In the existing tests which run this code the initial list element is  
always NIL.  Since linitial_node() allows NULL, we didn't trigger any  
assert failures in the existing regression tests.  
  
There is still some discussion as to whether we need a few more tests in  
this area, but for now, since beta2 is looming, fix the bug first.  
  
Bug: #17067  
Discussion: https://postgr.es/m/17067-665d50fa321f79e0@postgresql.org  
Reported-by: Yaoguang Chen  

commit   : a7bb0ce58f56ee8907c3f49c52d99f502536c796    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 12:32:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 12:32:14 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 70796ae860c444c764bb591c885f22cac1c168ec  

commit   : 047a259e35b9dde2dad5fd0e5d5d784bb327b848    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 21 Jun 2021 02:48:11 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 21 Jun 2021 02:48:11 -0700    

Jie Zhang  
  
Discussion: https://postgr.es/m/TYWPR01MB767844835390EDD8DB276D75F90A9@TYWPR01MB7678.jpnprd01.prod.outlook.com  

commit   : 97b7134186490b36e01efc9d2feaf7038c666457    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 11:17:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 21 Jun 2021 11:17:49 +0200    

Code comments were claiming that verify_heapam() was checking  
privileges on the relation it was operating on, but it didn't actually  
do that.  Perhaps earlier versions of the patch did that, but now the  
access is regulated by privileges on the function.  Remove the wrong  
comments.  

commit   : 69a58bfe4ab05567a8fab8bdce7f3095ed06b99c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 21 Jun 2021 01:09:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 21 Jun 2021 01:09:32 -0400    

commit   : 90855908b751d40f67352fa0252e0fcdaa7e317b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 20 Jun 2021 23:53:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 20 Jun 2021 23:53:00 -0400    

Reported-by: Masahiko Sawada  
  
Discussion: https://postgr.es/m/CAD21AoCTHyouoGv-xt1qNjjvPbGMErLi0AJncByTvr66Nq7j8g@mail.gmail.com  

commit   : e8f201ab82be234b2f103234cf9f262f9afeaeba    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 20 Jun 2021 18:14:00 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 20 Jun 2021 18:14:00 -0700    

The failsafe can trigger when index processing is already disabled.  
This can happen when VACUUM's INDEX_CLEANUP parameter is "off" and the  
failsafe happens to trigger.  Remove assertions that assume that index  
processing is directly tied to the failsafe.  
  
Oversight in commit c242baa4, which made it possible for the failsafe to  
trigger in a two-pass strategy VACUUM that has yet to make its first  
call to lazy_vacuum_all_indexes().  

commit   : 96795176810b979a2bf1f4563bdcb161679d5b95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 20 Jun 2021 12:28:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 20 Jun 2021 12:28:08 -0400    

This reverts commit 09126984a263; the test case added there failed once  
in circumstances that remain mysterious.  It seems better to remove the  
test for now so that 14beta2 doesn't have random failures built in.  

commit   : 5843659d091bfb6f2c60e010ea1fd00e55ee6ada    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Jun 2021 11:48:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Jun 2021 11:48:44 -0400    

Buildfarm members ayu and tern have sometimes shown a different  
plan than expected for this query.  I'd been unable to reproduce  
that before today, but I finally realized what is happening.  
If there is a concurrent open transaction (probably an autovacuum  
run in the buildfarm, but this can also be arranged manually),  
then the index entries for the rows removed by the DELETE a few  
lines up are not killed promptly, causing a change in the planner's  
estimate of the extremal value of ft2.c1, which moves the rowcount  
estimate for "c1 > 1100" by enough to change the join plan from  
nestloop to hash.  
  
To fix, change the query condition to "c1 > 1000", causing the  
hash plan to be preferred whether or not a concurrent open  
transaction exists.  Since this UPDATE is tailored to be a no-op,  
nothing else changes.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-09%2022%3A45%3A48  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=ayu&dt=2021-06-13%2022%3A38%3A18  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2021-06-20%2004%3A55%3A36  

commit   : 6991e774e0304f5ef488cf1ae4fa79578b6ae3d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jun 2021 11:44:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jun 2021 11:44:39 -0400    

We had a request to provide a way to test at compile time for the  
availability of the new pipeline features.  More generally, it  
seems like a good idea to provide a way to test via #ifdef for  
all new libpq API features.  People have been using the version  
from pg_config.h for that; but that's more likely to represent the  
server version than the libpq version, in the increasingly-common  
scenario where they're different.  It's safer if libpq-fe.h itself  
is the source of truth about what features it offers.  
  
Hence, establish a policy that starting in v14 we'll add a suitable  
feature-is-present macro to libpq-fe.h when we add new API there.  
(There doesn't seem to be much point in applying this policy  
retroactively, but it's not too late for v14.)  
  
Tom Lane and Alvaro Herrera, per suggestion from Boris Kolpackov.  
  
Discussion: https://postgr.es/m/boris.20210617102439@codesynthesis.com  

commit   : 2731ce1bd550d08f3fdd7bcb1497af4b95170976    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 19 Jun 2021 11:30:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 19 Jun 2021 11:30:33 +0530    

Commit e7eea52b2d has introduced a new function  
RelationGetIdentityKeyBitmap which omits to handle the case where there is  
no replica identity index on a relation.  
  
Author: Mark Dilger  
Reviewed-by: Takamichi Osumi, Amit Kapila  
Discussion: https://www.postgresql.org/message-id/4C99A862-69C8-431F-960A-81B1151F1B89@enterprisedb.com  

commit   : 3499df0dee8c4ea51d264a674df5b5e31991319a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 18 Jun 2021 20:04:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 18 Jun 2021 20:04:07 -0700    

Generalize the INDEX_CLEANUP VACUUM parameter (and the corresponding  
reloption): make it into a ternary style boolean parameter.  It now  
exposes a third option, "auto".  The "auto" option (which is now the  
default) enables the "bypass index vacuuming" optimization added by  
commit 1e55e7d1.  
  
"VACUUM (INDEX_CLEANUP TRUE)" is redefined to once again make VACUUM  
simply do any required index vacuuming, regardless of how few dead  
tuples are encountered during the first scan of the target heap relation  
(unless there are exactly zero).  This gives users a way of opting out  
of the "bypass index vacuuming" optimization, if for whatever reason  
that proves necessary.  It is also expected to be used by PostgreSQL  
developers as a testing option from time to time.  
  
"VACUUM (INDEX_CLEANUP FALSE)" does the same thing as it always has: it  
forcibly disables both index vacuuming and index cleanup.  It's not  
expected to be used much in PostgreSQL 14.  The failsafe mechanism added  
by commit 1e55e7d1 addresses the same problem in a simpler way.  
INDEX_CLEANUP can now be thought of as a testing and compatibility  
option.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-By: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/CAH2-WznrBoCST4_Gxh_G9hA8NzGUbeBGnOUC8FcXcrhqsv6OHQ@mail.gmail.com  

commit   : 09126984a2631db8dd6299f23954e0dede69735f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Jun 2021 18:42:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Jun 2021 18:42:00 -0400    

The code to signal a running walsender when its reserved WAL size grows  
too large is completely uncovered before this commit; this adds coverage  
for that case.  
  
This test involves sending SIGSTOP to walsender and walreceiver and  
running a checkpoint while advancing WAL, then sending SIGCONT.  There's  
no precedent for this coding in Perl tests, and my reading of relevant  
manpages says it's likely to fail on Windows.  Because of this, this  
test is always skipped on that platform.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106102202.mjw4huiix7lo@alvherre.pgsql  

commit   : d21fca084356946664bfce19d66d2df2bb873cbd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 18:00:09 -0400    

Ordinarily, a pg_policy.polroles array wouldn't list the same role  
more than once; but CREATE POLICY does not prevent that.  If we  
perform DROP OWNED BY on a role that is listed more than once,  
RemoveRoleFromObjectPolicy either suffered an assertion failure  
or encountered a tuple-updated-by-self error.  Rewrite it to cope  
correctly with duplicate entries, and add a CommandCounterIncrement  
call to prevent the other problem.  
  
Per discussion, there's other cleanup that ought to happen here,  
but this seems like the minimum essential fix.  
  
Per bug #17062 from Alexander Lakhin.  It's been broken all along,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/17062-11f471ae3199ca23@postgresql.org  

commit   : 84bee9610965331d5110971d8de390a5bbe2effc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 17:05:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 17:05:23 -0400    

Commit 547f04e73 caused pgbench to start printing its version number,  
which seems like a fine idea, but it needs a bit more work:  
* Print the server version number too, when different.  
* Print the PG_VERSION string, not some reconstructed approximation.  
  
This patch copies psql's well-tested code for the same purpose.  
  
Discussion: https://postgr.es/m/1226654.1624036821@sss.pgh.pa.us  

commit   : 7c337b6b527b7052e6a751f966d5734c56f668b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 11:22:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jun 2021 11:22:58 -0400    

In the "simple Query" code path, it's fine for parse analysis or  
execution of a utility statement to scribble on the statement's node  
tree, since that'll just be thrown away afterwards.  However it's  
not fine if the node tree is in the plan cache, as then it'd be  
corrupted for subsequent executions.  Up to now we've dealt with  
that by having individual utility-statement functions apply  
copyObject() if they were going to modify the tree.  But that's  
prone to errors of omission.  Bug #17053 from Charles Samborski  
shows that CREATE/ALTER DOMAIN didn't get this memo, and can  
crash if executed repeatedly from plan cache.  
  
In the back branches, we'll just apply a narrow band-aid for that,  
but in HEAD it seems prudent to have a more principled fix that  
will close off the possibility of other similar bugs in future.  
Hence, let's hoist the responsibility for doing copyObject up into  
ProcessUtility from its children, thus ensuring that it happens for  
all utility statement types.  
  
Also, modify ProcessUtility's API so that its callers can tell it  
whether a copy step is necessary.  It turns out that in all cases,  
the immediate caller knows whether the node tree is transient, so  
this doesn't involve a huge amount of code thrashing.  In this way,  
while we lose a little bit in the execute-from-cache code path due  
to sometimes copying node trees that wouldn't be mutated anyway,  
we gain something in the simple-Query code path by not copying  
throwaway node trees.  Statements that are complex enough to be  
expensive to copy are almost certainly ones that would have to be  
copied anyway, so the loss in the cache code path shouldn't be much.  
  
(Note that this whole problem applies only to utility statements.  
Optimizable statements don't have the issue because we long ago made  
the executor treat Plan trees as read-only.  Perhaps someday we will  
make utility statement execution act likewise, but I'm not holding  
my breath.)  
  
Discussion: https://postgr.es/m/931771.1623893989@sss.pgh.pa.us  
Discussion: https://postgr.es/m/17053-3ca3f501bbc212b4@postgresql.org  

commit   : 0a4efdc7ebf2584257b166c87e82797eb92815b5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Jun 2021 06:51:12 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Jun 2021 06:51:12 -0400    

The fast default code added in Release 11 omitted to check that the  
table a fast default was being added to was a plain table. Thus one  
could be added to a foreign table, which predicably blows up. Here we  
perform that check.  
  
In addition, on the back branches, since some of these might have  
escaped into the wild, if we encounter a missing value for  
an attribute of something other than a plain table we ignore it.  
  
Fixes bug #17056  
  
Backpatch to release 11,  
  
Reviewed by: Andres Freund, Álvaro Herrera and Tom Lane  

commit   : 981524d2e3aa3f28d364c472e34f5386be846811    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Jun 2021 17:57:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Jun 2021 17:57:09 +0900    

Commit d75288fb27 made WAL archiver process an auxiliary process.  
An auxiliary process needs to handle barrier events but the commit  
forgot to make archiver process do that.  
  
Reported-by: Thomas Munro  
Author: Fujii Masao  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGLah2w1pWKHonZP_+EQw69=q56AHYwCgEN8GDzsRG_Hgw@mail.gmail.com  

commit   : f80979f659d39e238e95444e6752142799428078    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Jun 2021 14:22:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Jun 2021 14:22:31 +0900    

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/CE12DD5C-4BB3-4166-BC9A-39779568734C@yesql.se  

commit   : d24c5658a80c8f5037e9e1948de311d3f3350f12    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 17 Jun 2021 14:50:42 +0300    

One of the error paths left *members uninitialized. That's not a live  
bug, because most callers don't look at *members when the function  
returns -1, but let's be tidy. One caller, in heap_lock_tuple(), does  
"if (members != NULL) pfree(members)", but AFAICS it never passes an  
invalid 'multi' value so it should not reach that error case.  
  
The callers are also a bit inconsistent in their expectations.  
heap_lock_tuple() pfrees the 'members' array if it's not-NULL, others  
pfree() it if "nmembers >= 0", and others if "nmembers > 0". That's  
not a live bug either, because the function should never return 0, but  
add an Assert for that to make it more clear. I left the callers alone  
for now.  
  
I also moved the line where we set *nmembers. It wasn't wrong before,  
but I like to do that right next to the 'return' statement, to make it  
clear that it's always set on return.  
  
Also remove one unreachable return statement after ereport(ERROR), for  
brevity and for consistency with the similar if-block right after it.  
  
Author: Greg Nancarrow with the additional changes by me  
Backpatch-through: 9.6, all supported versions  

commit   : 3cb828dbe26087e7754f49f3cfe3ed036d5af439    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Jun 2021 09:56:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Jun 2021 09:56:05 +0530    

In a synchronous logical setup, locking [user] catalog tables can cause  
deadlock. This is because logical decoding of transactions can lock  
catalog tables to access them so exclusively locking those in transactions  
can lead to deadlock. To avoid this users must refrain from having  
exclusive locks on catalog tables.  
  
Author: Takamichi Osumi  
Reviewed-by: Vignesh C, Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://www.postgresql.org/message-id/20210222222847.tpnb6eg3yiykzpky%40alap3.anarazel.de  

commit   : 131ea3e908d3c97a2fe1ab25cce5046dd5cb905f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 19:30:17 -0400    

When stuffing a plan from the plancache into a Portal, one is  
not supposed to risk throwing an error between GetCachedPlan and  
PortalDefineQuery; if that happens, the plan refcount incremented  
by GetCachedPlan will be leaked.  I managed to break this rule  
while refactoring code in 9dbf2b7d7.  There is no visible  
consequence other than some memory leakage, and since nobody is  
very likely to trigger the relevant error conditions many times  
in a row, it's not surprising we haven't noticed.  Nonetheless,  
it's a bug, so rearrange the order of operations to remove the  
hazard.  
  
Noted on the way to looking for a better fix for bug #17053.  
This mistake is pretty old, so back-patch to all supported  
branches.  

commit   : 99cea49d6525e30bc3768e4ffb95377e7584dea1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Jun 2021 22:53:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Jun 2021 22:53:31 +0200    

Commit b676ac443b optimized handling of tuple slots with bulk inserts  
into foreign tables, so that the slots are initialized only once and  
reused for all batches. The data was however copied into the slots only  
after the initialization, inserting duplicate values when the slot gets  
reused. Fixed by moving the ExecCopySlot outside the init branch.  
  
The existing postgres_fdw tests failed to catch this due to inserting  
data into foreign tables without unique indexes, and then checking only  
the number of inserted rows. This adds a new test with both a unique  
index and a check of inserted values.  
  
Reported-by: Alexander Pyhalov  
Discussion: https://postgr.es/m/7a8cf8d56b3d18e5c0bccd6cd42d04ac%40postgrespro.ru  

commit   : 6b787d9e32005867ee3660d1ea20f447810a403d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 11:52:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Jun 2021 11:52:05 -0400    

I started out with the goal of reporting ERRCODE_CONNECTION_FAILURE  
when walrcv_connect() fails, but as I looked around I realized that  
whoever wrote this code was of the opinion that errcodes are purely  
optional.  That's not my understanding of our project policy.  Hence,  
make sure that an errcode is provided in each ereport that (a) is  
ERROR or higher level and (b) isn't arguably an internal logic error.  
Also fix some very dubious existing errcode assignments.  
  
While this is not per policy, it's also largely cosmetic, since few  
of these cases could get reported to applications.  So I don't  
feel a need to back-patch.  
  
Discussion: https://postgr.es/m/2189704.1623512522@sss.pgh.pa.us  

commit   : d0303bc8d2670d11c9df9220aa08a2c33529e100    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jun 2021 12:34:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jun 2021 12:34:32 +0300    

Since commit c24dcd0cfd, we have been using pg_pread() to read the WAL  
file, which doesn't change the seek position (unless we fall back to  
the implementation in src/port/pread.c). Update comment accordingly.  
  
Backpatch-through: 12, where we started to use pg_pread()  

commit   : d3c878499c9d639ff06e0664d06b8c731e30c2fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:11:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:11:45 -0400    

This should have been updated in 533e9c6b0, but it was overlooked.  
Given the lack of complaints, I won't bother back-patching.  

commit   : f6352a0d4e437ac8bc266f77df22d064592056c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:09:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Jun 2021 16:09:14 -0400    

aborted-keyrevoke_2.out was apparently needed when it was added (in  
commit 0ac5ad513) to handle the case of serializable transaction mode.  
However, the output in serializable mode actually matches the regular  
aborted-keyrevoke.out file, and AFAICT has done so for a long time.  
There's no need to keep dragging this variant along.  

commit   : 54a5ed22016940d7ad5060ed62d23473924756a1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jun 2021 15:30:11 -0400    

TestLib::perl2host can take a file argument as well as a directory  
argument, so that code becomes substantially simpler. Also add comments  
on why we're using forward slashes, and why we're setting  
PERL_BADLANG=0.  
  
Discussion: https://postgr.es/m/e9947bcd-20ee-027c-f0fe-01f736b7e345@dunslane.net  

commit   : 817bb0a7d1e02df4643d37304aed8574cf43f629    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 21:43:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 21:43:17 +0300    

Reported-by: Tom Lane  
Discussion: https://postgr.es/m/CAPpHfdvcnw3x7jdV3r52p4%3D5S4WUxBCzcQKB3JukQHoicv1LSQ%40mail.gmail.com  

commit   : 958cfbcf2dd338e3179c2d8a35f48bde020eba60    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 15 Jun 2021 08:59:36 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 15 Jun 2021 08:59:36 -0700    

Bugfix commit 5fc89376 effectively made the lock_waiter_detected field  
from vacuumlazy.c's global state struct into private state owned by  
lazy_truncate_heap().  Finish this off by replacing the struct field  
with a local variable.  

commit   : ad2da246c69dd5ec55764d4b6066f3b0c0d24ca2    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 16:06:32 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 16:06:32 +0300    

Discussion: https://postgr.es/m/CAFj8pRDioOxiJgmgw9TqQqZ3CxnJC4P5B2Oospf2eMgAjJuewA%40mail.gmail.com  
Author: Pavel Stehule, Alexander Korotkov  
Reviewed-by: Justin Pryzby, Tom Lane  

commit   : 29854ee8d1ca4a46adb7e84deb17e6fb18e531cc    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 15:59:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 15 Jun 2021 15:59:20 +0300    

It has been spotted that multiranges lack of ability to decompose them into  
individual ranges.  Subscription and proper expanded object representation  
require substantial work, and it's too late for v14.  This commit  
provides the implementation of unnest(multirange) and cast multirange as  
an array of ranges, which is quite trivial.  
  
unnest(multirange) is defined as a polymorphic procedure.  The catalog  
description of the cast underlying procedure is duplicated for each multirange  
type because we don't have anyrangearray polymorphic type to use here.  
  
Catversion is bumped.  
  
Reported-by: Jonathan S. Katz  
Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org  
Author: Alexander Korotkov  
Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu  

commit   : 4daa140a2f50e9a160bc180c3997ee13c7aabf9e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 08:28:36 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 15 Jun 2021 08:28:36 +0530    

During decoding for speculative inserts, we were relying for cleaning  
toast hash on confirmation records or next change records. But that  
could lead to multiple problems (a) memory leak if there is neither a  
confirmation record nor any other record after toast insertion for a  
speculative insert in the transaction, (b) error and assertion failures  
if the next operation is not an insert/update on the same table.  
  
The fix is to start queuing spec abort change and clean up toast hash  
and change record during its processing. Currently, we are queuing the  
spec aborts for both toast and main table even though we perform cleanup  
while processing the main table's spec abort record. Later, if we have a  
way to distinguish between the spec abort record of toast and the main  
table, we can avoid queuing the change for spec aborts of toast tables.  
  
Reported-by: Ashutosh Bapat  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6, where it was introduced  
Discussion: https://postgr.es/m/CAExHW5sPKF-Oovx_qZe4p5oM6Dvof7_P+XgsNAViug15Fm99jA@mail.gmail.com  

commit   : 0a1e80c5c4f094087257fc4284a87e0bc7bca591    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:58:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:58:26 -0400    

This should have been updated in d2d8a229b, but it was overlooked.  
According to 31a877f18 which added it, this file is meant to show the  
results you get under default_transaction_isolation = serializable.  
We've largely lost track of that goal in other isolation tests, but  
as long as we've got this one, it should be right.  
  
Noted while fooling about with the isolationtester.  

commit   : ffbe9dec13599fa786ea6567df1c6a3f3ee3c673    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:28:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Jun 2021 21:28:21 -0400    

This should have been removed in 43e084197, which removed the  
corresponding spec file.  Noted while fooling about with the  
isolationtester.  

commit   : 5f1df62a459b51ab3bb625a0ee5e655429254257    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    

It was unable to wait on a backend that had already left the procarray.  
Users tolerant of that limitation can poll pg_stat_activity.  Other  
users can employ the "timeout" argument of pg_terminate_backend().  
  
Reviewed by Bharath Rupireddy.  
  
Discussion: https://postgr.es/m/20210605013236.GA208701@rfd.leadboat.com  

commit   : 0aac73e6a2602696d23aa7a9686204965f9093dc    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 14 Jun 2021 17:29:37 -0700    

Revert the pg_description entry to its v13 form, since those messages  
usually remain shorter and don't discuss individual parameters.  No  
catversion bump, since pg_description content does not impair backend  
compatibility or application compatibility.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20210612182743.GY16435@telsasoft.com  

commit   : 33c509956704e1d918077b51ccd954f2e201a8f5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Jun 2021 16:31:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Jun 2021 16:31:12 -0400    

I overlooked that one condition was logically inverted.  The fix is a  
little bit more involved than simply negating the condition, to make  
the code easier to read.  
  
Fix some outdated comments left by the same commit, while at it.  
  
Author: Masahiko Sawada <sawada.mshk@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>  
Discussion: https://postgr.es/m/YMRlmB3/lZw8YBH+@paquier.xyz  

commit   : 86b222b09071d3918c5c55b164d22b2236d3f872    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:14:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:14:04 -0400    

Items related to logical replication attribution and BRIN indexes  
  
Reported-by: Tomas Vondra, John Naylor  
  
Discussion: https://postgr.es/m/0db66294-a668-2caa-2b5e-a8db60b30662@enterprisedb.com, CAFBsxsH21KnteYdk33F1oZu2O726NSD6_XBq51Tn0jytsA1AnA@mail.gmail.com  

commit   : a2559d4093725592a3fd5da8a4c7ac7c883115a0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:03:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 16:03:18 -0400    

Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210612034551.GU16435@telsasoft.com  

commit   : 25dfb5a831a1b8a83a8a68453b4bbe38a5ef737e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 12:49:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 14 Jun 2021 12:49:05 -0400    

User-defined objects that reference some built-in array functions will  
need to be recreated in PG 14.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20210608225618.GR16435@telsasoft.com  

commit   : 2d689babe3cb50dcb29f6ed595a61d56e518c0d8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 14:57:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 14:57:22 +0900    

An object found as dropped when digging into the list of objects  
returned by pg_event_trigger_ddl_commands() could cause a cache lookup  
error, as the calls grabbing for the object address and the type name  
would fail if the object was missing.  
  
Those lookup errors could be seen with combinations of ALTER TABLE  
sub-commands involving identity columns.  The lookup logic is changed in  
this code path to get a behavior similar to any other SQL-callable  
function by ignoring objects that are not found, taking advantage of  
2a10fdc.  The back-branches are not changed, as they require this commit  
that is too invasive for stable branches.  
  
While on it, add test cases to exercise event triggers with identity  
columns, and stress more cases with the event ddl_command_end for  
relations.  
  
Author: Sven Klemm, Aleksander Alekseev, Michael Paquier  
Discussion: https://postgr.es/m/CAMCrgp2R1cEXU53iYKtW6yVEp2_yKUz+z=3-CTrYpPP+xryRtg@mail.gmail.com  

commit   : dbab0c07e5ba1f19a991da2d72972a8fe9a41bda    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 09:25:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Jun 2021 09:25:50 +0900    

The extra checks added by the recompression of toast data introduced in  
bbe0a81 is proving to have a performance impact on VACUUM or CLUSTER  
even if no recompression is done.  This is more noticeable with more  
toastable columns that contain non-NULL values.  
  
Improvements could be done to make those extra checks less expensive,  
but that's not material for 14 at this stage, and we are not sure either  
if the code path of VACUUM FULL/CLUSTER is adapted for this job.  
  
Per discussion with several people, including Andres Freund, Robert  
Haas, Álvaro Herrera, Tom Lane and myself.  
  
Discussion: https://postgr.es/m/20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de  

commit   : f807e3410fdfc29ced6590c7c2afa76637e001ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Jun 2021 14:32:42 -0400    

Recent glibc versions have made mktime() fail if tm_isdst is  
inconsistent with the prevailing timezone; in particular it fails for  
tm_isdst = 1 when the zone is UTC.  (This seems wildly inconsistent  
with the POSIX-mandated treatment of "incorrect" values for the other  
fields of struct tm, so if you ask me it's a bug, but I bet they'll  
say it's intentional.)  This has been observed to cause cosmetic  
problems when pg_restore'ing an archive created in a different  
timezone.  
  
To fix, do mktime() using the field values from the archive, and if  
that fails try again with tm_isdst = -1.  This will give a result  
that's off by the UTC-offset difference from the original zone, but  
that was true before, too.  It's not terribly critical since we don't  
do anything with the result except possibly print it.  (Someday we  
should flush this entire bit of logic and record a standard-format  
timestamp in the archive instead.  That's not okay for a back-patched  
bug fix, though.)  
  
Also, guard our only other use of mktime() by having initdb's  
build_time_t() set tm_isdst = -1 not 0.  This case could only have  
an issue in zones that are DST year-round; but I think some do exist,  
or could in future.  
  
Per report from Wells Oliver.  Back-patch to all supported  
versions, since any of them might need to run with a newer glibc.  
  
Discussion: https://postgr.es/m/CAOC+FBWDhDHO7G-i1_n_hjRzCnUeFO+H-Czi1y10mFhRWpBrew@mail.gmail.com  

commit   : 9d97c3408319b43718e4b85bc694697db1af32c6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Jun 2021 07:10:41 -0400    

Translate path slashes on target directory path. This was confusing old  
branches, but is applied to all branches for the sake of uniformity.  
Perl is perfectly able to understand paths with forward slashes.  
  
Along the way, restore the previous archive_wait query, for the sake of  
uniformity with other tests, per gripe from Tom Lane.  

commit   : a9e0b3b08fe38d5e31f03ea96859ff5e413d4a38    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:07:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Jun 2021 20:07:39 +0900    

This is similar to the work done in 8279f68 for TestLib.pm, where  
environment variables set may cause unwanted failures if using a  
temporary installation with pg_regress.  The list of variables reset is  
adjusted in each stable branch depending on what is supported.  
  
Comments are added to remember that the lists in TestLib.pm and  
pg_regress.c had better be kept in sync.  
  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/YMNR9GYDn+fHlMta@paquier.xyz  
Backpatch-through: 9.6  

commit   : f452aaf7d4a96cfcecd6c60ccd294ffe7b8ea088    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 15:12:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 15:12:10 -0400    

Several TAP tests use poll_query_until() to wait for the postmaster  
to restart.  They were checking to see if a trivial query  
(e.g. "SELECT 1") succeeds.  However, that's problematic in the wake  
of commit 11e9caff8, because now that we feed said query to psql  
via stdin, we risk IPC::Run whining about a SIGPIPE failure if psql  
quits before reading the query.  Hence, we can't use a nonempty  
query in cases where we need to wait for connection failures to  
stop happening.  
  
Per the precedent of commits c757a3da0 and 6d41dd045, we can pass  
"undef" as the query in such cases to ensure that IPC::Run has  
nothing to write.  However, then we have to say that the expected  
output is empty, and this exposes a deficiency in poll_query_until:  
if psql fails altogether and returns empty stdout, poll_query_until  
will treat that as a success!  That's because, contrary to its  
documentation, it makes no actual check for psql failure, looking  
neither at the exit status nor at stderr.  
  
To fix that, adjust poll_query_until to insist on empty stderr as  
well as a stdout match.  (I experimented with checking exit status  
instead, but it seems that psql often does exit(1) in cases that we  
need to consider successes.  That might be something to fix someday,  
but it would be a non-back-patchable behavior change.)  
  
Back-patch to v10.  The test cases needing this exist only as far  
back as v11, but it seems wise to keep poll_query_until's behavior  
the same in v10, in case we back-patch another such test case in  
future.  (9.6 does not currently need this change, because in that  
branch poll_query_until can't be told to accept empty stdout as  
a success case.)  
  
Per assorted buildfarm failures, mostly on hoverfly.  
  
Discussion: https://postgr.es/m/CAA4eK1+zM6L4QSA1XMvXY_qqWwdUmqkOS1+hWvL8QcYEBGA1Uw@mail.gmail.com  

commit   : 1250aad42520fd5a3db68d6381997b7e1f9bb4aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 13:29:24 -0400    

Previously, a zero value for the relfilenode resulted in  
a confusing error message about "unexpected duplicate".  
This function returns NULL for other invalid relfilenode  
values, so zero should be treated likewise.  
  
It's been like this all along, so back-patch to all supported  
branches.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20210612023324.GT16435@telsasoft.com  

commit   : fe6a20ce54cbbb6fcfe9f6675d563af836ae799a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 12:59:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Jun 2021 12:59:15 -0400    

Using an Assert to check the validity of incoming messages is an  
extremely poor decision.  In a debug build, it should not be that easy  
for a broken or malicious remote client to crash the logrep worker.  
The consequences could be even worse in non-debug builds, which will  
fail to make such checks at all, leading to who-knows-what misbehavior.  
Hence, promote every Assert that could possibly be triggered by wrong  
or out-of-order replication messages to a full test-and-ereport.  
  
To avoid bloating the set of messages the translation team has to cope  
with, establish a policy that replication protocol violation error  
reports don't need to be translated.  Hence, all the new messages here  
use errmsg_internal().  A couple of old messages are changed likewise  
for consistency.  
  
Along the way, fix some non-idiomatic or outright wrong uses of  
hash_search().  
  
Most of these mistakes are new with the "streaming replication"  
patch (commit 464824323), but a couple go back a long way.  
Back-patch as appropriate.  
  
Discussion: https://postgr.es/m/1719083.1623351052@sss.pgh.pa.us  

commit   : c3652f976b7696a96a9c5606cc2d613af77e2e63    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 12 Jun 2021 08:37:16 -0400    

Commit caba8f0d43 wasn't quite right for msys, as demonstrated by  
several buildfarm animals, including jacana and fairywren. We need to  
use the msys perl in the archive command, but call it in such a way that  
Windows will understand the path. Furthermore, inside the copy script we  
need to convert a Windows path to an msys path.  

commit   : b56b83aa0d6e044cf38d553f7a87f4b84708cac6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 16:29:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 16:29:11 +0900    

This routine is designed to never return an empty description or NULL,  
providing description fallbacks even if missing objects are accepted,  
but it included a code path where this was considered possible.  All the  
callers of this routine already consider NULL as not possible, so  
change a bit the code to map with the assumptions of the callers, and  
add more comments close to the callers of this routine to outline the  
behavior expected.  
  
This code is new as of 2a10fdc, so no backpatch is needed.  
  
Discussion: https://postgr.es/m/YMNY6RGPBRCeLmFb@paquier.xyz  

commit   : bfd96b7a3dc26a8384d4185d274573fb6a46b033    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 15:29:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 12 Jun 2021 15:29:48 +0900    

ab55d74 has introduced some tests with rows found as missing in logical  
replication subscriptions for partitioned tables, relying on a logic  
with a lookup of the logs generated, scanning the whole file.  This  
commit makes the logic more precise, by scanning the logs only from the  
position before the key queries are run to the position where we check  
for the logs.  This will reduce the risk of issues with log patterns  
overlapping with each other if those tests get more complicated in the  
future.  
  
Per discussion with Tom Lane.  
  
Discussion: https://postgr.es/m/YMP+Gx2S8meYYHW4@paquier.xyz  
Backpatch-through: 13  

commit   : d8e950d3ae7b33a2064a4fb39b7829334b0b47bc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 11 Jun 2021 21:22:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 11 Jun 2021 21:22:21 -0700    

941697c3c1a changed ProcArrayAdd()/Remove() substantially. As reported by  
zhanyi, I missed that due to the introduction of the PGPROC->pgxactoff  
ProcArrayRemove() does not need to search for the position in  
procArray->pgprocnos anymore - that's pgxactoff. Remove the search loop.  
  
The removal of the search loop reduces assertion coverage a bit - but we can  
easily do better than before by adding assertions to other loops over  
pgprocnos elements.  
  
Also do a bit of cleanup, mostly by reducing line lengths by introducing local  
helper variables and adding newlines.  
  
Author: zhanyi <w@hidva.com>  
Author: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/tencent_5624AA3B116B3D1C31CA9744@qq.com  

commit   : d120e66fac87f768ea2289d2d923d0ee4262ec0f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 21:01:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 21:01:52 -0400    

Reported-by: Justin Pryzby  

commit   : 0725913982e5e06895a32a9eeea2c59a13978927    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 19:51:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Jun 2021 19:51:35 -0400    

commit   : 5cc1cd502879d642da799e1fd12619d83d987369    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 19:07:32 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 19:07:32 -0400    

We were already reporting it, but only after the parallel workers were  
finished, which is visibly much later than what happens in a serial  
build.  
  
With this change we report it when the leader starts its own sort phase  
when participating in the build (the normal case).  Now this might  
happen a little later than when the workers start their sorting phases,  
but a) communicating the actual phase start from workers is likely to be  
a hassle, and b) the sort phase start is pretty fuzzy anyway, since  
sorting per se is actually initiated by tuplesort.c internally earlier  
than tuplesort_performsort() is called.  
  
Backpatch to pg12, where the progress reporting code for CREATE INDEX  
went in.  
  
Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>  
Author: Matthias van de Meent <boekewurm+postgres@gmail.com>  
Reviewed-by: Greg Nancarrow <gregn4422@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/1128176d-1eee-55d4-37ca-e63644422adb  

commit   : ab55d742eb7162c22ee60f1e15e07d2a60063c4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jun 2021 16:12:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jun 2021 16:12:36 -0400    

apply_handle_tuple_routing(), having detected and reported that  
the tuple it needed to update didn't exist, tried to update that  
tuple anyway, leading to a null-pointer dereference.  
  
logicalrep_partition_open() failed to ensure that the  
LogicalRepPartMapEntry it built for a partition was fully  
independent of that for the partition root, leading to  
trouble if the root entry was later freed or rebuilt.  
  
Meanwhile, on the publisher's side, pgoutput_change() sometimes  
attempted to apply execute_attr_map_tuple() to a NULL tuple.  
  
The first of these was reported by Sergey Bernikov in bug #17055;  
I found the other two while developing some test cases for this  
sadly under-tested code.  
  
Diagnosis and patch for the first issue by Amit Langote; patches  
for the others by me; new test cases by me.  Back-patch to v13  
where this logic came in.  
  
Discussion: https://postgr.es/m/17055-9ba800ec8522668b@postgresql.org  

commit   : 4efcf47053eaf8dd88de2b1a89478df43d37d5c0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 16:05:50 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 16:05:50 -0400    

Commit acb7e4eb6b1c added a new implementation for PQsendQuery so that  
it works in pipeline mode (by using extended query protocol), but it  
behaves differently from the 'Q' message (in simple query protocol) used  
by regular implementation: the new one doesn't close the unnamed portal.  
Change the new code to have identical behavior to the old.  
  
Reported-by: Yura Sokolov <y.sokolov@postgrespro.ru>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/202106072107.d4i55hdscxqj@alvherre.pgsql  

commit   : 1632ea43682fcea8836ea245771ae85b9e1bcd38    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 15:48:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 15:48:26 -0400    

Per 96540f80f833; the awkward API introduced by c6550776394e is no  
longer needed.  
  
Author: Andres Freund <andres@anarazel.de>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210408020913.zzprrlvqyvlt5cyy@alap3.anarazel.de  

commit   : b676ac443b6a83558d4701b2dd9491c0b37e17c4    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 11 Jun 2021 20:19:48 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 11 Jun 2021 20:19:48 +0200    

Commit b663a41363 introduced bulk inserts for FDW, but the handling of  
tuple slots turned out to be problematic for two reasons. Firstly, the  
slots were re-created for each individual batch. Secondly, all slots  
referenced the same tuple descriptor - with reasonably small batches  
this is not an issue, but with large batches this triggers O(N^2)  
behavior in the resource owner code.  
  
These two issues work against each other - to reduce the number of times  
a slot has to be created/dropped, larger batches are needed. However,  
the larger the batch, the more expensive the resource owner gets. For  
practical batch sizes (100 - 1000) this would not be a big problem, as  
the benefits (latency savings) greatly exceed the resource owner costs.  
But for extremely large batches it might be much worse, possibly even  
losing with non-batching mode.  
  
Fixed by initializing tuple slots only once (and reusing them across  
batches) and by using a new tuple descriptor copy for each slot.  
  
Discussion: https://postgr.es/m/ebbbcc7d-4286-8c28-0272-61b4753af761%40enterprisedb.com  

commit   : 96540f80f8334a3f0f4a13f0d42e4565d8fa9eb7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 12:16:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Jun 2021 12:16:14 -0400    

The code added to mark replication slots invalid in commit c6550776394e  
had the race condition that a slot can be dropped or advanced  
concurrently with checkpointer trying to invalidate it.  Rewrite the  
code to close those races.  
  
The changes to ReplicationSlotAcquire's API added with c6550776394e are  
not necessary anymore.  To avoid an ABI break in released branches, this  
commit leaves that unchanged; it'll be changed in a master-only commit  
separately.  
  
Backpatch to 13, where this code first appeared.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Author: Andres Freund <andres@anarazel.de>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20210408001037.wfmk6jud36auhfqm@alap3.anarazel.de  

commit   : d08237b5b494f96e72220bcef36a14a642969f16    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Jun 2021 15:46:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 11 Jun 2021 15:46:18 +0900    

The list of options provided by the tab completion was outdated for the  
following commands:  
- ALTER SUBSCRIPTION  
- CREATE SUBSCRIPTION  
- ALTER PUBLICATION  
- CREATE PUBLICATION  
  
Author: Vignesh C  
Reviewed-by: Bharath Rupireddy  
Discussion: https://postgr.es/m/CALDaNm18oHDFu6SFCHE=ZbiO153Fx7E-L1MG0YyScbaDV--U+A@mail.gmail.com  

commit   : 13a1ca160dcfc316c9f4005891a312f5a84c5ca2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:14 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:14 -0700    

Resolve the disagreement with nodes/*funcs.c field order in favor of the  
latter, which is better-aligned with the IndexStmt field order.  This  
field is new in v14.  
  
Discussion: https://postgr.es/m/20210611045546.GA573364@rfd.leadboat.com  

commit   : d0e750c0acaf31f60667b1635311bcef5ab38bbe    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:13 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 10 Jun 2021 21:56:13 -0700    

We have a dozen PQset*() functions.  PQresultSetInstanceData() and this  
were the libpq setter functions having a different word order.  Adopt  
the majority word order.  
  
Reviewed by Alvaro Herrera and Robert Haas, though this choice of name  
was not unanimous.  
  
Discussion: https://postgr.es/m/20210605060555.GA216695@rfd.leadboat.com  

commit   : 04539e73faaaaa1c06c1407671910dceaffdfcd4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 11 Jun 2021 13:38:04 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 11 Jun 2021 13:38:04 +1200    

We've accumulated quite a mix of instances of "an SQL" and "a SQL" in the  
documents.  It would be good to be a bit more consistent with these.  
  
The most recent version of the SQL standard I looked at seems to prefer  
"an SQL".  That seems like a good lead to follow, so here we change all  
instances of "a SQL" to become "an SQL".  Most instances correctly use  
"an SQL" already, so it also makes sense to use the dominant variation in  
order to minimise churn.  
  
Additionally, there were some other abbreviations that needed to be  
adjusted. FSM, SSPI, SRF and a few others.  Also fix some pronounceable,  
abbreviations to use "a" instead of "an".  For example, "a SASL" instead  
of "an SASL".  
  
Here I've only adjusted the documents and error messages.  Many others  
still exist in source code comments.  Translator hint comments seem to be  
the biggest culprit.  It currently does not seem worth the churn to change  
these.  
  
Discussion: https://postgr.es/m/CAApHDvpML27UqFXnrYO1MJddsKVMQoiZisPvsAGhKE_tsKXquw%40mail.gmail.com  

commit   : e56bce5d43789cce95d099554ae9593ada92b3b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 17:11:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 17:11:36 -0400    

Commit 2453ea142 redefined pg_proc.proargtypes to include the types of  
OUT parameters, for procedures only.  While that had some advantages  
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty  
disastrous from a number of other perspectives.  Notably, since the  
primary key of pg_proc is name + proargtypes, this made it possible to  
have multiple procedures with identical names + input arguments and  
differing output argument types.  That would make it impossible to call  
any one of the procedures by writing just NULL (or "?", or any other  
data-type-free notation) for the output argument(s).  The change also  
seems likely to cause grave confusion for client applications that  
examine pg_proc and expect the traditional definition of proargtypes.  
  
Hence, revert the definition of proargtypes to what it was, and  
undo a number of complications that had been added to support that.  
  
To support the SQL-spec behavior of DROP PROCEDURE, when there are  
no argmode markers in the command's parameter list, we perform the  
lookup both ways (that is, matching against both proargtypes and  
proallargtypes), succeeding if we get just one unique match.  
In principle this could result in ambiguous-function failures  
that would not happen when using only one of the two rules.  
However, overloading of procedure names is thought to be a pretty  
rare usage, so this shouldn't cause many problems in practice.  
Postgres-specific code such as pg_dump can defend against any  
possibility of such failures by being careful to specify argmodes  
for all procedure arguments.  
  
This also fixes a few other bugs in the area of CALL statements  
with named parameters, and improves the documentation a little.  
  
catversion bump forced because the representation of procedures  
with OUT arguments changes.  
  
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us  

commit   : 3a09d75b4f6cabc8331e228b6988dbfcd9afdfbe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 12:27:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 12:27:27 -0400    

It turns out that worker.c's code path for TRUNCATE was also  
careless about establishing a snapshot while executing user-defined  
code, allowing the checks added by commit 84f5c2908 to fail when  
a trigger is fired in that context.  
  
We could just wrap Push/PopActiveSnapshot around the truncate call,  
but it seems better to establish a policy of holding a snapshot  
throughout execution of a replication step.  To help with that and  
possible future requirements, replace the previous ensure_transaction  
calls with pairs of begin/end_replication_step calls.  
  
Per report from Mark Dilger.  Back-patch to v11, like the previous  
changes.  
  
Discussion: https://postgr.es/m/B4A3AF82-79ED-4F4C-A4E5-CD2622098972@enterprisedb.com  

commit   : bb4aed46a5aeb00d2f1d8b8160feed339f4eaf12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 11:15:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 11:15:13 -0400    

Previously, we left the EPQ sub-executor alone until ExecEndLockRows.  
This caused any buffer pins or other resources that it might hold to  
remain held until ExecutorEnd, which in some code paths means that  
they are held till the Portal is closed.  That can cause user-visible  
problems, such as blocking VACUUM; and it's unlike the behavior of  
ordinary table-scanning nodes, which will have released all buffer  
pins by the time they return an EOF indication.  
  
We can make LockRows work more like other plan nodes by calling  
EvalPlanQualEnd just before returning NULL.  We still need to call it  
in ExecEndLockRows in case the node was not run to completion, but in  
the normal case the second call does nothing and costs little.  
  
Per report from Yura Sokolov.  In principle this is a longstanding  
bug, but in view of the lack of other complaints and the low severity  
of the consequences, I chose not to back-patch.  
  
Discussion: https://postgr.es/m/4aa370cb91ecf2f9885d98b80ad1109c@postgrespro.ru  

commit   : 9bb5eecce645dd72853e3ed262bef7bf11cae566    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 10:45:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Jun 2021 10:45:31 -0400    

Buildfarm member hamerkop has been reporting that two cases in  
connect/test5.pgc show different error messages than the test expects,  
because since commit ffa2e4670 libpq's connection failure messages  
are exposing the fact that a GSS-encrypted connection was attempted  
and failed.  That's pretty interesting information in itself, and  
I certainly don't wish to shoot the messenger, but we need to do  
something to stabilize the ECPG results.  
  
For the second of these two failure cases, we can add the  
gssencmode=disable option to prevent the discrepancy.  However,  
that solution is problematic for the first failure, because the only  
unique thing about that case is that it's testing a completely-omitted  
connection target; there's noplace to add the option without defeating  
the point of the test case.  After some thrashing around with  
alternative fixes that turned out to have undesirable side-effects,  
the most workable answer is just to give up and remove that test case.  
Perhaps we can revert this later, if we figure out why the GSS code  
is misbehaving in hamerkop's environment.  
  
Thanks to Michael Paquier for exploration of alternatives.  
  
Discussion: https://postgr.es/m/YLRZH6CWs9N6Pusy@paquier.xyz  

commit   : b29fa951ec519bdde153465e2caa6c0b7b3bcfc3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Jun 2021 16:21:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Jun 2021 16:21:48 +0200    

One of these functions is new in PostgreSQL 14; might as well start it  
out right.  

commit   : 4dcb1d087aebc6fc2477ce4458ea82f548e2c1ee    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:08:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Jun 2021 09:08:30 -0400    

Per buildfarm member conchuela and Kyotaro Horiguchi, it's possible  
for the WAL segment that the cascading standby needs to be removed  
too quickly. Hopefully this will prevent that.  
  
Kyotaro Horiguchi  
  
Discussion: http://postgr.es/m/20210610.101240.1270925505780628275.horikyota.ntt@gmail.com  

commit   : 55ba5973d9144a552661cf1fa4cbd228a3799212    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 10 Jun 2021 20:13:44 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 10 Jun 2021 20:13:44 +1200    

Discussion: https://postgr.es/m/CAApHDvrbyJNOPBws4RUhXghZ7+TBjtdO-rznTsqZECuowNorXg@mail.gmail.com  

commit   : caba8f0d43fb679c6f9643456080408a6bc370e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:17:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Jun 2021 16:17:00 -0400    

This only happens if (1) the new standby has no WAL available locally,  
(2) the new standby is starting from the old timeline, (3) the promotion  
happened in the WAL segment from which the new standby is starting,  
(4) the timeline history file for the new timeline is available from  
the archive but the WAL files for are not (i.e. this is a race),  
(5) the WAL files for the new timeline are available via streaming,  
and (6) recovery_target_timeline='latest'.  
  
Commit ee994272ca50f70b53074f0febaec97e28f83c4e introduced this  
logic and was an improvement over the previous code, but it mishandled  
this case. If recovery_target_timeline='latest' and restore_command is  
set, validateRecoveryParameters() can change recoveryTargetTLI to be  
different from receiveTLI. If streaming is then tried afterward,  
expectedTLEs gets initialized with the history of the wrong timeline.  
It's supposed to be a list of entries explaining how to get to the  
target timeline, but in this case it ends up with a list of entries  
explaining how to get to the new standby's original timeline, which  
isn't right.  
  
Dilip Kumar and Robert Haas, reviewed by Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/CAFiTN-sE-jr=LB8jQuxeqikd-Ux+jHiXyh4YDiZMPedgQKup0g@mail.gmail.com  

commit   : 845cad4d51cb12a34ea012dfe58af5ef490384fc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:24:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Jun 2021 16:24:52 +0900    

The set of subcommands supported by \dAp, \do and \dy was described  
incorrectly in psql's --help.  The documentation was already consistent  
with the code.  
  
Reported-by: inoas, from IRC  
Author: Matthijs van der Vleuten  
Reviewed-by: Neil Chen  
Discussion: https://postgr.es/m/6a984e24-2171-4039-9050-92d55e7b23fe@www.fastmail.com  
Backpatch-through: 9.6  

commit   : be90098907475f3cfff7dc6d590641b9c2dae081    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 18:40:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 18:40:06 -0400    

Further thought about bug #17050 suggests that it's a good idea  
to use CURSOR_OPT_NO_SCROLL for the implicit cursor opened by  
a plpgsql FOR-over-query loop.  This ensures that, if somebody  
commits inside the loop, PersistHoldablePortal won't try to  
rewind and re-read the cursor.  While we'd have selected NO_SCROLL  
anyway if FOR UPDATE/SHARE appears in the query, there are other  
hazards with volatile functions; and in any case, it's silly to  
expend effort storing rows that we know for certain won't be needed.  
  
(While here, improve the comment in exec_run_select, which was a bit  
confused about the rationale for when we can use parallel mode.  
Cursor operations aren't a hazard for nameless portals.)  
  
This wasn't an issue until v11, which introduced the possibility  
of persisting such cursors.  Hence, back-patch to v11.  
  
Per bug #17050 from Алексей Булгаков.  
  
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org  

commit   : ba2c6d6cec000f0aeaeda4d56a23a335f6164860    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 17:50:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 17:50:15 -0400    

PersistHoldablePortal has long assumed that it should store the  
entire output of the query-to-be-persisted, which requires rewinding  
and re-reading the output.  This is problematic if the query is not  
stable: we might get different row contents, or even a different  
number of rows, which'd confuse the cursor state mightily.  
  
In the case where the cursor is NO SCROLL, this is very easy to  
solve: just store the remaining query output, without any rewinding,  
and tweak the portal's cursor state to match.  Aside from removing  
the semantic problem, this could be significantly more efficient  
than storing the whole output.  
  
If the cursor is scrollable, there's not much we can do, but it  
was already the case that scrolling a volatile query's result was  
pretty unsafe.  We can just document more clearly that getting  
correct results from that is not guaranteed.  
  
There are already prohibitions in place on using SCROLL with  
FOR UPDATE/SHARE, which is one way for a SELECT query to have  
non-stable results.  We could imagine prohibiting SCROLL when  
the query contains volatile functions, but that would be  
expensive to enforce.  Moreover, it could break applications  
that work just fine, if they have functions that are in fact  
stable but the user neglected to mark them so.  So settle for  
documenting the hazard.  
  
While this problem has existed in some guise for a long time,  
it got a lot worse in v11, which introduced the possibility  
of persisting plpgsql cursors (perhaps implicit ones) even  
when they violate the rules for what can be marked WITH HOLD.  
Hence, I've chosen to back-patch to v11 but not further.  
  
Per bug #17050 from Алексей Булгаков.  
  
Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org  

commit   : 444302ed56273e4c4006a9be319e60fa12a90346    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Jun 2021 16:47:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Jun 2021 16:47:14 -0400    

Protocol v2 was last used in PG 7.3, not 7.2.  
  
Reported-by: Tatsuo Ishii  
  
Discussion: https://postgr.es/m/20210608.091329.906837606658882674.t-ishii@sraoss.co.jp  

commit   : cb92703384e2bb3fa0a690e5dbb95ad333c2b44c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 20:22:18 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 20:22:18 +0200    

The FE/BE protocol identifies parameters with an Int16 index, which  
limits the maximum number of parameters per query to 65535. With  
batching added to postges_fdw this limit is much easier to hit, as  
the whole batch is essentially a single query, making this error much  
easier to hit.  
  
The failures are a bit unpredictable, because it also depends on the  
number of columns in the query. So instead of just failing, this patch  
tweaks the batch_size to not exceed the maximum number of parameters.  
  
Reported-by: Hou Zhijie <houzj.fnst@cn.fujitsu.com>  
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>  
Discussion: https://postgr.es/m/OS0PR01MB571603973C0AC2874AD6BF2594299%40OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : d1f0aa7696917213485c03b076b573497a535076    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 19:24:27 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 8 Jun 2021 19:24:27 +0200    

Commit 8e03eb92e9 reverted a bit too much code, reintroducing one of the  
issues fixed by 39b66a91bd - a page might have been left partially empty  
after relcache invalidation.  
  
Reported-By: Tom Lane  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/822752.1623032114@sss.pgh.pa.us  
Discussion: https://postgr.es/m/CAD21AoA%3D%3Df2VSw3c-Cp_y%3DWLKHMKc1D6s7g3YWsCOvgaYPpJcg%40mail.gmail.com  

commit   : bfeede9fa464ab707eb5ac5704742bf78bd7ac9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 11:59:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jun 2021 11:59:34 -0400    

gram.y should discard NULL pointers (empty statements) when  
assembling a routine_body_stmt_list, as it does for other  
sorts of statement lists.  
  
Julien Rouhaud and Tom Lane, per report from Noah Misch.  
  
Discussion: https://postgr.es/m/20210606044418.GA297923@rfd.leadboat.com  

commit   : 37e1cce4ddf0be362e3093cee55493aee41bc423    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Jun 2021 15:37:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Jun 2021 15:37:54 +0200    

Fix handling of NULL host name (possibly by using hostaddr).  It  
previously crashed.  Also, we should look at connhost, not pghost, to  
handle multi-host specifications.  
  
Also remove an unnecessary SSL_CTX_free().  
  
Reported-by: Jacob Champion <pchampion@vmware.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/504c276ab6eee000bb23d571ea9b0ced4250774e.camel@vmware.com  

commit   : eab81953682d5087295afb911c93f36cb1533bd9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 8 Jun 2021 13:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 8 Jun 2021 13:45:00 +0900    

Add a note about asynchronous execution by postgres_fdw when applied to  
Append nodes that contain synchronous subplan(s) as well.  Follow-up for  
commit 27e1f1456.  
  
Andrey Lepikhov and Etsuro Fujita  
  
Discussion: https://postgr.es/m/58fa2aa5-07f5-80b5-59a1-fec8a349fee7%40postgrespro.ru  

commit   : 4e47b02834827fa700627290fae02f89a450368c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jun 2021 08:53:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Jun 2021 08:53:12 +0900    

The use of this function is limited to superusers and the code includes  
a hardcoded check for that.  However, the code would look for the PGPROC  
entry to signal for the memory dump before checking if the user is a  
superuser or not, which does not make sense if we know that an error  
will be returned.  Note that the code would let one know if a process  
was a PostgreSQL process or not even for non-authorized users, which is  
not the case now, but this avoids taking ProcArrayLock that will most  
likely finish by being unnecessary.  
  
Thanks to Julien Rouhaud and Tom Lane for the discussion.  
  
Discussion: https://postgr.es/m/YLxw1uVGIAP5uMPl@paquier.xyz  

commit   : 3bb309be7533e153d86390642e8a2d054bbe82c8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Jun 2021 21:32:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Jun 2021 21:32:53 +0200    

We have outNode() coverage for all path nodes, but this one was  
missed when it was added.  

commit   : d16ebfbff74b30c83a4669a1df318cacfa7e52ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:52:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:52:42 -0400    

If autovacuum comes along just after we fill table test_seg with  
some data, it will update the stats to the point where we prefer  
a plain indexscan over a bitmap scan, breaking the expected  
output (as well as the point of the test case).  To fix, just  
force a bitmap scan to be chosen here.  
  
This has evidently been wrong since commit de1d042f5.  It's not  
clear why we just recently saw any buildfarm failures due to it;  
but prairiedog has failed twice on this test in the past week.  
Hence, backpatch to v11 where this test case came in.  

commit   : 42f94f56bf9559f0a3cf5f3ffde50655834694ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Jun 2021 14:15:25 -0400    

An incorrectly-encoded multibyte character near the end of a string  
could cause various processing loops to run past the string's  
terminating NUL, with results ranging from no detectable issue to  
a program crash, depending on what happens to be in the following  
memory.  
  
This isn't an issue in the server, because we take care to verify  
the encoding of strings before doing any interesting processing  
on them.  However, that lack of care leaked into client-side code  
which shouldn't assume that anyone has validated the encoding of  
its input.  
  
Although this is certainly a bug worth fixing, the PG security team  
elected not to regard it as a security issue, primarily because  
any untrusted text should be sanitized by PQescapeLiteral or  
the like before being incorporated into a SQL or psql command.  
(If an app fails to do so, the same technique can be used to  
cause SQL injection, with probably much more dire consequences  
than a mere client-program crash.)  Those functions were already  
made proof against this class of problem, cf CVE-2006-2313.  
  
To fix, invent PQmblenBounded() which is like PQmblen() except it  
won't return more than the number of bytes remaining in the string.  
In HEAD we can make this a new libpq function, as PQmblen() is.  
It seems imprudent to change libpq's API in stable branches though,  
so in the back branches define PQmblenBounded as a macro in the files  
that need it.  (Note that just changing PQmblen's behavior would not  
be a good idea; notably, it would completely break the escaping  
functions' defense against this exact problem.  So we just want a  
version for those callers that don't have any better way of handling  
this issue.)  
  
Per private report from houjingyi.  Back-patch to all supported branches.  

commit   : 68a6d8a87006ba727d9662ec84c7a3d9de402df0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jun 2021 18:12:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Jun 2021 18:12:29 +0900    

When run on a server using default_toast_compression set to LZ4, this  
test would fail because of a consistency issue with the order of the  
tuples treated.  LZ4 causes one tuple to be stored inline instead of  
getting externalized.  As the goal of this test is to check after data  
stored externally, stick to pglz as the compression algorithm used, so  
as all data of this test is stored the way it should.  
  
Analyzed-by: Dilip Kumar  
Discussion: https://postgr.es/m/YLrDWxJgM8WWMoCg@paquier.xyz  

commit   : be57f21650d36449ec34a67b2d9af71126a663b3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 7 Jun 2021 09:32:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 7 Jun 2021 09:32:06 +0530    

Commit 19890a064e added the option to enable two_phase commits via  
pg_create_logical_replication_slot but didn't extend the support of same  
in replication protocol. However, by mistake, it added the two_phase  
variable in CreateReplicationSlotCmd which is required only when we extend  
the replication protocol.  
  
Reported-by: Jeff Davis  
Author: Ajin Cherian  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/64b9f783c6e125f18f88fbc0c0234e34e71d8639.camel@j-davis.com  

commit   : f3baaf28a6da588987b94a05a725894805c3eae9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 7 Jun 2021 12:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 7 Jun 2021 12:45:00 +0900    

In cases where run-time pruning isn't required, the synchronous and  
asynchronous subplans for an async-aware Append node determined using  
classify_matching_subplans() should be re-used when rescanning the node,  
but the previous code re-determined them using that function repeatedly  
each time when rescanning the node, leading to incorrect results in a  
normal build and an Assert failure in an Assert-enabled build as that  
function doesn't assume that it's called repeatedly in such cases.  Fix  
the code as mentioned above.  
  
My oversight in commit 27e1f1456.  
  
While at it, initialize async-related pointers/variables to NULL/zero  
explicitly in ExecInitAppend() and ExecReScanAppend(), just to be sure.  
(The variables would have been set to zero before we get to the latter  
function, but let's do so.)  
  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAPmGK16Q4B2_KY%2BJH7rb7wQbw54AUprp7TMekGTd2T1B62yysQ%40mail.gmail.com  

commit   : a65e9f3f1405b786673feec131879843432bf9a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Jun 2021 15:46:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Jun 2021 15:46:58 -0400    

Other equalfuncs.c checks on CoercionForm fields use  
COMPARE_COERCIONFORM_FIELD (which makes them no-ops),  
but commit 40c24bfef neglected to make _equalFuncCall  
do likewise.  Fix that.  
  
This is only strictly correct if FuncCall.funcformat has  
no semantic effect, instead just determining ruleutils.c  
display formatting.  40c24bfef added a couple of checks  
in parse analysis that could break that rule; but on closer  
inspection, they're redundant, so just take them out again.  
  
Per report from Noah Misch.  
  
Discussion: https://postgr.es/m/20210606063331.GC297923@rfd.leadboat.com  

commit   : d57ecebd128cdf2f4844a2ea4d35ff28d7d69be8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 6 Jun 2021 20:52:58 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 6 Jun 2021 20:52:58 +0200    

Commit a4d75c86bf added a new flag, tracking if the statement was  
processed by transformStatsStmt(), but failed to add this flag to  
nodes/*funcs.c.  
  
Catversion bump, due to adding a flag to copy/equal/out functions.  
  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com  

commit   : a2dee328bbe5b1979bbc6a784deb86a336c9cd74    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 6 Jun 2021 00:08:21 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 6 Jun 2021 00:08:21 -0700    

catversion bump due to readfuncs.c field order change.  

commit   : 5c25fd650a774cc4f16ac9c635830d9bc5797f61    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:08:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:08:40 +0200    

Just say that objects that reside in schemas can be schema-qualified.  
Don't list all possible such objects.  The existing lists weren't  
complete anyway.  
  
Discussion: https://www.postgresql.org/message-id/flat/b2ec2234-67fe-d861-5cea-f526cd18c086%40enterprisedb.com  

commit   : 01ddd2f7e411ba434473faebf00f5b5af84c0f64    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:01:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 09:01:29 +0200    

Use "reside in" rather than "belong to" for objects in a schema.  
Previous use was a mix of the two.  
  
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/202106021932.idmbjjaqk7ke@alvherre.pgsql  

commit   : e6159885b78e9b91b2adc3161c5f827d081f2b13    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:57:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:57:31 +0200    

commit   : 4a682d85a1408e48ac529295c329ba2c17a44724    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 5 Jun 2021 07:16:34 +0200    

Starting with Python 3.10, the stacktrace looks differently:  
  -  PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in <module>  
  -    s.__exit__(None, None, None)  
  +  PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module>  
  +    with plpy.subtransaction() as s:  
Using try/except specifically makes the error look always the same.  
  
(See https://github.com/python/cpython/pull/25719 for the discussion  
of this change in Python.)  
  
Author: Honza Horak <hhorak@redhat.com>  
Discussion: https://www.postgresql.org/message-id/flat/853083.1620749597%40sss.pgh.pa.us  
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1959080  

commit   : f61db909dfb94f3411f8719916601a11a905b95e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Jun 2021 20:07:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Jun 2021 20:07:08 -0400    

Commit 86dc90056 expects that FDWs can cope with whole-row Vars for  
their tables, even if the Vars are marked with vartype RECORDOID.  
Previously, whole-row Vars generated by the planner had vartype equal  
to the relevant table's rowtype OID.  (The point behind this change is  
to enable sharing of resjunk columns across inheritance child tables.)  
  
It turns out that postgres_fdw fails to cope with this, though through  
bad fortune none of its test cases exposed that.  Things mostly work,  
but when we try to read back a value of such a Var, the expected  
rowtype is not available to record_in().  Fortunately, it's not  
difficult to hack up the tupdesc that controls this process to  
substitute the foreign table's rowtype for RECORDOID.  Thus we can  
solve the runtime problem while still sharing the resjunk column  
with other tables.  
  
Per report from Alexander Pyhalov.  
  
Discussion: https://postgr.es/m/7817fb9ebd6661cdf9b67dec6e129a78@postgrespro.ru  

commit   : 8f3c06c5d56fc0fa414bcf548860ac50a8fe5982    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 23:39:40 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 23:39:40 +1200    

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/7838B8EE-CFD6-48D7-AE2D-520D69FD84BD@yesql.se  

commit   : 8bdb36aab287f564eac534878bc0e1d873a4e3db    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 22:42:17 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 22:42:17 +1200    

This tidies up some questionable coding which made use of  
DatumGetPointer() for Datums being passed into functions where the  
parameter is expected to be a cstring.  We saw no compiler warnings with  
the old code as the Pointer type used in DatumGetPointer() happens to  
be a char * rather than a void *.  However, that's no excuse and we should  
be using the correct macro for the job.  
  
Here we also make use of OutputFunctionCall() rather than using  
FunctionCall1() directly to call the type's output function.  
OutputFunctionCall() is the standard way to do this.  It casts the  
returned value to a cstring for us.  
  
In passing get rid of a duplicate call to strlen().  Most compilers will  
likely optimize away the 2nd call, but there may be some that won't.  In  
any case, this just aligns the code to some other nearby code that already  
does this.  
  
Discussion: https://postgr.es/m/CAApHDvq1D=ehZ8hey8Hz67N+_Zth0GHO5wiVCfv1YcGPMXJq0A@mail.gmail.com  

commit   : e4539386decae1c435767a69507cc7cbb11ac3ff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 21:07:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 21:07:12 -0400    

The siglen parameter is provided by gist__intbig_ops not  
gist__int_ops.  
  
Simon Norris  
  
Discussion: https://postgr.es/m/11BF2AA9-17AE-432A-AFE1-584FB9FB079D@hillcrestgeo.ca  

commit   : 1e809db86b160e697a56bf47358f7733475840d3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:46:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:46:15 +0900    

This was missing in the section dedicated to the supported environment  
variables of libpq.  Oversight in f5465fa.  
  
Reviewed-by: Daniel Gustafsson, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/YLhI0mLoRkY3u4Wj@paquier.xyz  

commit   : 77e9d1b4884262fa09cd8d141c7eadad3affde8b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:33:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Jun 2021 09:33:14 +0900    

The link was pointing to the minimum protocol version.  Incorrect as of  
ff8ca5f.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/F893F184-C645-4C21-A2BA-583441B7288F@yesql.se  
Backpatch-through: 13  

commit   : 7fc26d11e370afe237631265714221364d7e7910    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 12:19:50 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 4 Jun 2021 12:19:50 +1200    

A few patches committed after ca3b37487 mistakenly forgot to make the  
copyright year 2021.  Fix these.  
  
Discussion: https://postgr.es/m/CAApHDvqyLmd9P2oBQYJ=DbrV8QwyPRdmXtCTFYPE08h+ip0UJw@mail.gmail.com  

commit   : 11e9caff82bc7326e2bc9782937cb03875050cc4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 3 Jun 2021 16:08:33 -0400    

The Msys shell mangles certain patterns in its command line, so avoid  
handing arbitrary SQL to psql on the command line and instead use  
IPC::Run's redirection facility for stdin. This pattern is already  
mostly whats used, but query_poll_until() was not doing the right thing.  
  
Problem discovered on the buildfarm when a new TAP test failed on msys.  

commit   : 3590680b85a8e51ef8df550e5a10dedd0d2dfd88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 14:54:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jun 2021 14:54:06 -0400    

The documented intent is for all columns except subconninfo to be  
publicly readable.  However, this has been overlooked twice.  
subsynccommit has never been readable since it was introduced,  
nor has the oid column (which is important for joining).  
  
Given the lack of previous complaints, it's not clear that it's  
worth doing anything about this in the back branches.  But there's  
still time to fix it inexpensively for v14.  
  
Per report from Israel Barth (via Euler Taveira).  
  
Patch by Euler Taveira, possibly-vain comment updates by me.  
  
Discussion: https://postgr.es/m/b8f7c17c-0041-46b6-acfe-2d1f5a985ab4@www.fastmail.com  

commit   : 187682c3217375c9b70417bf3235790f639e8e7e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:28:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 15:28:24 +0900    

The internal SQL queries used by REFRESH MATERIALIZED VIEW CONCURRENTLY  
include some aliases for its diff and temporary relations with  
rather-generic names: diff, newdata, newdata2 and mv.  Depending on the  
queries used for the materialized view, using CONCURRENTLY could lead to  
some internal failures if the matview query and those internal aliases  
conflict.  
  
Those names have been chosen in 841c29c8.  This commit switches instead  
to a naming pattern which is less likely going to cause conflicts, based  
on an idea from Thomas Munro, by appending _$ to those aliases.  This is  
not perfect as those new names could still conflict, but at least it has  
the advantage to keep the code readable and simple while reducing the  
likelihood of conflicts to be close to zero.  
  
Reported-by: Mathis Rudolf  
Author: Bharath Rupireddy  
Reviewed-by: Bernd Helmle, Thomas Munro, Michael Paquier  
Discussion: https://postgr.es/m/109c267a-10d2-3c53-b60e-720fcf44d9e8@credativ.de  
Backpatch-through: 9.6  

commit   : cb3cffe694b6041c1de47b12b225e05f664c7285    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 3 Jun 2021 06:55:04 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 3 Jun 2021 06:55:04 +0200    

The previous arrangement was just one big list, and the internal order  
was not all consistent either.  Now arrange the options by group and  
sort them, the way it's already done in the --help output and one  
other reference pages.  Also fix some ordering in the --help output.  

commit   : f736e188ce70bda34f04c9f381b7c5141dc20dce    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 3 Jun 2021 16:38:03 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 3 Jun 2021 16:38:03 +1200    

Fix a few places that were using appendStringInfo() when they should have  
been using appendStringInfoString().  Also some cases of  
appendPQExpBuffer() that would have been better suited to use  
appendPQExpBufferChar(), and finally, some places that used  
appendPQExpBuffer() when appendPQExpBufferStr() would have suited better.  
  
There are no bugs are being fixed here.  The aim is just to make the code  
use the most optimal function for the job.  
  
All the code being changed here is new to PG14.  It makes sense to fix  
these before we branch for PG15.  There are a few other places that we  
could fix, but those cases are older code so fixing those seems less  
worthwhile as it may cause unnecessary back-patching pain in the future.  
  
Author: Hou Zhijie  
Discussion: https://postgr.es/m/OS0PR01MB5716732158B1C4142C6FE375943D9@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : 8279f68a1b13d58a0c9869a60081009d8995e4df    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:50:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 3 Jun 2021 11:50:56 +0900    

Various environment variables were not getting reset in the TAP tests,  
which would cause failures depending on the tests or the environment  
variables involved.  For example, PGSSL{MAX,MIN}PROTOCOLVERSION could  
cause failures in the SSL tests.  Even worse, a junk value of  
PGCLIENTENCODING makes a server startup fail.  The list of variables  
reset is adjusted in each stable branch depending on what is supported.  
  
While on it, simplify a bit the code per a suggestion from Andrew  
Dunstan, using a list of variables instead of doing single deletions.  
  
Reviewed-by: Andrew Dunstan, Daniel Gustafsson  
Discussion: https://postgr.es/m/YLbjjRpucIeZ78VQ@paquier.xyz  
Backpatch-through: 9.6  

commit   : 2955c2be79b35fa369c83fa3b5f44661cb88afa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 18:50:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 18:50:15 -0400    

Commit 3db826bd5 disallowed this case, but it turns out that some  
people are depending on it.  Since the core grammar has allowed  
it since 3dc37cd8d, it seems like this code should fall in line.  
  
Per bug #17045 from Robert Sosinski.  
  
Discussion: https://postgr.es/m/17045-6a4a9f0d1513f72b@postgresql.org  

commit   : 8e03eb92e9ad54e2f1ed8b5a73617601f6262f81    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 3 Jun 2021 00:06:42 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 3 Jun 2021 00:06:42 +0200    

Reverts most of commit 39b66a91bd, which was found to cause significant  
regression for REFRESH MATERIALIZED VIEW. This means only rows inserted  
by heap_multi_insert will benefit from the optimization, implemented in  
commit 7db0cd2145.  
  
Reported-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoA%3D%3Df2VSw3c-Cp_y%3DWLKHMKc1D6s7g3YWsCOvgaYPpJcg%40mail.gmail.com  

commit   : 889592344c48d3965567f331b4ea89dfe6447bce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 14:38:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 14:38:14 -0400    

Commit 428b260f8 broke planning of cases where row marks are needed  
(SELECT FOR UPDATE, etc) and one of the query's tables is a foreign  
table that has regular table(s) as inheritance children.  We got the  
reverse case right, but apparently were thinking that foreign tables  
couldn't be inheritance parents.  Not so; so we need to be able to  
add a CTID junk column while adding a new child, not only a wholerow  
junk column.  
  
Back-patch to v12 where the faulty code came in.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqEmo3FV1LAQ4TVyS2h1WM=kMkZUmbNuZSCnfHvMcUcPeA@mail.gmail.com  

commit   : 79c50ca57828e9f8375766b36cce1e2960eebf87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 11:52:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 11:52:35 -0400    

The reference here to different physical column numbers in inherited  
UPDATE/DELETE plans is obsolete as of 86dc90056; remove it.  Also  
rework the text about inheritance cases to make it clearer.  

commit   : 9e3b3ff2664dd0b349d2a6d6f047128cb3489cf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 10:44:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jun 2021 10:44:16 -0400    

Commit c7aba7c14 missed adding SUBSCRIPT here,  
and commit 6df7a9698 missed adding MULTIRANGE_TYPE_NAME.  
  
Haiying Tang and Tom Lane  
  
Discussion: https://postgr.es/m/OS0PR01MB6113F9EDA46FA53BAA5445BDFB3D9@OS0PR01MB6113.jpnprd01.prod.outlook.com  

commit   : df466d30c6caa02e2215595fd83ca70be3199cec    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:20:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:20:15 +0900    

The regression test 013_crash_restart.pl included "use Time::HiRes qw(usleep)",  
but the usleep was not used there.  
  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/63ad1368-18e2-8900-8443-524bdfb1bef5@oss.nttdata.com  

commit   : 6bbc5c5e96b08f6b8c7d28d10ed8dfe6c49dca30    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:19:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jun 2021 12:19:39 +0900    

Previously there was no regression test for recovery pause feature.  
This commit adds the test that checks  
  
- recovery can be paused or resumed expectedly  
- pg_get_wal_replay_pause_state() reports the correct pause state  
- the paused state ends and promotion continues if a promotion  
   is triggered while recovery is paused  
  
Suggested-by: Michael Paquier  
Author: Fujii Masao  
Reviewed-by: Kyotaro Horiguchi, Dilip Kumar  
Discussion: https://postgr.es/m/YKNirzqM1HYyk5h4@paquier.xyz  

commit   : 42344ad0ed465ea988d8310d2f413d65329f55a8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:15 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:15 -0700    

commit   : 49527a32ca97761d78efef732a4ac76a2fc086b2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:14 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 1 Jun 2021 18:04:14 -0700    

This avoids a warning under MinGW versions having gettimeofday(), per  
buildfarm member walleye.  

commit   : 1103033aedc10295eb689a4b7158f21ef4c14a11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jun 2021 11:12:56 -0400    

This case should be disallowed, just as FOR UPDATE with a plain  
GROUP BY is disallowed; FOR UPDATE only makes sense when each row  
of the query result can be identified with a single table row.  
However, we missed teaching CheckSelectLocking() to check  
groupingSets as well as groupClause, so that it would allow  
degenerate grouping sets.  That resulted in a bad plan and  
a null-pointer dereference in the executor.  
  
Looking around for other instances of the same bug, the only one  
I found was in examine_simple_variable().  That'd just lead to  
silly estimates, but it should be fixed too.  
  
Per private report from Yaoguang Chen.  
Back-patch to all supported branches.  

commit   : eb89cb43a0d0e401e71b8e2345b5f5bc8b2755a1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jun 2021 14:14:02 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Jun 2021 14:14:02 +0530    

Release memory allocated when creating the tuple-conversion map and its  
component TupleDescs when its owning sync entry is invalidated.  
TupleDescs must also be freed when no map is deemed necessary, to begin  
with.  
  
Reported-by: Andres Freund  
Author: Amit Langote  
Reviewed-by: Takamichi Osumi, Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/MEYP282MB166933B1AB02B4FE56E82453B64D9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM  

commit   : a40646e30d85e51a76fb620822d4d921b6802157    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 1 Jun 2021 11:22:22 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 1 Jun 2021 11:22:22 +1200    

Commit 44bf3d50 incorrectly used an errno-style interface when supplying  
missing pthread functionality (i.e. on macOS), but it should check for  
and return error numbers directly.  

commit   : 7c544ecdad814ccda709cfb6aa7d62840c3a7486    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 31 May 2021 18:32:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 31 May 2021 18:32:41 +0200    

The RADIUS-related checks in parse_hba_line() did not respect elevel  
and did not fill in *err_msg.  Also, verify_option_list_length()  
pasted together error messages in an untranslatable way.  To fix the  
latter, remove the function and do the error checking inline.  It's a  
bit more verbose but only minimally longer, and it makes fixing the  
first two issues straightforward.  
  
Reviewed-by: Magnus Hagander <magnus@hagander.net>  
Discussion: https://www.postgresql.org/message-id/flat/8381e425-8c23-99b3-15ec-3115001db1b2%40enterprisedb.com  

commit   : 6ee41a301e70fc8e4ad383bad22d695f66ccb0ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 May 2021 12:03:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 31 May 2021 12:03:00 -0400    

create_projection_plan contains a hidden assumption (here made  
explicit by an Assert) that a projection-capable Path will yield a  
projection-capable Plan.  Unfortunately, that assumption is violated  
only a few lines away, by create_projection_plan itself.  This means  
that two stacked ProjectionPaths can yield an outcome where we try to  
jam the upper path's tlist into a non-projection-capable child node,  
resulting in an invalid plan.  
  
There isn't any good reason to have stacked ProjectionPaths; indeed the  
whole concept is faulty, since the set of Vars/Aggs/etc needed by the  
upper one wouldn't necessarily be available in the output of the lower  
one, nor could the lower one create such values if they weren't  
available from its input.  Hence, we can fix this by adjusting  
create_projection_path to strip any top-level ProjectionPath from the  
subpath it's given.  (This amounts to saying "oh, we changed our  
minds about what we need to project here".)  
  
The test case added here only fails in v13 and HEAD; before that, we  
don't attempt to shove the Sort into the parallel part of the plan,  
for reasons that aren't entirely clear to me.  However, all the  
directly-related code looks generally the same as far back as v11,  
where the hazard was introduced (by d7c19e62a).  So I've got no faith  
that the same type of bug doesn't exist in v11 and v12, given the  
right test case.  Hence, back-patch the code changes, but not the  
irrelevant test case, into those branches.  
  
Per report from Bas Poot.  
  
Discussion: https://postgr.es/m/534fca83789c4a378c7de379e9067d4f@politie.nl  

commit   : d03eeab886baa1be73f8fc2938fb842d25a71fe8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 31 May 2021 00:29:58 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 31 May 2021 00:29:58 -0700    

Per buildfarm member hornet.  Also, update Pod documentation showing the  
lower value.  Back-patch to v10, where the test first appeared.  

commit   : 12cc956664f159e97be71e33f15ec5f42e46b24e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 31 May 2021 11:35:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 31 May 2021 11:35:00 +0900    

Braces were referred in some error messages as only brackets (not curly  
brackets or curly braces), which can be confusing as other types of  
brackets could be used.  
  
While on it, add one test to check after the case of junk characters  
detected after a right brace.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20210514.153153.1814935914483287479.horikyota.ntt@gmail.com  

commit   : ba356a397de565c014384aa01a945aab7d50928c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 May 2021 14:27:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 May 2021 14:27:37 -0400    

Clarify libpq.sgml's description of service file locations and  
semantics.  Avoid use of backtick'ed pg_config calls to describe  
paths; that doesn't work on Windows, and even on Unix it's an  
idiom that not all readers may be instantly familiar with.  
  
Don't overspecify the locations of include files, instead writing  
only as much as you'd use in #include directives.  The previous text  
in these places was incorrect for some installations, depending on  
where "postgresql" is in the install path.  
  
Our convention for referencing the user's home directory seems  
to be "~", so change the one place that spelled it "$HOME".  
  
install-windows.sgml follows the platform convention of spelling  
file paths with "\", so change the one place that used "/".  
  
Haiying Tang and Tom Lane  
  
Discussion: https://postgr.es/m/162149020918.26174.7150424047314144297@wrigleys.postgresql.org  

commit   : b1d6538903504904db44679355ac109aeda01737    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 29 May 2021 14:48:15 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 29 May 2021 14:48:15 +1200    

Parallel query processes that called BlessTupleDesc() for identical  
tuple descriptors at the same moment could crash.  There was code to  
handle that rare case, but it dereferenced a bogus DSA pointer.  Repair.  
  
Back-patch to 11, where commit cc5f8136 added support for sharing tuple  
descriptors in parallel queries.  
  
Reported-by: Eric Thinnes <e.thinnes@gmx.de>  
Discussion: https://postgr.es/m/99aaa2eb-e194-bf07-c29a-1a76b4f2bcf9%40gmx.de  

commit   : d69fcb9caef1ac1f38241645d4fb9f7e0ce02a70    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:35:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:35:11 -0400    

commit   : fb424ae85f6b1e32e545f13902d3ba3429be44df    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:26:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 28 May 2021 09:26:30 -0400    

This is a long standing omission, discovered when trying to write code  
that relied on it.  
  
Backpatch to all live branches.  

commit   : 9afdea982420f9672b88e5c17d1ee8eec64105fc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 27 May 2021 17:09:16 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 27 May 2021 17:09:16 -0700    

Oversight in commit 5100010e.  

commit   : a4390abecf0f5152cff864e82b67e5f6c8489698    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 15:55:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 15:55:08 -0400    

Commit ab596105b increased FirstBootstrapObjectId from 12000 to 13000,  
but we've had some push-back about that.  It's worrisome to reduce the  
daylight between there and FirstNormalObjectId, because the number of  
OIDs consumed during initdb for collation objects is hard to predict.  
  
We can improve the situation by abandoning the assumption that these  
OIDs must be globally unique.  It should be sufficient for them to be  
unique per-catalog.  (Any code that's unhappy about that is broken  
anyway, since no more than per-catalog uniqueness can be guaranteed  
once the OID counter wraps around.)  With that change, the largest OID  
assigned during genbki.pl (starting from a base of 10000) is a bit  
under 11000.  This allows reverting FirstBootstrapObjectId to 12000  
with reasonable confidence that that will be sufficient for many years  
to come.  
  
We are not, at this time, abandoning the expectation that  
hand-assigned OIDs (below 10000) are globally unique.  Someday that'll  
likely be necessary, but the need seems years away still.  
  
This is late for v14, but it seems worth doing it now so that  
downstream software doesn't have to deal with the consequences of  
a change in FirstBootstrapObjectId.  In any case, we already  
bought into forcing an initdb for beta2, so another catversion  
bump won't hurt.  
  
Discussion: https://postgr.es/m/1665197.1622065382@sss.pgh.pa.us  

commit   : e6241d8e030fbd2746b3ea3f44e728224298f35b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 13:24:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 May 2021 13:24:24 -0400    

Redefine '\0' (InvalidCompressionMethod) as meaning "if we need to  
compress, use the current setting of default_toast_compression".  
This allows '\0' to be a suitable default choice regardless of  
datatype, greatly simplifying code paths that initialize tupledescs  
and the like.  It seems like a more user-friendly approach as well,  
because now the default compression choice doesn't migrate into table  
definitions, meaning that changing default_toast_compression is  
usually sufficient to flip an installation's behavior; one needn't  
tediously issue per-column ALTER SET COMPRESSION commands.  
  
Along the way, fix a few minor bugs and documentation issues  
with the per-column-compression feature.  Adopt more robust  
APIs for SetIndexStorageProperties and GetAttributeCompression.  
  
Bump catversion because typical contents of attcompression will now  
be different.  We could get away without doing that, but it seems  
better to ensure v14 installations all agree on this.  (We already  
forced initdb for beta2, anyway.)  
  
Discussion: https://postgr.es/m/626613.1621787110@sss.pgh.pa.us  

commit   : a717e5c771610cf8607f2423ab3ab6b5d30f44ea    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 16:40:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 16:40:52 +0200    

The path needs to be set to refer to the build directory, not the  
current directory, because that's actually the source directory at  
that point.  
  
fix for 6abc8c2596dbfcb24f9b4d954a1465b8015118c3  

commit   : 6abc8c2596dbfcb24f9b4d954a1465b8015118c3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 13:58:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 13:58:13 +0200    

Apply in libpq_pipeline test makefile, so that the test file is not  
installed into tmp_install.  
  
Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/cb9d16a6-760f-cd44-28d6-b091d5fb6ca7%40enterprisedb.com  

commit   : 025110663448a8c877f4b591495f2e5d187d8936    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 20:11:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 20:11:00 +0900    

The deliverables of upstream Kerberos on Windows are installed with  
paths that do not match our MSVC scripts.  First, the include folder was  
named "inc/" in our scripts, but the upstream MSIs use "include/".  
Second, the build would fail with 64-bit environments as the libraries  
are named differently.  
  
This commit adjusts the MSVC scripts to be compatible with the latest  
installations of upstream, and I have checked that the compilation was  
able to work with the 32-bit and 64-bit installations.  
  
Special thanks to Kondo Yuta for the help in investigating the situation  
in hamerkop, which had an incorrect configuration for the GSS  
compilation.  
  
Reported-by: Brian Ye  
Discussion: https://postgr.es/m/162128202219.27274.12616756784952017465@wrigleys.postgresql.org  
Backpatch-through: 9.6  

commit   : 388e75ad33489b77cfb9a8590a91e9287d8fb960    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 09:52:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 May 2021 09:52:12 +0200    

The error message was checking that the structures returned from the  
parser matched expectations.  That's something we usually use  
assertions for, not a full user-facing error message.  So replace that  
with an assertion (hidden inside lfirst_node()).  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/452e9df8-ec89-e01b-b64a-8cc6ce830458%40enterprisedb.com  

commit   : 2941138e60fc711bd221b3264807f36cc079dfbb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:57:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 May 2021 14:57:28 +0900    

The following parameters have been imprecise, or incorrect, about their  
description (PGC_POSTMASTER or PGC_SIGHUP):  
- autovacuum_work_mem (docs, as of 9.6~)  
- huge_page_size (docs, as of 14~)  
- max_logical_replication_workers (docs, as of 10~)  
- max_sync_workers_per_subscription (docs, as of 10~)  
- min_dynamic_shared_memory (docs, as of 14~)  
- recovery_init_sync_method (postgresql.conf.sample, as of 14~)  
- remove_temp_files_after_crash (docs, as of 14~)  
- restart_after_crash (docs, as of 9.6~)  
- ssl_min_protocol_version (docs, as of 12~)  
- ssl_max_protocol_version (docs, as of 12~)  
  
This commit adjusts the description of all these parameters to be more  
consistent with the practice used for the others.  
  
Revewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/YK2ltuLpe+FbRXzA@paquier.xyz  
Backpatch-through: 9.6  

commit   : 6f4bdf81529fdaf6744875b0be99ecb9bfb3b7e0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 May 2021 07:59:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 27 May 2021 07:59:43 +0530    

While decoding the multi-insert WAL we can't clean the toast untill we get  
the last insert of that WAL record. Now if we stream the changes before we  
get the last change, the memory for toast chunks won't be released and we  
expect the txn to have streamed all changes after streaming.  This  
restriction is mainly to ensure the correctness of streamed transactions  
and it doesn't seem worth uplifting such a restriction just to allow this  
case because anyway we will stream the transaction once such an insert is  
complete.  
  
Previously we were using two different flags (one for toast tuples and  
another for speculative inserts) to indicate partial changes. Now instead  
we replaced both of them with a single flag to indicate partial changes.  
  
Reported-by: Pavan Deolasee  
Author: Dilip Kumar  
Reviewed-by: Pavan Deolasee, Amit Kapila  
Discussion: https://postgr.es/m/CABOikdN-_858zojYN-2tNcHiVTw-nhxPwoQS4quExeweQfG1Ug@mail.gmail.com  

commit   : 190fa5a00a8f9ecee8eef2c8e26136b772b94e19    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 May 2021 19:53:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 May 2021 19:53:03 +0900    

Author: Hou Zhijie  
Discussion: https://postgr.es/m/OS0PR01MB571612191738540B27A8DE5894249@OS0PR01MB5716.jpnprd01.prod.outlook.com  

commit   : eb43bdbf5104c183412aac0fccf8e515e60d9212    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 19:32:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 19:32:22 -0400    

Same as 5e0b1aeb2dfe, for the companion test file.  
  
This one seems lower probability (only two failures in a month of runs);  
I was hardly able to reproduce a failure without a patch, so the fact  
that I was also unable to reproduce one with it doesn't say anything.  
We'll have to wait for further buildfarm results to see if we need any  
further adjustments.  
  
Discussion: https://postgr.es/m/20210524090712.GA3771394@rfd.leadboat.com  

commit   : e30e3fdea873e4e9517c490232ea1d3bcef6c643    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 May 2021 12:55:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 May 2021 12:55:52 -0400    

Commit e717a9a18 introduced a code path that bypassed the call of  
get_expr_result_type, which is not good because we need its rettupdesc  
result to pass to check_sql_fn_retval.  We'd failed to notice right  
away because the code path in which check_sql_fn_retval uses that  
argument is fairly hard to reach in this context.  It's not impossible  
though, and in any case inline_function would have no business  
assuming that check_sql_fn_retval doesn't need that value.  
  
To fix, move get_expr_result_type out of the if-block, which in  
turn requires moving the construction of the dummy FuncExpr  
out of it.  
  
Per report from Ranier Vilela.  (I'm bemused by the lack of any  
compiler complaints...)  
  
Discussion: https://postgr.es/m/CAEudQAqBqQpQ3HruWAGU_7WaMJ7tntpk0T8k_dVtNB46DqdBgw@mail.gmail.com  

commit   : 5e0b1aeb2dfed4f1eb7ac5154c1573885a70db41    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 12:53:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 May 2021 12:53:29 -0400    

This recently added test has shown to be too sensitive to timing when  
sending a cancel to a session waiting for a lock.  
  
We fix this by running a no-op query in the blocked session immediately  
after the cancel; this avoids the session that sent the cancel sending  
another query immediately before the cancel has been reported.  
Idea by Noah Misch.  
  
With that fix, we sometimes see that the cancel error report is shown  
only relative to the step that is cancelled, instead of together with  
the step that sends the cancel.  To increase the probability that both  
steps are shown togeter, add a 0.1s sleep to the cancel.  In normal  
conditions this appears sufficient to silence most failures, but we'll  
see that the slower buildfarm members say about it.  
  
Reported-by: Takamichi Osumi <osumi.takamichi@fujitsu.com>  
Discussion: https://postgr.es/m/OSBPR01MB4888C4ABA361C7E81094AC66ED269@OSBPR01MB4888.jpnprd01.prod.outlook.com  

commit   : 8673a37c85fef00dd5b9c04197538142bec10542    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 May 2021 11:49:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 25 May 2021 11:49:54 +0200    

commit   : fb0f5f0172edf9f63c8f70ea9c1ec043b61c770e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 14:27:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 14:27:18 +0900    

VACUUM FULL and CLUSTER can be used to enforce the use of the existing  
compression method of a toastable column if a value currently stored is  
compressed with a method that does not match the column's defined  
method.  The code in charge of decompressing and recompressing toast  
values at rewrite left around the detoasted values, causing an  
accumulation of memory allocated in TopTransactionContext.  
  
When processing large relations, this could cause the system to run out  
of memory.  The detoasted values are not needed once their tuple is  
rewritten, and this commit ensures that the necessary cleanup happens.  
  
Issue introduced by bbe0a81d.  The comments of the area are reordered a  
bit while on it.  
  
Reported-by: Andres Freund  
Analyzed-by: Andres Freund  
Author: Michael Paquier  
Reviewed-by: Dilip Kumar  
Discussion: https://postgr.es/m/20210521211929.pcehg6f23icwstdb@alap3.anarazel.de  

commit   : 0c6b92d9c6fb74255467573fde54f65139b26603    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 10:51:45 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 10:51:45 +0530    

Add the information of pg_stat_replication_slots view along with other  
system catalogs related to logical decoding.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de  

commit   : 0734b0e983443882ec509ab4501c30ba9b706f5f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 09:26:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 25 May 2021 09:26:53 +0530    

The error messages, docs, and one of the options were using  
'parallel degree' to indicate parallelism used by vacuum command. We  
normally use 'parallel workers' at other places so change it for parallel  
vacuum accordingly.  
  
Author: Bharath Rupireddy  
Reviewed-by: Dilip Kumar, Amit Kapila  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CALj2ACWz=PYrrFXVsEKb9J1aiX4raA+UBe02hdRp_zqDkrWUiw@mail.gmail.com  

commit   : 01e6f1a842f406170e5f717305e4a6cf0e84b3ee    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 10:10:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 May 2021 10:10:09 +0900    

SSL renegotiation is already disabled as of 48d23c72, however this does  
not prevent the server to comply with a client willing to use  
renegotiation.  In the last couple of years, renegotiation had its set  
of security issues and flaws (like the recent CVE-2021-3449), and it  
could be possible to crash the backend with a client attempting  
renegotiation.  
  
This commit takes one extra step by disabling renegotiation in the  
backend in the same way as SSL compression (f9264d15) or tickets  
(97d3a0b0).  OpenSSL 1.1.0h has added an option named  
SSL_OP_NO_RENEGOTIATION able to achieve that.  In older versions  
there is an option called SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS that  
was undocumented, and could be set within the SSL object created when  
the TLS connection opens, but I have decided not to use it, as it feels  
trickier to rely on, and it is not official.  Note that this option is  
not usable in OpenSSL < 1.1.0h as the internal contents of the *SSL  
object are hidden to applications.  
  
SSL renegotiation concerns protocols up to TLSv1.2.  
  
Per original report from Robert Haas, with a patch based on a suggestion  
by Andres Freund.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/YKZBXx7RhU74FlTE@paquier.xyz  
Backpatch-through: 9.6  

commit   : cba5c70b956810c61b3778f7041f92fbb8065acb    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 25 May 2021 12:50:22 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 25 May 2021 12:50:22 +1200    

Result Cache, added in 9eacee2e6 neglected to properly adjust the plan  
references in setrefs.c.  This could lead to the following error during  
EXPLAIN:  
  
ERROR:  cannot decompile join alias var in plan tree  
  
Fix that.  
  
Bug: 17030  
Reported-by: Hans Buschmann  
Discussion: https://postgr.es/m/17030-5844aecae42fe223@postgresql.org  

commit   : c242baa4a831ac2e7dcaec85feb410aefa3a996e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 May 2021 17:14:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 May 2021 17:14:02 -0700    

The wraparound failsafe mechanism added by commit 1e55e7d1 handled the  
one-pass strategy case (i.e. the "table has no indexes" case) by adding  
a dedicated failsafe check.  This made up for the fact that the usual  
one-pass checks inside lazy_vacuum_all_indexes() cannot ever be reached  
during a one-pass strategy VACUUM.  
  
This approach failed to account for two-pass VACUUMs that opt out of  
index vacuuming up-front.  The INDEX_CLEANUP off case in the only case  
that works like that.  
  
Fix this by performing a failsafe check every 4GB during the first scan  
of the heap, regardless of the details of the VACUUM.  This eliminates  
the special case, and will make the failsafe trigger more reliably.  
  
Author: Peter Geoghegan <pg@bowt.ie>  
Reported-By: Andres Freund <andres@anarazel.de>  
Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>  
Discussion: https://postgr.es/m/20210424002921.pb3t7h6frupdqnkp@alap3.anarazel.de  

commit   : 713a431c781fbfe1a22fae4991836077f0f4c513    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 May 2021 18:03:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 May 2021 18:03:47 -0400    

pg_statistic_ext_data.stxdexpr was listed under the wrong catalog,  
as was pg_stats_ext.exprs.  Also there was a bogus entry for  
pg_statistic_ext_data.stxexprs.  Apparently a merge failure in  
commit a4d75c86b.  
  
Guillaume Lelarge and Tom Lane  
  
Discussion: https://postgr.es/m/CAECtzeUHw+w64eUFVeV_2FJviAw6oZ0wNLkmU843ZH4hAQfiWg@mail.gmail.com  

commit   : 99c5852e20a0987eca1c38ba0c09329d4076b6a0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 24 May 2021 12:37:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 24 May 2021 12:37:11 +1200    

Code added in 9e215378d to disable building of Result Cache paths when  
not all join conditions are part of the parameterization of a unique  
join failed to first check if the inner path's param_info was set before  
checking the param_info's ppi_clauses.  
  
Add a check for NULL values here and just bail on trying to build the  
path if param_info is NULL. lateral_vars are not considered when  
deciding if the join is unique, so we're not missing out on doing the  
optimization when there are lateral_vars and no param_info.  
  
Reported-by: Coverity, via Tom Lane  
Discussion: https://postgr.es/m/457998.1621779290@sss.pgh.pa.us  

commit   : f5024d8d7b04de2f5f4742ab433cc38160354861    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 12:12:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 12:12:09 -0400    

Now that attcompression is just a char, there's a lot of wasted  
padding space after it.  Move it into the group of char-wide  
columns to save a net of 4 bytes per pg_attribute entry.  While  
we're at it, swap the order of attstorage and attalign to make for  
a more logical grouping of these columns.  
  
Also re-order actions in related code to match the new field ordering.  
  
This patch also fixes one outright bug: equalTupleDescs() failed to  
compare attcompression.  That could, for example, cause relcache  
reload to fail to adopt a new value following a change.  
  
Michael Paquier and Tom Lane, per a gripe from Andres Freund.  
  
Discussion: https://postgr.es/m/20210517204803.iyk5wwvwgtjcmc5w@alap3.anarazel.de  

commit   : bc2a389efb3b52d259cefd53c16cfa00742116f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 10:50:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 May 2021 10:50:21 -0400    

Emit a LOG message when the postmaster stops because of a failure in  
the startup process.  There already is a similar message if we exit  
for that reason during PM_STARTUP phase, so it seems inconsistent  
that there was none if the startup process fails later on.  
  
Also emit a LOG message when the postmaster stops after a crash  
because restart_after_crash is disabled.  This seems potentially  
helpful in case DBAs (or developers) forget that that's set.  
Also, it was the only remaining place where the postmaster would  
do an abnormal exit without any comment as to why.  
  
In passing, remove an unreachable call of ExitPostmaster(0).  
  
Discussion: https://postgr.es/m/194914.1621641288@sss.pgh.pa.us  

commit   : 8f73ed6b659464274eb9cc8358588b569960d0be    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 22:25:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 22:25:05 -0400    

commit   : b39630fd41f25b414d0ea9b30804f4105f2a0aff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 21:24:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 21:24:48 -0400    

If we redirected a replicated tuple operation into a partition child  
table, and then tried to fire AFTER triggers for that event, the  
relation cache entry for the child table was already closed.  This has  
no visible ill effects as long as the entry is still there and still  
valid, but an unluckily-timed cache flush could result in a crash or  
other misbehavior.  
  
To fix, postpone the ExecCleanupTupleRouting call (which is what  
closes the child table) until after we've fired triggers.  This  
requires a bit of refactoring so that the cleanup function can  
have access to the necessary state.  
  
In HEAD, I took the opportunity to simplify some of worker.c's  
function APIs based on use of the new ApplyExecutionData struct.  
However, it doesn't seem safe/practical to back-patch that aspect,  
at least not without a lot of analysis of possible interactions  
with a04daa97a.  
  
In passing, add an Assert to afterTriggerInvokeEvents to catch  
such cases.  This seems worthwhile because we've grown a number  
of fairly unstructured ways of calling AfterTriggerEndQuery.  
  
Back-patch to v13, where worker.c grew the ability to deal with  
partitioned target tables.  
  
Discussion: https://postgr.es/m/3382681.1621381328@sss.pgh.pa.us  

commit   : 7ce7d07e1c5fb33ee56bda235ae3d53f162f3bc0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 20:17:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 20:17:58 -0400    

Reported-by: Stephen Frost  
  
Discussion: https://postgr.es/m/20210522232945.GO20766@tamriel.snowman.net  

commit   : 8dcae7f0a3d6aba1afad1599ab18d259c417b4ee    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 19:24:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 22 May 2021 19:24:23 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-WzmgSnDX9WVoxRZxuKeCy2MzLO9Dmo4+go0RzNW0VBdhmw@mail.gmail.com  

commit   : 30168be8f75b95183abccf48f0da7a64a0cfbd9f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 10:25:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 May 2021 10:25:36 -0400    

In the wake of 84f5c2908, it's no longer necessary for plpgsql to  
handle SET/RESET specially.  The point of that was just to avoid  
taking a new transaction snapshot prematurely, which the regular code  
path through _SPI_execute_plan() now does just fine (in fact better,  
since it now does the right thing for LOCK too).  Hence, rip out a  
few lines of code, going back to the old way of treating SET/RESET  
as a generic SQL command.  This essentially reverts all but the  
test cases from b981275b6.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : 9e215378d7fbb7d4615be917917c52f246cc6c61    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 22 May 2021 16:22:27 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 22 May 2021 16:22:27 +1200    

When the planner considered using a Result Cache node to cache results  
from the inner side of a Nested Loop Join, it failed to consider that the  
inner path's parameterization may not be the entire join condition.  If  
the join was marked as inner_unique then we may accidentally put the cache  
in singlerow mode.  This meant that entries would be marked as complete  
after caching the first row.  That was wrong as if only part of the join  
condition was parameterized then the uniqueness of the unique join was not  
guaranteed at the Result Cache's level.  The uniqueness is only guaranteed  
after Nested Loop applies the join filter.  If subsequent rows were found,  
this would lead to:  
  
ERROR: cache entry already complete  
  
This could have been fixed by only putting the cache in singlerow mode if  
the entire join condition was parameterized.  However, Nested Loop will  
only read its inner side so far as the first matching row when the join is  
unique, so that might mean we never get an opportunity to mark cache  
entries as complete.  Since non-complete cache entries are useless for  
subsequent lookups, we just don't bother considering a Result Cache path  
in this case.  
  
In passing, remove the XXX comment that claimed the above ERROR might be  
better suited to be an Assert.  After there being an actual case which  
triggered it, it seems better to keep it an ERROR.  
  
Reported-by: David Christensen  
Discussion: https://postgr.es/m/CAOxo6X+dy-V58iEPFgst8ahPKEU+38NZzUuc+a7wDBZd4TrHMQ@mail.gmail.com  

commit   : 0cdaa05b40e9f28e5d6d58ccd06fe19f3cd920c9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 20:51:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 20:51:53 -0400    

commit   : 55370f8db96c8416940ad0b05be7a00a9f059a9f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 16:16:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 May 2021 16:16:56 -0400    

commit   : 4b10074453d182b5fc11a5667bab2ef8532ff3a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:12:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:12:08 -0400    

This was previously allowed, but I think that was just an oversight.  
It's a clear violation of the rule that a generated column cannot  
depend on itself or other generated columns.  Moreover, because the  
code was relying on the assumption that no such cross-references  
exist, it was pretty easy to crash ALTER TABLE and perhaps other  
places.  Even if you managed not to crash, you got quite unstable,  
implementation-dependent results.  
  
Per report from Vitaly Ustinov.  
Back-patch to v12 where GENERATED came in.  
  
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com  

commit   : 2b0ee126bbf01cbfd657bd53c94f9284ba903ca2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:02:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 15:02:06 -0400    

We consider this supported (though I've got my doubts that it's a  
good idea, because tableoid is not immutable).  However, several  
code paths failed to fill the field in soon enough, causing such  
a GENERATED expression to see zero or the wrong value.  This  
occurred when ALTER TABLE adds a new GENERATED column to a table  
with existing rows, and during regular INSERT or UPDATE on a  
foreign table with GENERATED columns.  
  
Noted during investigation of a report from Vitaly Ustinov.  
Back-patch to v12 where GENERATED came in.  
  
Discussion: https://postgr.es/m/CAM_DEiWR2DPT6U4xb-Ehigozzd3n3G37ZB1+867zbsEVtYoJww@mail.gmail.com  

commit   : 84f5c2908dad81e8622b0406beea580e40bb03ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 14:03:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 May 2021 14:03:53 -0400    

COMMIT/ROLLBACK necessarily destroys all snapshots within the session.  
The original implementation of intra-procedure transactions just  
cavalierly did that, ignoring the fact that this left us executing in  
a rather different environment than normal.  In particular, it turns  
out that handling of toasted datums depends rather critically on there  
being an outer ActiveSnapshot: otherwise, when SPI or the core  
executor pop whatever snapshot they used and return, it's unsafe to  
dereference any toasted datums that may appear in the query result.  
It's possible to demonstrate "no known snapshots" and "missing chunk  
number N for toast value" errors as a result of this oversight.  
  
Historically this outer snapshot has been held by the Portal code,  
and that seems like a good plan to preserve.  So add infrastructure  
to pquery.c to allow re-establishing the Portal-owned snapshot if it's  
not there anymore, and add enough bookkeeping support that we can tell  
whether it is or not.  
  
We can't, however, just re-establish the Portal snapshot as part of  
COMMIT/ROLLBACK.  As in normal transaction start, acquiring the first  
snapshot should wait until after SET and LOCK commands.  Hence, teach  
spi.c about doing this at the right time.  (Note that this patch  
doesn't fix the problem for any PLs that try to run intra-procedure  
transactions without using SPI to execute SQL commands.)  
  
This makes SPI's no_snapshots parameter rather a misnomer, so in HEAD,  
rename that to allow_nonatomic.  
  
replication/logical/worker.c also needs some fixes, because it wasn't  
careful to hold a snapshot open around AFTER trigger execution.  
That code doesn't use a Portal, which I suspect someday we're gonna  
have to fix.  But for now, just rearrange the order of operations.  
This includes back-patching the recent addition of finish_estate()  
to centralize the cleanup logic there.  
  
This also back-patches commit 2ecfeda3e into v13, to improve the  
test coverage for worker.c (it was that test that exposed that  
worker.c's snapshot management is wrong).  
  
Per bug #15990 from Andreas Wicht.  Back-patch to v11 where  
intra-procedure COMMIT was added.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : 124966c1a35b950210e12048e64533963960febd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 May 2021 17:10:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 21 May 2021 17:10:09 +0200    

commit   : 6d0eb38557155855539cd007f04736dc3b2ba16f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 May 2021 07:54:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 21 May 2021 07:54:27 +0530    

While applying the truncate change, the logical apply worker acquires  
RowExclusiveLock on the relation being truncated. This allowed truncate on  
the relation at a time by two apply workers which lead to a deadlock. The  
reason was that one of the workers after updating the pg_class tuple tries  
to acquire SHARE lock on the relation and started to wait for the second  
worker which has acquired RowExclusiveLock on the relation. And when the  
second worker tries to update the pg_class tuple, it starts to wait for  
the first worker which leads to a deadlock. Fix it by acquiring  
AccessExclusiveLock on the relation before applying the truncate change as  
we do for normal truncate operation.  
  
Author: Peter Smith, test case by Haiying Tang  
Reviewed-by: Dilip Kumar, Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAHut+PsNm43p0jM+idTvWwiGZPcP0hGrHMPK9TOAkc+a4UpUqw@mail.gmail.com  

commit   : f21fadafaf0fb5ea4c9622d915972651273d62ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 18:32:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 18:32:37 -0400    

exec_for_query() normally tries to prefetch a few rows at a time  
from the query being iterated over, so as to reduce executor  
entry/exit overhead.  Unfortunately this is unsafe if we have  
COMMIT or ROLLBACK within the loop, because there might be  
TOAST references in the data that we prefetched but haven't  
yet examined.  Immediately after the COMMIT/ROLLBACK, we have  
no snapshots in the session, meaning that VACUUM is at liberty  
to remove recently-deleted TOAST rows.  
  
This was originally reported as a case triggering the "no known  
snapshots" error in init_toast_snapshot(), but even if you miss  
hitting that, you can get "missing toast chunk", as illustrated  
by the added isolation test case.  
  
To fix, just disable prefetching in non-atomic contexts.  Maybe  
there will be performance complaints prompting us to work harder  
later, but it's not clear at the moment that this really costs  
much, and I doubt we'd want to back-patch any complicated fix.  
  
In passing, adjust that error message in init_toast_snapshot()  
to be a little clearer about the likely cause of the problem.  
  
Patch by me, based on earlier investigation by Konstantin Knizhnik.  
  
Per bug #15990 from Andreas Wicht.  Back-patch to v11 where  
intra-procedure COMMIT was added.  
  
Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org  

commit   : 4f586fe244a296d7c781de3f06c54755f2ae222b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 20 May 2021 15:50:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 20 May 2021 15:50:46 -0400    

commit   : bdbb2ce7d51e93ca2ec68e25e2fafb271b34e72d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 15:11:17 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 15:11:17 -0400    

A lamentable oversight on my part meant that when PostgresVersion.pm was  
added in commit 4c4eaf3d19 provision to install it was not added to the  
Makefile, so it was not installed along with the other perl modules.  

commit   : 6d59a218c38adf5b993200a804713df4982a0c75    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 13:03:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 May 2021 13:03:08 -0400    

"typename" is a C++ keyword, so pg_upgrade.h fails to compile in C++.  
Fortunately, there seems no likely reason for somebody to need to  
do that.  Nonetheless, it's project policy that all .h files should  
pass cpluspluscheck, so rename the argument to fix that.  
  
Oversight in 57c081de0; back-patch as that was.  (The policy requiring  
pg_upgrade.h to pass cpluspluscheck only goes back to v12, but it  
seems best to keep this code looking the same in all branches.)  

commit   : 8bdd6f563aa2456de602e78991e6a9f61b8ec86d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 08:03:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 20 May 2021 08:03:15 -0400    

Older versions of perl on Windows don't like the list form of pipe open,  
and perlcritic doesn't like the string form of open, so we avoid both  
with a simpler formulation using qx{}.  
  
Per complaint from Amit Kapila.  

commit   : 413c1ef98e0c9c708c4a9a13a838a55b65b16a80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 May 2021 14:04:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 May 2021 14:04:01 -0400    

Recently we refactored things so that pg_regress makes the  
"testtablespace" subdirectory used by the core regression tests,  
instead of doing that in the makefiles.  That had the undesirable  
side effect of making such a subdirectory in every directory that  
has "input" or "output" test files.  Since these subdirectories  
remain empty, git doesn't complain about them, but nonetheless  
they're clutter.  
  
To fix, invent an explicit --make-testtablespace-dir switch,  
so that pg_regress only makes the subdirectory when explicitly  
told to.  
  
Discussion: https://postgr.es/m/2854388.1621284789@sss.pgh.pa.us  

commit   : 4f7d1c30966cc02fd5eba2f0d51d1f53be07d457    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:22:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:22:21 -0400    

Fix PG 14 relnotes to use <link> instead of <xref>.  This was discussed  
in commit message 59fa7eb603.  

commit   : 1e7d53bd019e9d86ef1013308715622a2e400d3b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:01:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 19 May 2021 11:01:28 -0400    

commit   : 0f516d039d8023163e82fa51104052306068dd69    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 19 May 2021 12:50:58 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 19 May 2021 12:50:58 +0100    

One of the tests for the pgbench permute() function added by  
6b258e3d68 fails on some 32-bit platforms, due to variations in the  
floating point computations in getrand(). The remaining tests give  
sufficient coverage, so just remove the failing test.  
  
Reported by Christoph Berg. Analysis by Thomas Munro and Tom Lane.  
Based on patch by Fabien Coelho.  
  
Discussion: https://postgr.es/m/YKQnUoYV63GRJBDD@msg.df7cb.de  

commit   : 167bd4804995afd654bd97ca9486acbece24377e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 13:48:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 13:48:19 +0900    

If a promotion is triggered while recovery is paused, the paused state ends  
and promotion continues. But previously in that case  
pg_get_wal_replay_pause_state() returned 'paused' wrongly while a promotion  
was ongoing.  
  
This commit changes a standby promotion so that it marks the recovery  
pause state as 'not paused' when it's triggered, to fix the issue.  
  
Author: Fujii Masao  
Reviewed-by: Dilip Kumar, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/f706876c-4894-0ba5-6f4d-79803eeea21b@oss.nttdata.com  

commit   : 0a442a408b40d2c6710de7e5397cb2e769d8c630    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 19 May 2021 08:54:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 19 May 2021 08:54:46 +0530    

We were not waiting for a publisher to catch up with the subscriber after  
creating a subscription. Now, it can happen that apply worker starts  
replication even after we have disabled the subscription in the test. This  
will make the test expect that there is no active slot whereas there  
exists one. Fix this symptom by allowing the publisher to wait for  
catching up with the subscription.  
  
It is not a good idea to ensure if the slot is still active by checking  
for walsender existence as we release the slot after we clean up the  
walsender related memory. Fix that by checking the slot status in  
pg_replication_slots.  
  
Also, it is better to avoid repeated enabling/disabling of the  
subscription.  
  
Finally, we make autovacuum off for this test to avoid any empty  
transaction appearing in the test while consuming changes.  
  
Reported-by: as per buildfarm  
Author: Vignesh C  
Reviewed-by: Amit Kapila, Michael Paquier  
Discussion: https://postgr.es/m/CAA4eK1+uW1UGDHDz-HWMHMen76mKP7NJebOTZN4uwbyMjaYVww@mail.gmail.com  

commit   : 6a5bde7d4f96ef153578eaeb624ae12e48b46e85    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 23:21:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 23:21:47 -0400    

commit   : d8735b8b4651f5ed50afc472e236a8e6120f07f2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 11:38:34 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 May 2021 11:38:34 +0900    

1) Previously there were both pgstat_send_wal() and pgstat_report_wal()  
   in order to send WAL activity to the stats collector. With the former being  
   used by wal writer, the latter by most other processes. They were a bit  
   redundant and so this commit merges them into pgstat_send_wal() to  
   simplify the code.  
  
2) Previously WAL global statistics counters were calculated and then  
   compared with zero-filled buffer in order to determine whether any WAL  
   activity has happened since the last submission. These calculation and  
   comparison were not cheap. This was regularly exercised even in read-only  
   workloads. This commit fixes the issue by making some WAL activity  
   counters directly be checked to determine if there's WAL activity stats  
   to send.  
  
3) Previously pgstat_report_stat() did not check if there's WAL activity  
   stats to send as part of the "Don't expend a clock check if nothing to do"  
   check at the top. It's probably rare to have pending WAL stats without  
   also passing one of the other conditions, but for safely this commit  
   changes pgstat_report_stats() so that it checks also some WAL activity  
   counters at the top.  
  
This commit also adds the comments about the design of WAL stats.  
  
Reported-by: Andres Freund  
Author: Masahiro Ikeda  
Reviewed-by: Kyotaro Horiguchi, Atsushi Torikoshi, Andres Freund, Fujii Masao  
Discussion: https://postgr.es/m/20210324232224.vrfiij2rxxwqqjjb@alap3.anarazel.de  

commit   : 694da1983e9569b2a2f96cd786ead6b8dba31f1d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 May 2021 09:38:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 May 2021 09:38:48 +0900    

This is an oversight from bbe0a81d, where the equivalent option exists  
in pg_dump.  This is useful to be able to reset the compression methods  
cluster-wide when restoring the data based on default_toast_compression.  
  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/YKHC+qCJvzCRVCpY@paquier.xyz  

commit   : 2e7c17837064297f25c427d58154dce8d4287302    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 15:17:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 18 May 2021 15:17:44 -0400    

commit   : 2ded19fa3a4dafbae80245710fa371d5163bdad4    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:54:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 18 May 2021 09:54:56 +1200    

README.barrier didn't seem to get the memo when atomics were added. Fix  
that.  
  
Author: Tatsuo Ishii, David Rowley  
Discussion: https://postgr.es/m/20210516.211133.2159010194908437625.t-ishii%40sraoss.co.jp  
Backpatch-through: 9.6, oldest supported release  

commit   : e4f9737fac77a5cb03a84d1f4038d300ffd28afd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 May 2021 16:11:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 May 2021 16:11:18 -0400    

commit   : cff8436f19e1c0c278f1ee96d450507fbd43f9ef    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 17 May 2021 21:54:36 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 17 May 2021 21:54:36 +0200    

We used to distribute a binary version of flex for windows on our  
download site, but it hasn't been working for many years. The "old  
documentation" referenced was also for versions that have been EOL for  
many years. So, remove it.  
  
Discussion: https://postgr.es/m/CABUevEwXLJpVpab62f7AFXNWQ5=U0kvErCLq4VEsikidLyzSQg@mail.gmail.com  

commit   : fe2fb9ebcae8445fdb3915ecf8402a3a887effc2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 May 2021 14:05:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 17 May 2021 14:05:05 -0400    

commit   : 6292b83074243db94df89271842bda0877cbc4ce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 May 2021 14:30:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 May 2021 14:30:27 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 9bbd9c3714d0c76daaa806588b1fbf744aa60496