PostgreSQL 13.1 commit log

commit   : 6daf725a9c66e880fd76d25279ce00710535e030    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 17:24:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Nov 2020 17:24:30 -0500    

commit   : 90cf59c8c8c66c8b0b4c719b6f7ba8fce60b87e1    
  
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   : f47841fbad8a7f6dd579db68d782857697ad25c6    
  
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   : 67029845b08d93108d53f572e2d58334c850126f    
  
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   : c90c84b3f797a54a40ebc6795fbd743bdf44adad    
  
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   : 62e7ae75f441e7c91f446b05f5b206fe01e34f0c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 9 Nov 2020 12:34:05 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 9 Nov 2020 12:34:05 +0100    

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

commit   : 7d94c017b94577548a0656b2aef7ce8be18fbc1b    
  
author   : Magnus Hagander <[email protected]>    
date     : Mon, 9 Nov 2020 10:36:49 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Mon, 9 Nov 2020 10:36:49 +0100    

Appears to have been a copy/paste error in the original commit that  
moved the messages to fe_utils/.  
  
Author: Tang, Haiying <[email protected]>  
Backpatch-through: 13  
Discussion: https://postgr.es/m/3321cbcea76d4d2c8320a05c19b9304a@G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 213774a45b9259ea797cd6b5e1e9a74bd7d12d28    
  
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   : 7aeb6404f0aa250e75b7156d21ebe12d0ec2d1c8    
  
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   : 5ca6f685b834518187b15926d196c5dbb086efe7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 8 Nov 2020 07:49:07 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 8 Nov 2020 07:49:07 +0100    

fix for f3ad4fddfaf71e8f6f037cd627f398ba43625ca1  

commit   : 99f9384ea91761cdb957d051b0ca64179320b2ed    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sat, 7 Nov 2020 19:33:43 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sat, 7 Nov 2020 19:33:43 -0300    

* Avoid pointlessly highlighting that an index vacuum was executed by a  
  parallel worker; user doesn't care.  
  
* Don't give the impression that a non-concurrent reindex of an invalid  
  index on a TOAST table would work, because it wouldn't.  
  
* Add a "translator:" comment for a mysterious message.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Michael Paquier <[email protected]>  

commit   : f3ad4fddfaf71e8f6f037cd627f398ba43625ca1    
  
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   : 3459f4169ba9665fbc7965165ec4ef83170b748b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 Nov 2020 16:25:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 Nov 2020 16:25:42 -0500    

The buildfarm thinks this leads to memory stomps, though annoyingly  
I can't duplicate that here.  The existing code in strings.pgc is  
doing something that doesn't seem to be sanctioned at all really  
by the documentation, but I'm disinclined to try to make that nicer  
right now.  Let's just declare some more output variables in hopes  
of working around it.  

commit   : 7fb326e04b5c367f03b2ebb85348e79a722afef9    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 Nov 2020 15:27:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 Nov 2020 15:27:36 -0500    

Add items committed in the last 24 hours.  Also correct my failure  
to credit Nikita Glukhov for 52ad1e659, which did all the heavy  
lifting for 3db322eaa.  

commit   : 1bccb159af5813b8f34fd177acdbdb2ad82cd596    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 Nov 2020 15:03:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 Nov 2020 15:03:44 -0500    

These were broken in multiple ways:  
  
* The xbstart and xhstart lexer actions neglected to set  
"state_before_str_start" before transitioning to the xb/xh states,  
thus possibly resulting in "internal error: unreachable state" later.  
  
* The test for valid string contents at the end of xb state was flat out  
wrong, as it accounted incorrectly for the "b" prefix that the xbstart  
action had injected.  Meanwhile, the xh state had no such check at all.  
  
* The generated literal value failed to include any quote marks.  
  
* The grammar did the wrong thing anyway, typically ignoring the  
literal value and emitting something else, since BCONST and XCONST  
tokens were handled randomly differently from SCONST tokens.  
  
The first of these problems is evidently an oversight in commit  
7f380c59f, but the others seem to be very ancient.  The lack of  
complaints shows that ECPG users aren't using these syntaxes much  
(although I do vaguely remember one previous complaint).  
  
As written, this patch is dependent on 7f380c59f, so it can't go  
back further than v13.  Given the shortage of complaints, I'm not  
excited about adapting the patch to prior branches.  
  
Report and patch by Shenhao Wang (test case adjusted by me)  
  
