PostgreSQL 12.5 commit log

commit   : 6bb1b38fa5388a4aa39ed9e56ef477f618fb28e1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 17:26:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 17:26:33 -0500    

commit   : 0b59df670bd15065a87d1d9c216c3787839937fe    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 13:02:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 13:02:13 -0500    

Security: CVE-2020-25694, CVE-2020-25695, CVE-2020-25696  

commit   : d4fd571b3e74dc921028de0892911e49ccf800a0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 12:02:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 12:02:24 -0500    

After studying the code, NULLIF is a lot more subtle than you might  
have guessed.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3855e5b4767b189d4daf6e9a774e4e64be72e0ff    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    

If an interactive psql session used \gset when querying a compromised  
server, the attacker could execute arbitrary code as the operating  
system account running psql.  Using a prefix not found among specially  
treated variables, e.g. every lowercase string, precluded the attack.  
Fix by issuing a warning and setting no variable for the column in  
question.  Users wanting the old behavior can use a prefix and then a  
meta-command like "\set HISTSIZE :prefix_HISTSIZE".  Back-patch to 9.5  
(all supported versions).  
  
Reviewed by Robert Haas.  Reported by Nick Cleaton.  
  
Security: CVE-2020-25696  

commit   : ac8f6243cb002f3386322fb231a0c5daa637941d    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 9 Nov 2020 07:32:09 -0800    

Specifically, this blocks DECLARE ... WITH HOLD and firing of deferred  
triggers within index expressions and materialized view queries.  An  
attacker having permission to create non-temp objects in at least one  
schema could execute arbitrary SQL functions under the identity of the  
bootstrap superuser.  One can work around the vulnerability by disabling  
autovacuum and not manually running ANALYZE, CLUSTER, REINDEX, CREATE  
INDEX, VACUUM FULL, or REFRESH MATERIALIZED VIEW.  (Don't restore from  
pg_dump, since it runs some of those commands.)  Plain VACUUM (without  
FULL) is safe, and all commands are fine when a trusted user owns the  
target object.  Performance may degrade quickly under this workaround,  
however.  Back-patch to 9.5 (all supported versions).  
  
Reviewed by Robert Haas.  Reported by Etienne Stalmans.  
  
Security: CVE-2020-25695  

commit   : a98b46194434927b8402b08ac0edfa6408c7e823    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 9 Nov 2020 12:36:44 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 9 Nov 2020 12:36:44 +0100    

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

commit   : cd3c6e50b958f66285a4ea58eb456ca26750e65d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Nov 2020 15:16:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Nov 2020 15:16:12 -0500    

commit   : 94ec005f334e1ae740a04f4f8a14e3f7f934a346    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Nov 2020 13:08:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Nov 2020 13:08:36 -0500    

This back-patches commit 20d3fe900 into the v12 and v13 branches.  
At the time I thought that commit was not fixing any observable  
bug, but Bertrand Drouvot showed otherwise: adding a dropped column  
to the previously-considered scenario crashes v12 and v13, unless the  
dropped column happens to be an integer.  That is, of course, because  
the tupdesc we derive from the plan output tlist fails to describe  
the dropped column accurately, so that we'll do the wrong thing with  
a tuple in which that column isn't NULL.  
  
There is no bug in pre-v12 branches because they already did use  
the table's real tuple descriptor for any trigger-returned tuple.  
It seems that this set of bugs can be blamed on the changes that  
removed es_trig_tuple_slot, though I've not attempted to pin that  
down precisely.  
  
Although there's no code change needed in HEAD, update the test case  
to include a dropped column there too.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 16eadc4695ef120e5a6f6adf026a034e291806cc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 7 Nov 2020 22:15:52 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 7 Nov 2020 22:15:52 +0100    

A few client tools duplicate error messages already provided by libpq.  
  
Discussion: https://www.postgresql.org/message-id/flat/3e937641-88a1-e697-612e-99bba4b8e5e4%40enterprisedb.com  

commit   : 8ad6a0c1bb1c5a041cadfed713ef6bcabd0955ab    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 6 Nov 2020 22:52:15 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 6 Nov 2020 22:52:15 -0300    

The list of indexes was being leaked when asked for an index that  
doesn't have an index partition in the table partition.  Not a common  
case admittedly --and in most cases where it occurs, caller throws an  
error anyway-- but worth fixing for cleanliness and in case any  
third-party code is calling this function.  
  
While at it, remove use of lfirst_oid() to obtain a value we already  
have.  
  
Author: Justin Pryzby <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8149e9f9a0d684dce883d9e5a9f7380afbdbd7d6    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 7 Nov 2020 00:40:40 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 7 Nov 2020 00:40:40 +0100    

brin_form_tuple failed to consider the values may be toasted, inserting  
the toast pointer into the index. This may easily result in index  
corruption, as the toast data may be deleted and cleaned up by vacuum.  
The cleanup however does not care about indexes, leaving invalid toast  
pointers behind, which triggers errors like this:  
  
  ERROR:  missing chunk number 0 for toast value 16433 in pg_toast_16426  
  
A less severe consequence are inconsistent failures due to the index row  
being too large, depending on whether brin_form_tuple operated on plain  
or toasted version of the row. For example  
  
    CREATE TABLE t (val TEXT);  
    INSERT INTO t VALUES ('... long value ...')  
    CREATE INDEX idx ON t USING brin (val);  
  
would likely succeed, as the row would likely include toast pointer.  
Switching the order of INSERT and CREATE INDEX would likely fail:  
  
    ERROR:  index row size 8712 exceeds maximum 8152 for index "idx"  
  
because this happens before the row values are toasted.  
  
The bug exists since PostgreSQL 9.5 where BRIN indexes were introduced.  
So backpatch all the way back.  
  
Author: Tomas Vondra  
Reviewed-by: Alvaro Herrera  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/20201001184133.oq5uq75sb45pu3aw@development  
Discussion: https://postgr.es/m/20201104010544.zexj52mlldagzowv%40development  

commit   : f07811009ffd176be24e02f1164a690af927ab89    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 16:17:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 16:17:57 -0500    

Revert 59ab4ac32, as well as the followup fix 33862cb9c, in all  
branches.  We need to think a bit harder about what the behavior  
of LOCK TABLE on views should be, and there's no time for that  
before next week's releases.  We'll take another crack at this  
later.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f4fa4a82133fcca23acd128b341831ca7088f885    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 15:48:21 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 15:48:21 -0500    

Revert 403a3d91c, as well as the followup fix 7f4235032, in all  
branches.  We need to think a bit harder about what the behavior  
of LOCK TABLE on views should be, and there's no time for that  
before next week's releases.  We'll take another crack at this  
later.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0bdf1ef3d53e42c1c050a9f30b663fe72269a129    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 Nov 2020 11:44:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 Nov 2020 11:44:32 -0500    

LOCK TABLE has complained about "infinite recursion" when applied  
to a self-referential view, ever since we made it recurse into views  
in v11.  However, that breaks pg_dump's new assumption that it's  
okay to lock every relation.  There doesn't seem to be any good  
reason to throw an error: if we just abandon the recursion, we've  
still satisfied the requirement of locking every referenced relation.  
  
Per bug #16703 from Andrew Bille (via Alexander Lakhin).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ea9087938131ae0da822ccb96c2d8dc71c177f53    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 4 Nov 2020 07:47:06 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 4 Nov 2020 07:47:06 +0100    

hash_array_extended() needs to pass PG_GET_COLLATION() to the hash  
function of the element type.  Otherwise, the hash function of a  
collation-aware data type such as text will error out, since the  
introduction of nondeterministic collation made hash functions require  
a collation, too.  
  
The consequence of this is that before this change, hash partitioning  
using an array over text in the partition key would not work.  
  
Reviewed-by: Heikki Linnakangas <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/32c1fdae-95c6-5dc6-058a-a90330a3b621%40enterprisedb.com  

commit   : 55416b26a98fcf354af88cdd27fc2e045453b68a    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 3 Nov 2020 16:16:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 3 Nov 2020 16:16:36 -0500    

If the planner erroneously puts a non-parallel-safe SubPlan into  
a parallelized portion of the query tree, nodeSubplan.c will fail  
in the worker processes because it finds a null in es_subplanstates,  
which it's unable to cope with.  It seems worth a test-and-elog to  
make that an error case rather than a core dump case.  
  
