PostgreSQL 13.0 commit log

commit   : 29be9983a64c011eac0b9ee29895cce71e15ea77    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Sep 2020 16:47:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Sep 2020 16:47:36 -0400    

commit   : 4406364e2bf421459be7bd21503da093d910e0c3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Sep 2020 13:30:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Sep 2020 13:30:18 -0400    

The previous text was confusing, per off-list discussion with  
Bruce Momjian.  

commit   : e62c5ea22c12f63d8d5ca3b228a458dfc10ae314    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Sep 2020 12:43:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Sep 2020 12:43:42 -0400    

99% of this is docs, but also a couple of comments.  No code changes.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d83268ae10cdeb2aa88e32286e94a8a8f59653a0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 21 Sep 2020 10:06:30 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 21 Sep 2020 10:06:30 +0200    

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

commit   : f6727f29d52072bd0e87fbc9ed7af0d880db0d5c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 21 Sep 2020 09:05:13 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 21 Sep 2020 09:05:13 +0200    

commit   : 9ab5ed4194f3863ff744e195027da747d4db4106    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Sep 2020 18:03:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Sep 2020 18:03:44 -0400    

These two SQL functions are aliases for the same C function, so this  
change has no semantic effect.  However, because we dropped the  
numeric_fac alias in HEAD (commit 76f412ab3), operator definitions  
based on that one don't port forward, causing problems for cross-version  
upgrade tests based on the regression database.  
  
Patch all active back branches to dodge the problem.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f083afac9df707778288b9ab448be169a25e3ea6    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 18 Sep 2020 09:40:04 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 18 Sep 2020 09:40:04 +0530    

After commits 85f6b49c2c and 3ba59ccc89, we can allow parallel inserts  
which was earlier not possible as parallel group members won't conflict  
for relation extension and page lock.  In those commits, we forgot to  
update comments at few places.  
  
Author: Amit Kapila  
Reviewed-by: Robert Haas and Dilip Kumar  
Backpatch-through: 13  
Discussion: https://postgr.es/m/CAFiTN-tMrQh5FFMPx5aWJ+1gi1H6JxktEhq5mDwCHgnEO5oBkA@mail.gmail.com  

commit   : 0abd9cd2f3a1cad201ca28767aa0a720cc341179    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 17 Sep 2020 15:16:46 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 17 Sep 2020 15:16:46 +0530    

For parallel btree scan to work for array of scan keys, it should reach  
BTPARALLEL_DONE state once for every distinct combination of array keys.  
This is required to ensure that the parallel workers don't try to seize  
blocks at the same time for different scan keys. We missed to update this  
state when we discovered that the scan keys can't be satisfied.  
  
Author: James Hunter  
Reviewed-by: Amit Kapila  
Tested-by: Justin Pryzby  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/[email protected]  

commit   : bfb12cd2b59da2ce51a9c86bf2c468202d8f96ee    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 16 Sep 2020 13:04:38 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 16 Sep 2020 13:04:38 -0300    

Since commit fd5942c18f97 (2012, 9.3-era), walsender has been sending  
completion tags for certain replication commands twice -- and they're  
not even consistent.  Apparently neither libpq nor JDBC have a problem  
with it, but it's not kosher.  Fix by remove the EndCommand() call in  
the common code path for them all, and inserting specific calls to  
EndReplicationCommand() specifically in those places where it's needed.  
  
EndReplicationCommand() is a new simple function to send the completion  
tag for replication commands.  Do this instead of sending a generic  
SELECT completion tag for them all, which was also pretty bogus (if  
innocuous).  While at it, change StartReplication() to use  
EndReplicationCommand() instead of pg_puttextmessage().  
  
In commit 2f9661311b83, I failed to realize that replication commands  
are not close-enough kin of regular SQL commands, so the  
DROP_REPLICATION_SLOT tag I added is undeserved and a type pun.  Take it  
out.  
  
Backpatch to 13, where the latter commit appeared.  The duplicate tag  
has been sent since 9.3, but since nothing is broken, it doesn't seem  
worth fixing.  
  
Per complaints from Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c287f585865b81c96602db995dacf2c006c79d58    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 16 Sep 2020 10:42:28 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 16 Sep 2020 10:42:28 -0700    

Commit d114cc53 overlooked the fact that pg_upgrade'd B-Tree indexes  
have leaf page high keys whose offset numbers do not match the one from  
the copy of the tuple one level up (the copy stored with a downlink for  
leaf page's right sibling page).  This led to false positive reports of  
corruption from bt_index_parent_check() when it was called to verify a  
pg_upgrade'd index.  
  
To fix, skip comparing the offset number on pg_upgrade'd B-Tree indexes.  
  
Author: Anastasia Lubennikova <[email protected]>  
Author: Peter Geoghegan <[email protected]>  
Reported-By: Andrew Bille <[email protected]>  
Diagnosed-By: Anastasia Lubennikova <[email protected]>  
Bug: #16619  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 13-, where child check was enhanced.  

commit   : 17280b31c2f218f1b1f0c1fbacae7e781010a01b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Sep 2020 13:38:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Sep 2020 13:38:26 -0400    

If a partitioned table's column is already marked NOT NULL, there is  
no need to examine its partitions, because we can rely on previous  
DDL to have enforced that the child columns are NOT NULL as well.  
(Unfortunately, the same cannot be said for traditional inheritance,  
so for now we have to restrict the optimization to partitioned tables.)  
Hence, we may skip recursing to child tables in this situation.  
  
The reason this case is worth worrying about is that when pg_dump dumps  
a partitioned table having a primary key, it will include the requisite  
NOT NULL markings in the CREATE TABLE commands, and then add the  
primary key as a separate step.  The primary key addition generates a  
SET NOT NULL as a subcommand, just to be sure.  So the situation where  
a SET NOT NULL is redundant does arise in the real world.  
  
Skipping the recursion does more than just save a few cycles: it means  
that a command such as "ALTER TABLE ONLY partition_parent ADD PRIMARY  
KEY" will take locks only on the partition parent table, not on the  
partitions.  It turns out that parallel pg_restore is effectively  
assuming that that's true, and has little choice but to do so because  
the dependencies listed for such a TOC entry don't include the  
partitions.  pg_restore could thus issue this ALTER while data restores  
on the partitions are still in progress.  Taking unnecessary locks on  
the partitions not only hurts concurrency, but can lead to actual  
deadlock failures, as reported by Domagoj Smoljanovic.  
  
(A contributing factor in the deadlock is that TRUNCATE on a child  
partition wants a non-exclusive lock on the parent.  This seems  
likewise unnecessary, but the fix for it is more invasive so we  
won't consider back-patching it.  Fortunately, getting rid of one  
of these two poor behaviors is enough to remove the deadlock.)  
  
Although support for partitioned primary keys came in with v11,  
this patch is dependent on the SET NOT NULL refactoring done by  
commit f4a3fdfbd, so we can only patch back to v12.  
  
Patch by me; thanks to Alvaro Herrera and Amit Langote for review.  
  
Discussion: https://postgr.es/m/VI1PR03MB31670CA1BD9625C3A8C5DD05EB230@VI1PR03MB3167.eurprd03.prod.outlook.com  

commit   : 3e3f8f20206cbbb8d30be528d2a640d14a95c25c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Sep 2020 12:07:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Sep 2020 12:07:31 -0400    

The code recorded cache invalidation events by zeroing the "localreloid"  
field of affected cache entries.  However, it's possible for an inval  
event to occur even while we have the entry open and locked.  So an  
ill-timed inval could result in "cache lookup failed for relation 0"  
errors, if the worker's code tried to use the cleared field.  We can  
fix that by creating a separate bool field to record whether the entry  
needs to be revalidated.  (In the back branches, cram the bool into  
what had been padding space, to avoid an ABI break in the somewhat  
unlikely event that any extension is looking at this struct.)  
  
Also, rearrange the logic in logicalrep_rel_open so that it  
does the right thing in cases where table_open would fail.  
We should retry the lookup by name in that case, but we didn't.  
  
The real-world impact of this is probably small.  In the first place,  
the error conditions are very low probability, and in the second place,  
the worker would just exit and get restarted.  We only noticed because  
in a CLOBBER_CACHE_ALWAYS build, the failure can occur repeatedly,  
preventing the worker from making progress.  Nonetheless, it's clearly  
a bug, and it impedes a useful type of testing; so back-patch to v10  
where this code was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6e146a663536f86c8421ac6ed08c4eb9a69979fd    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 15 Sep 2020 21:34:05 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 15 Sep 2020 21:34:05 -0700    

Previously, it was based on nBlocksAllocated to account for tapes with  
open write buffers that may not have made it to the BufFile yet.  
  
That was unnecessary, because callers do not need to get the number of  
blocks while a tape has an open write buffer; and it also conflicted  
with the preallocation logic added for HashAgg.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : 42a46f5a76ecb435ac3a29fc3a0d03f1cfff17ab    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 15 Sep 2020 21:16:31 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 15 Sep 2020 21:16:31 -0700    

This was an oversight. The purpose of 7fdd919ae7 was to avoid keeping  
tape buffers around unnecessisarily, but HashAgg didn't rewind early  
enough.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : 873cb8fca9b14bde3e1d5577fcbb7b76d303076d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 15 Sep 2020 21:03:14 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 15 Sep 2020 21:03:14 -0300    

ALTER TABLE commands in an extension script are added to an event  
trigger command list; but starting with commit b5810de3f4 they do so in  
a memory context that's too short-lived, so when execution ends and time  
comes to use the entries, they've already been freed.  
  
(This would also be a problem with ALTER TABLE commands in a  
multi-command query string, but these serendipitously end in  
PortalContext -- which probably explains why it took so long for this to  
be reported.)  
  
Fix by using the memory context specifically set for that, instead.  
  
Backpatch to 13, where the aforementioned commit appeared.  
  
Reported-by: Philippe Beaudoin  
Author: Jehan-Guillaume de Rorthais <[email protected]>  
Discussion: https://postgr.es/m/20200902193715.6e0269d4@firost  

commit   : d42c6176446440b185fcb95c214b7e40d5758b60    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 15 Sep 2020 14:29:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 15 Sep 2020 14:29:43 -0400    

Per gripe from Jonathan Katz.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 001d2c5f15bf8d554a7fe28af033d82c24de4e44    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 15 Sep 2020 10:58:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 15 Sep 2020 10:58:37 -0400    

Parallel vacuuming isn't restricted to b-tree indexes.  
Noted by Peter Eisentraut.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : efea2b85fa2c3dec1c8039f1c97fcfe53ee5e82c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Sep 2020 16:08:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Sep 2020 16:08:07 -0400    

commit   : bab6f77f24407e0924dac292af9e65016fce99bf    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 14 Sep 2020 13:14:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 14 Sep 2020 13:14:53 +0200    

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

commit   : 6fb1c5b528267918a88c4143985a08a3c997e528    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 13 Sep 2020 23:29:51 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 13 Sep 2020 23:29:51 -0700    

A pre-commit review had reported the problem, but the fix reached only  
v10 and earlier.  Back-patch to v11.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b1b53f15bbac106e241b14ae1bc13f2708fe74c8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 14 Sep 2020 06:42:07 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 14 Sep 2020 06:42:07 +0200    

commit   : b380484a850b6bf7d9fc0d85c555a2366e38451f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 13 Sep 2020 12:51:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 13 Sep 2020 12:51:21 -0400    

transformCreateStmt() adjusts the transformed statement's RangeVar  
to specify the target schema explicitly, for the express reason  
of making sure that auxiliary statements derived by parse  
transformation operate on the right table.  But the refactoring  
I did in commit 502898192 got this wrong and passed the untransformed  
RangeVar to expandTableLikeClause().  This could lead to assertion  
failures or weird misbehavior if the wrong table was accessed.  
  
Per report from Alexander Lakhin.  Like the previous patch, back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e6bbe07deec9824eb62fbbf38c4bfe7aaf674d37    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 6 Sep 2020 16:46:13 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 6 Sep 2020 16:46:13 +0200    

The original stylesheets seemed to think this was a good idea, but our  
users find it confusing and unhelpful, so undo that logic.  
  
Reported-by: Fabien COELHO <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.22.394.2006210914370.859381%40pseudo  

commit   : 93106d71a18afdda2b9bf6e6b8e6c7f9cea2d0ef    
  
author   : Jeff Davis <[email protected]>    
date     : Fri, 11 Sep 2020 17:10:02 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Fri, 11 Sep 2020 17:10:02 -0700    

The preallocation logic is only useful for HashAgg, so disable it when  
sorting.  
  
Also, adjust an out-of-date comment.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wzn_o7tE2+hRVvwSFghRb75AJ5g-nqGzDUqLYMexjOAe=g@mail.gmail.com  
Backpatch-through: 13  

commit   : aeb781107a7ca0cfe109c188534ecbf9c392f6ba    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 11 Sep 2020 16:15:47 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 11 Sep 2020 16:15:47 -0300    

The stats target can be set since commit d06215d03, but wasn't shown by  
psql.  
  
Author: Justin Pryzby <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Georgios Kokolatos <[email protected]>  
Reviewed-by: Tatsuro Yamada <[email protected]>  

commit   : 6dcec8fe13b41b0773e9122168a1b53f3e458206    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 11 Sep 2020 12:53:25 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 11 Sep 2020 12:53:25 -0300    

Thinko in 40b3e2c201af.  
  
Reported-by: "Wang, Shenhao" <[email protected]>  
Discussion: https://postgr.es/m/ed98706b82694b57a8c0d339a10732aa@G08CNEXMBPEKD06.g08.fujitsu.local  

commit   : 9892564121d425291c4fd06ff083147dd70b9156    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 18:42:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 18:42:57 -0400    

Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3965de54e718600a4703233936e56a3202caf73f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 17:43:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 17:43:16 -0400    

Also set the release date ... hopefully we won't have to change that.  

commit   : 3d92252d7d8bf7080ba61f1bda3d27bd8a3617e1    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 13:14:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 13:14:09 -0400    

Jonathan S. Katz, minor tweaks by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3f29aa48b6df318e43d0efe5735f61175ef38574    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 12:06:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 Sep 2020 12:06:26 -0400    

Bring the signal handling for startup-packet collection into line  
with the policy established in commits bedadc732 and 8e19a8264,  
namely don't risk running atexit callbacks when handling SIGQUIT.  
  
Ideally, we'd not do so for SIGTERM or timeout interrupts either,  
but that change seems a bit too risky for the back branches.  
For now, just improve the comments in this area to describe the risk.  
  
Also relocate where BackendInitialize re-disables these interrupts,  
to minimize the code span where they're active.  This doesn't buy  
a whole lot of safety, but it can't hurt.  
  
In passing, rename startup_die() to remove confusion about whether  
it is for the startup process.  
  
Like the previous commits, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9f358c5ef31327f7a67af783f5f37468bbac3aed    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 10 Sep 2020 15:31:09 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 10 Sep 2020 15:31:09 +0200    

We have had multiple reports that point to the  
'@colReorder=latn-digit' collation customization being buggy.  We have  
reported this to ICU and are waiting for a fix.  In the meantime,  
remove references to this from the documentation and replace it by  
another reordering example.  Apparently, many users have been picking  
up this example specifically from the documentation.  
  
Author: Jehan-Guillaume de Rorthais <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/153201618542.1404.3611626898935613264%40wrigleys.postgresql.org  

commit   : 727f6fb8f71f7ed64e6883164765bbf6cb7684ec    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 10 Sep 2020 14:15:26 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 10 Sep 2020 14:15:26 +0200    

Reported-by: Robert Kahlert  
Author: Daniel Gustafsson  

commit   : d601a930756b96fe05beb75a1b624a8155c98cc8    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 10 Sep 2020 18:00:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 10 Sep 2020 18:00:01 +0900    

Do some minor cleanup for commit c8434d64c: 1) remove a useless  
assignment (in normal builds) and 2) improve comments a little.  
  