Discussion: https://postgr.es/m/d6402f1bacb74ecba22ef715dbba17fd@G08CNEXMBPEKD06.g08.fujitsu.local  

commit   : d94d37f8c0c77cf1b9c5ae924bb6cfc12f4bc692    
  
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   : 6a7b55f3716fad9c40ecb960cb7b7d616d5b02fd    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 7 Nov 2020 00:40:06 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 7 Nov 2020 00:40:06 +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   : c66a3225e07b5098a796f24588a6b81bfdedd2fd    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 17:05:43 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 17:05:43 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  
  
Also as usual for a .1 release, there are some entries here that  
are not really relevant for v13 because they already appeared in 13.0.  
Those'll be removed later.  

commit   : 4352c2394a547e5797c512cbaf0d0b7ca824747a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 16:17:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Nov 2020 16:17:56 -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   : fa3840c8800f290b8352c5c81714a4439d2e1f46    
  
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   : 44b973b91029cb5aecf09d589bdf3f05cfddaa60    
  
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   : 02c9386ca4f706364904be2720e2d09916e2b619    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 4 Nov 2020 18:42:24 -0800    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 4 Nov 2020 18:42:24 -0800    

Logic for counting heap TIDs from posting list tuples (added by commit  
0d861bbb) was faulty.  It didn't count any TIDs/index tuples in the  
event of no callback being set.  This meant that we incorrectly counted  
no index tuples in clean-up only VACUUMs, which could lead to  
pg_class.reltuples being spuriously set to 0 in affected indexes.  
  
To fix, go back to counting items from the page in cases where there is  
no callback.  This approach isn't very accurate, but it works well  
enough in practice while avoiding the expense of accessing every index  
tuple during cleanup-only VACUUMs.  
  
Author: Peter Geoghegan <[email protected]>  
Reported-By: Jehan-Guillaume de Rorthais <[email protected]>  
https://postgr.es/m/20201023174451.69e358f1@firost  
Backpatch: 13-, where nbtree deduplication was introduced  

commit   : 82d4a2a7d63e79f6a6724f366cfaa4beed6b8326    
  
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   : 7d39586a59c6f5816a068bd38e1e4887d4c984ff    
  
author   : Tomas Vondra <[email protected]>    
date     : Tue, 3 Nov 2020 20:43:12 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Tue, 3 Nov 2020 20:43:12 +0100    

Commit 6ee3b5fb99 cleaned up most of the long/int64 confusion related to  
incremental sort, but the sort debug messages were still using %ld for  
int64 variables. So fix that.  
  
Author: Haiying Tang  
Backpatch-through: 13, where the incremental sort code was added  
Discussion: https://postgr.es/m/4250be9d350c4992abb722a76e288aef%40G08CNEXMBPEKD05.g08.fujitsu.local  

commit   : 2d26c4ac703447a002a02124c1edd01e70a5d1ee    
  
author   : Tomas Vondra <[email protected]>    
date     : Tue, 3 Nov 2020 20:07:23 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Tue, 3 Nov 2020 20:07:23 +0100    

When considering Incremental Sort below a Gather Merge, we need to be  
a bit more careful when matching pathkeys to EC members. It's not enough  
to find a member whose Vars are all in the current relation's target;  
volatile expressions in particular need to be contained in the target,  
otherwise it's too early to use the pathkey.  
  
Reported-by: Jaime Casanova  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Backpatch-through: 13, where the incremental sort code was added  
Discussion: https://postgr.es/m/CAJGNTeNaxpXgBVcRhJX%2B2vSbq%2BF2kJqGBcvompmpvXb7pq%2BoFA%40mail.gmail.com  

commit   : 936043c9eacb9e9c7356a8190a410d2c4e4ea03a    
  
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   : 768dbef0d49826c2e404ceb1567b3cc9e2bbc30a    
  
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   : 53977598174652dcb06bc2b26674c29b9ae601cc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 3 Nov 2020 15:14:50 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 3 Nov 2020 15:14:50 +0100    

The current implementation cannot handle this correctly, so just  
forbid it for now.  
  
GENERATED clauses must be attached to the column definition and cannot  
be added later like DEFAULT, so if a child table has a generation  
expression that the parent does not have, the child column will  
necessarily be an attlocal column.  So to implement ALTER TABLE ONLY /  
DROP EXPRESSION, we'd need extra code to update attislocal of the  
direct child tables, somewhat similar to how DROP COLUMN does it, so  
that the resulting state can be properly dumped and restored.  
  