This probably should have been included in commit 16ebab688, which  
was responsible for allowing nulls to appear in es_subplanstates  
to begin with.  So, back-patch to v10 where that came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 136f87ea57b3a7a6bf64c832a5e1b69e18091775    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 3 Nov 2020 15:41:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 3 Nov 2020 15:41:32 -0500    

The intention in commit 491c029db was to require superuserness to  
change the BYPASSRLS property, but the actual effect of the coding  
in AlterRole() was to require superuserness to change anything at all  
about a BYPASSRLS role.  Other properties of a BYPASSRLS role should  
be changeable under the same rules as for a normal role, though.  
  
Fix that, and also take care of some documentation omissions related  
to BYPASSRLS and REPLICATION role properties.  
  
Tom Lane and Stephen Frost, per bug report from Wolfgang Walther.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d3befe9b98d523d7ae04d93c295001385550e4a3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Nov 2020 21:11:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Nov 2020 21:11:50 -0500    

fill_hba_line() thought it could get away with passing sizeof(struct  
sockaddr_storage) rather than the actual addrlen previously returned  
by getaddrinfo().  While that appears to work on many platforms,  
it does not work on FreeBSD 11: you get back a failure, which leads  
to the view showing NULL for the address and netmask columns in all  
rows.  The POSIX spec for getnameinfo() is pretty clearly on  
FreeBSD's side here: you should pass the actual address length.  
So it seems plausible that there are other platforms where this  
coding also fails, and we just hadn't noticed.  
  
Also, IMO the fact that getnameinfo() failure leads to a NULL output  
is pretty bogus in itself.  Our pg_getnameinfo_all() wrapper is  
careful to emit "???" on failure, and we should use that in such  
cases.  NULL should only be emitted in rows that don't have IP  
addresses.  
  
Per bug #16695 from Peter Vandivier.  Back-patch to v10 where this  
code was added.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5ba4987a4048f1ad3002bc047279cb633429d7d1    
  
author   : Magnus Hagander <[email protected]>    
date     : Mon, 2 Nov 2020 15:20:19 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Mon, 2 Nov 2020 15:20:19 +0100    

commit   : bebad33420044240297e7288d4f311095bab76b9    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 15:15:25 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 15:15:25 +0900    

The documentation fixes are backpatched down to where they apply.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.6  

commit   : a8795445bc1bacc98d54ad746809bcb638700aca    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 10:41:30 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 10:41:30 +0900    

This is useful for checks of relation pages without having to load the  
pages into the shared buffers, and two cases can make use of that: page  
verification in base backups and the online, lock-safe, flavor.  
  
Compatibility is kept with past versions using a routine that calls the  
new extended routine with the set of options compatible with the  
original version.  Contrary to d401c576, a macro cannot be used as there  
may be external code relying on the presence of the original routine.  
  
This is applied down to 11, where this will be used by a follow-up  
commit addressing a set of issues with page verification in base  
backups.  
  
Extracted from a larger patch by the same author.  
  
Author: Anastasia Lubennikova  
Reviewed-by: Michael Paquier, Julien Rouhaud  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 7d72fd9e6db686c9a499d4238d23525437adc132    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Nov 2020 11:26:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Nov 2020 11:26:16 -0500    

Although error results received from the backend should always have  
a SQLSTATE field, ones generated by libpq won't, making this code  
vulnerable to a crash after, say, untimely loss of connection.  
Noted by Coverity.  
  
Oversight in commit 403a3d91c.  Back-patch to 9.5, as that was.  

commit   : 41a033b5054e047cc67a92e17fbbe4accb658b3b    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 1 Nov 2020 21:24:15 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 1 Nov 2020 21:24:15 +0900    

Statistics associated to an index got lost after running REINDEX  
CONCURRENTLY, while the non-concurrent case preserves these correctly.  
The concurrent and non-concurrent operations need to be consistent for  
the end-user, and missing statistics would force to wait for a new  
analyze to happen, which could take some time depending on the activity  
of the existing autovacuum workers.  This issue is fixed by copying any  
existing entries in pg_statistic associated to the old index to the new  
one.  Note that this copy is already done with the data of the index in  
the stats collector.  
  
Reported-by: Fabrízio de Royes Mello  
Author: Michael Paquier, Fabrízio de Royes Mello  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/CAFcNs+qpFPmiHd1oTXvcPdvAHicJDA9qBUSujgAhUMJyUMb+SA@mail.gmail.com  
Backpatch-through: 12  

commit   : 741b84e9f74726fbc97f63ddb46ab5675de98bdf    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 31 Oct 2020 08:43:28 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 31 Oct 2020 08:43:28 -0700    

Certain background workers initiate parallel queries while  
debug_query_string==NULL, at which point they attempted strlen(NULL) and  
died to SIGSEGV.  Older debug_query_string observers allow NULL, so do  
likewise in these newer ones.  Back-patch to v11, where commit  
7de4a1bcc56f494acbd0d6e70781df877dc8ecb5 introduced the first of these.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 25b587f03a8372786ec06fbd033fdf49750be0e5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Oct 2020 15:28:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Oct 2020 15:28:14 -0400    

The timetz test cases I added in commit a9632830b were unintentionally  
sensitive to whether or not DST is active in the PST8PDT time zone.  
Thus, they'll start failing this coming weekend, as reported by  
Bernhard M. Wiedemann in bug #16689.  Fortunately, DST-awareness is  
not significant to the purpose of these test cases, so we can just  
force them all to PDT (DST hours) to preserve stability of the  
results.  
  
Back-patch to v10, as the prior patch was.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : cb0982ba9796e16a0d38953c14ef32af657e6fd4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 28 Oct 2020 14:35:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 28 Oct 2020 14:35:53 -0400    