Back-patch to v13 where the aforementioned commit went in.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/CAPmGK16yCd2R4=bQ4g8N2dT9TtA5ZU+qNmJ3LPc_nypbNy4_2A@mail.gmail.com  

commit   : 32a433455a0a6918b9c8f300d6c0be73ef06e9f9    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 10 Sep 2020 16:15:00 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 10 Sep 2020 16:15:00 +0900    

Standardize Japanese names as given-name-first.  
  
Author: Etsuro Fujita  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/CAPmGK14S5frHWzsKS14R2LeMjKkjr5PeqRGiKZ0os0A+o8BWuQ@mail.gmail.com  

commit   : b3d89b7a889614a5ad549bae49b8a6fdda3a6bdd    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 10 Sep 2020 15:50:42 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 10 Sep 2020 15:50:42 +0900    

Some comments are fixed while on it.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : 6f15be5bedfc423b8a8f2f0282e2a0eb20a16663    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 9 Sep 2020 18:50:24 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 9 Sep 2020 18:50:24 -0700    

Move applicable code out of RelationBuildDesc(), which nailed relations  
bypass.  Non-assert builds experienced no known problems.  Back-patch to  
v13, where commit c6b92041d38512a4176ed76ad06f713d2e6c01a8 introduced  
rd_firstRelfilenodeSubid.  
  
Kyotaro Horiguchi.  Reported by Justin Pryzby.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 35e59398abbb562f1e831af206f1d1cc8c3cb7db    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Sep 2020 15:32:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Sep 2020 15:32:34 -0400    

Commit 8e19a8264 changed the SIGQUIT handlers of almost all server  
processes not to run atexit callbacks.  The archiver process was  
skipped, perhaps because it's not connected to shared memory; but  
it's just as true here that running atexit callbacks in a signal  
handler is unsafe.  So let's make it work like the rest.  
  
In HEAD and v13, we can use the common SignalHandlerForCrashExit  
handler.  Before that, just tweak pgarch_exit to use _exit(2)  
explicitly.  
  
Like the previous commit, back-patch to all supported branches.  
  
Kyotaro Horiguchi, back-patching by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6b473ab4f23736d67c420909ab65c55228dcd6e6    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Sep 2020 12:00:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Sep 2020 12:00:49 -0400    

Commit 15cb2bd27 neglected to make the running text match the  
tables, leaving the reader with the strong impression that  
we cannot count.  Also, don't drop an unrelated para between  
a table and the para describing it.  

commit   : aa33187164e1d8571f1568f0470aaace8f791876    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Sep 2020 11:53:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Sep 2020 11:53:39 -0400    

Alexander Lakhin  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1bf0b9c5f58c61c160519a77a8f9dd24cea68b32    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 9 Sep 2020 12:20:53 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 9 Sep 2020 12:20:53 +0200    

Mistake in commit 68b603e1a9.  
  
Reported-by: Ian Barwick  

commit   : d0230a43fcae6f923fcedfe6f27db7fca8760d95    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 8 Sep 2020 19:35:15 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 8 Sep 2020 19:35:15 -0300    

Partitioning tuple route code assumes that the partition chosen while  
descending the partition hierarchy is always the correct one.  This is  
true except when the partition is the default partition and another  
partition has been added concurrently: the partition constraint changes  
and we don't recheck it.  This can lead to tuples mistakenly being added  
to the default partition that should have been rejected.  
  
Fix by rechecking the default partition constraint while descending the  
hierarchy.  
  
An isolation test based on the reproduction steps described by Hao Wu  
(with tweaks for extra coverage) is included.  
  
Backpatch to 12, where this bug came in with 898e5e3290a7.  
  
Reported by: Hao Wu <[email protected]>  
Author: Amit Langote <[email protected]>  
Author: Álvaro Herrera <[email protected]>  
Discussion: https://postgr.es/m/CA+HiwqFqBmcSSap4sFnCBUEL_VfOMmEKaQ3gwUhyfa4c7J_-nA@mail.gmail.com  
Discussion: https://postgr.es/m/DM5PR0501MB3910E97A9EDFB4C775CF3D75A42F0@DM5PR0501MB3910.namprd05.prod.outlook.com  

commit   : b61d048e0d480f4311c62bf3026879c83ba9aaad    
  
author   : Jeff Davis <[email protected]>    
date     : Mon, 7 Sep 2020 13:31:59 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Mon, 7 Sep 2020 13:31:59 -0700    

Tomas Vondra observed that the IO behavior for HashAgg tends to be  
worse than for Sort. Penalize HashAgg IO costs accordingly.  
  
Also, account for the CPU effort of spilling the tuples and reading  
them back.  
  
Discussion: https://postgr.es/m/20200906212112.nzoy5ytrzjjodpfh@development  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13  

commit   : e02c99bff6fcf7a14292cf99b16e4810ea89a2de    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Sep 2020 14:52:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Sep 2020 14:52:33 -0400    

Some of the pre-existing comments were vague about whether they  
referred to all polymorphic types or only the old-style ones.  
  
Also be more consistent about using the "family 1" vs "family 2"  
terminology.  
  
Himanshu Upadhyaya and Tom Lane  
  
Discussion: https://postgr.es/m/CAPF61jBUg9XoMPNuLpoZ+h6UZ2VxKdNt3rQL1xw1GOBwjWzAXQ@mail.gmail.com  

commit   : 1e83138da14d61d572b0b58a9da6a2cf535ea198    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Sep 2020 09:08:58 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Sep 2020 09:08:58 +0200    

current through b7cf9e42ac2d4b153eb781195ebf369d4b8b566e  

commit   : b7cf9e42ac2d4b153eb781195ebf369d4b8b566e    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 7 Sep 2020 14:35:13 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 7 Sep 2020 14:35:13 +0900    

The previous version of the docs mentioned that files are rewritten,  
implying that a second copy of each file gets created, but each file is  
updated in-place.  
  
Author: Michael Banck  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : a82919afe26ad93a135aa5f017a3f31ec5a6547a    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 6 Sep 2020 19:28:32 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Sun, 6 Sep 2020 19:28:32 +0200    

It's better to use a relative path into the data directory, than to a  
hardcoded home directory of user 'josh'.  
  
Discussion: https://postgr.es/m/CABUevEyuf67Yu_r9gpDMs5MKifK7+-+pe=ZjKzya4JEn9kUk1w@mail.gmail.com  

commit   : f04203ab7e683bc3e961a40b002cf3c8d1d12100    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Sep 2020 12:55:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Sep 2020 12:55:13 -0400    

We reported the wrong types when complaining that an aggregate's  
moving-aggregate implementation is inconsistent with its regular  
implementation.  
  
This was wrong since the feature was introduced, so back-patch  
to all supported branches.  
  
Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1x808LH=LPhZp9mNSP0Xd1xDqEd+XeGcvEe48dfE6xV=A@mail.gmail.com  

commit   : e7f06ea60a3c07128176b294ce3fb0555edd15a5    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Sep 2020 11:50:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Sep 2020 11:50:40 -0400    

This is duplicative of an lstat that was just done by the calling  
function (traverse_datadir), besides which we weren't really doing  
anything with the results.  There's not much point in checking to  
see if someone removed the file since the previous lstat, since the  
FILE_ACTION_REMOVE code would have to deal with missing-file cases  
anyway.  Moreover, the "exists = false" assignment was a dead store;  
nothing was done with that value later.  
  