Discussion: https://www.postgresql.org/message-id/flat/15830.1575468847%40sss.pgh.pa.us  

commit   : a58a631b4af0c027c07ea7cc4110a60b5f279ddf    
  
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   : 7957e75c588c0b17210d4379afb50ea2673b0d20    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Nov 2020 11:25:18 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Nov 2020 11:25:18 -0500    

On detecting a corrupted match tag, pglz_decompress() should just  
summarily return -1.  Breaking out of the loop, as I did in dfc797730,  
doesn't quite guarantee that will happen.  Also, we can use  
unlikely() on that check, just in case it helps.  
  
Backpatch to v13, like the previous patch.  

commit   : 57fae192f8f7d094159c913f10fcfd11cd827332    
  
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   : 796885a0713374f7bdcc3edec136e0527fcafafa    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 15:15:20 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 15:15:20 +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   : 017e78a3edc261143c7d791cafca5a5ad326a679    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 10:41:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 2 Nov 2020 10:41:23 +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   : 2330f4d3a87ac43b6ecd31bfd698384888ed03cb    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Nov 2020 18:38:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Nov 2020 18:38:42 -0500    

pglz_maximum_compressed_size() potentially underestimated the amount  
of compressed data required to produce N bytes of decompressed data;  
this is a fault in commit 11a078cf8.  
  
Separately from that, pglz_decompress() failed to protect itself  
against corrupt compressed data, particularly off == 0 in a match  
tag.  Commit c60e520f6 turned such a situation into an infinite loop,  
where before it'd just have resulted in garbage output.  
  
The combination of these two bugs seems like it may explain bug #16694  
from Tom Vijlbrief, though it's impossible to be quite sure without  
direct inspection of the failing session.  (One needs to assume that  
the pglz_maximum_compressed_size() bug caused us to fail to fetch the  
second byte of a match tag, and what happened to be there instead was  
a zero.  The reported infinite loop is hard to explain without off == 0,  
though.)  
  
Aside from fixing the bugs, rewrite associated comments for more  
clarity.  
  
Back-patch to v13 where both these commits landed.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0041941f5bbe48ff3a05942efc6aa65f4f389efc    
  
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   : bb62df46bcaa109d5eb1907392034024dde0886e    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 1 Nov 2020 21:24:10 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 1 Nov 2020 21:24:10 +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   : ab2e2ce466683b6af5ec956106cd905380d3d349    
  
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   : ee03baad267dd83fa66a0ca4c1a7635f549fc1a6    
  
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   : ba4f5413e357faac2f33cd5d22db2a21c0be7727    
  
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   : 70492195be5e0283cf134c3c531ca0a23fdf9919    
  
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   : b4395cc87ed5c49e0b9bfd0770383d4086fd9f12    
  
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   : 64fc3e03495162154797f7d01e871462b1f42979    
  
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   : 272bff6a35ef85b0226ac536c58ca24881c3c8d2    
  
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   : d04c4a8f7066bdac71d012fa868ba9d84538632e    
  
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   : a645c08838d6d4ae55ac4df57cfd91f0b9e4f812    
  
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   : 4747655111b0bae6e45729ee4b06156ea6c40a77    
  
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   : d88d8ad28484a745fffe036a4085f4674b3064bc    
  
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   : 563973bf066893b9386c1d026433708797361575    
  
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   : fd048e0cb5aa45ef67b5b2b0446f4b1b6bdefbf3    
  
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   : e4538708d58400c8c0336ebabca0b7bdb72e0ff6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Oct 2020 11:32:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Oct 2020 11:32:33 -0400    

The ExplainCloseGroup arguments for incremental sort usage data  
didn't match the corresponding ExplainOpenGroup.  This only matters  
for XML-format output, which is probably why we'd not noticed.  
  
Daniel Gustafsson, per bug #16683 from Frits Jalvingh  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 96ed2ae9360d9b89f695f00c2b6417c4e4d9fcba    
  
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   : 0e551533b46069ec3b909ce5159eed51b768ca52    
  
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   : 2e4af411075c10c5007eb09bcb67abf7f825572d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Oct 2020 16:18:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Oct 2020 16:18:40 -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   : ddc728d437a08c68638101ef01d742d6f4476675    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 21 Oct 2020 14:37:26 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 21 Oct 2020 14:37:26 -0300    

