PostgreSQL 14.0 commit log

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