A syscall saved is a syscall earned, so back-patch to 9.5  
where this code was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8df601bd4067ecdf373ebe43bdf03159a12e2e9d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Sep 2020 21:01:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Sep 2020 21:01:59 -0400    

I happened to notice that the new test case I added in b55b4dad9  
falls over if one runs "make check" repeatedly; though not in branches  
after v10.  That's because it was assuming that tmp_check/pgpass  
wouldn't exist already.  However, it's only been since v11 that the  
Makefiles forcibly remove all of tmp_check/ before starting a TAP run.  
This fix to unlink the file is therefore strictly necessary only in  
v10 ... but it seems wisest to do it across the board, rather than  
let the test rely on external logic to get the conditions right.  

commit   : 9b81a30f924cf30e6bf3abb3366706440351e163    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Sep 2020 20:20:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Sep 2020 20:20:05 -0400    

Commit 3f60f690f only partially fixed the broken-status-tracking  
issue in LogicalRepApplyLoop: we need ping_sent to have the same  
lifetime as last_recv_timestamp.  The effects are much less serious  
than what that commit fixed, though.  AFAICS this would just lead to  
extra ping requests being sent, once per second until the sender  
responds.  Still, it's a bug, so backpatch to v10 as before.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4a4f3bf983b4abd908585a8d752eee0e47627034    
  
author   : Jeff Davis <[email protected]>    
date     : Fri, 4 Sep 2020 12:01:58 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Fri, 4 Sep 2020 12:01:58 -0700    

Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wz=NZPZc3-fkdmvu=w2itx0PiB-G6QpxHXZOjuvFAzPdZw@mail.gmail.com  
Backpatch-through: 13  

commit   : 72857482c135677703111855f33550c442108eaa    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 4 Sep 2020 13:53:09 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 4 Sep 2020 13:53:09 -0400    

If this data is not collected, pg_dump segfaults if asked for column  
inserts.  
  
Fix by Fabrízio de Royes Mello  
  
Backpatch to release 12 where the bug was introduced.  

commit   : 7574af1e1b94a4de7a6f63f3a7854a508ab7b0e0    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 4 Sep 2020 13:27:52 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 4 Sep 2020 13:27:52 -0400    

Reported-by: Kelly Min  
  
Discussion: https://postgr.es/m/CAPSbxatOiQO90LYpSC3+svAU9-sHgDfEP4oFhcEUt_X=DqFA9g@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : afec6ba0bae0258835b81fcc0eeed3ff9c455427    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Sep 2020 12:40:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Sep 2020 12:40:28 -0400    

The "DROP ACCESS METHOD gist2" test will require locking the index  
to be dropped and then its table; while most ordinary operations  
lock a table first then its index.  While no concurrent test scripts  
should be touching fast_emp4000, autovacuum might chance to be  
processing that table when the DROP runs, resulting in a deadlock  
failure.  This is pretty rare but we see it in the buildfarm from  
time to time.  
  
To fix, acquire a lock on fast_emp4000 before issuing the DROP.  
  
Since the point of the exercise is mostly to prevent buildfarm  
failures, back-patch to 9.6 where this test was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 17424e79d9794b00bdb6653185fc27ba423d8d81    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Sep 2020 16:52:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Sep 2020 16:52:09 -0400    

Because sigsetjmp() will restore the initial state with signals blocked,  
the code path in bgworker.c for reporting an error and exiting would  
execute that way.  Usually this is fairly harmless; but if a parallel  
worker had an error message exceeding the shared-memory communication  
buffer size (16K) it would lock up, because it would wait for a  
resume-sending signal from its parallel leader which it would never  
detect.  
  
To fix, just unblock signals at the appropriate point.  
  
This can be shown to fail back to 9.6.  The lack of parallel query  
infrastructure makes it difficult to provide a simple test case for  
9.5; but I'm pretty sure the issue exists in some form there as well,  
so apply the code change there too.  
  
Vignesh C, reviewed by Bharath Rupireddy, Robert Haas, and myself  
  
Discussion: https://postgr.es/m/CALDaNm1d1hHPZUg3xU4XjtWBOLCrA+-2cJcLpw-cePZ=GgDVfA@mail.gmail.com  

commit   : 214bc9038e39e209924514b77db4ee491f95509a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Sep 2020 11:45:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Sep 2020 11:45:26 -0400    

The majority of our audience is probably using a pre-packaged Postgres  
build rather than raw sources.  For them, much of runtime.sgml is not  
too relevant, and they should be reading the packager's docs instead.  
Add some notes pointing that way in appropriate places.  
  
Text by me; thanks to Daniel Gustafsson for review and discussion,  
and to Laurenz Albe for an earlier version.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 352b8cf59f400e69a80db12f920adf12a1b0607c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 1 Sep 2020 20:43:23 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 1 Sep 2020 20:43:23 -0400    

Introduced by 8b08f7d4820f; backpatch to 11.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2c7db50ce83ec375ad6ddeba498f07c78bc10e97    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 1 Sep 2020 17:00:10 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 1 Sep 2020 17:00:10 -0400    

Previous wording was "between".  
  
Reported-by: Pavel Luzanov  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 15dad5776578e884ee7857abb278a116c0c3e578    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 1 Sep 2020 13:40:43 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 1 Sep 2020 13:40:43 -0400    

We were already raising an error for DROP INDEX CONCURRENTLY on a  
partitioned table, albeit a different and confusing one:  
  ERROR:  DROP INDEX CONCURRENTLY must be first action in transaction  
  
Change that to throw a more comprehensible error:  
  ERROR:  cannot drop partitioned index \"%s\" concurrently  
  
Michael Paquier authored the test case for indexes on temporary  
partitioned tables.  
  
Backpatch to 11, where indexes on partitioned tables were added.  
  
Reported-by: Jan Mussler <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4178b749963cbf28d438b81e38dedcf885ccdda3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 1 Sep 2020 13:14:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 1 Sep 2020 13:14:44 -0400    

Historically there's been a hard-wired assumption here that no line of  
a .pgpass file could be as long as NAMEDATALEN*5 bytes.  That's a bit  
shaky to start off with, because (a) there's no reason to suppose that  
host names fit in NAMEDATALEN, and (b) this figure fails to allow for  
backslash escape characters.  However, it fails completely if someone  
wants to use a very long password, and we're now hearing reports of  
people wanting to use "security tokens" that can run up to several  
hundred bytes.  Another angle is that the file is specified to allow  
comment lines, but there's no reason to assume that long comment lines  
aren't possible.  
  
Rather than guessing at what might be a more suitable limit, let's  
replace the fixed-size buffer with an expansible PQExpBuffer.  That  
adds one malloc/free cycle to the typical use-case, but that's surely  
pretty cheap relative to the I/O this code has to do.  
  
Also, add TAP test cases to exercise this code, because there was no  
test coverage before.  
  
This reverts most of commit 2eb3bc588, as there's no longer a need for  
a warning message about overlength .pgpass lines.  (I kept the explicit  
check for comment lines, though.)  
  
In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not  
much point in explicit_bzero'ing the line buffer if we only do so in two  
of the three exit paths.  
  
Back-patch to all supported branches, except that the test case only  
goes back to v10 where src/test/authentication/ was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 73018f564af91b135e541b28133369c5e3de975d    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 18:48:38 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 18:48:38 -0400    

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

commit   : 1d3ff89ecfbbdd8bf56d4773d8f2749156eeb7c1    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 18:33:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 18:33:37 -0400    

This follows the American format,  
https://jakubmarian.com/comma-after-i-e-and-e-g/. There is no intention  
of requiring this format for future text, but making existing text  
consistent every few years makes sense.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 787ccf5a5fc92698e8cc8ebfb6fe1a0bf28981a4    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:51:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:51:31 -0400    

Reported-by: Antonin Houska  
  
Discussion: https://postgr.es/m/21643.1595353537@antos  
  
Backpatch-through: 9.5  

commit   : cef30b66fdf619a1b7aa0c2605719e64e980c6f2    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:36:23 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:36:23 -0400    

Also mention files included by postgresql.conf.  
  
Reported-by: Álvaro Herrera  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 97dc0d1d58916e2f063ce8a7eec6bd4d3bc29197    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 31 Aug 2020 17:04:40 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 31 Aug 2020 17:04:40 -0400    

Reported-by: Erwin Brandstetter <[email protected]>  
Discussion: https://postgr.es/m/CAGHENJ6Le7S3qJJx2TvWvTwRNS3N=BtoNeb7AF2rZvfNBMeQcg@mail.gmail.com  

commit   : bef7b917a76af659b4d6bce813702764e2c749db    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:05:53 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:05:53 -0400    

It is an int64.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 9bb4f98bb7745b7339fb7d102cdc36d66c002f67    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 16:59:59 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 16:59:59 -0400    

There is an file-fdw example that reads the server config file, so cross  
link them.  
  
Reported-by: Oleg Samoilov  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 8924ca865b18cac0b655170989bcd9507991d06f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 16:21:03 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 16:21:03 -0400    

Specifically, explain the v3_ca openssl specification.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 1bb41c6ad795e018e396eb3e216b2d21fadc865a    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 15:23:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 15:23:19 -0400    

For PG, "durable storage" has a clear meaning, while "stable storage"  
does not, so use the former.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 8006ac1c5117a56fcd138d663a3fe3709c8f9988    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 13:49:17 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 13:49:17 -0400    

It wasn't clear the non-integers are cast to integers for subscripting,  
rather than throwing an error.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 64fd65008c62ec011ba2d0673ca09849ae2b07c8    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 13:43:04 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 13:43:04 -0400    

Adds constraints and improves wording.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 785affc1d653bac43b7d4fad93f22e9e51aefcc1    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 13:20:04 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 13:20:04 -0400    

This was not clearly documented when procedures were added in PG 11.  
  
Reported-by: Robin Abbi  
  
Discussion: https://postgr.es/m/CAGmg_NX327KKVuJmbWZD=pGutYFxzZjX1rU+3ji8UuX=8ONn9Q@mail.gmail.com  
  
Backpatch-through: 11  

commit   : 3a1f6a2581e41ee2c724e8422675942d30a52ff7    
  
author   : Magnus Hagander <[email protected]>    
date     : Mon, 31 Aug 2020 13:03:54 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Mon, 31 Aug 2020 13:03:54 +0200    

It has always (since the first commit) worked with relative paths, so  
use the same wording as other parts of the documentation.  
  
Author: Bruce Momjian  
Discussion: https://postgr.es/m/CABUevExx-hm=cit+A9LeKBH39srvk8Y2tEZeEAj5mP8YfzNKUg@mail.gmail.com  

commit   : 845cfe012fd15300cd090b05fb4029a26b848a67    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 30 Aug 2020 14:37:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 30 Aug 2020 14:37:24 -0400    

Per discussion, we're planning to remove parser support for postfix  
operators in order to simplify the grammar.  So it behooves us to  
put out a deprecation notice at least one release before that.  
  
There is only one built-in postfix operator, ! for factorial.  
Label it deprecated in the docs and in pg_description, and adjust  
some examples that formerly relied on it.  (The sister prefix  
operator !! is also deprecated.  We don't really have to remove  
that one, but since we're suggesting that people use factorial()  
instead, it seems better to remove both operators.)  
  
Also state in the CREATE OPERATOR ref page that postfix operators  
in general are going away.  
  
Although this changes the initial contents of pg_description,  
I did not force a catversion bump; it doesn't seem essential.  
  
In v13, also back-patch 4c5cf5431, so that there's someplace for  
the <link>s to point to.  
  