Should cause tests to be a bit faster  

commit   : 5f6463a20af183db10d372f16ddeb5690a92aa1b    
  
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   : 1f53d0b9f45521a85e85b6dcab7c15a7d8b4b973    
  
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   : 0a1377760bcdfe837ea5f602a800ea97c668bf16    
  
author   : Amit Kapila <[email protected]>    
date     : Tue, 20 Oct 2020 08:31:43 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Tue, 20 Oct 2020 08:31:43 +0530    

In v13, the id for max_parallel_maintenance_workers is defined differently  
as compared to HEAD in docs, so adjust the docs accordingly.  
  
Reported-by: Magnus Hagander and Tom Lane  
Discussion: https://postgr.es/m/CABUevEyAFQZ_jvjY_KtRUWbci4YMyQC1QAMzDQAbLs=XCo3m5Q@mail.gmail.com  

commit   : 1814f915b526d5022b3e2a6ce4ea3bcbe59abe2c    
  
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   : 25378db74fd97f2b10ad44d1f0b2e1f8b0a651f2    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Oct 2020 14:33:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Oct 2020 14:33:02 -0400    

Since commit 913bbd88d, check_sql_fn_retval() can either insert type  
coercion steps in-line in the Query that produces the SQL function's  
results, or generate a new top-level Query to perform the coercions,  
if modifying the Query's output in-place wouldn't be safe.  However,  
it appears that the latter case has never actually worked, because  
the code tried to inject the new Query back into the query list it was  
passed ... which is not the list that will be used for later processing  
when we execute the SQL function "normally" (without inlining it).  
So we ended up with no coercion happening at run-time, leading to  
wrong results or crashes depending on the datatypes involved.  
  