In almost all other places, we use plain "r" or "w" mode in popen()  
calls (the exceptions being for COPY data).  This one has been  
overlooked (possibly because it's buried in a ".l" flex file?),  
but it's using PG_BINARY_R.  
  
Kensuke Okamura complained in bug #16688 that we fail to strip \r  
when stripping the trailing newline from a backtick result string.  
That's true enough, but we'd also fail to convert embedded \r\n  
cleanly, which also seems undesirable.  Fixing the popen() mode  
seems like the best way to deal with this.  
  
It's been like this for a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 43330cdd40f12f352bc8f8100974c4b7eeb45d18    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 28 Oct 2020 13:47:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 28 Oct 2020 13:47:02 -0400    

It's unsafe to do this at parse time because addition of generated  
columns to a table would not invalidate stored rules containing  
UPDATEs on the table ... but there might now be dependent generated  
columns that were not there when the rule was made.  This also fixes  
an oversight that rewriteTargetView failed to update extraUpdatedCols  
when transforming an UPDATE on an updatable view.  (Since the new  
calculation is downstream of that, rewriteTargetView doesn't actually  
need to do anything; but before, there was a demonstrable bug there.)  
  
In v13 and HEAD, this leads to easily-visible bugs because (since  
commit c6679e4fc) we won't recalculate generated columns that aren't  
listed in extraUpdatedCols.  In v12 this bitmap is mostly just used  
for trigger-firing decisions, so you'd only notice a problem if a  
trigger cared whether a generated column had been updated.  
  
I'd complained about this back in May, but then forgot about it  
until bug #16671 from Michael Paul Killian revived the issue.  
  
Back-patch to v12 where this field was introduced.  If existing  
stored rules contain any extraUpdatedCols values, they'll be  
ignored because the rewriter will overwrite them, so the bug will  
be fixed even for existing rules.  (But note that if someone were  
to update to 13.1 or 12.5, store some rules with UPDATEs on tables  
having generated columns, and then downgrade to a prior minor version,  
they might observe issues similar to what this patch fixes.  That  
seems unlikely enough to not be worth going to a lot of effort to fix.)  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 93f726c04fb134e1b28aaec84f10f296a00b6df8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Oct 2020 15:37:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 27 Oct 2020 15:37:13 -0400    

EventTriggerAlterTableEnd neglected to make sure that it built its  
output list in the right context.  In simple cases this was masked  
because the function is called in PortalContext which will be  
sufficiently long-lived anyway; but that doesn't make it not a bug.  
Commit ced138e8c fixed this in HEAD and v13, but mistakenly chose  
not to back-patch further.  Back-patch the same code change all  
the way (I didn't bother with the test case though, as it would  
prove nothing in pre-v13 branches).  
  
Per report from Arseny Sher.  
Original fix by Jehan-Guillaume de Rorthais.  
  
Discussion: https://postgr.es/m/877drcyprb.fsf@ars-thinkpad  
Discussion: https://postgr.es/m/20200902193715.6e0269d4@firost  

commit   : 197014baa4128f4c35a9eca98f55b9655f3bd346    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 27 Oct 2020 14:00:38 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 27 Oct 2020 14:00:38 -0400    

You can't compile thread_test alone anymore, and the location moved too.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 9f829aeb3636830f60aeb8ef4f7872e5a5c9044a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 27 Oct 2020 14:31:37 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 27 Oct 2020 14:31:37 -0300    

Now that LOCK TABLE can take any relation type, acquire lock on all  
relations that are to be dumped.  This prevents schema changes or  
deadlock errors that could cause a dump to fail after expending much  
effort.  The server is tested to have the capability and the feature  
disabled if it doesn't, so that a patched pg_dump doesn't fail when  
connecting to an unpatched server.  
  
Backpatch to 9.5.  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Reported-by: Wells Oliver <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7ffead21a4fa02338572696203587f7dac3a2aef    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 27 Oct 2020 13:49:19 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 27 Oct 2020 13:49:19 -0300    

The restriction that only tables and views can be locked by LOCK TABLE  
is quite arbitrary, since the underlying mechanism can lock any relation  
type.  Drop the restriction so that programs such as pg_dump can lock  
all relations they're interested in, preventing schema changes that  
could cause a dump to fail after expending much effort.  
  
Backpatch to 9.5.  
  
Author: Álvaro Herrera <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Reported-by: Wells Oliver <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 340bbe1fef585cbd472810f038f817df4c314aeb    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 27 Oct 2020 12:43:11 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 27 Oct 2020 12:43:11 -0400    

This directory and the ability to build the thread test independently  
were removed in commit 8a2121185b.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : 209e8e4c8747434a70f0add141d8ef26252b549c    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 26 Oct 2020 22:38:11 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 26 Oct 2020 22:38:11 -0400    

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

commit   : baad9adfa988f34996e0ce377e7e68da70df975e    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 26 Oct 2020 19:17:05 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 26 Oct 2020 19:17:05 -0400    

Parallel execution changed the way bloom queries are executed, so update  
the EXPLAIN output, and restructure the docs to be clearer and more  
accurate.  
  
Reported-by: Daniel Westermann  
  
Discussion: https://postgr.es/m/ZR0P278MB0122119FAE78721A694C30C8D2340@ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM  
  
Author: Daniel Westermann and me  
  
Backpatch-through: 9.6  

commit   : de78c10072b35f47770c67fcc25f2a17eb394180    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Oct 2020 13:57:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Oct 2020 13:57:46 -0400    

If the old row has any "missing" attributes that are supposed to  
be retrieved from an associated tuple descriptor, the wrong things  
happened because the trigger result is shoved directly into an  
executor slot that lacks the missing-attribute data.  Notably,  
CHECK-constraint verification would incorrectly see those columns  
as NULL, and so would RETURNING-list evaluation.  
  
Band-aid around this by forcibly expanding the tuple before passing  
it to the trigger function.  (IMO it was a fundamental misdesign to  
put the missing-attribute data into tuple constraints, which so  
much of the system considers to be optional.  But we're probably  
stuck with that now, and will have to continue to apply band-aids  
as we find other places with similar issues.)  
  
Back-patch to v12.  v11 would also have the issue, except that  
commit 920311ab1 already applied a similar band-aid.  That forced  
expansion in more cases than seem really necessary, though, so  
this isn't a directly equivalent fix.  
  
Amit Langote, with some cosmetic changes by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2a15eeeddff982b7b9732d18985276d91ff210a7    
  
author   : David Rowley <[email protected]>    
date     : Sun, 25 Oct 2020 22:39:00 +1300    
  
committer: David Rowley <[email protected]>    
date     : Sun, 25 Oct 2020 22:39:00 +1300    

Author: Zhijie Hou  
Discussion: https://postgr.es/m/14cd74ea00204cc8a7ea5d738ac82cd1@G08CNEXMBPEKD05.g08.fujitsu.local  
Backpatch-through: 12, where the mistake was introduced  

commit   : bdc79ddd10790fcbaecc92e9ac3a64caa44d71e1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Oct 2020 13:12:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Oct 2020 13:12:08 -0400    

We must not set the "done" flag until after we've executed the  
initialization function.  Otherwise, other threads can fall through  
the initial unlocked test before initialization is really complete.  
  
This has been seen to cause rare failures of ecpg's thread/descriptor  
test, and it could presumably cause other sorts of misbehavior in  
threaded ECPG-using applications, since ecpglib relies on  
pthread_once() in several places.  
  
Diagnosis and patch by me, based on investigation by Alexander Lakhin.  
Back-patch to all supported branches (the bug dates to 2007).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 78ccf7f42b98add6528ae99ea2c2198b6c574c65    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 22 Oct 2020 21:23:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 22 Oct 2020 21:23:47 -0400    

DST law changes in Palestine, with a whopping 120 hours' notice.  
Also some historical corrections for Palestine.  

commit   : f56c42e503a565333f9e77d0ea40d70ecc152af8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 22 Oct 2020 21:15:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 22 Oct 2020 21:15:22 -0400    

There's no functional change at all here, but I'm curious to see  
whether this change successfully shuts up Coverity's warning about  
a useless strcmp(), which appeared with the previous update.  
  
Discussion: http://mm.icann.org/pipermail/tz/2020-October/029370.html  

commit   : f656517ecdf405abeac26b4aebc97ebfefaba633    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Oct 2020 16:18:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Oct 2020 16:18:41 -0400    

psql's \connect claims to be able to re-use previous connection  
parameters, but in fact it only re-uses the database name, user name,  
host name (and possibly hostaddr, depending on version), and port.  
This is problematic for assorted use cases.  Notably, pg_dump[all]  
emits "\connect databasename" commands which we would like to have  
re-use all other parameters.  If such a script is loaded in a psql run  
that initially had "-d connstring" with some non-default parameters,  
those other parameters would be lost, potentially causing connection  
failure.  (Thus, this is the same kind of bug addressed in commits  
a45bc8a4f and 8e5793ab6, although the details are much different.)  
  
To fix, redesign do_connect() so that it pulls out all properties  
of the old PGconn using PQconninfo(), and then replaces individual  
properties in that array.  In the case where we don't wish to re-use  
anything, get libpq's default settings using PQconndefaults() and  
replace entries in that, so that we don't need different code paths  
for the two cases.  
  
This does result in an additional behavioral change for cases where  
the original connection parameters allowed multiple hosts, say  
"psql -h host1,host2", and the \connect request allows re-use of the  
host setting.  Because the previous coding relied on PQhost(), it  
would only permit reconnection to the same host originally selected.  
Although one can think of scenarios where that's a good thing, there  
are others where it is not.  Moreover, that behavior doesn't seem to  
meet the principle of least surprise, nor was it documented; nor is  
it even clear it was intended, since that coding long pre-dates the  
addition of multi-host support to libpq.  Hence, this patch is content  
to drop it and re-use the host list as given.  
  
Per Peter Eisentraut's comments on bug #16604.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a818000f6a88cfe39e3751f5bedf40dd5294433b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 21 Oct 2020 14:37:25 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 21 Oct 2020 14:37:25 -0300    

Should cause tests to be a bit faster  

commit   : 0e6b6f8c7192c82f62b4bbc0b40e9c6252a67bd1    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 20 Oct 2020 19:22:09 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Oct 2020 19:22:09 -0300    

More precisely, correctly handle the ONLY flag indicating not to  
recurse.  This was implemented in 86f575948c77 by recursing in  
trigger.c, but that's the wrong place; use ATSimpleRecursion instead,  
which behaves properly.  However, because legacy inheritance has never  
recursed in that situation, make sure to do that only for new-style  
partitioning.  
  
I noticed this problem while testing a fix for another bug in the  
vicinity.  
  
This has been wrong all along, so backpatch to 11.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : bd0677bb8a54683b05b75fc242bd5c757ce5edd8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 19 Oct 2020 08:52:25 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 19 Oct 2020 08:52:25 +0200    

In shm_mq_receive(), a huge payload could trigger an unjustified  
"invalid memory alloc request size" error due to the way the buffer  
size is increased.  
  
Add error checks (documenting the upper limit) and avoid the error by  
limiting the allocation size to MaxAllocSize.  
  
Author: Markus Wanner <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/3bb363e7-ac04-0ac4-9fe8-db1148755bfa%402ndquadrant.com  

commit   : c6d0b9b1668cde5f13e632bad813bd9d666caf9b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Oct 2020 19:03:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Oct 2020 19:03:46 -0400    

When told to process all databases, clusterdb, reindexdb, and vacuumdb  
would reconnect by replacing their --maintenance-db parameter with the  
name of the target database.  If that parameter is a connstring (which  
has been allowed for a long time, though we failed to document that  
before this patch), we'd lose any other options it might specify, for  
example SSL or GSS parameters, possibly resulting in failure to connect.  
Thus, this is the same bug as commit a45bc8a4f fixed in pg_dump and  
pg_restore.  We can fix it in the same way, by using libpq's rules for  
handling multiple "dbname" parameters to add the target database name  
separately.  I chose to apply the same refactoring approach as in that  
patch, with a struct to handle the command line parameters that need to  
be passed through to connectDatabase.  (Maybe someday we can unify the  
very similar functions here and in pg_dump/pg_restore.)  
  
Per Peter Eisentraut's comments on bug #16604.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7e175c53d997a67f771d6a6bdc5a85a0fe99db00    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 19:28:54 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 19:28:54 +0300    

- Misc grammar and punctuation fixes.  
  
- Stylistic cleanup: use spaces between function arguments and JSON fields  
  in examples. For example "foo(a,b)" -> "foo(a, b)". Add semicolon after  
  last END in a few PL/pgSQL examples that were missing them.  
  
- Make sentence that talked about "..." and ".." operators more clear,  
  by avoiding to end the sentence with "..". That makes it look the same  
  as "..."  
  
- Fix syntax description for HAVING: HAVING conditions cannot be repeated  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report. Backpatch to all  
supported versions, to the extent that the patch applies easily.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : c092b2ee235e125cc1f8b727052398683bd88428    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 19:02:25 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 19:02:25 +0300    

ALTER SEQUENCE RESTART was made transactional in commit 3d79013b97.  
Backpatch to v10, where that was introduced.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : 660cbe807596399c34e56f7ff2554a39cde0f70c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 18:50:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 18:50:33 +0300    

The output for this query changed in commit 4e2477b7b8. Backport to 9.6  
like that commit.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : 407580aabb831f933234c91991387b2ba3fe2318    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Oct 2020 11:23:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Oct 2020 11:23:51 -0400    

The Windows documentation insists that every WSAStartup call should  
have a matching WSACleanup call.  However, if that ever had actual  
relevance, it wasn't in this century.  Every remotely-modern Windows  
kernel is capable of cleaning up when a process exits without doing  
that, and must be so to avoid resource leaks in case of a process  
crash.  Moreover, Postgres backends have done WSAStartup without  
WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any  
indication of a problem with that.  
  
libpq's habit of doing WSAStartup during connection start and  
WSACleanup during shutdown is also rather inefficient, since a  
series of non-overlapping connection requests leads to repeated,  
quite expensive DLL unload/reload cycles.  We document a workaround  
for that (having the application call WSAStartup for itself), but  
that's just a kluge.  It's also worth noting that it's far from  
uncommon for applications to exit without doing PQfinish, and  
we've not heard reports of trouble from that either.  
  
However, the real reason for acting on this is that recent  
experiments by Alexander Lakhin show that calling WSACleanup  
during PQfinish is triggering the symptom we occasionally see  
that a process using libpq fails to emit expected stdio output.  
  
Therefore, let's change libpq so that it calls WSAStartup only  
once per process, during the first connection attempt, and never  
calls WSACleanup at all.  
  
While at it, get rid of the only other WSACleanup call in our code  
tree, in pg_dump/parallel.c; that presumably is equally useless.  
  
Back-patch of HEAD commit 7d00a6b2d.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f0e92bc4b0d783d700058f457a09d6c31e7edb01    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 17:58:38 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Oct 2020 17:58:38 +0300    

Commit 028350f619 changed its behavior from "at most" to "exactly", but  
forgot to update the documentation. Backpatch to 9.6.  
  
Patch by Justin Pryzby, per Yaroslav Schekin's report.  
  
Discussion: https://www.postgresql.org/message-id/20201005191922.GE17626%40telsasoft.com  

commit   : 9b27176c3ff62bd5fae4b57b58f8723fadeb34f8    
  
author   : Magnus Hagander <[email protected]>    
date     : Mon, 19 Oct 2020 13:47:09 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Mon, 19 Oct 2020 13:47:09 +0200    

Author: Daniel Gustafsson <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 77ca44b76477ae4efbac0766b578607e1d261383    
  
author   : David Rowley <[email protected]>    
date     : Tue, 20 Oct 2020 00:05:41 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 20 Oct 2020 00:05:41 +1300    

In the planner, it was possible, given an extreme enough case containing a  
large number of joins for the number of estimated rows to become infinite.  
This could cause problems in initial_cost_mergejoin() where we perform  
some calculations based on those row estimates.  
  
A problem case, presented by Onder Kalaci showed an Assert failure from  
an Assert checking outerstartsel <= outerendsel.  In his test case this  
was effectively NaN <= Inf, which is false.  The NaN outerstartsel came  
from multiplying the infinite outer_path_rows by 0.0.  
  
In master, this problem was fixed by a90c950fc, however, that fix was too  
invasive for the backbranches.  Here we just relax the Asserts to allow  
them to pass.  The worst that appears to happen from this is that we show  
NaN cost values and infinite row estimates in EXPLAIN.  add_path() would  
have had a hard time doing anything useful with such costs, but that does  
not really matter as if the row estimates were even close to accurate,  
such plan would not complete this side of the heat death of the universe.  
  
Reported-by: Onder Kalaci  
Backpatch: 9.5 to 13  
Discussion: https://postgr.es/m/DM6PR21MB1211FF360183BCA901B27F04D80B0@DM6PR21MB1211.namprd21.prod.outlook.com  

commit   : 57bdf29dd5f66bda9bcb538b6911b1accd89f47e    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 19 Oct 2020 09:37:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 19 Oct 2020 09:37:55 +0900    

When allocating a EVP context, it would have been possible to leak some  
memory allocated directly by OpenSSL, that PostgreSQL lost track of if  
the initialization of the context allocated failed.  The cleanup can be  
done with EVP_MD_CTX_destroy().  
  
Note that EVP APIs exist since OpenSSL 0.9.7 and we have in the tree  
equivalent implementations for older versions since ce9b75d (code  
removed with 9b7cd59a as of 10~).  However, in 9.5 and 9.6, the existing  
code makes use of EVP_MD_CTX_destroy() and EVP_MD_CTX_create() without  
an equivalent implementation when building the tree with OpenSSL 0.9.6  
or older, meaning that this code is in reality broken with such versions  
since it got introduced in e2838c5.  As we have heard no complains about  
that, it does not seem worth bothering with in 9.5 and 9.6, so I have  
left that out for simplicity.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.5  

commit   : 3753e2720a9691d38aa85fe1e641ba55703e2a6f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 17 Oct 2020 16:02:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 17 Oct 2020 16:02:47 -0400    

Section 8.5.1.4, which defines these literals, made only a vague  
reference to the fact that they might be evaluated too soon to be  
safe in non-interactive contexts.  Provide a more explicit caution  
against misuse.  Also, generalize the wording in the related tip in  
section 9.9.4: while it clearly described this problem, it implied  
(or really, stated outright) that the problem only applies to table  
DEFAULT clauses.  
  
Per gripe from Tijs van Dam.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com  

commit   : b39c94097da968cccdd68bf8f08b386667421a1c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 21:53:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 21:53:33 -0400    

DST law changes in Morocco, Canadian Yukon, Fiji, Macquarie Island,  
Casey Station (Antarctica).  Historical corrections for France,  
Hungary, Monaco.  

commit   : 3d13a83079dad27e82cd760b7483e604af83e167    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 21:40:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 21:40:16 -0400    

This changes zic's default output format from "-b fat" to "-b slim".  
We were already using "slim" in v13/HEAD, so those branches drop  
the explicit -b switch in the Makefiles.  Instead, add an explicit  
"-b fat" in v12 and before, so that we don't change the output file  
format in those branches.  (This is perhaps excessively conservative,  
but we decided not to do so in a12079109, and I'll stick with that.)  
  
Other non-cosmetic changes are to drop support for zic's long-obsolete  
"-y" switch, and to ensure that strftime() does not change errno  
unless it fails.  
  
As usual with tzcode changes, back-patch to all supported branches.  

commit   : 7004ce75897e008442673289b7c71af2832200f8    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 11:59:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 11:59:13 -0400    

In theory, the second px_find_digest call in px_crypt_md5 could fail  
even though the first one succeeded, since resource allocation is  
required.  Don't skip testing for a failure.  (If one did happen,  
the likely result would be a crash rather than clean recovery from  
an OOM failure.)  
  
The code's been like this all along, so back-patch to all supported  
branches.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 05e6fa8b1bcad527629bbfa04d9fc0d29ca790a2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 11:36:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 16 Oct 2020 11:36:34 -0400    

Commit a97e85f2b caused "exceed the available area" warnings in PDF  
builds.  Fine-tune colwidth values to avoid that.  
  
Back-patch to 9.6, like the prior patch.  (This is of dubious value  
before v13, since we were far from free of such warnings in older  
branches.  But we might as well keep the SGML looking the same in all  
branches.)  
  
Per buildfarm.  

commit   : c835c7ffe21dae8233d21c0ad01e3cbbe475082d    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 15 Oct 2020 17:38:00 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 15 Oct 2020 17:38:00 -0700    

Unfortunately in LLVM 3.9 LLVMGetAttributeCountAtIndex(func, index)  
crashes when called with an index that has 0 attributes. Since there's  
no way to work around this in the C API, add a small C++ wrapper doing  
so.  
  
The only reason this didn't fail before 72559438f92 is that there  
always are function attributes...  
  
Author: Andres Freund <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, like 72559438f92  

commit   : 0ab7ca98a16f9e4954f47c7f180e0760b4f355ec    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 15 Oct 2020 20:37:20 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 15 Oct 2020 20:37:20 -0400    

This commit required support for inline variable definition, which is  
not a requirement.  
  
RELEASE NOTE AUTHOR:  the author of commit 3c0471b5fd  
(pg_upgrade/tablespaces) was Justin Pryzby, not me.  
  
Reported-by: Andres Freund  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : a106236d8287315a8b7d24b38cb283817fd4d391    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 15 Oct 2020 19:33:36 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 15 Oct 2020 19:33:36 -0400    

Previously, if pg_upgrade failed, and the user recreated the cluster but  
did not remove the new cluster tablespace directory, a later pg_upgrade  
would fail since the new tablespace directory would already exists.  
This adds error reporting for this during check.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : c8a2bb0f1abfa2c6ca4ed253a581431855e639c5    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 15 Oct 2020 13:39:41 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 15 Oct 2020 13:39:41 -0700    

Previously we only copied the function attributes. That caused problems at  
least on s390x: Because we didn't copy the 'zeroext' attribute for  
ExecAggTransReparent()'s *IsNull parameters, expressions invoking it didn't  
ensure that the upper bytes of the registers were zeroed. In the - relatively  
rare - cases where not, ExecAggTransReparent() wrongly ended up in the  
newValueIsNull branch due to the register not being zero. Subsequently causing  
a crash.  
  
It's quite possible that this would cause problems on other platforms, and in  
other places than just ExecAggTransReparent() on s390x.  
  
Thanks to Christoph (and the Debian project) for providing me with access to a  
s390x machine, allowing me to debug this.  
  
Reported-By: Christoph Berg  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, where JIT was added  

commit   : f915453c5a38c3dcd5f87efec630801adc3c93a9    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 15 Oct 2020 15:15:29 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 15 Oct 2020 15:15:29 -0400    

Previously it wasn't clear exactly what each of the synchronous_commit  
modes accomplished.  This clarifies that, and adds a table describing it.  
Only backpatched through 9.6 since 9.5 doesn't have all the options.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.6  

commit   : 8b53dbada4a6a9e5f16548ca2c4d17cff55933d8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Oct 2020 12:50:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Oct 2020 12:50:57 -0400    

POSIX sigaction(2) can be told to block a set of signals while a  
signal handler executes.  Make use of that instead of manually  
blocking and unblocking signals in the postmaster's signal handlers.  
This should save a few cycles, but more importantly it prevents  
recursive invocation of signal handlers when many signals arrive in  
close succession.  (Assuming that the platform's signal infrastructure  
is designed to avoid consuming stack space in that case, but this is  
demonstrably true at least on Linux.)  The existing code has been seen  
to recurse to the point of stack overflow, either in the postmaster  
or in a forked-off child.  
  
Back-patch of commit 9abb2bfc0.  At the time, we'd only seen excess  
postmaster stack consumption in the buildfarm; but we now have a  
user report of it, and that commit has aged enough to have a fair  
amount of confidence that it doesn't break anything.  
  
This still doesn't change anything about the way that it works on  
Windows.  Perhaps someone else would like to fix that?  
  
Per bug #16673 from David Geier.  Back-patch to 9.6.  Although  
the problem exists in principle before that, we've only seen it  
actually materialize in connection with heavy use of parallel  
workers, so it doesn't seem necessary to do anything in 9.5;  
and the relevant code is different there, too.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 72b15740900cb6e0646bcdafabecbaa8eaad9e7e    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 15 Oct 2020 11:04:07 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 15 Oct 2020 11:04:07 +0900    

Previously it was documented that toast_tuple_target affected column  
marked as only External or Extended. But this description is not correct  
and toast_tuple_target affects also column marked as Main.  
  
Back-patch to v11 where toast_tuple_target reloption was introduced.  
  
Author: Shinya Okano  
Reviewed-by: Tatsuhito Kasahara, Fujii Masao  
Discussion: https://postgr.es/m/[email protected]  

commit   : c7e2364a5f17b3ef3518f92542fb1b1628288382    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Oct 2020 17:44:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Oct 2020 17:44:56 -0400    

Our infinite_recurse() test to verify sane stack-overrun behavior  
is affected by a bug of the Linux kernel on PPC64: it will get SIGSEGV  
if it receives a signal when the stack depth is (a) over 1MB and  
(b) within a few kB of filling the current physical stack allocation.  
See https://bugzilla.kernel.org/show_bug.cgi?id=205183.  
  
Since this test is a bit time-consuming and we run it in parallel with  
test scripts that do a lot of DDL, it can be expected to get an sinval  
catchup interrupt at some point, leading to failure if the timing is  
wrong.  This has caused more than 100 buildfarm failures over the  
past year or so.  
  
While a fix exists for the kernel bug, it might be years before that  
propagates into all production kernels, particularly in some of the  
older distros we have in the buildfarm.  For now, let's just back off  
and not run this test on Linux PPC64; that loses nothing in test  
coverage so far as our own code is concerned.  
  
To do that, split this test into a new script infinite_recurse.sql  
and skip the test when the platform name is powerpc64...-linux-gnu.  
  
Back-patch to v12.  Branches before that have not been seen to get  
this failure.  No doubt that's because the "errors" test was not  
run in parallel with other tests before commit 798070ec0, greatly  
reducing the odds of an sinval catchup being necessary.  
  
I also back-patched 3c8553547 into v12, just so the new regression  
script would look the same in all branches having it.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/20190723162703.GM22387%40telsasoft.com  

commit   : 12945874ebd661b1748d2258d28f96adb473486b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Oct 2020 18:01:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Oct 2020 18:01:34 -0400    

gistRelocateBuildBuffersOnSplit did not get the memo about which  
attribute count to use.  This could lead to a crash if there were  
included columns and buffering build was chosen.  (Because there  
are random page-split decisions elsewhere in GiST index build,  
the crashes are not entirely deterministic.)  
  
Back-patch to v12 where GiST gained support for included columns.  
  
Pavel Borisov  
  
Discussion: https://postgr.es/m/CALT9ZEECCV5m7wvxg46PC-7x-EybUmnpupBGhSFMoAAay+r6HQ@mail.gmail.com  

commit   : f35c117700122cca2229b9a20a30d12a2ace7bfd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Oct 2020 13:31:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Oct 2020 13:31:24 -0400    

The prohibitValueChange code paths in set_config_option(), which  
are executed whenever we re-read a PGC_POSTMASTER variable from  
postgresql.conf, neglected to free anything before exiting.  Thus  
we'd leak the proposed new value of a PGC_STRING variable, as noted  
by BoChen in bug #16666.  For all variable types, if the check hook  
creates an "extra" chunk, we'd also leak that.  
  
These are malloc not palloc chunks, so there is no mechanism for  
recovering the leaks before process exit.  Fortunately, the values  
are typically not very large, meaning you'd have to go through an  
awful lot of SIGHUP configuration-reload cycles to make the leakage  
amount to anything.  Still, for a long-lived postmaster process it  
could potentially be a problem.  
  
Oversight in commit 2594cf0e8.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8b231d9753287fc16328af2ab31943b79e1cc8a3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Oct 2020 18:41:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Oct 2020 18:41:39 -0400    

It appears that commit cf63c641c, which intended to prevent  
misoptimization of the result-building step in makeOrderedSetArgs,  
didn't go far enough: buildfarm member hornet's version of xlc  
is now optimizing back to the old, broken behavior in which  
list_length(directargs) is fetched only after list_concat() has  
changed that value.  I'm not entirely convinced whether that's  
an undeniable compiler bug or whether it can be justified by a  
sufficiently aggressive interpretation of C sequence points.  
So let's just change the code to make it harder to misinterpret.  
  
Back-patch to all supported versions, just in case.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d8c2a2199867460ff65796be37eecff56426136b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Oct 2020 12:50:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Oct 2020 12:50:54 -0400    

Commit 3eb3d3e78 was a few bricks shy of a load: while it correctly  
set the table's "interesting" flag when deciding to dump the data of  
an extension config table, it was not correct to clear that flag  
if we concluded we shouldn't dump the data.  This led to the crash  
reported in bug #16655, because in fact we'll traverse dumpTableSchema  
anyway for all extension tables (to see if they have user-added  
seclabels or RLS policies).  
  
The right thing to do is to force "interesting" true in makeTableDataInfo,  
and otherwise leave the flag alone.  (Doing it there is more future-proof  
in case additional calls are added, and it also avoids setting the flag  
unnecessarily if that function decides the table is non-dumpable.)  
  
This investigation also showed that while only the --inserts code path  
had an obvious failure in the case considered by 3eb3d3e78, the COPY  
code path also has a problem with not having loaded table subsidiary  
data.  That causes fmtCopyColumnList to silently return an empty string  
instead of the correct column list.  That accidentally mostly works,  
which perhaps is why we didn't notice this before.  It would only fail  
if the restore column order is different from the dump column order,  
which only happens in weird inheritance cases, so it's not surprising  
nobody had hit the case with an extension config table.  Nonetheless,  
it's a bug, and it goes a long way back, not just to v12 where the  
--inserts code path started to have a problem with this.  
  
In hopes of catching such cases a bit sooner in future, add some  
Asserts that "interesting" has been set in both dumpTableData and  
dumpTableSchema.  Adjust the test case added by 3eb3d3e78 so that it  
checks the COPY rather than INSERT form of that bug, allowing it to  
detect the longer-standing symptom.  
  
Per bug #16655 from Cameron Daniel.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 77971bc4f2371ce25b87b105470a39d5f21815d1    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 6 Oct 2020 14:31:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 6 Oct 2020 14:31:21 -0400    

We only support upgrading from >= 8.4 so no need for this code or tests.  
  
Reported-by: Magnus Hagander  
  
Discussion: https://postgr.es/m/CABUevEx-D0PNVe00tkeQRGennZQwDtBJn=493MJt-x6sppbUxA@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : dc3953421b436981260ff3dc658e9a6c4c3f6ebe    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 6 Oct 2020 12:12:09 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 6 Oct 2020 12:12:09 -0400    

This makes checking for older major versions more consistent.  
  
Backpatch-through: 9.5  

commit   : 3d69efc4f07d773329dfbd39d6ec67a025cf7339    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Oct 2020 11:43:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Oct 2020 11:43:54 -0400    

This patch prevents crashes or wrong plans when partition-wise joins  
are considered during GEQO planning, as a consequence of the  
EquivalenceClass data structures becoming corrupt after a GEQO  
context reset.  
  
A remaining problem is that successive GEQO cycles will make multiple  
copies of the required EC members, since add_child_join_rel_equivalences  
has no idea that such members might exist already.  For now we'll just  
live with that.  The lack of field complaints of crashes suggests that  
this is a mighty little-used situation.  
  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9b8e6857b8170f09861baa1bfd074fa0c8af9cfd    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 5 Oct 2020 16:27:33 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 5 Oct 2020 16:27:33 -0400    

Previously it was unclear exactly how ROWS FROM behaved and how to cast  
the data types of columns returned by FROM functions.  Also document  
that only non-OUT record functions can have their columns cast to data  
types.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.5  

commit   : f05ca47132ddf58de463fd8396a44d7ccd06e123    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 5 Oct 2020 16:07:15 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 5 Oct 2020 16:07:15 -0400    

This is the first paragraph change of master-only commit 253f1025da.  
  
Backpatch-through: PG 12-13 only  

commit   : 1f94d76856bc7e473e300134e092eb231cba83fe    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Oct 2020 13:15:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Oct 2020 13:15:39 -0400    

get_eclass_for_sort_expr() computes expr_relids and nullable_relids  
early on, even though they won't be needed unless we make a new  
EquivalenceClass, which we often don't.  Aside from the probably-minor  
inefficiency, there's a memory management problem: these bitmapsets will  
be built in the caller's context, leading to dangling pointers if that  
is shorter-lived than root->planner_cxt.  This would be a live bug if  
get_eclass_for_sort_expr() could be called with create_it = true during  
GEQO join planning.  So far as I can find, the core code never does  
that, but it's hard to be sure that no extensions do, especially since  
the comments make it clear that that's supposed to be a supported case.  
Fix by not computing these values until we've switched into planner_cxt  
to build the new EquivalenceClass.  
  
generate_join_implied_equalities() uses inner_rel->relids to look up  
relevant eclasses, but it ought to be using nominal_inner_relids.  
This is presently harmless because a child RelOptInfo will always have  
exactly the same eclass_indexes as its topmost parent; but that might  
not be true forever, and anyway it makes the code confusing.  
  
The first of these is old (introduced by me in f3b3b8d5b), so back-patch  
to all supported branches.  The second only dates to v13, but we might  
as well back-patch it to keep the code looking similar across branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5856ed1099d9288a7cee20cff9f95831a96add1c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Oct 2020 20:45:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Oct 2020 20:45:06 -0400    

I noticed while trying to run the regression tests under a low  
geqo_threshold that one query on information_schema.columns had  
unstable (as in, variable from one run to the next) output order.  
This is pretty unsurprising given the complexity of the underlying  
plan.  Interestingly, of this test's three nigh-identical queries on  
information_schema.columns, the other two already had ORDER BY clauses  
guaranteeing stable output.  Let's make this one look the same.  
  
Back-patch to v10 where this test was added.  We've not heard field  
reports of the test failing, but this experience shows that it can  
happen when testing under even slightly unusual conditions.  

commit   : 62f6f11d9e2c53ce5b130c8cafe9e12870f1c81d    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 2 Oct 2020 22:19:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 2 Oct 2020 22:19:31 -0400    

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

commit   : 8075f3f2f8450e71941b418affe29f488277b006    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 2 Oct 2020 21:39:33 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 2 Oct 2020 21:39:33 -0400    

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

commit   : 6854c45b36aaf83378209168711bdef1ba99ec83    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Oct 2020 10:59:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Oct 2020 10:59:20 -0400    

Commit 151c0c5f7 neglected the possibility that a TEMP_CONFIG file  
would explicitly set max_wal_senders=0; as indeed buildfarm member  
thorntail does, so that it can test wal_level=minimal in other test  
suites.  Hence, rather than assuming that max_wal_senders=10 will  
prevail if we say nothing, set it explicitly.  
  
Set max_replication_slots=10 explicitly too, just to be safe.  
  
Back-patch to v10, like the previous patch.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : fb35798a88558875371d746a69099338c7241dcb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 1 Oct 2020 11:48:48 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 1 Oct 2020 11:48:48 +0300    

This has been wrong ever since the support for multi-dimensional  
arrays as PL/python function arguments and return values was  
introduced in commit 94aceed317.  
  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/61647b8e-961c-0362-d5d3-c8a18f4a7ec6%40iki.fi  

commit   : f669ba7bdb009c0ed5335aedc632c928c97b38af    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 30 Sep 2020 18:25:23 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 30 Sep 2020 18:25:23 -0300    

The error message about columns in the primary key not including all of  
the partition key was unclear; reword it.  
  
Backpatch all the way to pg11, where it appeared.  
  
Reported-by: Nagaraj Raj <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : c5232dca8d1bbe1cab4a2d6773566ff53146340b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 Sep 2020 15:40:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 Sep 2020 15:40:23 -0400    

Previously, a conversion such as  
	to_date('-44-02-01','YYYY-MM-DD')  
would result in '0045-02-01 BC', as the code attempted to interpret  
the negative year as BC, but failed to apply the correction needed  
for our internal handling of BC years.  Fix the off-by-one problem.  
  
Also, arrange for the combination of a negative year and an  
explicit "BC" marker to cancel out and produce AD.  This is how  
the negative-century case works, so it seems sane to do likewise.  
  
Continue to read "year 0000" as 1 BC.  Oracle would throw an error,  
but we've accepted that case for a long time so I'm hesitant to  
change it in a back-patch.  
  
Per bug #16419 from Saeed Hubaishan.  Back-patch to all supported  
branches.  
  
Dar Alathar-Yemen and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 5c7afb4a29aa0f75def751406b4004e7f047a7f3    
  
author   : David Rowley <[email protected]>    
date     : Wed, 30 Sep 2020 13:03:34 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 30 Sep 2020 13:03:34 +1300    

Explicitly mention that primary key constraints are also included in the  
limitation that the constraint columns must be a superset of the partition key  
columns.  
  
Wording suggestion from Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11, where unique constraints on partitioned tables were added  

commit   : 09b29ca82bc8be2e8b2f9ef74d12425b765b40ee    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Sep 2020 20:02:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Sep 2020 20:02:58 -0400    

PostgresNode.pm set "max_wal_senders = 5" for replication testing,  
but this seems to be slightly too low for our current test suite.  
Slower buildfarm members frequently report "number of requested standby  
connections exceeds max_wal_senders" failures, due to old walsenders  
not exiting instantaneously.  Usually, the test does not fail overall  
because of automatic walreceiver restart, but sometimes the failure  
becomes visible; and in any case such retries slow down the test.  
  
That value came in with commit 89ac7004d, but was soon obsoleted by  
f6d6d2920, which raised the built-in default from zero to 10; so that  
PostgresNode.pm is actually setting it to less than the conservative  
built-in default.  That seems pretty pointless, so let's remove the  
special setting and let the default prevail, in hopes of making  
the TAP tests more robust.  
  
Likewise, the setting "max_replication_slots = 5" is obsolete and  
can be removed.  
  
While here, reverse-engineer a comment about why we're choosing  
less-than-default values for some other settings.  
  
(Note: before v12, max_wal_senders counted against max_connections  
so that the latter setting also needs some fiddling with.)  
  
Back-patch to v10 where the subscription tests were added.  
It's likely that the older branches aren't pushing the boundaries  
of max_wal_senders, but I'm disinclined to spend time trying to  
figure out exactly when it started to be a problem.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c1e044bb30f26edf54b7d5f668d18b69a0bb3ea6    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Sep 2020 11:18:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Sep 2020 11:18:31 -0400    

When executing a CALL or DO in a non-atomic context (i.e., not inside  
a function or query), plpgsql creates a new plan each time through,  
as a rather hacky solution to some resource management issues.  But  
it failed to free this plan until exit of the current procedure or DO  
block, resulting in serious memory bloat in procedures that called  
other procedures many times.  Fix by remembering to free the plan,  
and by being more honest about restoring the previous state (otherwise,  
recursive procedure calls have a problem).  
  
There was also a smaller leak associated with recalculation of the  
"target" list of output variables.  Fix that by using the statement-  
lifespan context to hold non-permanent values.  
  
Back-patch to v11 where procedures were introduced.  
  
Pavel Stehule and Tom Lane  
  
Discussion: https://postgr.es/m/CAFj8pRDiiU1dqym+_P4_GuTWm76knJu7z9opWayBJTC0nQGUUA@mail.gmail.com  

commit   : 4d342b9d41533df94b1b637d814333a716ec1050    
  
author   : Fujii Masao <[email protected]>    
date     : Tue, 29 Sep 2020 16:21:46 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Tue, 29 Sep 2020 16:21:46 +0900    

Previously the standby server didn't archive timeline history files  
streamed from the primary even when archive_mode is set to "always",  
while it archives the streamed WAL files. This could cause the PITR to  
fail because there was no required timeline history file in the archive.  
The cause of this issue was that walreceiver didn't mark those files as  
ready for archiving.  
  
This commit makes walreceiver mark those streamed timeline history  
files as ready for archiving if archive_mode=always. Then the archiver  
process archives the marked timeline history files.  
  
Back-patch to all supported versions.  
  
Reported-by: Grigory Smolkin  
Author: Grigory Smolkin, Fujii Masao  
Reviewed-by: David Zhang, Anastasia Lubennikova  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8aa4496dd3ae91d897a89bed9884d94102357dd4    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 29 Sep 2020 14:16:18 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 29 Sep 2020 14:16:18 +0900    

This addresses a couple of issues with the so-said subject:  
- Report the correct parent relation with the index actually being  
rebuilt or validated.  Previously, the command status remained set to  
the last index created for the progress of the index build and  
validation, which would be incorrect when working on a table that has  
more than one index.  
- Use the correct phase when waiting before the drop of the old  
indexes.  Previously, this was reported with the same status as when  
waiting before the old indexes are marked as dead.  
  
Author: Matthias van de Meent, Michael Paquier  
Discussion: https://postgr.es/m/CAEze2WhqFgcwe1_tv=sFYhLWV2AdpfukumotJ6JNcAOQs3jufg@mail.gmail.com  
Backpatch-through: 12  

commit   : 29f20db85ed220f075fe8181bac49269611f13cb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Sep 2020 14:12:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Sep 2020 14:12:38 -0400    

Failure to do this can result in errors during evaluation of  
the bound expression, as illustrated by the new regression test.  
  
Back-patch to v12 where the ability for partition bounds to be  
expressions was added.  
  
Discussion: https://postgr.es/m/CAJV4CdrZ5mKuaEsRSbLf2URQ3h6iMtKD=hik8MaF5WwdmC9uZw@mail.gmail.com  

commit   : bda32733ceeb0687ee5a1e734005270b1dee66a7    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Sep 2020 16:04:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Sep 2020 16:04:06 -0400    

This function leaked some memory while loading qual clauses for  
an RLS policy.  While ordinarily negligible, that could build up  
in some repeated-reload cases, as reported by Konstantin Knizhnik.  
We can improve matters by borrowing the coding long used in  
RelationBuildRuleLock: build stringToNode's result directly in  
the target context, and remember to explicitly pfree the  
input string.  
  
This patch by no means completely guarantees zero leaks within  
this function, since we have no real guarantee that the catalog-  
reading subroutines it calls don't leak anything.  However,  
practical tests suggest that this is enough to resolve the issue.  
In any case, any remaining leaks are similar to those risked by  
RelationBuildRuleLock and other relcache-loading subroutines.  
If we need to fix them, we should adopt a more global approach  
such as that used by the RECOVER_RELATION_BUILD_MEMORY hack.  
  
While here, let's remove the need for an expensive PG_TRY block by  
using MemoryContextSetParent to reparent an initially-short-lived  
context for the RLS data.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : fb93f784fc9c31f12361462653d325fdce01207d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Sep 2020 18:19:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Sep 2020 18:19:38 -0400    

Parallel pg_dump failed if its -d parameter was a connection string  
containing any essential information other than host, port, or username.  
The same was true for pg_restore with --create.  
  
The reason is that these scenarios failed to preserve the connection  
string from the command line; the code felt free to replace that with  
just the database name when reconnecting from a pg_dump parallel worker  
or after creating the target database.  By chance, parallel pg_restore  
did not suffer this defect, as long as you didn't say --create.  
  
In practice it seems that the error would be obvious only if the  
connstring included essential, non-default SSL or GSS parameters.  
This may explain why it took us so long to notice.  (It also makes  
it very difficult to craft a regression test case illustrating the  
problem, since the test would fail in builds without those options.)  
  
Fix by refactoring so that ConnectDatabase always receives all the  
relevant options directly from the command line, rather than  
reconstructed values.  Inject a different database name, when necessary,  
by relying on libpq's rules for handling multiple "dbname" parameters.  
  
While here, let's get rid of the essentially duplicate _connectDB  
function, as well as some obsolete nearby cruft.  
  
Per bug #16604 from Zsolt Ero.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7664cc869aba2ca116eb04d9b86fc88f24084836    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 24 Sep 2020 09:26:09 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 24 Sep 2020 09:26:09 +1200    

Harmonize behavior by moving reponsibility for fsyncing directories down  
into slru.c.  In 10 and later, only the multixact directories were  
missed (see commit 1b02be21), and in older branches all SLRUs were  
missed.  
  
Back-patch to all supported releases.  
  
Reviewed-by: Andres Freund <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://postgr.es/m/CA%2BhUKGLtsTUOScnNoSMZ-2ZLv%2BwGh01J6kAo_DM8mTRq1sKdSQ%40mail.gmail.com  

commit   : 5d0c80658328aa654864ce4e0d0b4031fda0ddd5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Sep 2020 11:36:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Sep 2020 11:36:13 -0400    

tsearch_readline() saves the string pointer it returns to the caller  
for possible use in the associated error context callback.  However,  
the caller will usually pfree that string sometime before it next  
calls tsearch_readline(), so that there is a window where an ereport  
will try to print an already-freed string.  
  
The built-in users of tsearch_readline() happen to all do that pfree  
at the bottoms of their loops, so that the window is effectively  
empty for them.  However, this is not documented as a requirement,  
and contrib/dict_xsyn doesn't do it like that, so it seems likely  
that third-party dictionaries might have live bugs here.  
  
The practical consequences of this seem pretty limited in any case,  
since production builds wouldn't clobber the freed string immediately,  
besides which you'd not expect syntax errors in dictionary files  
being used in production.  Still, it's clearly a bug waiting to bite  
somebody.  
  
Fix by pstrdup'ing the string to be saved for the error callback,  
and then pfree'ing it next time through.  It's been like this for  
a long time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 11071da39e3969430b9c24ff792d806317e8d736    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 20 Sep 2020 14:41:28 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 20 Sep 2020 14:41:28 +0200    

commit   : 1af91dc032cfc3f1e47d3bbb976ad6c880668bad    
  
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   : 4bc63462d9d8dd12a5564c3d4ca06c99449d2d07    
  
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   : 511690ec5dccd7c93573367c2920e8f0919c901b    
  
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   : 8580631ff77c5bb29d0b9fed8a38ee461872e86a    
  
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   : af2d09fa1c28216286649d519f4aca3ebbd5399a    
  
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   : 1371a1e4161a25a128b666109ac5a9d449da982a    
  
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   : 6a8f6aee0cbea617df90fe3b715d6dd73e0f8c04    
  
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   : 4e10c0c8a6690d9b950a0ab1633de6c02d1a1069    
  
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   : 697c8e620443ca15b834f46e66d682dc9ce5c191    
  
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   : 059872cea147617f688d314664df99d73a9c407e    
  
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   : 25ff747721a5f4d386127528f50fd81d6cea365a    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 10 Sep 2020 15:50:46 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 10 Sep 2020 15:50:46 +0900    

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

commit   : d038c6c6318b1959640a5a4b0f25cd577ebffbdf    
  
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   : ef1e1250e716056a240ecabc6f2a91c5956ed6c8    
  
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   : 87483c7bb32059f203a3fa36b4ffa9070970fa03    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 7 Sep 2020 14:35:17 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 7 Sep 2020 14:35:17 +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   : f45dd3fed9cf7d336af08b53a1f73bf90c88fb1a    
  
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   : a7bcf391f329561307a3d936443a715ad74a2e9d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Sep 2020 11:50:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Sep 2020 11:50:41 -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   : fc37c6f6105a594467eb8922eb6d47e0d156ab21    
  
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   : 9b47ee6e7cba30701b4e11b872455461460650c4    
  
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   : 616110eac3b5d939954391c5e9330ce9432502e4    
  
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   : 56f42cf9063d3ddf89962857d30a15d7ac49ce97    
  
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   : aa4eeb38f3aa3e4ebde4abb6edc79dd530ecda79    
  
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   : 82dd373f2c56f7b32a3304260195fdaf6ed7cd9c    
  
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   : fcc42756818cef68e61e35e6d71cac6a73e24bb9    
  
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   : e3646325f4b6ca78c0a4234bf978cfda53721e4d    
  
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   : 7067ba1b4b905046819368e787809c5df0ebef04    
  
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   : 55aea0c706caa1d69dd550303ebefc310be4672c    
  
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   : 3fb67ac9c65b31ae179a80662b6bed0b00bba248    
  
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   : b1f52817bcdc3a6d269d4bd9b4d02a635e5d39c3    
  
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   : 9774d9c777ba56b8a46357303aeb8e7d94420011    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:36:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 17:36:22 -0400    

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

commit   : 2bf1bec585972e16daa9104db08531d3b32ada54    
  
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   : 02fb7eef91df41fab9c68cc73e6ec9f22c060981    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 16:59:58 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 31 Aug 2020 16:59:58 -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   : 01bcfe705d69e0b9b50c752742a79bb88bdc72ff    
  
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   : 0d447ba962bbaa40f9d47d563086f1debf562b20    
  
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   : 2f8ea9116b17036400b71ec95923990e9fa833cf    
  
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   : ac736e43aa70dfb3da99e8d12349b801229aa2bc    
  
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   : 5277f493dde7de00250d33a8ea79a5b93ee89dae    
  
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   : 73952310bfcd4ebcffa3db7137d0b705f1bfdae2    
  
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   : 9dee85b5b83310598c66efc9322ed6792c77fa78    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 30 Aug 2020 16:03:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 30 Aug 2020 16:03:19 -0400    

Back-patch key parts of 4c5cf5431 and 6ca547cf7 into stable branches.  
I didn't touch pg_description entries here, so it's purely a docs  
change; and I didn't fool with any examples either.  The main point  
is so that anyone who's wondering if factorial() exists in the stable  
branches will be reassured.  
  
Mark Dilger and John Naylor, with some adjustments by me  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ff3c16d1e751d8a7dfc753c3871d01ce8cf36089    
  
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   : fa3bd8d853edd0f47523f8f0ce3bc74d21cf05f7    
  
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   : 4534a1e81039866f1a0c4326e0458031a8ef483e    
  
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   : 6b701eaaa90e07035f9a965d7ca9831d01586c63    
  
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   : 2060f0064e856ed0648ef2a77cda085d35837bca    
  
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   : 90f6435f672c7de92220a92084fcbef99f95bb4e    
  
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   : d9253df12e4c06a54e515136b115538c56eace56    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 21 Aug 2020 15:00:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 21 Aug 2020 15:00:43 -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   : 3248633579e9ed1c718afa70bb93d499fe85d40c    
  
author   : David Rowley <[email protected]>    
date     : Fri, 21 Aug 2020 09:35:24 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 21 Aug 2020 09:35:24 +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   : da9ec328dda9625725ae8210ad6e6599ab876206    
  
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   : 814a57065ec97e44de58db61a16957ddd09938e8    
  
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   : aecefffc3f8041c883ab4fb035cf0d5519b5a7ed    
  
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   : 4f47c8e7d438a0ae8ea631cd0c3b92db5593901d    
  
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   : 314f65716c37d515979eb2f06430b18bb7a09a0d    
  
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   : 9f44d71b06b0d457ad3e5d7fdcbba2039f3000ef    
  
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   : 29bd2cbe36bd3549a6a81df6e5dab172f43ef033    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Aug 2020 10:24:31 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Aug 2020 10:24:31 +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   : 06e50d8f7eee9a0b42c8392b75e0780c0a30fa84    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 15 Aug 2020 16:15:59 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 15 Aug 2020 16:15:59 -0700    

Several PGXN modules reference LockTagType values; renumbering would  
force a recompile of those modules.  Oversight in back-patch of today's  
commit 566372b3d6435639e4cc4476d79b8505a0297c87.  Back-patch to released  
branches, v12 through 9.5.  
  
Reported by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 30e68a2abb3890c3292ff0b2422a7ea04d62acdd    
  
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   : 912fb290c5dd087ccc4b04c19692137bb786a9fd    
  
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]