Mark Dilger and John Naylor, with some adjustments by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1df14a5669428c0060ebdcebed8c1f807b659893    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Aug 2020 17:36:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Aug 2020 17:36:13 -0400    

collectMatchBitmap() needs to re-find the index tuple it was previously  
looking at, after transiently dropping lock on the index page it's on.  
The tuple should still exist and be at its prior position or somewhere  
to the right of that, since ginvacuum never removes tuples but  
concurrent insertions could add one.  However, there was a thinko in  
that logic, to the effect of expecting any inserted tuples to have the  
same index "attnum" as what we'd been scanning.  Since there's no  
physical separation of tuples with different attnums, it's not terribly  
hard to devise scenarios where this fails, leading to transient "lost  
saved point in index" errors.  (While I've duplicated this with manual  
testing, it seems impossible to make a reproducible test case with our  
available testing technology.)  
  
Fix by just continuing the scan when the attnum doesn't match.  
  
While here, improve the error message used if we do fail, so that it  
matches the wording used in btree for a similar case.  
  
collectMatchBitmap()'s posting-tree code path was previously not  
exercised at all by our regression tests.  While I can't make  
a regression test that exhibits the bug, I can at least improve  
the code coverage here, so do that.  The test case I made for this  
is an extension of one added by 4b754d6c1, so it only works in  
HEAD and v13; didn't seem worth trying hard to back-patch it.  
  
Per bug #16595 from Jesse Kinkead.  This has been broken since  
multicolumn capability was added to GIN (commit 27cb66fdf),  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 32c42b815ad2377c0bddc4f55b7bf32a5204a87d    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 25 Aug 2020 09:53:12 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 25 Aug 2020 09:53:12 -0400    

They are not "requested" by the server.  
  
Reported-by: Kyotaro Horiguchi  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 62340f8eca4c9d4e49097eaf0a341aca8450b56b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 25 Aug 2020 07:29:05 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 25 Aug 2020 07:29:05 +0200    

This fixes some instances that were missed in earlier processings and  
that now look a bit strange because they are inconsistent with nearby  
titles.  

commit   : b4ef5ac0b7bfa734ad908bb5577cf4ee65ce2974    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 24 Aug 2020 08:22:54 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 24 Aug 2020 08:22:54 +0530    

We were displaying the wrong phase information for 'info' message in the  
index clean up phase because we were switching to the previous phase a bit  
early. We were also not displaying context information for heap phase  
unless the block number is valid which is fine for error cases but for  
messages at 'info' or lower error level it appears to be inconsistent with  
index phase information.  
  
Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/CA+fd4k4HcbhPnCs7paRTw1K-AHin8y4xKomB9Ru0ATw0UeTy2w@mail.gmail.com  

commit   : de627adaad3a161b3ae0cafeb76c20519845799b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 22 Aug 2020 14:46:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 22 Aug 2020 14:46:40 -0400    

The trouble with doing this is that an apparently-constant subquery  
output column isn't really constant if it is a grouping column that  
appears in only some of the grouping sets.  A qual using such a  
column would be subject to incorrect const-folding after push-down,  
as seen in bug #16585 from Paul Sivash.  
  
To fix, just disable qual pushdown altogether if the sub-query has  
nonempty groupingSets.  While we could imagine far less restrictive  
solutions, there is not much point in working harder right now,  
because subquery_planner() won't move HAVING clauses to WHERE within  
such a subquery.  If the qual stays in HAVING it's not going to be  
a lot more useful than if we'd kept it at the outer level.  
  
Having said that, this restriction could be removed if we used a  
parsetree representation that distinguished such outputs from actual  
constants, which is something I hope to do in future.  Hence, make  
the patch a minimal addition rather than integrating it more tightly  
(e.g. by renumbering the existing items in subquery_is_pushdown_safe's  
comment).  
  
Back-patch to 9.5 where grouping sets were introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 47de6ac11b53cf24393a2ef048f9e8921163da0a    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 22 Aug 2020 12:34:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 22 Aug 2020 12:34:17 -0400    

Commit 1281a5c90 rearranged the logic in this area rather drastically,  
and it broke the case of adding a foreign key constraint in the same  
ALTER that adds the pkey or unique constraint it depends on.  While  
self-referential fkeys are surely a pretty niche case, this used to  
work so we shouldn't break it.  
  
To fix, reorganize the scheduling rules in ATParseTransformCmd so  
that a transformed AT_AddConstraint subcommand will be delayed into  
a later pass in all cases, not only when it's been spit out as a  
side-effect of parsing some other command type.  
  
Also tweak the logic so that we won't run ATParseTransformCmd twice  
while doing this.  It seems to work even without that, but it's  
surely wasting cycles to do so.  
  
Per bug #16589 from Jeremy Evans.  Back-patch to v13 where the new  
code was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 610394c7b876bc841464aad38f8abed09d63924e    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 22 Aug 2020 22:26:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 22 Aug 2020 22:26:18 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : 3669792934593a7b682c5b32dea41c9e3b48e6cc    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 21 Aug 2020 20:23:09 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 21 Aug 2020 20:23:09 -0400    

This is a redesign of the intro to the managing databases chapter.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: David G. Johnston  
  
Backpatch-through: 9.5  

commit   : 35f2d22ba909735448606fefc126b73e4fb3c627    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 21 Aug 2020 18:29:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 21 Aug 2020 18:29:37 -0400    

Reported-by: Jürgen Purtz  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Jürgen Purtz  
  
Backpatch-through: 11  

commit   : 894f5dea76e1a59fa2f3e1905c6a44f254d9d08b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 21 Aug 2020 15:00:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 21 Aug 2020 15:00:42 -0400    

If a CREATE TABLE command uses both LIKE and traditional inheritance,  
Vars in CHECK constraints and expression indexes that are absorbed  
from a LIKE parent table tended to get mis-numbered, resulting in  
wrong answers and/or bizarre error messages (though probably not any  
actual crashes, thanks to validation occurring in the executor).  
  
In v12 and up, the same could happen to Vars in GENERATED expressions,  
even in cases with no LIKE clause but multiple traditional-inheritance  
parents.  
  
The cause of the problem for LIKE is that parse_utilcmd.c supposed  
it could renumber such Vars correctly during transformCreateStmt(),  
which it cannot since we have not yet accounted for columns added via  
inheritance.  Fix that by postponing processing of LIKE INCLUDING  
CONSTRAINTS, DEFAULTS, GENERATED, INDEXES till after we've performed  
DefineRelation().  
  
The error with GENERATED and multiple inheritance is a simple oversight  
in MergeAttributes(); it knows it has to renumber Vars in inherited  
CHECK constraints, but forgot to apply the same processing to inherited  
GENERATED expressions (a/k/a defaults).  
  
Per bug #16272 from Tom Gottfried.  The non-GENERATED variants of the  
issue are ancient, presumably dating right back to the addition of  
CREATE TABLE LIKE; hence back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bc2ebf3acfd287247cd9ee286c44e969af1c81de    
  
author   : Fujii Masao <[email protected]>    
date     : Sat, 22 Aug 2020 01:22:55 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Sat, 22 Aug 2020 01:22:55 +0900    

Commit 9d701e624f caused the regression test for EXPLAIN to fail on  
the buildfarm member prion. This happened because of instability of  
test output, i.e., in text format, whether "Planning:" line is output  
varies depending on the system state.  
  
This commit updated the regression test so that it ignores that  
"Planning:" line to produce more stable test output and get rid of  
the test failure.  
  
Back-patch to v13.  
  
Author: Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : 674899ae02c375b03411c0676e7cfb4bafeebac9    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 21 Aug 2020 20:48:59 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 21 Aug 2020 20:48:59 +0900    

Commit ce77abe63c allowed EXPLAIN (BUFFERS) to report the information  
on buffer usage during planning phase. However three issues were  
reported regarding this feature.  
  
(1) Previously, EXPLAIN option BUFFERS required ANALYZE. So the query  
    had to be actually executed by specifying ANALYZE even when we  
    want to see only the planner's buffer usage. This was inconvenient  
    especially when the query was write one like DELETE.  
  
(2) EXPLAIN included the planner's buffer usage in summary  
    information. So SUMMARY option had to be enabled to report that.  
    Also this format was confusing.  
  
(3) The output structure for planning information was not consistent  
    between TEXT format and the others. For example, "Planning" tag  
    was output in JSON format, but not in TEXT format.  
  
For (1), this commit allows us to perform EXPLAIN (BUFFERS) without  
ANALYZE to report the planner's buffer usage.  
  
For (2), this commit changed EXPLAIN output so that the planner's  
buffer usage is reported before summary information.  
  
For (3), this commit made the output structure for planning  
information more consistent between the formats.  
  
Back-patch to v13 where the planner's buffer usage was allowed to  
be reported in EXPLAIN.  
  
Reported-by: Pierre Giraud, David Rowley  
Author: Fujii Masao  
Reviewed-by: David Rowley, Julien Rouhaud, Pierre Giraud  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0d7437de73b68b0105d00ff4fed3e7894b02f6d5    
  
author   : David Rowley <[email protected]>    
date     : Fri, 21 Aug 2020 09:34:47 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 21 Aug 2020 09:34:47 +1200    

Reviewed-by: Abhijit Menon-Sen  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CAApHDvobgmCs6CohqhKTUf7D8vffoZXQTCBTERo9gbOeZmvLTw%40mail.gmail.com  
Backpatch-through: 11, where JIT was added  

commit   : 2a9f042c47053e3ce73f634cce9622fa0151f63c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 20 Aug 2020 13:49:04 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 20 Aug 2020 13:49:04 -0400    

When the leftover invalid index is "ccold", there's no need to re-run  
the command.  Reword the instructions to make that explicit.  
  
Backpatch to 12, where REINDEX CONCURRENTLY appeared.  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Reviewed-by: Julien Rouhaud <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 69ffc2f838990fb2c802087091ce7c2ff1b735eb    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Aug 2020 14:07:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Aug 2020 14:07:49 -0400    

Commit a477bfc1d fixed eval_const_expressions() to ensure that it  
didn't generate unnecessary RelabelType nodes, but I failed to notice  
that some other places in the planner had the same issue.  Really  
noplace in the planner should be using plain makeRelabelType(), for  
fear of generating expressions that should be equal() to semantically  
equivalent trees, but aren't.  
  
An example is that because canonicalize_ec_expression() failed  
to be careful about this, we could end up with an equivalence class  
containing both a plain Const, and a Const-with-RelabelType  
representing exactly the same value.  So far as I can tell this led to  
no visible misbehavior, but we did waste a bunch of cycles generating  
and evaluating "Const = Const-with-RelabelType" to prove such entries  
are redundant.  
  
Hence, move the support function added by a477bfc1d to where it can  
be more generally useful, and use it in the places where planner code  
previously used makeRelabelType.  
  
Back-patch to v12, like the previous patch.  While I have no concrete  
evidence of any real misbehavior here, it's certainly possible that  
I overlooked a case where equivalent expressions that aren't equal()  
could cause a user-visible problem.  In any case carrying extra  
RelabelType nodes through planning to execution isn't very desirable.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bff41b2b8938f5e3e7d536da6d7a14a1648b4dec    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 18 Aug 2020 13:13:09 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 18 Aug 2020 13:13:09 +0300    

As Tom Lane pointed out, it could defeat the compiler's printf() format  
string verification.  
  
Backpatch to v12, like that patch that introduced it.  
  
Discussion: https://www.postgresql.org/message-id/1069283.1597672779%40sss.pgh.pa.us  