While the regression tests look like they cover this area well enough,  
through a huge bit of bad luck all the test cases that exercise the  
separate-Query path were checking either inline-able cases (which  
accidentally didn't have the bug) or cases that are no-ops at runtime  
(e.g., varchar to text), so that the failure to perform the coercion  
wasn't obvious.  The fact that the cases that don't work weren't  
allowed at all before v13 probably contributed to not noticing the  
problem sooner, too.  
  
To fix, get rid of the separate "flat" list of Query nodes and instead  
pass the real two-level list that is going to be used later.  I chose  
to make the same change in check_sql_fn_statements(), although that has  
no actual bug, just so that we don't need that data structure at all.  
  
This is an API change, as evidenced by the adjustments needed to  
callers outside functions.c.  That's a bit scary to be doing in a  
released branch, but so far as I can tell from a quick search,  
there are no outside callers of these functions (and they are  
sufficiently specific to our semantics for SQL-language functions that  
it's not apparent why any extension would need to call them).  In any  
case, v13 already changed the API of check_sql_fn_retval() compared to  
prior branches.  
  
Per report from pinker.  Back-patch to v13 where this code came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 33acc6bc8795d8e3c2802c78e17e57a75a143904    
  
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   : 3b5bf7b893fc70d298881cff14f7f0c82d8fee34    
  
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   : f0b3d3bb89ae34281edc49de24f865af85671a37    
  
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   : d2074daebe1699f0d48fa63f6ba196b6426023ad    
  
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   : f2f03f9bb10b0749eddea5ad1dd730926421f090    
  
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   : d49357c0dc51378aeded51ecb8a290d761ac5b8c    
  
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   : 33a332bc1cff27c5138fe117ae56b6a6f476f30c    
  
author   : David Rowley <[email protected]>    
date     : Tue, 20 Oct 2020 00:06:40 +1300    
  
committer: David Rowley <[email protected]>    
date     : Tue, 20 Oct 2020 00:06:40 +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   : 99ae342fc4ffe5f9a6ec7f540c5a31fb483b06e6    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 19 Oct 2020 09:34:04 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 19 Oct 2020 09:34:04 +0530    

The rules to choose the number of parallel workers to perform parallel  
vacuum operation were not clearly specified.  
  
Reported-by: Peter Eisentraut  
Author: Amit Kapila  
Backpatch-through: 13, where it was introduced  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1bd9b2b2369608de7763b3947af2f59292152268    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 19 Oct 2020 09:37:50 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 19 Oct 2020 09:37:50 +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   : d317fd7570ca69553eef9a9ec1825967c2680927    
  
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   : 3f26dca76343d2e4aca5e2070875c93057925dca    
  
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   : e0cf5e9b226aae3df8ab8df7f5f7c8fe295be24e    
  
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   : 3d338a46a4c342fa1a4e276e0c84532141f4264b    
  
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   : 2cde0fd6fcaf70a8cf59972c36e86c00cc97e90c    
  
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   : efc9a8e9800cc04ff7460c3c78f9dc2120f3aea6    
  
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   : 79fe23465d56e7a3e649fd95bdb4e8b0af27a376    
  
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   : 59cfff65b10036b637a3f6e50d8f654e855d3b69    
  
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   : ae3e75abab222519aef90eb130d93c1ea745ac2e    
  
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   : 264e517e68190767de7cd50734956db02c6dbef1    
  
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   : 9f783aea669f56c2e7c875ee1391949f234a2257    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 15 Oct 2020 09:48:36 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 15 Oct 2020 09:48:36 -0300    

Rather than looking for tablesync workers, it is more reliable to see  
the sync state of the tables.  
  
Per note from Amit Kapila.  
Discussion: https://postgr.es/m/CAA4eK1JSSD7FVwq+_rOme86jUZTQFzjsNU06hQ4-LiRt1xFmSg@mail.gmail.com  

commit   : 47522ee00ddbe77280e4c063605b443ec1de3881    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 15 Oct 2020 18:23:30 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 15 Oct 2020 18:23:30 +1300    

While registering for postmaster exit events, we have to handle a couple  
of edge cases where the postmaster is already gone.  Commit 815c2f09  
missed one: EACCES must surely imply that PostmasterPid no longer  
belongs to our postmaster process (or alternatively an unexpected  
permissions model has been imposed on us).  Like ESRCH, this should be  
treated as a WL_POSTMASTER_DEATH event, rather than being raised with  
ereport().  
  
No known problems reported in the wild.  Per code review from Tom Lane.  
Back-patch to 13.  
  
Reported-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/3624029.1602701929%40sss.pgh.pa.us  

commit   : 53c07dbbf36855a4f5b11654106654b18e00ee15    
  
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   : 72e43fc313e93c95704c574bcf98805805668063    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 14 Oct 2020 20:12:26 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 14 Oct 2020 20:12:26 -0300    

I removed the duplicate command tags for START_REPLICATION inadvertently  
in commit 07082b08cc5d, but the replication protocol requires them.  The  
fact that the replication protocol was broken was not noticed because  
all our test cases use an optimized code path that exits early, failing  
to verify that the behavior is correct for non-optimized cases.  Put  
them back.  
  
Also document this protocol quirk.  
  
Add a test case that shows the failure.  It might still succeed even  
without the patch when run on a fast enough server, but it suffices to  
show the bug in enough cases that it would be noticed in buildfarm.  
  
Author: Álvaro Herrera <[email protected]>  
Reported-by: Henry Hinze <[email protected]>  
Reviewed-by: Petr Jelínek <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : e0950135ae5d50140feecc7bc87c018019c6e406    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 15 Oct 2020 11:31:20 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 15 Oct 2020 11:31:20 +1300    

If WaitEventSetWait() reports that the postmaster has gone away, later  
calls to WaitEventSetWait() should continue to report that.  Otherwise  
further waits that occur in the proc_exit() path after we already  
noticed the postmaster's demise could block forever.  
  
Back-patch to 13, where the kqueue support landed.  
  
Reported-by: Tom Lane <[email protected]>  
Discussion: https://postgr.es/m/3624029.1602701929%40sss.pgh.pa.us  

commit   : 855b6f287100f3eab24df0a83998db251ac4fd09    
  
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   : 962ab473ec3d4c1090ba75fa677167126956c1ee    
  
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   : 9343bfefa4514e5623cfc2610c44e3d93d776e64    
  
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   : 5efa788e1d070dd14cb94a8e087184dda36dc3ea    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    

The implementation uses smaller code when the "expected" operand is a  
small constant, but the implementation needlessly defined the set of  
acceptable constants more narrowly than the ABI does.  Core PostgreSQL  
and PGXN don't use the constant path at all, so this is future-proofing.  
Back-patch to v13, where commit 30ee5d17c20dbb282a9952b3048d6ad52d56c371  
introduced this code.  
  
Reviewed by Tom Lane.  Reported by Christoph Berg.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d41cb63ff4d114d856837fbf61ba2872c5076ac2    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 11 Oct 2020 21:31:37 -0700    

While xlc defines __64BIT__, gcc does not.  Due to this oversight in  
commit 30ee5d17c20dbb282a9952b3048d6ad52d56c371, gcc builds continued  
implementing 64-bit atomics by way of intrinsics.  Back-patch to v13,  
where that commit first appeared.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : dc14aa038e20d0287a569c36498da9469fe9d4e3    
  
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   : 5ed20a689e3d5d47a70b971f388e9da2a996dea9    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Oct 2020 17:10:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Oct 2020 17:10:26 -0400    

The date-vs-timestamp, date-vs-timestamptz, and timestamp-vs-timestamptz  
comparators all worked by promoting the first type to the second and  
then doing a simple same-type comparison.  This works fine, except  
when the conversion result is out of range, in which case we throw an  
entirely avoidable error.  The sources of such failures are  
(a) type date can represent dates much farther in the future than  
the timestamp types can;  
(b) timezone rotation might cause a just-in-range timestamp value to  
become a just-out-of-range timestamptz value.  
  
Up to now we just ignored these corner-case issues, but now we have  
an actual user complaint (bug #16657 from Huss EL-Sheikh), so let's  
do something about it.  
  
It turns out that commit 52ad1e659 already built all the necessary  
infrastructure to support error-free comparisons, but neglected to  
actually use it in the main-line code paths.  Fix that, do a little  
bit of code style review, and remove the now-duplicate logic in  
jsonpath_exec.c.  
  
Back-patch to v13 where 52ad1e659 came in.  We could take this back  
further by back-patching said infrastructure, but given the small  
number of complaints so far, I don't feel a great need to.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2ea624b4b51caa0e82a4084d2499f5fc72cbe418    
  
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   : be304cf9f5665e1c19d02f1144d4f0affa0034c7    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 6 Oct 2020 14:31:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 6 Oct 2020 14:31:22 -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   : 2cb4b8e0ae16e7091a7bd5cf94f21d2719b108e0    
  
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   : b7f166efade004ba293f52b672961ae064d202cd    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Oct 2020 11:43:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Oct 2020 11:43:53 -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   : 96423711918f44600c9ef91f4342984624f053bb    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 6 Oct 2020 15:50:03 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 6 Oct 2020 15:50:03 +0200    

Ian submitted an updated patch just as I was pushing the previous one,  
so use this newer wording instead.  
  
Author: Ian Barwick  

commit   : 0639f9b8c251d152695a968c3978edca844c3cad    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 6 Oct 2020 15:46:36 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 6 Oct 2020 15:46:36 +0200    

The behavior is different for different types of objects, so make that  
more clear.  
  
Author: Ian Barwick  

commit   : e9703ce6e7ac263e0e5a6fca9266e09284195dc7    
  
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   : ef40ab77d5143385d15dcfd08c5a7d66719ef7a3    
  
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   : d1c23d726d50e10179235b6cee6b34543a879b19    
  
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   : 019eb962fb869b55ac8db173c4424a5de6cfee61    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Oct 2020 11:42:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Oct 2020 11:42:33 -0400    

The descriptions of make_interval() and pg_options_to_table()  
were randomly different from the reality embedded in pg_proc.  
  
(These are not all the discrepancies I found in a quick search,  
but the others perhaps require more discussion, since there's  
at least a case to be made for changing pg_proc not the docs.)  
  
make_interval issue noted by Thomas Kellerer.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : e01e339560ea7d8716924f3b014e902ef646729c    
  
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   : d2c9ef1c80b6adfbeee49507445c1b2eb3d08783    
  
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   : 566c6d4fd8bb76a761ae144a33514428ab048880    
  
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   : 6731f1ef19fdf912cfbf2686a4d344a022b7704b    
  
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   : 3c85489ec9cd08ce43976afa75f613f939635cb9    
  
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   : 49433744ff65d8d799572cd616aecaf3074bcda5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 30 Sep 2020 18:25:22 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 30 Sep 2020 18:25:22 -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   : 99fd38c02299acdc2282ac2dea8057a7a8f5f807    
  
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   : db8e60b82d6af88a4c8e1f9572abd5f5d84906b2    
  
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   : 5610ffaf00a53877ec973881b9b0b7a1acad689a    
  
author   : David Rowley <[email protected]>    
date     : Wed, 30 Sep 2020 13:03:01 +1300    
  
committer: David Rowley <[email protected]>    
date     : Wed, 30 Sep 2020 13:03:01 +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   : f0e4ec74e452f55922b52f50da4ba4834771a268    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Sep 2020 11:18:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Sep 2020 11:18:30 -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   : 651bdbc811652638e1205440c3181a18feb8f967    
  
author   : Alexander Korotkov <[email protected]>    
date     : Tue, 29 Sep 2020 11:41:46 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Tue, 29 Sep 2020 11:41:46 +0300    

The SQL standard doesn't require jsonpath .datetime() method to support the  
ISO 8601 format.  But our to_json[b]() functions convert timestamps to text in  
the ISO 8601 format in the sake of compatibility with javascript.  So, we add  
support of the  ISO 8601 to the jsonpath .datetime() in the sake compatibility  
with to_json[b]().  
  
The standard mode of datetime parsing currently supports just template patterns  
and separators in the format string.  In order to implement ISO 8601, we have to  
add support of the format string double quotes to the standard parsing mode.  
  
Discussion: https://postgr.es/m/94321be0-cc96-1a81-b6df-796f437f7c66%40postgrespro.ru  
Author: Nikita Glukhov, revised by me  
Backpatch-through: 13  

commit   : abcc0ab163003d2ab7c82a1e810ba257ebbec15f    
  
author   : Alexander Korotkov <[email protected]>    
date     : Tue, 29 Sep 2020 11:00:22 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Tue, 29 Sep 2020 11:00:22 +0300    

bffe1bd684 has introduced jsonpath .datetime() method, but default formats  
for time and timestamp contain excess space between time and timezone.  This  
commit removes this excess space making behavior of .datetime() method  
standard-compliant.  
  
Discussion: https://postgr.es/m/94321be0-cc96-1a81-b6df-796f437f7c66%40postgrespro.ru  
Author: Nikita Glukhov  
Backpatch-through: 13  

commit   : 059caf36c3074afd998b6e5f36ea9da460dcaee8    
  
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   : 1aedaba78aa8617b24b7a703abd1359f9d78f62a    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 29 Sep 2020 14:16:12 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 29 Sep 2020 14:16:12 +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   : 67b2ceea01576933a1dc881ef6a65403e03483ee    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Sep 2020 20:32:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Sep 2020 20:32:53 -0400    

We have a dozen or so places that need to iterate over all but the  
first cell of a List.  Prior to v13 this was typically written as  
	for_each_cell(lc, lnext(list_head(list)))  
Commit 1cff1b95a changed these to  
	for_each_cell(lc, list, list_second_cell(list))  
This patch introduces a new macro for_each_from() which expresses  
the start point as a list index, allowing these to be written as  
	for_each_from(lc, list, 1)  
This is marginally more efficient, since ForEachState.i can be  
initialized directly instead of backing into it from a ListCell  
address.  It also seems clearer and less typo-prone.  
  
Some of the remaining uses of for_each_cell() look like they could  
profitably be changed to for_each_from(), but here I confined myself  
to changing uses of list_second_cell().  
  
Also, fix for_each_cell_setup() and for_both_cell_setup() to  
const-ify their arguments; that's a simple oversight in 1cff1b95a.  
  
Back-patch into v13, on the grounds that (1) the const-ification  
is a minor bug fix, and (2) it's better for back-patching purposes  
if we only have two ways to write these loops rather than three.  
  
In HEAD, also remove list_third_cell() and list_fourth_cell(),  
which were also introduced in 1cff1b95a, and are unused as of  
cc99baa43.  It seems unlikely that any third-party code would  
have started to use them already; anyone who has can be directed  
to list_nth_cell instead.  
  
Discussion: https://postgr.es/m/CAApHDvpo1zj9KhEpU2cCRZfSM3Q6XGdhzuAS2v79PH7WJBkYVA@mail.gmail.com  

commit   : 61a78c71a656593bf4121e624348a990ba5b91da    
  
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   : f7873900f353ff210ef2ef2aa587e39196b8bf5a    
  
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   : cb8885ac49697eb2568c4764ae3565cea52be92b    
  
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   : 052014a2066827cb96dbc9ef464ce44293585601    
  
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   : 569f6a89a9153ee05ab429522e835b00b11ad7f9    
  
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]