commit   : b83f1bcca0bb460413da4ce856b030502b4f71c5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 17 Aug 2020 16:20:06 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 17 Aug 2020 16:20:06 -0400    

This should improve stability in the tests.  
  
Per buildfarm member hyrax (CLOBBER_CACHE_ALWAYS) via Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8216a1d3ed27364c7b2a9e6db76f15202a6070c1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 17 Aug 2020 15:40:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 17 Aug 2020 15:40:07 -0400    

The description of what select_common_type() does was not terribly  
accurate.  Improve it.  
  
David Johnston and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5ca1798f32b7fe730fef7ccd8d69e785a50134b8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 17 Aug 2020 09:27:29 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 17 Aug 2020 09:27:29 +0300    

A number of client programs have a "--progress" option that when printing  
to a TTY, updates the current line by printing a '\r' and overwriting it.  
After the last line, '\n' needs to be printed to move the cursor to the  
next line. pg_basebackup and pgbench got this right, but pg_rewind and  
pg_checksums were slightly wrong. pg_rewind printed the newline to stdout  
instead of stderr, and pg_checksums printed the newline even when not  
printing to a TTY. Fix them, and also add a 'finished' argument to  
pg_basebackup's progress_report() function, to keep it consistent with  
the other programs.  
  
Backpatch to v12. pg_rewind's newline was broken with the logging changes  
in commit cc8d415117 in v12, and pg_checksums was introduced in v12.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : 3424c6bef0b897f9c6800f55d34a162a07319795    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Aug 2020 10:24:24 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Aug 2020 10:24:24 +0900    

Since 806a2ae, the work of the bgwriter is split the checkpointer, but a  
portion of the documentation did not get the message.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CA+fd4k6jXxjAtjMVC=wG3=QGpauZBtcgN3Jhw+oV7zXGKVLKzQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 277e49eca73a719695d0b74360b54124e76c6833    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 15 Aug 2020 15:43:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 15 Aug 2020 15:43:34 -0400    

Put the -r option in the right section (it certainly isn't an  
option controlling "the location and format of the output").  
  
Clarify the behavior of the tablespace and waldir options  
(that part per gripe from [email protected]).  
  
Make a large number of small copy-editing fixes in text that  
visibly wasn't written by native speakers, and try to avoid  
grammatical inconsistencies between the descriptions of  
the different options.  
  
Back-patch to v13, since HEAD hasn't meaningfully diverged yet.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 592a589a04bd456410b853d86bd05faa9432cbbb    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 15 Aug 2020 10:15:53 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 15 Aug 2020 10:15:53 -0700    

The SimpleLruTruncate() header comment states the new coding rule.  To  
achieve this, add locktype "frozenid" and two LWLocks.  This closes a  
rare opportunity for data loss, which manifested as "apparent  
wraparound" or "could not access status of transaction" errors.  Data  
loss is more likely in pg_multixact, due to released branches' thin  
margin between multiStopLimit and multiWrapLimit.  If a user's physical  
replication primary logged ":  apparent wraparound" messages, the user  
should rebuild standbys of that primary regardless of symptoms.  At less  
risk is a cluster having emitted "not accepting commands" errors or  
"must be vacuumed" warnings at some point.  One can test a cluster for  
this data loss by running VACUUM FREEZE in every database.  Back-patch  
to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b538e83f17e36fd0fe0686815da0ff5866ce8a64    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Aug 2020 22:14:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Aug 2020 22:14:03 -0400    

nodeSubplan.c expects that the testexpr for a hashable ANY SubPlan  
has the form of one or more OpExprs whose LHS is an expression of the  
outer query's, while the RHS is an expression over Params representing  
output columns of the subquery.  However, the planner only went as far  
as verifying that the clauses were all binary OpExprs.  This works  
99.99% of the time, because the clauses have the right shape when  
emitted by the parser --- but it's possible for function inlining to  
break that, as reported by PegoraroF10.  To fix, teach the planner  
to check that the LHS and RHS contain the right things, or more  
accurately don't contain the wrong things.  Given that this has been  
broken for years without anyone noticing, it seems sufficient to just  
give up hashing when it happens, rather than go to the trouble of  
commuting the clauses back again (which wouldn't necessarily work  
anyway).  
  
While poking at that, I also noticed that nodeSubplan.c had a baked-in  
assumption that the number of hash clauses is identical to the number  
of subquery output columns.  Again, that's fine as far as parser output  
goes, but it's not hard to break it via function inlining.  There seems  
little reason for that assumption though --- AFAICS, the only thing  
it's buying us is not having to store the number of hash clauses  
explicitly.  Adding code to the planner to reject such cases would take  
more code than getting nodeSubplan.c to cope, so I fixed it that way.  
  
This has been broken for as long as we've had hashable SubPlans,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b7cc21c57d738b41f6116f46d566b9949a433747    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 14 Aug 2020 17:33:31 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 14 Aug 2020 17:33:31 -0400    

Parallel-restoring a foreign key that references a partitioned table  
with several levels of partitions can fail:  
  
pg_restore: while PROCESSING TOC:  
pg_restore: from TOC entry 6684; 2606 29166 FK CONSTRAINT fk fk_a_fkey postgres  
pg_restore: error: could not execute query: ERROR:  there is no unique constraint matching given keys for referenced table "pk"  
Command was: ALTER TABLE fkpart3.fk  
    ADD CONSTRAINT fk_a_fkey FOREIGN KEY (a) REFERENCES fkpart3.pk(a);  
  
This happens in parallel restore mode because some index partitions  
aren't yet attached to the topmost partitioned index that the FK uses,  
and so the index is still invalid.  The current code marks the FK as  
dependent on the first level of index-attach dump objects; the bug is  
fixed by recursively marking the FK on their children.  
  
Backpatch to 12, where FKs to partitioned tables were introduced.  
  
Reported-by: Tom Lane <[email protected]>  
Author: Álvaro Herrera <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12-master  

commit   : 1c6066fbdb70a92b10b8616652d25c4434cd222e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Aug 2020 13:26:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Aug 2020 13:26:57 -0400    

Up to now, upon receipt of a SIGTERM ("smart shutdown" command), the  
postmaster has immediately killed all "optional" background processes,  
and subsequently refused to launch new ones while it's waiting for  
foreground client processes to exit.  No doubt this seemed like an OK  
policy at some point; but it's a pretty bad one now, because it makes  
for a seriously degraded environment for the remaining clients:  
  
* Parallel queries are killed, and new ones fail to launch. (And our  
parallel-query infrastructure utterly fails to deal with the case  
in a reasonable way --- it just hangs waiting for workers that are  
not going to arrive.  There is more work needed in that area IMO.)  
  
* Autovacuum ceases to function.  We can tolerate that for awhile,  
but if bulk-update queries continue to run in the surviving client  
sessions, there's eventually going to be a mess.  In the worst case  
the system could reach a forced shutdown to prevent XID wraparound.  
  
* The bgwriter and walwriter are also stopped immediately, likely  
resulting in performance degradation.  
  
Hence, let's rearrange things so that the only immediate change in  
behavior is refusing to let in new normal connections.  Once the last  
normal connection is gone, shut everything down as though we'd received  
a "fast" shutdown.  To implement this, remove the PM_WAIT_BACKUP and  
PM_WAIT_READONLY states, instead staying in PM_RUN or PM_HOT_STANDBY  
while normal connections remain.  A subsidiary state variable tracks  
whether or not we're letting in new connections in those states.  
  
This also allows having just one copy of the logic for killing child  
processes in smart and fast shutdown modes.  I moved that logic into  
PostmasterStateMachine() by inventing a new state PM_STOP_BACKENDS.  
  
Back-patch to 9.6 where parallel query was added.  In principle  
this'd be a good idea in 9.5 as well, but the risk/reward ratio  
is not as good there, since lack of autovacuum is not a problem  
during typical uses of smart shutdown.  
  
Per report from Bharath Rupireddy.  
  
Patch by me, reviewed by Thomas Munro  
  
Discussion: https://postgr.es/m/CALj2ACXAZ5vKxT9P7P89D87i3MDO9bfS+_bjMHgnWJs8uwUOOw@mail.gmail.com  

commit   : cabec1dbdf405211c1a4d30f52a91e8de2cf7226    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 14 Aug 2020 10:40:50 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 14 Aug 2020 10:40:50 +0300    

commit   : 124772e3cac6d3bf6c1f6d32518209c6a3fdd3eb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Aug 2020 20:00:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Aug 2020 20:00:39 -0400    

Make these examples self-contained by providing declarations of the  
user-defined row types they rely on.  There wasn't room to do this  
in the old doc format, but now there is, and I think it makes the  
examples a good bit less confusing.  

commit   : 2f29fd4cb2522dfd64888892f0442a0ead8c6dd0    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 13 Aug 2020 17:33:49 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 13 Aug 2020 17:33:49 -0400    

When a table is scanned by heapam_index_build_range_scan (née  
IndexBuildHeapScan) and the table lock being held allows concurrent data  
changes, it is possible for new HOT chains to sprout in a page that were  
unknown when the scan of a page happened.  This leads to an error such  
as  
  ERROR:  failed to find parent tuple for heap-only tuple at (X,Y) in table "tbl"  
because the root tuple was not present when we first obtained the list  
of the page's root tuples.  This can be fixed by re-obtaining the list  
of root tuples, if we see that a heap-only tuple appears to point to a  
non-existing root.  
  
This was reported by Anastasia as occurring for BRIN summarization  
(which exists since 9.5), but I think it could theoretically also happen  
with CREATE INDEX CONCURRENTLY (much older) or REINDEX CONCURRENTLY  
(very recent).  It seems a happy coincidence that BRIN forces us to  
backpatch this all the way to 9.5.  
  
Reported-by: Anastasia Lubennikova <[email protected]>  
Diagnosed-by: Anastasia Lubennikova <[email protected]>  
Co-authored-by: Anastasia Lubennikova <[email protected]>  
Co-authored-by: Álvaro Herrera <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.5 - master  

commit   : 8782ea2f36a2468e08c227c8d7907a5a1a9f5e32    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 12 Aug 2020 15:33:36 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 12 Aug 2020 15:33:36 -0400    

If a page range is desummarized at just the right time concurrently with  
an index walk, BRIN would raise an error indicating index corruption.  
This is scary and unhelpful; silently returning that the page range is  
not summarized is sufficient reaction.  
  
This bug was introduced by commit 975ad4e602ff as additional protection  
against a bug whose actual fix was elsewhere.  Backpatch equally.  
  
Reported-By: Anastasia Lubennikova <[email protected]>  
Diagnosed-By: Alexander Lakhin <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.5 - master  

commit   : 1754a71986e806330ac3ab9e8125c902286b829d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Aug 2020 17:12:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Aug 2020 17:12:51 -0400    

commit   : b601f24c875d79e747eb8b50a4b1555ac22cf8f9    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

Back-patch to v10, which introduced logical replication.  
  
Security: CVE-2020-14349  

commit   : 412c5c4010c0bec294f60a10cd56929680d3f95b    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

This is like CVE-2018-1058 commit  
582edc369cdbd348d68441fc50fa26a84afd0c1a.  Today, a malicious user of a  
publisher or subscriber database can invoke arbitrary SQL functions  
under an identity running replication, often a superuser.  This fix may  
cause "does not exist" or "no schema has been selected to create in"  
errors in a replication process.  After upgrading, consider watching  
server logs for these errors.  Objects accruing schema qualification in  
the wake of the earlier commit are unlikely to need further correction.  
Back-patch to v10, which introduced logical replication.  
  
Security: CVE-2020-14349  

commit   : 41dae35532d40041297ee728eac1f4584af05570    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 10 Aug 2020 09:22:54 -0700    

Any libpq client can use the header.  Clients include backend components  
postgres_fdw, dblink, and logical replication apply worker.  Back-patch  
to v10, because another fix needs this.  In released branches, just copy  
the header and keep the original.  

commit   : 98ca64899cec6a4bf3099481aff43b8777319c41    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Aug 2020 10:44:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Aug 2020 10:44:42 -0400    

Hostile objects located within the installation-time search_path could  
capture references in an extension's installation or upgrade script.  
If the extension is being installed with superuser privileges, this  
opens the door to privilege escalation.  While such hazards have existed  
all along, their urgency increases with the v13 "trusted extensions"  
feature, because that lets a non-superuser control the installation path  
for a superuser-privileged script.  Therefore, make a number of changes  
to make such situations more secure:  
  
* Tweak the construction of the installation-time search_path to ensure  
that references to objects in pg_catalog can't be subverted; and  
explicitly add pg_temp to the end of the path to prevent attacks using  
temporary objects.  
  
* Disable check_function_bodies within installation/upgrade scripts,  
so that any security gaps in SQL-language or PL-language function bodies  
cannot create a risk of unwanted installation-time code execution.  
  
* Adjust lookup of type input/receive functions and join estimator  
functions to complain if there are multiple candidate functions.  This  
prevents capture of references to functions whose signature is not the  
first one checked; and it's arguably more user-friendly anyway.  
  
* Modify various contrib upgrade scripts to ensure that catalog  
modification queries are executed with secure search paths.  (These  
are in-place modifications with no extension version changes, since  
it is the update process itself that is at issue, not the end result.)  
  
Extensions that depend on other extensions cannot be made fully secure  
by these methods alone; therefore, revert the "trusted" marking that  
commit eb67623c9 applied to earthdistance and hstore_plperl, pending  
some better solution to that set of issues.  
  
Also add documentation around these issues, to help extension authors  
write secure installation scripts.  
  
Patch by me, following an observation by Andres Freund; thanks  
to Noah Misch for review.  
  
Security: CVE-2020-14350  

commit   : 378bd1ed6e4314a8b8b32c555f73524c2283b016    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 10 Aug 2020 15:15:50 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 10 Aug 2020 15:15:50 +0200    

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

commit   : bc635dd16388015c72e47a4b90c4c3ceecebb0cd    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Aug 2020 16:59:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Aug 2020 16:59:53 -0400    

commit   : dd63a71ebe3937e0ec965248513fb71e45ee0ec8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Aug 2020 12:39:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Aug 2020 12:39:08 -0400    

Coverity pointed out, not unreasonably, that we checked fseeko's  
result at every other call site but these.  Failure to seek in the  
temp file (note this is NOT pg_dump's output file) seems quite  
unlikely, and even if it did happen the file length cross-check  
further down would probably detect the problem.  Still, that's a  
poor excuse for not checking the result of a system call.  

commit   : 900429d0c03668ac474770c01ba5911b15025dfb    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 8 Aug 2020 12:31:55 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 8 Aug 2020 12:31:55 -0400    

Ashutosh Bapat noticed that when logical walsender needs to wait for  
WAL, and it realizes that it must send a keepalive message to  
walreceiver to update the sent-LSN, which *does not* request a reply  
from walreceiver, it wrongly sets the flag that it's going to wait for  
that reply.  That means that any future would-be sender of feedback  
messages ends up not sending a feedback message, because they all  
believe that a reply is expected.  
  
With built-in logical replication there's not much harm in this, because  
WalReceiverMain will send a ping-back every wal_receiver_timeout/2  
anyway; but with other logical replication systems (e.g. pglogical) it  
can cause significant pain.  
  
This problem was introduced in commit 41d5f8ad734, where the  
request-reply flag was changed from true to false to WalSndKeepalive,  
without at the same time removing the line that sets  
waiting_for_ping_response.  
  
Just removing that line would be a sufficient fix, but it seems better  
to shift the responsibility of setting the flag to WalSndKeepalive  
itself instead of requiring caller to do it; this is clearly less  
error-prone.  
  
Author: Álvaro Herrera <[email protected]>  
Reported-by: Ashutosh Bapat <[email protected]>  
Backpatch: 9.5 and up  
Discussion: https://postgr.es/m/[email protected]  

commit   : f1c3a41bd695c4ba97d50ffa4b2ab2a72068bd3b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 7 Aug 2020 20:38:55 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 7 Aug 2020 20:38:55 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 13 development.  
  
current through 79a3ab1e98d6b5952e29ad91e07c0e9fc777cc0b  

commit   : 79a3ab1e98d6b5952e29ad91e07c0e9fc777cc0b    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 7 Aug 2020 14:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 7 Aug 2020 14:45:01 +0900    

Commit 13838740f fixed some issues with step generation in partition  
pruning, but there was yet another one: get_steps_using_prefix() assumes  
that clauses in the passed-in prefix list are sorted in ascending order  
of their partition key numbers, but the caller failed to ensure this for  
range partitioning, which led to an assertion failure in debug builds.  
Adjust the caller function to arrange the clauses in the prefix list in  
the required order for range partitioning.  
  
Back-patch to v11, like the previous commit.  
  
Patch by me, reviewed by Amit Langote.  
  
Discussion: https://postgr.es/m/CAPmGK16jkXiFG0YqMbU66wte-oJTfW6D1HaNvQf%3D%2B5o9%3Dm55wQ%40mail.gmail.com  

commit   : be9bdab983cfc44db1d7f8c06df7d7a7cbcb8128    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 6 Aug 2020 15:25:47 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 6 Aug 2020 15:25:47 -0700    

This will be helpful if it ever proves necessary to revoke an opclass's  
support for deduplication.  
  
Backpatch: 13-, where nbtree deduplication was introduced.  

commit   : 05dfb813245bf3b896b5317570a24a3d66e97a41    
  
author   : David Rowley <[email protected]>    
date     : Fri, 7 Aug 2020 10:22:08 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 7 Aug 2020 10:22:08 +1200    

9bdb300de modified the EXPLAIN output for Hash Aggregate to show details  
from parallel workers. However, it neglected to consider that a given  
parallel worker may not have assisted with the given Hash Aggregate. This  
can occur when workers fail to start or during Parallel Append with  
enable_partitionwise_join enabled when only a single worker is working on  
a non-parallel aware sub-plan. It could also happen if a worker simply  
wasn't fast enough to get any work done before other processes went and  
finished all the work.  
  
The bogus output came from the fact that ExplainOpenWorker() skipped  
showing any details for non-initialized workers but show_hashagg_info()  
did show details from the worker.  This meant that the worker properties  
that were shown were not properly attributed to the worker that they  
belong to.  
  
In passing, we also now don't show Hash Aggregate properties for the  
leader process when it did not contribute any work to the Hash Aggregate.  
This can occur either during Parallel Append when only a parallel worker  
worked on a given sub plan or with parallel_leader_participation set to  
off.  This aims to make the behavior of Hash Aggregate's EXPLAIN output  
more similar to Sort's.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20200805012105.GZ28072%40telsasoft.com  
Backpatch-through: 13, where the original breakage was introduced  

commit   : d0aa57d0e9441b9fab5de5dbed0cb0afd4fa756d    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 5 Aug 2020 17:12:10 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 5 Aug 2020 17:12:10 -0400    

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

commit   : c43a36fa8fff380072d9fc745b1e27baf1a4d3f8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 5 Aug 2020 15:38:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 5 Aug 2020 15:38:55 -0400    

Since we no longer require AccessExclusiveLock to add a partition,  
the executor may see that a partitioned table has more partitions  
than the planner saw.  ExecCreatePartitionPruneState's code for  
matching up the partition lists in such cases was faulty, and would  
misbehave if the planner had successfully pruned any partitions from  
the query.  (Thus, trouble would occur only if a partition addition  
happens concurrently with a query that uses both static and dynamic  
partition pruning.)  This led to an Assert failure in debug builds,  
and probably to crashes or query misbehavior in production builds.  
  
To repair the bug, just explicitly skip zeroes in the plan's  
relid_map[] list.  I also made some cosmetic changes to make the code  
more readable (IMO anyway).  Also, convert the cross-checking Assert  
to a regular test-and-elog, since it's now apparent that this logic  
is more fragile than one would like.  
  
Currently, there's no way to repeatably exercise this code, except  
with manual use of a debugger to stop the backend between planning  
and execution.  Hence, no test case in this patch.  We oughta do  
something about that testability gap, but that's for another day.  
  
Amit Langote and Tom Lane, per report from Justin Pryzby.  Oversight  
in commit 898e5e329; backpatch to v12 where that appeared.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 565f1690264b5773c23b86303645cf11a0893cff    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 4 Aug 2020 15:20:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 4 Aug 2020 15:20:31 -0400    

A couple of test cases had connect_timeout=14, a value that seems  
to have been plucked from a hat.  While it's more than sufficient  
for normal cases, slow/overloaded buildfarm machines can get a timeout  
failure here, as per recent report from "sungazer".  Increase to 180  
seconds, which is in line with our typical timeouts elsewhere in  
the regression tests.  
  
Back-patch to 9.6; the code looks different in 9.5, and this doesn't  
seem to be quite worth the effort to adapt to that.  
  
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2020-08-04%2007%3A12%3A22  

commit   : 1a01595cc2ffb20ef9f2bc1a92d39728b65e3797    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 4 Aug 2020 14:36:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 4 Aug 2020 14:36:09 +0900    

The test would fail in an environment including a certificate file in  
~/.postgresql/.  bdd6e9b fixed a similar failure, and d6e612f introduced  
the same problem again with a new test.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : e7a6cd5dcf24c6d4b04d036a4837c7af154c4b49    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 3 Aug 2020 17:01:42 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 3 Aug 2020 17:01:42 -0400    

Document that hash_mem_multiplier can get query behavior closer to the  
pre-PG 13 behavior of allowing hashing to use more memory.  
  
Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-Wzn3kwQm_pe6g2=ki+P7+ZRqH5GvFGn6SWfv_j7UUgcLdQ@mail.gmail.com  
  
Backpatch-through: 13 only  

commit   : 72ca61101ad4076941f175b50cc86e6372023034    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Aug 2020 14:02:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Aug 2020 14:02:35 -0400    

A moment's examination of these queries is sufficient to see that  
they do not produce duplicate rows, unless perhaps there's  
catalog corruption.  Using DISTINCT anyway is inefficient and  
confusing; moreover it sets a poor example for anyone who  
refers to psql -E output to see how to query the catalogs.  

commit   : 6d78f219e8afc57b6ca3765eb2dfa1b8fe095ddc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Aug 2020 13:11:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Aug 2020 13:11:16 -0400    

We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but  
that commit forgot to fix the documentation about timetz.  
  
Per bug #16571 from osdba.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 44cd434ec4a70d2dfbc460492fc0574d08440250    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Aug 2020 09:46:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Aug 2020 09:46:12 -0400    

This ought to work much like C's "#elif defined(name)"; but the code  
implemented it in a way equivalent to endif followed by ifdef, so that  
it didn't matter whether any previous branch of the IF construct had  
succeeded.  Fix that; add some test cases covering elif and nested IFs;  
and improve the documentation, which also seemed a bit confused.  
  
AFAICS the code has been like this since the feature was added in 1999  
(commit b57b0e044).  So while it's surely wrong, there might be code  
out there relying on the current behavior.  Hence, don't back-patch  
into stable branches.  It seems all right to fix it in v13 though.  
  
Per report from Ashutosh Sharma.  Reviewed by Ashutosh Sharma and  
Michael Meskes.  
  
Discussion: https://postgr.es/m/CAE9k0P=dQk9X0cU2tN49S7a9tv733-e1pVdpB1P-pWJ5PdTktg@mail.gmail.com  

commit   : f5293fb09e7346bb663f2f5c63081e8aabe61a8e    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 3 Aug 2020 12:39:15 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Mon, 3 Aug 2020 12:39:15 +1200    

Instead of writing a query to psql's stdin, use -c.  This avoids a  
failure where psql exits before we write, seen a few times on the build  
farm.  Thanks to Tom Lane for the suggestion.  
  
Back-patch to 11, where the LDAP tests arrived.  
  
Reviewed-by: Noah Misch <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLFmW%2BHQYPeKiwSp5sdFFHtFViCpw4Mh6yAgEx74r5-Cw%40mail.gmail.com  

commit   : 719304a3043d9f60247df371f55236058a7f3caa    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 2 Aug 2020 17:00:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 2 Aug 2020 17:00:26 -0400    

The type-name pattern in \dAc and \dAf was matched only to the actual  
pg_type.typname string, which is fairly user-unfriendly in cases where  
that is not what's shown to the user by format_type (compare "_int4"  
and "integer[]").  Make this code match what \dT does, i.e. match the  
pattern against either typname or format_type() output.  Also fix its  
broken handling of schema-name restrictions.  (IOW, make these  
processSQLNamePattern calls match \dT's.)  While here, adjust  
whitespace to make the query a little prettier in -E output, too.  
  
Also improve some inaccuracies and shaky grammar in the related  
documentation.  
  
Noted while working on a patch for intarray's opclasses; I wondered  
why I couldn't get a match to "integer*" for the input type name.  

commit   : 22c105595fc736ae94ce3b806da16b0bd8e94fb8    
  
author   : David Rowley <[email protected]>    
date     : Sun, 2 Aug 2020 14:23:57 +1200    
  
committer: David Rowley <[email protected]>    
date     : Sun, 2 Aug 2020 14:23:57 +1200    

Windows 64bit has 4-byte long values which is not suitable for tracking  
disk space usage in the incremental sort code. Let's just make all these  
fields int64s.  
  
Author: James Coleman  
Discussion: https://postgr.es/m/CAApHDvpky%2BUhof8mryPf5i%3D6e6fib2dxHqBrhp0Qhu0NeBhLJw%40mail.gmail.com  
Backpatch-through: 13, where the incremental sort code was added  

commit   : 725b43b9c3b3c25c60ac717c41047ad0dffb1312    
  
author   : Peter Geoghegan <[email protected]>    
date     : Fri, 31 Jul 2020 15:34:26 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Fri, 31 Jul 2020 15:34:26 -0700    

Commit eba77534 fixed an amcheck false positive bug involving  
inconsistencies in TOAST input state between table and index.  A test  
case was added that verified that such an inconsistency didn't result in  
a spurious corruption related error.  
  
Test coverage from the test was accidentally lost by commit 501e41dd,  
which propagated ALTER TABLE ...  SET STORAGE attstorage state to  
indexes.  This broke the test because the test specifically relied on  
attstorage not being propagated.  This artificially forced there to be  
index tuples whose datums were equivalent to the datums in the heap  
without the datums actually being bitwise equal.  
  
Fix this by updating pg_attribute directly instead.  Commit 501e41dd  
made similar changes to a test_decoding TOAST-related test case which  
made the same assumption, but overlooked the amcheck test case.  
  
Backpatch: 11-, just like commit eba77534 (and commit 501e41dd).  

commit   : 5c439f189bf4bdbb0ff75b2043ca713d76019528    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 31 Jul 2020 17:11:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 31 Jul 2020 17:11:28 -0400    

If a base type supports typmods, its array type does too, with the  
same interpretation.  Hence changes in pg_type.typmodin/typmodout  
must be propagated to the array type.  
  
While here, improve AlterTypeRecurse to not recurse to domains if  
there is nothing we'd need to change.  
  
Oversight in fe30e7ebf.  Back-patch to v13 where that came in.  

commit   : 11dce63d6c3f676a9f1829eca96f085b6d935af0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 31 Jul 2020 11:43:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 31 Jul 2020 11:43:12 -0400    

The new hlCover() algorithm that I introduced in commit c9b0c678d  
turns out to potentially take O(N^2) or worse time on long documents,  
if there are many occurrences of individual query words but few or no  
substrings that actually satisfy the query.  (One way to hit this  
behavior is with a "common_word & rare_word" type of query.)  This  
seems unavoidable given the original goal of checking every substring  
of the document, so we have to back off that idea.  Fortunately, it  
seems unlikely that anyone would really want headlines spanning all of  
a long document, so we can avoid the worse-than-linear behavior by  
imposing a maximum length of substring that we'll consider.  
  
For now, just hard-wire that maximum length as a multiple of max_words  
times max_fragments.  Perhaps at some point somebody will argue for  
exposing it as a ts_headline parameter, but I'm hesitant to make such  
a feature addition in a back-patched bug fix.  
  
I also noted that the hlFirstIndex() function I'd added in that  
commit was unnecessarily stupid: it really only needs to check whether  
a HeadlineWordEntry's item pointer is null or not.  This wouldn't make  
all that much difference in typical cases with queries having just  
a few terms, but a cycle shaved is a cycle earned.  
  
In addition, add a CHECK_FOR_INTERRUPTS call in TS_execute_recurse.  
This ensures that hlCover's loop is cancellable if it manages to take  
a long time, and it may protect some other TS_execute callers as well.  
  
Back-patch to 9.6 as the previous commit was.  I also chose to add the  
CHECK_FOR_INTERRUPTS call to 9.5.  The old hlCover() algorithm seems  
to avoid the O(N^2) behavior, at least on the test case I tried, but  
nonetheless it's not very quick on a long document.  
  
Per report from Stephen Frost.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0d9b64fe8d2d98f8f074334f86aaaedfb2b5a1e1    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Fri, 31 Jul 2020 07:46:25 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Fri, 31 Jul 2020 07:46:25 +0900    

In "High Availability, Load Balancing, and Replication" chapter,  
certain descriptions of Pgpool-II were not correct at this point.  It  
does not need conflict resolution. Also "Multiple-Server Parallel  
Query Execution" is not supported anymore.  
  
Discussion: https://postgr.es/m/20200726.230128.53842489850344110.t-ishii%40sraoss.co.jp  
Author: Tatsuo Ishii  
Reviewed-by: Bruce Momjian  
Backpatch-through: 9.5  

commit   : 07cbcdd00c2465a844513f14b7a96232013d3129    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 30 Jul 2020 08:44:58 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 30 Jul 2020 08:44:58 -0700    

Using pg_leftmost_one_post32() yields substantial performance benefits.  
  
Backpatching to version 13 because HLL is used for HashAgg  
improvements in 9878b643, which was also backpatched to 13.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-WzkGvDKVDo+0YvfvZ+1CE=iCi88DCOGFF3i1hTGGaxcKPw@mail.gmail.com  
Backpatch-through: 13  

commit   : e710f3b8e7da43de2ad8113ce7c7933928092656    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 30 Jul 2020 15:48:52 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 30 Jul 2020 15:48:52 +0900    

Partitioned indexes are also registered in pg_inherits, but the  
description of this catalog did not reflect that.  
  
Author: Dagfinn Ilmari Mannsåker  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 78530c8e7a5abe0b646b0b46527f8799f831e1e1    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 29 Jul 2020 14:14:57 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 29 Jul 2020 14:14:57 -0700    

Add a GUC that acts as a multiplier on work_mem.  It gets applied when  
sizing executor node hash tables that were previously size constrained  
using work_mem alone.  
  
The new GUC can be used to preferentially give hash-based nodes more  
memory than the generic work_mem limit.  It is intended to enable admin  
tuning of the executor's memory usage.  Overall system throughput and  
system responsiveness can be improved by giving hash-based executor  
nodes more memory (especially over sort-based alternatives, which are  
often much less sensitive to being memory constrained).  
  
The default value for hash_mem_multiplier is 1.0, which is also the  
minimum valid value.  This means that hash-based nodes continue to apply  
work_mem in the traditional way by default.  
  
hash_mem_multiplier is generally useful.  However, it is being added now  
due to concerns about hash aggregate performance stability for users  
that upgrade to Postgres 13 (which added disk-based hash aggregation in  
commit 1f39bce0).  While the old hash aggregate behavior risked  
out-of-memory errors, it is nevertheless likely that many users actually  
benefited.  Hash agg's previous indifference to work_mem during query  
execution was not just faster; it also accidentally made aggregation  
resilient to grouping estimate problems (at least in cases where this  
didn't create destabilizing memory pressure).  
  
hash_mem_multiplier can provide a certain kind of continuity with the  
behavior of Postgres 12 hash aggregates in cases where the planner  
incorrectly estimates that all groups (plus related allocations) will  
fit in work_mem/hash_mem.  This seems necessary because hash-based  
aggregation is usually much slower when only a small fraction of all  
groups can fit.  Even when it isn't possible to totally avoid hash  
aggregates that spill, giving hash aggregation more memory will reliably  
improve performance (the same cannot be said for external sort  
operations, which appear to be almost unaffected by memory availability  
provided it's at least possible to get a single merge pass).  
  
The PostgreSQL 13 release notes should advise users that increasing  
hash_mem_multiplier can help with performance regressions associated  
with hash aggregation.  That can be taken care of by a later commit.  
  
Author: Peter Geoghegan  
Reviewed-By: Álvaro Herrera, Jeff Davis  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/CAH2-WzmD%2Bi1pG6rc1%2BCjc4V6EaFJ_qSuKCCHVnH%3DoruqD-zqow%40mail.gmail.com  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : 3a232a3183d517743acf232794fadc07f0944220    
  
author   : Jeff Davis <[email protected]>    
date     : Tue, 28 Jul 2020 23:15:47 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Tue, 28 Jul 2020 23:15:47 -0700    

Use HyperLogLog to estimate the group cardinality in a spilled  
partition. This estimate is used to choose the number of partitions if  
we recurse.  
  
The previous behavior was to use the number of tuples in a spilled  
partition as the estimate for the number of groups, which lead to  
overpartitioning. That could cause the number of batches to be much  
higher than expected (with each batch being very small), which made it  
harder to interpret EXPLAIN ANALYZE results.  
  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : cdd7bd695bed552936e86b70ff1d234360bc5bea    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 28 Jul 2020 17:59:14 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 28 Jul 2020 17:59:14 -0700    

Missed by my commit 564ce621.  
  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : b6c15e71f33fe9aa7f38cc7bde26d420fbaaef5b    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 28 Jul 2020 17:14:06 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 28 Jul 2020 17:14:06 -0700    

Oversight in commit 1f39bce0, which added disk-based hash aggregation.  
  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : e362f469c50f6e671285640cc2087345ab55a9b2    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 28 Jul 2020 16:58:59 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 28 Jul 2020 16:58:59 -0700    

The planner is in fact willing to use hash aggregation when work_mem is  
not set high enough for everything to fit in memory.  This has been the  
case since commit 1f39bce0, which added disk-based hash aggregation.  
  
There are a few remaining cases in which hash aggregation is avoided as  
a matter of policy when the planner surmises that spilling will be  
necessary.  For example, callers of choose_hashed_setop() still  
conservatively avoid hash aggregation when spilling is anticipated.  
That doesn't seem like a good enough reason to mention hash aggregation  
in this context.  
  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : a57c837e5cdf601d6ec05e5e10a40d01f1d2b84e    
  
author   : David Rowley <[email protected]>    
date     : Wed, 29 Jul 2020 11:43:11 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 29 Jul 2020 11:43:11 +1200    

There were various unnecessary differences between Hash Agg's EXPLAIN  
ANALYZE output and Hash Join's.  Here we modify the Hash Agg output so  
that it's better aligned to Hash Join's.  
  
The following changes have been made:  
1. Start batches counter at 1 instead of 0.  
2. Always display the "Batches" property, even when we didn't spill to  
   disk.  
3. Use the text "Batches" instead of "HashAgg Batches" for text format.  
4. Use the text "Memory Usage" instead of "Peak Memory Usage" for text  
   format.  
5. Include "Batches" before "Memory Usage" in both text and non-text  
   formats.  
  
In passing also modify the "Planned Partitions" property so that we show  
it regardless of if the value is 0 or not for non-text EXPLAIN formats.  
This was pointed out by Justin Pryzby and probably should have been part  
of 40efbf870.  
  
Reviewed-by: Justin Pryzby, Jeff Davis  
Discussion: https://postgr.es/m/CAApHDvrshRnA6C0VFnu7Fb9TVvgGo80PUMm5+2DiaS1gEkPvtw@mail.gmail.com  
Backpatch-through: 13, where HashAgg batching was introduced  

commit   : dc6f2fb4353508af27dde44bdf5cb14749ae73a1    
  
author   : David Rowley <[email protected]>    
date     : Tue, 28 Jul 2020 22:52:43 +1200    
  
committer: David Rowley <[email protected]>    
date     : Tue, 28 Jul 2020 22:52:43 +1200    

Per complaint from Scott Ribe. Based on wording suggestion from Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11, where pg_jit_available() was added  

commit   : 128fd0a65ae54d97896cb6409fbc56d5da6319f1    
  
author   : Fujii Masao <[email protected]>    
date     : Tue, 28 Jul 2020 11:23:02 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Tue, 28 Jul 2020 11:23:02 +0900    

Commit f5dff45962 renamed wal_keep_segments to wal_keep_size.  
This commit adds the mention to this change in the release note.  
  
Author: Fujii Masao  
Reviewed-by: David Steele  
Discussion: https://postgr.es/m/[email protected]  

commit   : cebe10a5f307635e187f424d0dce700666ae58fd    
  
author   : Etsuro Fujita <[email protected]>    
date     : Tue, 28 Jul 2020 11:00:00 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Tue, 28 Jul 2020 11:00:00 +0900    

In the case of range partitioning, get_steps_using_prefix() assumes that  
the passed-in prefix list contains at least one clause for each of the  
partition keys earlier than one specified in the passed-in  
step_lastkeyno, but the caller (ie, gen_prune_steps_from_opexps())  
didn't take it into account, which led to a server crash or incorrect  
results when the list contained no clauses for such partition keys, as  
reported in bug #16500 and #16501 from Kobayashi Hisanori.  Update the  
caller to call that function only when the list created there contains  
at least one clause for each of the earlier partition keys in the case  
of range partitioning.  
  
While at it, fix some other issues:  
  
* The list to pass to get_steps_using_prefix() is allowed to contain  
  multiple clauses for the same partition key, as described in the  
  comment for that function, but that function actually assumed that the  
  list contained just a single clause for each of middle partition keys,  
  which led to an assertion failure when the list contained multiple  
  clauses for such partition keys.  Update that function to match the  
  comment.  
* In the case of hash partitioning, partition keys are allowed to be  
  NULL, in which case the list to pass to get_steps_using_prefix()  
  contains no clauses for NULL partition keys, but that function treats  
  that case as like the case of range partitioning, which led to the  
  assertion failure.  Update the assertion test to take into account  
  NULL partition keys in the case of hash partitioning.  
* Fix a typo in a comment in get_steps_using_prefix_recurse().  
* gen_partprune_steps() failed to detect self-contradiction from  
  strict-qual clauses and an IS NULL clause for the same partition key  
  in some cases, producing incorrect partition-pruning steps, which led  
  to incorrect results of partition pruning, but didn't cause any  
  user-visible problems fortunately, as the self-contradiction is  
  detected later in the query planning.  Update that function to detect  
  the self-contradiction.  
  
Per bug #16500 and #16501 from Kobayashi Hisanori.  Patch by me, initial  
diagnosis for the reported issue and review by Dmitry Dolgov.  
Back-patch to v11, where partition pruning was introduced.  
  
Discussion: https://postgr.es/m/16500-d1613f2a78e1e090%40postgresql.org  
Discussion: https://postgr.es/m/16501-5234a9a0394f6754%40postgresql.org  

commit   : 5a6cc6ffa914775e0184207686c2216998126549    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 27 Jul 2020 17:53:17 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Mon, 27 Jul 2020 17:53:17 -0700    

Note: This GUC was originally named enable_hashagg_disk when it appeared  
in commit 1f39bce0, which added disk-based hash aggregation.  It was  
subsequently renamed in commit 92c58fd9.  
  
Author: Peter Geoghegan  
Reviewed-By: Jeff Davis, Álvaro Herrera  
Discussion: https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel%40j-davis.com  
Backpatch: 13-, where disk-based hash aggregation was introduced.  

commit   : 0caf1fc6e86a8985ef8b881a4dbb3488381ff976    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 27 Jul 2020 15:58:54 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 27 Jul 2020 15:58:54 +0900    

A compressed stream may end with an empty packet.  In this case  
decompression finishes before reading the empty packet and the  
remaining stream packet causes a failure in reading the following  
data.  This commit makes sure to consume such extra data, avoiding a  
failure when decompression the data.  This corner case was reproducible  
easily with a data length of 16kB, and existed since e94dd6a.  A cheap  
regression test is added to cover this case based on a random,  
incompressible string.  
  
The first attempt of this patch has allowed to find an older failure  
within the compression logic of pgcrypto, fixed by b9b6105.  This  
involved SLES 15 with z390 where a custom flavor of libz gets used.  
Bonus thanks to Mark Wong for providing access to the specific  
environment.  
  
Reported-by: Frank Gagnepain  
Author: Kyotaro Horiguchi, Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.5  

commit   : ed4a9dc9cf69eee06f4e655ef5d175c5efa87dd7    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 27 Jul 2020 10:29:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 27 Jul 2020 10:29:08 +0900    

Some code paths dedicated to bytea used the structure for varchar.  This  
did not lead to any actual bugs, as bytea and varchar have the same  
definition, but it could become a trap if one of these definitions  
changes for a new feature or a bug fix.  
  
Issue introduced by 050710b.  
  
Author: Shenhao Wang  
Reviewed-by: Vignesh C, Michael Paquier  
Discussion: https://postgr.es/m/07ac7dee1efc44f99d7f53a074420177@G08CNEXMBPEKD06.g08.fujitsu.local  
Backpatch-through: 12  

commit   : 7f5f2249b27a46a4d91d6be5aff188ca67719fa7    
  
author   : Jeff Davis <[email protected]>    
date     : Sun, 26 Jul 2020 14:55:52 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Sun, 26 Jul 2020 14:55:52 -0700    

Refactor hash lookups in nodeAgg.c to improve performance.  
  
Author: Andres Freund and Jeff Davis  
Discussion: https://postgr.es/m/20200612213715.op4ye4q7gktqvpuo%40alap3.anarazel.de  
Backpatch-through: 13  

commit   : 21b0055359f036e3ba22402d14536431dd39242e    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 26 Jul 2020 16:32:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 26 Jul 2020 16:32:20 +0900    

The initial implementation of leader_pid in pg_stat_activity added by  
b025f32 took the approach to strictly print what a PGPROC entry  
includes.  In short, if a backend has been involved in parallel query at  
least once, leader_pid would remain set as long as the backend is alive.  
For a parallel group leader, this means that the field would always be  
set after it participated at least once in parallel query, and after  
more discussions this could be confusing if using for example a  
connection pooler.  
  
This commit changes the data printed so as leader_pid becomes always  
NULL for a parallel group leader, showing up a non-NULL value only for  
the parallel workers, and actually as long as a parallel query is  
running as workers are shut down once the query has completed.  
  
This does not change the definition of any catalog, so no catalog bump  
is needed.  Per discussion with Justin Pryzby, Álvaro Herrera, Julien  
Rouhaud and me.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 13  

commit   : b15367ae39402eb4eb8736f9c38c607995c82bb2    
  
author   : Amit Kapila <[email protected]>    
date     : Sat, 25 Jul 2020 10:31:19 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Sat, 25 Jul 2020 10:31:19 +0530    

Commit 85c9d347 addressed a similar problem for Gather and Gather  
Merge nodes but forgot to account for nodes above parallel nodes.  This  
still works for nodes above Gather node because we shut down the workers  
for Gather node as soon as there are no more tuples.  We can do a similar  
thing for Gather Merge as well but it seems better to account for stats  
during nodes shutdown after completing the execution.  
  
Reported-by: Stéphane Lorek, Jehan-Guillaume de Rorthais  
Author: Jehan-Guillaume de Rorthais <[email protected]>  
Reviewed-by: Amit Kapila  
Backpatch-through: 10, where it was introduced  
Discussion: https://postgr.es/m/20200718160206.584532a2@firost  

commit   : 70eca6a9a6df679a86f30442194cc6b858b82000    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 24 Jul 2020 15:43:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 24 Jul 2020 15:43:56 -0400    

It's fairly silly that ignoring NOT subexpressions is TS_execute's  
default behavior.  It's wrong on its face and it encourages errors  
of omission.  Moreover, the only two remaining callers that aren't  
specifying CALC_NOT are in ts_headline calculations, and it's very  
arguable that those are bugs: if you've specified "!foo" in your  
query, why would you want to get a headline that includes "foo"?  
  
Hence, rip that out and change the default behavior to be to calculate  
NOT accurately.  As a concession to the slim chance that there is still  
somebody somewhere who needs the incorrect behavior, provide a new  
SKIP_NOT flag to explicitly request that.  
  
Back-patch into v13, mainly because it seems better to change this  
at the same time as the previous commit's rejiggering of TS_execute  
related APIs.  Any outside callers affected by this change are  
probably also affected by that one.  
  
Discussion: https://postgr.es/m/CALT9ZEE-aLotzBg-pOp2GFTesGWVYzXA3=mZKzRDa_OKnLF7Mg@mail.gmail.com  

commit   : 92fe6895d66da93a3c920089cfbbe4eb2db2145e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 24 Jul 2020 15:26:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 24 Jul 2020 15:26:51 -0400    

Text search sometimes failed to find valid matches, for instance  
'!crew:A'::tsquery might fail to locate 'crew:1B'::tsvector during  
an index search.  The root of the issue is that TS_execute's callback  
functions were not changed to use ternary (yes/no/maybe) reporting  
when we made the search logic itself do so.  It's somewhat annoying  
to break that API, but on the other hand we now see that any code  
using plain boolean logic is almost certainly broken since the  
addition of phrase search.  There seem to be very few outside callers  
of this code anyway, so we'll just break them intentionally to get  
them to adapt.  
  
This allows removal of tsginidx.c's private re-implementation of  
TS_execute, since that's now entirely duplicative.  It's also no  
longer necessary to avoid use of CALC_NOT in tsgistidx.c, since  
the underlying callbacks can now do something reasonable.  
  
Back-patch into v13.  We can't change this in stable branches,  
but it seems not quite too late to fix it in v13.  
  
Tom Lane and Pavel Borisov  
  
Discussion: https://postgr.es/m/CALT9ZEE-aLotzBg-pOp2GFTesGWVYzXA3=mZKzRDa_OKnLF7Mg@mail.gmail.com