PostgreSQL 12.0 commit log

commit   : ad1f2885b8c82e0c2d56d7974f012cbecce17a17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 16:03:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 16:03:42 -0400    

commit   : b60f9afcf4bfe6b1ff73b49b9bab20dde356c7f4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    

This one was exposed by a12c75a10.  
  
Backpatch to release 11 where check_pg_config was introduced.  

commit   : ca0b3828504a51247607913e16f45c635ec168b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 14:31:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 14:31:12 -0400    

The behavior described in the PREPARE man page applies only for the  
default plan_cache_mode setting, so explain that properly.  Rewrite  
some of the text while I'm here.  Per suggestion from Bruce.  
  
Discussion: https://postgr.es/m/20190930155505.GA21095@momjian.us  

commit   : 737f226842748cf946cad3bd30aadfd0c03ad16f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Sep 2019 13:44:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Sep 2019 13:44:22 -0400    

This commit adds a mention that the order of columns specified during  
multi-column most-common-value statistics is insignificant, and tries to  
simplify examples.  
  
Discussion: https://postgr.es/m/20190828162238.GA8360@momjian.us  
  
Backpatch-through: 12  

commit   : 9d42df74a3ad0379fe90e56c92eecac6957876f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 12:03:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 12:03:28 -0400    

Set the release date, make a few adjustments for recent commits.  

commit   : 4af2ac3deeca24d3b8cb1abeb49bd62a7d013fa3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Sep 2019 10:18:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Sep 2019 10:18:15 +0900    

In v11 or before, recovery target settings could not take effect in  
crash recovery because they are specified in recovery.conf and  
crash recovery always starts without recovery.conf. But commit  
2dedf4d9a8 integrated recovery.conf into postgresql.conf and  
which unexpectedly allowed recovery target settings to take effect  
even in crash recovery. This is definitely not good behavior.  
  
To fix the issue, this commit makes crash recovery always ignore  
recovery target settings.  
  
Back-patch to v12.  
  
Author: Peter Eisentraut  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net  

commit   : 2ce9bca36458a1f1907c82eb2e9bd642cb1fca26    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 16:27:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 16:27:18 -0700    

In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed  
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass  
in the parent node, but NULL. Which in turn prevents the tuple  
equality comparator from being JIT compiled.  While that fixes  
bug #15486, it is not actually necessary after all of the above commits,  
as we don't re-build the comparator when using the new  
BuildTupleHashTableExt() interface (as the content of the hashtable  
are reset, but the TupleHashTable itself is not).  
  
Therefore re-allow jit compilation for callers that use  
BuildTupleHashTableExt with a separate context for "metadata" and  
content.  
  
As in the previous commit, there's ongoing work to make this easier to  
test to prevent such regressions in the future, but that  
infrastructure is not going to be backpatchable.  
  
The performance impact of not JIT compiling hashtable equality  
comparators can be substantial e.g. for aggregation queries that  
aggregate a lot of input rows to few output rows (when there are a lot  
of output groups, there will be fewer comparisons).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de  
Backpatch: 11, just as 5567d12ce03  

commit   : 6cf74f1bbd6545321d9e2929c7618550863f72d1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 15:24:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 15:24:54 -0700    

For many queries the fact that the tuple descriptor from the lower  
node was not taken into account when determining whether the type of a  
slot is fixed, lead to tuple deforming for such upper nodes not to be  
JIT accelerated.  
  
I broke this in 675af5c01e297.  
  
There is ongoing work to enable writing regression tests for related  
behavior (including a patch that would have detected this  
regression), by optionally showing such details in EXPLAIN. But as it  
seems unlikely that that will be suitable for stable branches, just  
merge the fix for now.  
  
While it's fairly close to the 12 release window, the fact that 11  
continues to perform JITed tuple deforming in these cases, that  
there's still cases where we do so in 12, and the fact that the  
performance regression can be sizable, weigh in favor of fixing it  
now.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de  
Backpatch: 12-, where 675af5c01e297 was merged.  

commit   : 3c70de2e12b9ef10925a57a350dffc01b95e067e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:46:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:46:15 +0200    

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

commit   : f0eadaa717eae75392d03479aea282bc752df276    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:38:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:38:51 +0200    

commit   : 63d3e1142a0554c33818741d44926fc036a0499b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    

Windows does not enforce key file permissions checks in libpq, and psql  
can produce CRLF line endings on Windows.  
  
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)  

commit   : bba1baecb7b07dff33e4c5d32253db5f4c1a0507    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:29:45 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:29:45 +0200    

Reported-by: Justin Pryzby <pryzby@telsasoft.com>  

commit   : a7e5ae53cbe7bd88102b38d5f6e15f5adc94e15c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:07:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:07:22 +0200    

Recovery target parameters are all applied even in standby mode.  The  
previous documentation mostly wished they were not but this was never  
the case.  
  
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net  

commit   : 3e3e32a1c160ec4e2342068515dfaf1dd04c6078    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 09:50:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 09:50:36 +0200    

In particular, make some more precise links for some major items.  

commit   : a430c7b4afe8278223541d3efee2281ee9135c1d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Sep 2019 15:54:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Sep 2019 15:54:02 +0200    

Some older OpenSSL versions (0.9.8 branch) define TLS*_VERSION macros  
but not the corresponding SSL_OP_NO_* macro, which causes the code for  
handling ssl_min_protocol_version/ssl_max_protocol_version to fail to  
compile.  To fix, add more #ifdefs and error handling.  
  
Reported-by: Victor Wagner <vitus@wagner.pp.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/20190924101859.09383b4f%40fafnir.local.vm  

commit   : 9de7ea6aca5a394dbddac4b13b475b313e352b3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    

This test already knew that, to get stable test output, it had to hide  
"loops" counts in EXPLAIN ANALYZE results.  But that's not nearly enough:  
if we get a smaller number of workers than we planned for, then the  
"Workers Launched" number will change, and so will all the rows and loops  
counts up to the Gather node.  This has resulted in repeated failures in  
the buildfarm, so adjust the test to filter out all these counts.  
  
(Really, we wouldn't bother with EXPLAIN ANALYZE at all here, except  
that currently the only way to verify that executor-time pruning has  
happened is to look for '(never executed)' annotations.  Those are  
stable and needn't be filtered out.)  
  
Back-patch to v11 where the test was introduced.  
  
Discussion: https://postgr.es/m/11952.1569536725@sss.pgh.pa.us  

commit   : e40f3c7472036f5a06897a11ac79fd26ec2ccf7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:28:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:28:25 -0400    

We've noted certain EXPLAIN queries on these tables occasionally showing  
unexpected plan choices.  This seems to happen because VACUUM sometimes  
fails to update relpages/reltuples for one of these single-page tables,  
due to bgwriter or checkpointer holding a pin on the lone page at just  
the wrong time.  To ensure those values get set, insert explicit ANALYZE  
operations on these tables after we finish populating them.  This  
doesn't seem to affect any other test cases, so it's a usable fix.  
  
Back-patch to v12.  In principle the issue exists further back, but  
we have not seen it before v12, so I won't risk back-patching further.  
  
Discussion: https://postgr.es/m/24480.1569518042@sss.pgh.pa.us  

commit   : b34bc87030655a677b0a4d6317bfe3a6a7d10546    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    

The markup for optional parameters was neither correct nor consistent.  
In passing, fix a spelling mistake.  
  
Per report from Alex Macy.  Some of these mistakes are old, so  
back-patch as appropriate.  
  
Discussion: https://postgr.es/m/156953522258.1204.12736099368284950578@wrigleys.postgresql.org  

commit   : a37980d4282436b4019a8e427b02919b04cb625a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Sep 2019 16:21:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Sep 2019 16:21:47 +0200    

The documentation states that no target settings will be used when  
standby.signal is present, but this is not quite the case since  
recovery_target_timeline is a valid recovery target for a standby.  
  
Update the documentation with this exception.  
  
Author: David Steele <david@pgmasters.net>  
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net  

commit   : 268c4e9d4d88f5b4baca88ef31e914a1ac1fb7e9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Sep 2019 12:53:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Sep 2019 12:53:57 +0900    

Author: Justin Pryzby  
Reviewed-by: Tatsuro Yamada  
Discussion: https://postgr.es/m/20190927022051.GC24334@telsasoft.com  
Backpatch-through: 12  

commit   : fb341a7db9ba03f365bd02dc47123fbad6cc3761    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    

The test name and the following test cases suggest the index created  
should be hash index, but it forgot to add 'using hash' in the test case.  
This in itself won't improve code coverage as there were some other tests  
which were covering the corresponding code.  However, it is better if the  
added tests serve their actual purpose.  
  
Reported-by: Paul A Jungwirth  
Author: Paul A Jungwirth  
Reviewed-by: Mahendra Singh  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com  

commit   : d10475a0433291bfd136df6edb06497af0f52cb8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:29:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:29:14 +0200    

commit   : 79504cfe1b23cd22c78dd5786f81f40905c5cce0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:27:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:27:34 +0200    

commit   : baca53d3dca701e6a8b04a1b2dd0ed603289fbf0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 16:35:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 16:35:10 +0200    

Author: Liudmila Mantrova <l.mantrova@postgrespro.ru>  
Reported-by: Jeff Janes <jeff.janes@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAMkU%3D1wP-SO4KpiLxHJuPezTJCmK%3DJqefLXrr3eXFO7Qku%2BtMg%40mail.gmail.com  

commit   : b4d615aaa1ecedcf1e2ca415cd2893d1f18aeeca    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 10:51:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 10:51:39 +0200    

Update the note about why not to use // comments, even though it's now  
technically supported.  
  
The note about variable declarations was dropped here because it's  
addressed more properly later in the chapter.  
  
Discussion: https://www.postgresql.org/message-id/flat/156924954640.1117.6309209869705522549%40wrigleys.postgresql.org  

commit   : 66e0ea75bb9d4b40c734067dd7c7e1fc804a88cb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 09:42:19 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 09:42:19 +0200    

Put the description of the SQL/JSON path language after the  
description of the general JSON functions and operators, instead of  
before.  
  
Discussion: https://www.postgresql.org/message-id/16968.1569189812@sss.pgh.pa.us  

commit   : 658d391d87c13a4b27425a2fd014f2162956ad4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Sep 2019 17:30:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Sep 2019 17:30:42 -0400    

LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without  
copying the state of the attgenerated column.  This is in fact wrong,  
because GENERATED and DEFAULT expressions are not the same kind of animal;  
one can contain Vars and the other not.  We *must* copy attgenerated  
when we're copying the attrdef expression.  Rearrange the if-tests  
so that the expression is copied only when the correct one of  
INCLUDING DEFAULTS and INCLUDING GENERATED has been specified.  
  
Per private report from Manuel Rigger.  
  
Tom Lane and Peter Eisentraut  

commit   : 37ad1266147626bfe505b2c5b016497605915a8e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 13:44:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 13:44:43 +0900    

Append node has been removed in v12 when there would be only one subnode  
under it.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqHhS62w8zUFXF4NBjvMboCXYnD-jWoWp-tfo2aHvP3Gxg@mail.gmail.com  
Backpatch-through: 12  

commit   : 707f38e38e8d4ee891bf52c2f9684f87c72b5234    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:08:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:08:26 +0900    

In-core relation options can use a custom lock mode since 47167b7, that  
has lowered the lock available for some autovacuum parameters.  However  
it forgot to consider custom relation options.  This causes failures  
with ALTER TABLE SET when changing a custom relation option, as its lock  
is not defined.  The existing APIs to define a custom reloption does not  
allow to define a custom lock mode, so enforce its initialization to  
AccessExclusiveMode which should be safe enough in all cases.  An  
upcoming patch will extend the existing APIs to allow a custom lock mode  
to be defined.  
  
The problem can be reproduced with bloom indexes, so add a test there.  
  
Reported-by: Nikolay Sharplov  
Analyzed-by: Thomas Munro, Michael Paquier  
Author: Michael Paquier  
Reviewed-by: Kuntal Ghosh  
Discussion: https://postgr.es/m/20190920013831.GD1844@paquier.xyz  
Backpatch-through: 9.6  

commit   : 8728552b291b8fe3778346fb4d4b7d1c8743f708    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 01:47:36 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 01:47:36 +0300    

Our item contains only so->numberOfNonNullOrderBys of distances.  Reflect that  
in the loop upper bound.  
  
Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru  
Author: Nikita Glukhov  
Backpatch-through: 12  

commit   : 17822c0e4f5ab8093e78f665c9e44766ae648a44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 16:24:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 16:24:42 -0400    

commit   : 53c89aed7b38ab412fddc1d6118822ce5d962acd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 13:04:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 13:04:52 -0400    

Further adjust Japanese names, per advice from Etsuro Fujita.  
  
Discussion: https://postgr.es/m/CAPmGK15XT8eCwn1j3tB3CnOn2q6ksHNKwKjDrEcca5ZEfG0tng@mail.gmail.com  

commit   : 216bcf583802011365b8bb038b4e73f143e857b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    

The array <@ and @> operators do not worry about duplicates: if every  
member of array X matches some element of array Y, then X is contained  
in Y, even if several members of X get matched to the same Y member.  
This was not explicitly stated in the docs though, so improve matters.  
  
Discussion: https://postgr.es/m/156614120484.1310.310161642239149585@wrigleys.postgresql.org  

commit   : a25fb9ceb1a63d4383370d4a017aa572d8e99b42    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 10:40:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 10:40:42 -0400    

Mostly markup improvements, with a couple of grammar fixes.  
  
Liudmila Mantrova  
  
Discussion: https://postgr.es/m/CAEkD-mDxVV1Hrxzo3-hPaS5b1s-+Gin+9Cbu2eMBqRovRVjC0w@mail.gmail.com  

commit   : ac8fb2c7e25ce6062d063c56b3c20d24ca581751    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 10:32:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 10:32:02 -0400    

In the v12 contributors list, remove a couple of duplicates  
that had crept in due to variant spellings of a person's name.  
Try to standardize Japanese names as given-name-first.  
  
Alexander Lakhin  
  
Discussion: https://postgr.es/m/a8263c91-6a21-61d4-3156-34bf2fe54e15@gmail.com  

commit   : 8cdd1c4d07a70df0963a26da2533d4c10852504f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 15:30:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 15:30:41 +0200    

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

commit   : 516a4c116c5c4206388828f7e2b4e75fa1b1fc87    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 13:37:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 13:37:33 +0200    

commit   : 84eb871647b3cc88c89d26d25f0cd84a8ac200fe    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 09:04:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 09:04:20 +0200    

The backend also needs to pull in translations from the frontend  
pg_log_*() functions, since some files in src/common/ use those.  

commit   : 860216efa10a0b8ba54b84aa370ba5cbc27dd32a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    

If the bitstring length is not a multiple of 8, we'd shift the  
rightmost bits into the pad space, which must be zeroes --- bit_cmp,  
for one, depends on that.  This'd lead to the result failing to  
compare equal to what it should compare equal to, as reported in  
bug #16013 from Daryl Waycott.  
  
This is, if memory serves, not the first such bug in the bitstring  
functions.  In hopes of making it the last one, do a bit more work  
than minimally necessary to fix the bug:  
  
* Add assertion checks to bit_out() and varbit_out() to complain if  
they are given incorrectly-padded input.  This will improve the  
odds that manual testing of any new patch finds problems.  
  
* Encapsulate the padding-related logic in macros to make it  
easier to use.  
  
Also, remove unnecessary padding logic from bit_or() and bitxor().  
Somebody had already noted that we need not re-pad the result of  
bit_and() since the inputs are required to be the same length,  
but failed to extrapolate that to the other two.  
  
Also, move a comment block that once was near the head of varbit.c  
(but people kept putting other stuff in front of it), to put it in  
the header block.  
  
Note for the release notes: if anyone has inconsistent data as a  
result of saving the output of bitshiftright() in a table, it's  
possible to fix it with something like  
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);  
  
This has been broken since day one, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org  

commit   : 308813846e737f7d92ffb4e033d65e3df6cbddba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 14:21:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 14:21:07 -0400    

The code used the destination slot's natts where it intended to  
use the source slot's natts.  Adding an Assert shows that there  
is no case in "make check-world" where these counts are different,  
so maybe this is a harmless bug, but it's still a bug.  
  
Takayuki Tsunakawa  
  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1FD34C0E@G01JPEXMBYT05  

commit   : ee98adede535ed6bd584857d7f5095328a1ce78c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 21 Sep 2019 23:22:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 21 Sep 2019 23:22:15 +0200    

part of revert "Add DECLARE STATEMENT support to ECPG."  

commit   : 87b601605467812c48675a0ec127707bf381cda2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 21 Sep 2019 22:51:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 21 Sep 2019 22:51:54 +0200    

current through 25f9368304e41c8837f59e94b161f07ac4c7d622  

commit   : d9110d7e14819c10049c9beb1034958787c77e79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:56:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:56:30 -0400    

Since we introduced the idea of leakproof functions, texteq and textne  
were marked leakproof but their sibling text comparison functions were  
not.  This inconsistency seemed justified because texteq/textne just  
relied on memcmp() and so could easily be seen to be leakproof, while  
the other comparison functions are far more complex and indeed can  
throw input-dependent errors.  
  
However, that argument crashed and burned with the addition of  
nondeterministic collations, because now texteq/textne may invoke  
the exact same varstr_cmp() infrastructure as the rest.  It makes no  
sense whatever to give them different leakproofness markings.  
  
After a certain amount of angst we've concluded that it's all right  
to consider varstr_cmp() to be leakproof, mostly because the other  
choice would be disastrous for performance of many queries where  
leakproofness matters.  The input-dependent errors should only be  
reachable for corrupt input data, or so we hope anyway; certainly,  
if they are reachable in practice, we've got problems with requirements  
as basic as maintaining a btree index on a text column.  
  
Hence, run around to all the SQL functions that derive from varstr_cmp()  
and mark them leakproof.  This should result in a useful gain in  
flexibility/performance for queries in which non-leakproofness degrades  
the efficiency of the query plan.  
  
Back-patch to v12 where nondeterministic collations were added.  
While this isn't an essential bug fix given the determination  
that varstr_cmp() is leakproof, we might as well apply it now that  
we've been forced into a post-beta4 catversion bump.  
  
Discussion: https://postgr.es/m/31481.1568303470@sss.pgh.pa.us  

commit   : d3c61e88d94cba2070574dccbfba06bbc738c876    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:29:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:29:17 -0400    

text_pattern_ops and its siblings can't be used with nondeterministic  
collations, because they use the text_eq operator which will not behave  
as bitwise equality if applied with a nondeterministic collation.  The  
initial implementation of that restriction was to insert a run-time test  
in the related comparison functions, but that is inefficient, may throw  
misleading errors, and will throw errors in some cases that would work.  
It seems sufficient to just prevent the combination during CREATE INDEX,  
so do that instead.  
  
Lacking any better way to identify the opclasses involved, we need to  
hard-wire tests for them, which requires hand-assigned values for their  
OIDs, which forces a catversion bump because they previously had OIDs  
that would be assigned automatically.  That's slightly annoying in the  
v12 branch, but fortunately we're not at rc1 yet, so just do it.  
  
Back-patch to v12 where nondeterministic collations were added.  
  
In passing, run make reformat-dat-files, which found some unrelated  
whitespace issues (slightly different ones in HEAD and v12).  
  
Peter Eisentraut, with small corrections by me  
  
Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us  

commit   : 25f9368304e41c8837f59e94b161f07ac4c7d622    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 15:23:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 15:23:53 -0400    

Remove mention of ECPG's DECLARE STATEMENT, since that was reverted  
yesterday.  Rewrite some other entries per suggestions from Peter  
Eisentraut.  Make a couple of desultory wording and markup adjustments.  
  
Discussion: https://postgr.es/m/d4dff575-90ab-9c8c-cc6f-8c657e2de665@2ndquadrant.com  

commit   : 2966e30e553b12d2d25aea184f52f9c6ffbcee51    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    

DST law changes in Fiji and Norfolk Island.  Historical corrections  
for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong,  
Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk  
Island, South Korea, and Turkey.  

commit   : 5f3bec0769c1d3c345ee2de30de271dce4feb469    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 14:22:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 14:22:58 -0400    

Although the SQL/JSON tech report makes reference to ECMAScript which  
allows both single- and double-quoted strings, all the rest of the  
report speaks only of double-quoted string literals in jsonpaths.  
That's more compatible with JSON itself; moreover single-quoted strings  
are hard to use inside a jsonpath that is itself a single-quoted SQL  
literal.  So guess that the intent is to allow only double-quoted  
literals, and remove lexer support for single-quoted literals.  
It'll be less painful to add this again later if we're wrong, than to  
remove a shipped feature.  
  
Also, adjust the lexer so that unrecognized backslash sequences are  
treated as just meaning the escaped character, not as errors.  This  
change has much better support in the standards, as JSON, JavaScript  
and ECMAScript all make it plain that that's what's supposed to  
happen.  
  
Back-patch to v12.  
  
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com  

commit   : 08e04a5f99d50285edf8e89a18da67ce2d75d676    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 12:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 12:47:21 -0400    

This reverts commit bd7c95f0c1a38becffceb3ea7234d57167f6d4bf,  
along with assorted follow-on fixes.  There are some questions  
about the definition and implementation of that statement, and  
we don't have time to resolve them before v13 release.  Rather  
than ship the feature and then have backwards-compatibility  
concerns constraining any redesign, let's remove it for now  
and try again later.  
  
Discussion: https://postgr.es/m/TY2PR01MB2443EC8286995378AEB7D9F8F5B10@TY2PR01MB2443.jpnprd01.prod.outlook.com  

commit   : c3c131e295af6530381a8ace749c81fcc8930059    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 12:53:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 12:53:58 -0300    

I (Álvaro) broke that in commit 6212276e4343 -- forgot to set the  
necessary flag.  Repair.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqEaM2tV5awKhP1vSbgjQe_uXVU15Oi4sTgwgempwMiT8g@mail.gmail.com  

commit   : d75386a3fd34d8902667474318c2ebe40978de32    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 15:31:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 15:31:12 +0300    

f5f084fc3e has removed test because of its instability.  This commit provides  
alternative test with determined ordering using extra ORDER BY expression.  
  
Backpatch-through: 12  

commit   : 09f8106b968e10c7855c0a9fd07dd3520d30e4eb    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    

Reported-By: Kuntal Ghosh (off-list)  
Backpatch-through: 9.4, like 82fa3ff8672  

commit   : 340536dd489286d0f98878843390d92ddc593be0    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:46:49 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:46:49 +0300    

6cae9d2c10 introduced test for NULL values in KNN SP-GiST.  This test relies on  
undetermined ordering showing different results on various platforms.  This  
commit removes that test.  Will be replaced with better test later.  
  
Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl  
Backpatch-through: 12  

commit   : 8c58e480d9ddecbe94badc737d60c866974144b5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:10:56 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:10:56 +0300    

6cae9d2c10 has added an error in freeing old values in  
index_store_float8_orderby_distances() function.  It looks for old value in  
scan->xs_orderbynulls[i] after setting a new value there.  
This commit fixes that.  Also it removes short-circuit in handling  
distances == NULL situation.  Now distances == NULL will be treated the same  
way as array with all null distances.  That is, previous values will be freed  
if any.  
  
Reported-by: Tom Lane, Nikita Glukhov  
Discussion: https://postgr.es/m/CAPpHfdu2wcoAVAm3Ek66rP%3Duo_C-D84%2B%2Buf1VEcbyi_caBXWCA%40mail.gmail.com  
Discussion: https://postgr.es/m/426580d3-a668-b9d1-7b8e-f74d1a6524e0%40postgrespro.ru  
Backpatch-through: 12  

commit   : 31cbd760578fc0aeb87db11422c32afaf5de129b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    

This commit improves subject in two ways:  
  
 * It removes ugliness of 02f90879e7, which stores distance values and null  
   flags in two separate arrays after GISTSearchItem struct.  Instead we pack  
   both distance value and null flag in IndexOrderByDistance struct.  Alignment  
   overhead should be negligible, because we typically deal with at most few  
   "col op const" expressions in ORDER BY clause.  
 * It fixes handling of "col op NULL" expression in KNN-SP-GiST.  Now, these  
   expression are not passed to support functions, which can't deal with them.  
   Instead, NULL result is implicitly assumed.  It future we may decide to  
   teach support functions to deal with NULL arguments, but current solution is  
   bugfix suitable for backpatch.  
  
Reported-by: Nikita Glukhov  
Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : b9cf94c8c2496af30dcdf7cea083463f6464dff0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Sep 2019 11:22:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Sep 2019 11:22:21 -0400    

Provide some documentation about the differences between XQuery  
regular expressions and those supported by Spencer's regex engine.  
Since SQL now exposes XQuery regexps with the LIKE_REGEX operator,  
I made this a standalone section designed to help somebody who  
has to translate a LIKE_REGEX query to Postgres.  (Eventually we might  
extend Spencer's engine to allow precise implementation of XQuery,  
but not today.)  
  
Reference that in the jsonpath docs, provide definitions of the  
XQuery flag letters, and add a description of the JavaScript-inspired  
string literal syntax used within jsonpath.  Also point out explicitly  
that backslashes used within like_regex patterns will need to be doubled.  
  
This also syncs the docs with the decision implemented in commit  
d5b90cd64 to desupport XQuery's 'x' flag for now.  
  
Jonathan Katz and Tom Lane  
  
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com  

commit   : 596cf9e806826936869f62232bd011687c467965    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 15:03:23 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 15:03:23 +0200    

Make the error messages around GSSAPI encryption a bit clearer.  Tweak  
some messages to avoid plural problems.  
  
Also make a code change for clarity.  Using "conf" for "confidential"  
is quite confusing.  Using "conf_state" is perhaps not much better but  
that's what the GSSAPI documentation uses, so there is at least some  
hope of understanding it.  

commit   : 9c4f20066fb20197dfc20e3cf31aa3c890f3646b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 11:46:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 11:46:40 +0200    

commit   : a4188a65be9426136fc176430ea646cb0fa04fff    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 14:40:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 14:40:09 +0530    

Reported-by: Filip Rembiałkowski  
Author: Filip Rembiałkowski  
Backpatch-through: 12, where it was introduced  
Discussion: https://postgr.es/m/CAP_rwwmSNy1=_82rwGe3-X4PjWqPSFXtzNf43DCtGzD7SazdXA@mail.gmail.com  

commit   : 1aaa3ee34466780d6f050b7d4aa5cc69935c08b5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 09:58:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 09:58:43 +0200    

Improve the LDAP DNS SRV item.  

commit   : fbd1cb2fd9796a08a198d929774280ecce933057    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 09:02:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 09:02:41 +0200    

The major version of ecpglib was changed in  
bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, apparently without  
justification.  Revert this, since nothing has changed in this library  
except some added functions.  
  
Discussion: https://www.postgresql.org/message-id/flat/48ee4c56-e1df-b39d-2cad-c7d80b120eb5%402ndquadrant.com  

commit   : ae2d826922b745ea2c77c51019948ccf4309f50f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Sep 2019 13:19:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Sep 2019 13:19:00 +0900    

This fixes an inconsistency with this parameter name not listed in the  
command synopsis, and connection_name is the parameter name more  
commonly used in the docs for ECPG commands.  
  
Reported-by: Yusuke Egashita  
Discussion: https://postgr.es/m/156870956796.1259.11456186889345212399@wrigleys.postgresql.org  
Backpatch-through: 9.4  

commit   : 62ed5e77f3dc6d8c65d917b60dc8512ddd6fd18e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    

It's important users be able to know (without looking at the source code)  
that running DDL or DDL-like commands can interrupt autovacuum which can  
lead to a lot of dead tuples and hence slower database operations.  
  
Reported-by: James Coleman  
Author: James Coleman  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com  

commit   : cb23c63bc6de3ecef2a6a9d58d44640865472da4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    

Lack of quotes results in failure to run the test under older Solaris.  
  
Author: Marina Polyakova, Victor Wagner  
Discussion: https://postgr.es/m/feba89f89e8925b3535cb7d72b9e05e1@postgrespro.ru  

commit   : 68c3c493674d81131c8f2685b91ec8de4fdcb862    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 18 Sep 2019 18:50:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 18 Sep 2019 18:50:01 +0900    

1. Commit 7086be6e3 should have documented the limitation that the direct  
   modification is disabled when WCO constraints are present, but didn't,  
   which is definitely my fault.  Update the documentation (Postgres 9.6  
   onwards).  
  
2. Commit fc22b6623 should have documented the limitation that the direct  
   modification is disabled when generated columns are defined, but  
   didn't.  Update the documentation (Postgres 12 onwards).  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com  

commit   : 14888145420802a32ec018246e12f3b377c61c29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Sep 2019 15:39:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Sep 2019 15:39:51 -0400    

The SQL spec defers to XQuery to define what the option flags are  
for LIKE_REGEX patterns.  XQuery says that:  
* 's' allows the dot character to match newlines, which by  
  default it will not;  
* 'm' allows ^ and $ to match at newlines, not only at the  
  start/end of the whole string.  
Thus, these are *not* inverses as they are for the similarly-named  
POSIX options, and neither one corresponds to the POSIX 'n' option.  
Fortunately, Spencer's library does expose these two behaviors as  
separately twiddlable flags, so we just have to fix the mapping from  
JSP flag bits to REG flag bits.  I also chose to rename the symbol  
for 's' to DOTALL, to make it clearer that it's not the inverse  
of MLINE.  
  
Also, XQuery says that if the 'q' flag "is used together with the m, s,  
or x flag, that flag has no effect".  I read this as saying that 'q'  
overrides the other flags; whoever wrote our code seems to have read  
it backwards.  
  
Lastly, while XQuery's 'x' flag is related to what Spencer's code  
does for REG_EXPANDED, it's not the same or a subset.  It seems best  
to treat XQuery's 'x' as unimplemented for now.  Maybe later we can  
expand our regex code to offer 'x'-style parsing as a separate option.  
  
While at it, refactor the jsonpath code so that (a) there's only  
one copy of the flag transformation logic not two, and (b) the  
processing of flags is independent of the order in which the flags  
are written.  
  
We need some documentation updates to go with this, but I'll  
tackle that separately.  
  
Back-patch to v12 where this code originated.  
  
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com  
Reference: https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#flags  

commit   : 27bc87985c4135f27bdcddd905baad3b62a3f03a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Sep 2019 11:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Sep 2019 11:51:57 -0400    

Noted by Coverity.  Typo in 27cc7cd2b, so back-patch to v12  
as that was.  

commit   : 5576cbc8ff1f8b34e519e54ef43de68ed1b2f93e    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 15 Sep 2019 13:16:59 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 15 Sep 2019 13:16:59 +0100    

Commit d7f8d26d9 added new tests to the stats_ext regression test that  
included creating a view in the public schema, without realising that  
the stats_ext test runs in the same parallel group as the rules test,  
which makes doing that unsafe.  
  
This led to intermittent failures of the rules test on the buildfarm,  
although I wasn't able to reproduce that locally. Fix by creating the  
view in a different schema.  
  
Tomas Vondra and Dean Rasheed, report and diagnosis by Thomas Munro.  
  
Discussion: https://postgr.es/m/CA+hUKGKX9hFZrYA7rQzAMRE07L4hziCc-nO_b3taJpiuKyLLxg@mail.gmail.com  

commit   : 1c6b62a7d0e57bf9ac7a91d47484b1ea9f2857cd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    

PostgreSQL has been unusable when built with xlc 13 and newer, which are  
incompatible with our use of __fetch_and_add().  Back-patch to 9.5,  
which introduced pg_atomic_fetch_add_u32().  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com  

commit   : 5b5b0f721d9cece8fb68ecdd1d53c3bffe6e753c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    

Back-patch to 9.5, which introduced these functions.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com  

commit   : 96b5033e117141eecf3782ee555f39b3006a732f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    

Most WAL records are ignored in early SnapBuild snapshot build phases.  
But it's critical to process some of them, so that later messages have  
the correct transaction state after the snapshot is completely built; in  
particular, XLOG_XACT_ASSIGNMENT messages are critical in order for  
sub-transactions to be correctly assigned to their parent transactions,  
or at least one assert misbehaves, as reported by Ildar Musin.  
  
Diagnosed-by: Masahiko Sawada  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com  

commit   : a0a40f611e9af81507a48f7fd96833ad57c8e4ae    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    

Lack of parens in the definitions could cause a statement using these  
macros to have unexpected semantics.  In current code no bug is  
apparent, but best to fix the definitions to avoid problems down the  
line.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/19795.1568400476@sss.pgh.pa.us  

commit   : da47e43dc32e3c5916396f0cbcfa974b371e4875    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 14:51:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 14:51:13 -0300    

The progress state was being clobbered once the first index completed  
being rebuilt, causing the final phases of the operation not show  
anything in the progress view.  This was inadvertently broken in  
03f9e5cba0ee, which added progress tracking for REINDEX.  
  
(The reason this bugfix is this small is that I had already noticed this  
problem when writing monitoring for CREATE INDEX, and had already worked  
around it, as can be seen in discussion starting at  
https://postgr.es/m/20190329150218.GA25010@alvherre.pgsql Fixing the  
problem is just a matter of fixing one place touched by the REINDEX  
monitoring.)  
  
Reported by: Álvaro Herrera  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/20190801184333.GA21369@alvherre.pgsql  

commit   : 6eb9b20bb7dd770c78bf43b205b98e15972e2341    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:21:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:21:20 +0300    

Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com  
Author: Liudmila Mantrova, Alexander Lakhin  
Reviewed-by: Alexander Korotkov, Alvaro Herrera  
Backpatch-through: 12  

commit   : 9f771868c446c44dae6b97c68eeb1b19da32c50a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:12:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:12:20 +0300    

Besides cosmetic improvements it removes statement that operators necessary  
need to be separated from operands with spaces, which is not really true.  
  
Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com  
Author: Liudmila Mantrova, Alexander Lakhin  
Reviewed-by: Alexander Korotkov, Alvaro Herrera  
Backpatch-through: 12  

commit   : 3097a0d6e9e28137691a2e89949f1b525160de2d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:07 -0700    

Include newitemoff in rmgr desc output for nbtree page split records.  
In passing, correct an obsolete comment that claimed that newitemoff is  
only logged for _L variant nbtree page split WAL records.  
  
Both issues were oversights in commit 2c03216d831, which revamped the  
WAL format.  
  
Author: Peter Geoghegan  
Backpatch: 9.5-, where the WAL format was revamped.  

commit   : 5e9b18c78789aa905d7aba8e0f0729e965aa32fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    

Since WITH CHECK OPTION was introduced, ExecInitModifyTable has  
initialized WCO expressions with the wrong plan node as parent -- that is,  
it passed its input subplan not the ModifyTable node itself.  Up to now  
we thought this was harmless, but bug #16006 from Vinay Banakar shows it's  
not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get  
confused into doing the wrong thing.  (The fact that ExecInitWholeRowVar  
contains such logic is certainly a horrid kluge that doesn't deserve to  
live, but figuring out another way to do that is a task for some other day.)  
  
Andres had already noticed the wrong-parent mistake and fixed it in commit  
148e632c0, but not being aware of any user-visible consequences, he quite  
reasonably didn't back-patch.  This patch is simply a back-patch of  
148e632c0, plus addition of a test case based on bug #16006.  I also added  
the test case to v12/HEAD, even though the bug is already fixed there.  
  
Back-patch to all supported branches.  9.4 lacks RLS policies so the  
new test case doesn't work there, but I'm pretty sure a test could be  
devised based on using a whole-row Var in a plain WITH CHECK OPTION  
condition.  (I lack the cycles to do so myself, though.)  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/16006-99290d2e4642cbd5@postgresql.org  
Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de  

commit   : fef55c569eeda4286451f4fb884ad7d3b1de29fd    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    

The example used to explain 'Looping Through Query Results' uses  
pseudo-materialized views.  Replace it with a more up-to-date example  
which does the same thing with actual materialized views, which have  
been available since PostgreSQL 9.3.  
  
In the passing, change '%' as format specifier instead of '%s' as is used  
in other examples in plpgsql.sgml.  
  
Reported-by: Ian Barwick  
Author: Ian Barwick  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/9a70d393-7904-4918-c97c-649f6d114b6a@2ndquadrant.com  

commit   : dc92bf5cad7ccae294ec7055382c7727726702cc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 11:07:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 11:07:25 +0900    

Depending on the system used, t/*.pl may not be expanded into a list of  
tests which can be consumed by prove when attempting to run TAP tests on  
a given path.  Fix that by using glob() directly in the script, to make  
sure that a complete list of tests is provided.  This has not proved to  
be an issue with MSVC as the list was properly expanded, but it is on  
Linux with perl's system().  
  
This is extracted from a larger patch.  
  
Author: Tom Lane  
Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us  
Backpatch-through: 9.4  

commit   : b1016834d325dff5eb168e5f6f261462eb6f1d56    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 12:04:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 12:04:57 -0400    

For its entire existence, isolationtester.c has forced client_min_messages  
to WARNING, but that seems like a very poor choice of test design.  It  
should be up to individual test scripts to manage whether they emit notices  
and to ensure that the results are stable.  (There were no NOTICE messages  
in the original set of isolation tests, so this was certainly dead code  
when committed, but perhaps it was needed at some earlier point.)  
  
It's possible that the original motivation was due to platform-dependent  
variations in the timing of stdout vs. stderr output.  That should be  
moot since commits 73bcb76b7/6eda3e9c2, but just in case, adjust  
isotesterNoticeProcessor to print to stdout not stderr.  (stderr seems  
like the wrong thing anyway: it should be for error printouts not expected  
test output.)  
  
Back-patch of commit ebd499282 into v12.  I'll separately push this  
into older branches, but this is as much change as v12 needs.  
  
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us  
Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org  

commit   : 97fb88ea4a646343d5f0a8cd65b7e5f598785cb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 22:53:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 22:53:51 -0400    

If a test sends a notice just before blocking, it's possible on  
slow machines for isolationtester to detect the blocked state before  
it's consumed the notice.  (For this to happen, the notice would have  
to arrive after isolationtester has waited for data for 10ms, so on  
fast/lightly-loaded machines it's hard to reproduce the failure.)  
But, if we have seen the backend as blocked, it's certainly already  
sent any notices it's going to send.  Therefore, one more round of  
PQconsumeInput and PQisBusy should be enough to collect and process  
any such notices.  
  
Back-patch of 30717637c into v12.  We're still discussing whether  
to back-patch this further and/or back-patch some other recent  
isolationtester fixes, but this much is provably necessary to  
make the test cases added by 27cc7cd2b stable in v12.  
  
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us  
Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org  

commit   : 84bb33c4804ea26b3f23df875701731bd01d3f0a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 16:24:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 16:24:29 -0400    

commit   : 5348e22b969f6af8bd4400256a6a190721a01f34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    

Don't just assume that the next port is free; it might not be, or  
if we're really unlucky it might even be out of the TCP range.  
Do it honestly with two get_free_port() calls instead.  
  
This is surely a pretty low-probability problem, but I think it  
explains a buildfarm failure seen today, so let's fix it.  
  
Back-patch to v11 where this script was added.  
  
Discussion: https://postgr.es/m/25124.1568052346@sss.pgh.pa.us  

commit   : 9668b02f80425dc72116101cb368c6ac1cc210a1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    

Modern versions of msys2 have changed the treatment of "cmd /c" so that  
the runtime will try to convert the switch to a native file path. This  
patch adds a setting to inhibit that behaviour.  
  
Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com  
  
Backpatch to all live branches.  

commit   : 7d49803259de7514e16dfdf2b6a36e7b514f0505    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    

These tests were disabled on git master in commit 8e5ce1c3f8. This does  
the same thing on the back branches.  
  
Discussion: https://postgr.es/m/a1c40fab-a38c-cb42-6879-125f834e837b@2ndQuadrant.com  

commit   : 3fb307bc4a76815f96fec28a0d1525ab3fbbcfb4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Sep 2019 05:21:30 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Sep 2019 05:21:30 -0700    

In ad0bda5d24ea I changed the EvalPlanQual machinery to store  
substitution tuples in slot, instead of using plain HeapTuples. The  
main motivation for that was that using HeapTuples will be inefficient  
for future tableams.  But it turns out that that conversion was buggy  
for non-locking rowmarks - the wrong tuple descriptor was used to  
create the slot.  
  
As a secondary issue 5db6df0c0 changed ExecLockRows() to begin EPQ  
earlier, to allow to fetch the locked rows directly into the EPQ  
slots, instead of having to copy tuples around. Unfortunately, as Tom  
complained, that forces some expensive initialization to happen  
earlier.  
  
As a third issue, the test coverage for EPQ was clearly insufficient.  
  
Fixing the first issue is unfortunately not trivial: Non-locked row  
marks were fetched at the start of EPQ, and we don't have the type  
information for the rowmarks available at that point. While we could  
change that, it's not easy. It might be worthwhile to change that at  
some point, but to fix this bug, it seems better to delay fetching  
non-locking rowmarks when they're actually needed, rather than  
eagerly. They're referenced at most once, and in cases where EPQ  
fails, might never be referenced. Fetching them when needed also  
increases locality a bit.  
  
To be able to fetch rowmarks during execution, rather than  
initialization, we need to be able to access the active EPQState, as  
that contains necessary data. To do so move EPQ related data from  
EState to EPQState, and, only for EStates creates as part of EPQ,  
reference the associated EPQState from EState.  
  
To fix the second issue, change EPQ initialization to allow use of  
EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but  
obviously still requiring EvalPlanQualInit() to have been done).  
  
As these changes made struct EState harder to understand, e.g. by  
adding multiple EStates, significantly reorder the members, and add a  
lot more comments.  
  
Also add a few more EPQ tests, including one that fails for the first  
issue above. More is needed.  
  
Reported-By: yi huang  
Author: Andres Freund  
Reviewed-By: Tom Lane  
Discussion:  
    https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com  
    https://postgr.es/m/24530.1562686693@sss.pgh.pa.us  
Backpatch: 12-, where the EPQ changes were introduced  

commit   : c6ce5f71b08235f9ed8e0206267ae560ea1ebc91    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    

f2e40380 introduces support of non-key attributes in GiST indexes.  Then if  
get_index_column_opclass() is asked by gistproperty() to get an opclass of  
non-key column, it returns garbage past oidvector value.  This commit fixes  
that by making get_index_column_opclass() return InvalidOid in this case.  
  
Discussion: https://postgr.es/m/20190902231948.GA5343%40alvherre.pgsql  
Author: Nikita Glukhov, Alexander Korotkov  
Backpatch-through: 12  

commit   : 55a808c1a899380bff3340ed8d896d06f0b19f9b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 11:34:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 11:34:06 +0200    

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

commit   : ef48a0573bf0fc5c7e23f077788a055aad9f5e9e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    

Tweak the tests so that we're not just testing the default setting of  
transaction_read_only.  
  
Reported-by: fn ln <emuser20140816@gmail.com>  

commit   : 2403e54fff3b47735fc1a77c51e407c3596d3331    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    

Some of these are quite old, but that doesn't make them not bugs.  
We'd rather report a failure via elog than SIGSEGV.  
  
While at it, uniformly spell the error check as !RelationIsValid(rel)  
rather than a bare rel == NULL test.  The machine code is the same  
but it seems better to be consistent.  
  
Coverity complained about this today, not sure why, because the  
mistake is in fact old.  

commit   : e6af7b367cf46fc385307efcef5a1fece0e5fef3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    

In order to implement NULL LAST semantic GiST previously assumed distance to  
the NULL value to be Inf.  However, our distance functions can return Inf and  
NaN for non-null values.  In such cases, NULL LAST semantic appears to be  
broken.  This commit fixes that by introducing separate array of null flags for  
distances.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : bc67f4189a7a3381db76dbfeafca463187bfe87a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    

Previously plain float comparison was used in GiST pairing heap.  Such  
comparison doesn't provide proper ordering for value sets containing Inf and Nan  
values.  This commit fixes that by usage of float8_cmp_internal().  Note, there  
is remaining problem with NULL distances, which are represented as Inf in  
pairing heap.  It would be fixes in subsequent commit.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrey Borodin  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 9.4  

commit   : b6d72ddd5fbf3f6eb79597ab0c8ec3aaa7c16805    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    

When using COMMIT AND CHAIN or ROLLBACK AND CHAIN not in an explicit  
transaction block, the previous implementation would leave a  
transaction block active in the ROLLBACK case but not the COMMIT case.  
To fix for now, error out when using these commands not in an explicit  
transaction block.  This restriction could be lifted if a sensible  
definition and implementation is found.  
  
Bug: #15977  
Author: fn ln <emuser20140816@gmail.com>  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  

commit   : 422910423b6cba6abc3790b8f20854c9e78e04a4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    

commit   : eecd7c3d2b44094d00e967c7283fc2236d8def5d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    

Note: Following existing practice, titles of formalpara and step are  
not titlecased.  

commit   : 121e3ceed6d93c2891208005f0b270ee80dc13e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    

Commit 6f6b99d13 stuck an INFO message into the fast path for  
checking partition constraints, for no very good reason except  
that it made it easy for the regression tests to verify that  
that path was taken.  Assorted later patches did likewise,  
increasing the unsuppressable-chatter level from ALTER TABLE  
even more.  This isn't good for the user experience, so let's  
drop these messages down to DEBUG1 where they belong.  So as  
not to have a loss of test coverage, create a TAP test that  
runs the relevant queries with client_min_messages = DEBUG1  
and greps for the expected messages.  
  
This testing method is a bit brute-force --- in particular,  
it duplicates the execution of a fair amount of the core  
create_table and alter_table tests.  We experimented with  
other solutions, but running any significant amount of  
standard testing with client_min_messages = DEBUG1 seems  
to have a lot of output-stability pitfalls, cf commits  
bbb96c370 and 5655565c0.  Possibly at some point we'll look  
into whether we can reduce the amount of test duplication.  
  
Backpatch into v12, because some of these messages are new  
in v12 and we don't really want to ship it that way.  
  
Sergei Kornilov  
  
Discussion: https://postgr.es/m/81911511895540@web58j.yandex.ru  
Discussion: https://postgr.es/m/4859321552643736@myt5-02b80404fd9e.qloud-c.yandex.net  

commit   : b6a4d0498757a6e345e07b2a84eb8333f5e5235e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 11:21:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 11:21:24 -0400    

Copy-edit or rewrite some items, add some items that I thought  
deserved documenting, remove some others that didn't (notably,  
I'm not on board with documenting documentation changes), fix  
some poorly-pointed links, move some items to other sections,  
etc etc.  

commit   : 2552c78c18a1cb11d0f49a3af0660a477f81839d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    

commit   : ce35a265a438813cd337307b6997a58ac87bf9c9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    

commit   : 69116b743af01bd0ab87b5dfc7395029002e23a1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    

commit   : 700a1ac073730eca8b2d2235ced133f563a26a1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 15:15:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 15:15:38 -0400    

I still want to review the rest of the notes, but this seems like the  
minimum work required to prepare for beta4.  
  
Major-enhancements text, and a couple of other fixes, from Jonathan Katz  
(with minor copy-editing by me).  

commit   : d1da0bc92c3124de44fca5989ed4506a30bb1a6a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    

We don't consider that building with MinGW is deprecated,  
so adjust some places that gave that impression.  
Per discussion with Peter Eisentraut.  
  
Discussion: https://postgr.es/m/4a023388-8652-fea0-a0b4-35ad5e734e9a@2ndquadrant.com  

commit   : ce5542d4025321273d7d0915fb76977937da6994    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    

The old code didn't differentiate between a read error and a  
concurrent truncation. fread reports both of these by returning 0;  
you have to use feof() or ferror() to distinguish between them,  
which this code did not do.  
  
It might be a better idea to use read() rather than fread() here,  
so that we can display a less-generic error message, but I'm not  
sure that would qualify as a back-patchable bug fix, so just do  
this much for now.  
  
Jeevan Chalke, reviewed by Jeevan Ladhe and by me.  
  
Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com  

commit   : d57a931a85dff67fb7447da5f252bb9a9ecbb6d9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    

The term "ccache" is overloaded.  Let's be more clear, in case someone  
other than a Kerberos wizard has to read this code.  

commit   : 7aa815a7aadd0dcc0515dfc3a88677deb0ca11ff    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    

Previously even if postmaster died and WaitLatch() woke up with that event  
while pg_promote() was waiting for the standby promotion to finish,  
pg_promote() did nothing special and kept waiting until timeout occurred.  
This could cause a busy loop.  
  
This patch make pg_promote() return false immediately when postmaster  
dies, to avoid such a busy loop.  
  
Back-patch to v12 where pg_promote() was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEs9ROgSp+QF+YdDU+xP8W=CY1k-_Ov-d_Z3JY+to3eXA@mail.gmail.com  

commit   : 4c3e750ab4b5f1900abfa7000aad5e6322f47b5d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 15:46:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 15:46:45 +0900    

The logic ending progress reporting for a backend entry introduced by  
b6fb647 causes callers of pgstat_progress_end_command() to do some extra  
work when track_activities is enabled as the process fields are reset in  
the backend entry even if no command were started for reporting.  
  
This resets the fields only if a command is registered for progress  
reporting, and only if track_activities is enabled.  
  
Author: Masahiho Sawada  
Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 64eb426afc344600d7d4b9944ed7c3be7ed1812d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:23:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:23:41 +0900    

Since the addition of fsync requests in bc34223 to make base backup data  
consistent on disk once pg_basebackup finishes, each tablespace tar file  
is individually flushed once completed, with an additional flush of the  
parent directory when the base backup finishes.  While holding a  
connection to the server, a fsync request taking a long time may cause a  
failure of the base backup, which is annoying for any integration.  A  
recent example of breakage can involve tcp_user_timeout, but  
wal_sender_timeout can cause similar problems.  
  
While reviewing the code, there was a second issue causing too many  
fsync requests to be done for the same WAL data.  As recursive fsyncs  
are done at the end of the backup for both the plain and tar formats  
from the base target directory where everything is written, it is fine  
to disable fsyncs when fetching or streaming WAL.  
  
Reported-by: Ryohei Takahashi  
Author: Michael Paquier  
Reviewed-by: Ryohei Takahashi  
Discussion: https://postgr.es/m/OSBPR01MB4550DAE2F8C9502894A45AAB82BE0@OSBPR01MB4550.jpnprd01.prod.outlook.com  
Backpatch-through: 10  

commit   : 73687190d1e750b4ff94dd0213af7f5f4d3026a7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    

Clarify in the help output and documentation that -n, -t etc. take a  
"pattern" rather than a "schema" or "table" etc.  This was especially  
confusing now that the new pg_dumpall --exclude-database option was  
documented with "pattern" and the others not, even though they all  
behave the same.  
  
Discussion: https://www.postgresql.org/message-id/flat/b85f3fa1-b350-38d1-1893-4f7911bd7310%402ndquadrant.com  

commit   : 3e20b7fa408f1b5a1bf17120b55b5473e82a7e63    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    

The read() return was not checking for errors, the write() return was  
not checking for short writes.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 6ef121647f7f29b59b86eca3dee9b90548245a3a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    

This avoids getting a  
  
    Could not read from file ...: Success.  
  
for a short read or write (since errno is not set in that case).  
Instead, report a more specific error messages.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 5380719f931a101a6e83efc7a1664e42bd6bf6c3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:31:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:31:03 +0900    

The leak happens in str_tolower, str_toupper and str_initcap, which are  
used in several places including their equivalent SQL-level functions,  
and can only be triggered when using an ICU-provided collation when  
converting the input string.  
  
b615920 fixed a similar leak.  Backpatch down 10 where ICU collations  
have been introduced.  
  
Author: Konstantin Knizhnik  
Discussion: https://postgr.es/m/94c0ad0a-cbc2-e4a3-7829-2bdeaf9146db@postgrespro.ru  
Backpatch-through: 10  

commit   : aad0926ebbe96fbbc3c963b58f2abbcf81895a06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    

In what seems like a fit of misplaced optimization,  
ExtractReplicaIdentity() accessed the relation's replica-identity  
index without taking any lock on it.  Usually, the surrounding query  
already holds some lock so this is safe enough ... but in the case  
of a previously-planned delete, there might be no existing lock.  
Given a suitable test case, this is exposed in v12 and HEAD by an  
assertion added by commit b04aeb0a0.  
  
The whole thing's rather poorly thought out anyway; rather than  
looking directly at the index, we should use the index-attributes  
bitmap that's held by the parent table's relcache entry, as the  
caller functions do.  This is more consistent and likely a bit  
faster, since it avoids a cache lookup.  Hence, change to doing it  
that way.  
  
While at it, rather than blithely assuming that the identity  
columns are non-null (with catastrophic results if that's wrong),  
add assertion checks that they aren't null.  Possibly those should  
be actual test-and-elog, but I'll leave it like this for now.  
  
In principle, this is a bug that's been there since this code was  
introduced (in 9.4).  In practice, the risk seems quite low, since  
we do have a lock on the index's parent table, so concurrent  
changes to the index's catalog entries seem unlikely.  Given the  
precedent that commit 9c703c169 wasn't back-patched, I won't risk  
back-patching this further than v12.  
  
Per report from Hadi Moshayedi.  
  
Discussion: https://postgr.es/m/CAK=1=Wrek44Ese1V7LjKiQS-Nd-5LgLi_5_CskGbpggKEf3tKQ@mail.gmail.com  

commit   : 90433c38ec5a2c3da576d9526370bcc3057ee9fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    

After an unexpected connection loss and successful reconnection,  
psql neglected to resynchronize its internal state about the server,  
such as server version.  Ordinarily we'd be reconnecting to the same  
server and so this isn't really necessary, but there are scenarios  
where we do need to update --- one example is where we have a list  
of possible connection targets and they're not all alike.  
  
Define "resynchronize" as including connection_warnings(), so that  
this case acts the same as \connect.  This seems useful; for example,  
if the server version did change, the user might wish to know that.  
An attuned user might also notice that the new connection isn't  
SSL-encrypted, for example, though this approach isn't especially  
in-your-face about such changes.  Although this part is a behavioral  
change, it only affects interactive sessions, so it should not break  
any applications.  
  
Also, in do_connect, make sure that we desynchronize correctly when  
abandoning an old connection in non-interactive mode.  
  
These problems evidently are the result of people patching only one  
of the two places where psql deals with connection changes, so insert  
some cross-referencing comments in hopes of forestalling future bugs  
of the same ilk.  
  
Lastly, in Windows builds, issue codepage mismatch warnings only at  
startup, not during reconnections.  psql's codepage can't change  
during a reconnect, so complaining about it again seems like useless  
noise.  
  
Peter Billen and Tom Lane.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com  

commit   : 5eec908c3c2e2d328e0b1bee76881f0d63cedd1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    

These have been there a long time, but their format was never explained  
in the docs.  Per complaint from Yusuke Egashira.  
  
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02  

commit   : 359209835223db95fa589064d8f7548e17da287c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    

Section 16.2 pointed to platform-specific FAQ files that we removed  
way back in 8.4.  Section 16.7 contained a bunch of information about  
AIX and HPUX bugs that were squashed decades ago, plus discussions of  
old compiler versions that are certainly moot now that we require C99  
support.  Since we're obviously not maintaining this stuff carefully,  
just remove it.  The HPUX sub-section seems like it can go away  
entirely, since everything it said that was still applicable was  
redundant with material elsewhere in the chapter.  
  
In passing, I couldn't resist the temptation to do a small amount  
of copy-editing on nearby text.  
  
Back-patch to v12, since this stuff is surely obsolete in any  
branch that requires C99.  
  
Discussion: https://postgr.es/m/15538.1567042743@sss.pgh.pa.us  

commit   : 8ff5de1c7aa2439ae69f53efd61390026505aee4    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Aug 2019 18:45:01 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Aug 2019 18:45:01 +0900    

commit   : 6b7819a0bd01ebe4ede13bf84dbd51b524eb128a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    

The comment did not match what the code actually did for integers with  
the 43rd bit set. You get an integer like that, if you have a posting  
list with two adjacent TIDs that are more than 2^31 blocks apart.  
According to the comment, we would store that in 6 bytes, with no  
continuation bit on the 6th byte, but in reality, the code encodes it  
using 7 bytes, with a continuation bit on the 6th byte as normal.  
  
The decoding routine also handled these 7-byte integers correctly, except  
for an overflow check that assumed that one integer needs at most 6 bytes.  
Fix the overflow check, and fix the comment to match what the code  
actually does. Also fix the comment that claimed that there are 17 unused  
bits in the 64-bit representation of an item pointer. In reality, there  
are 64-32-11=21.  
  
Fitting any item pointer into max 6 bytes was an important property when  
this was written, because in the old pre-9.4 format, item pointers were  
stored as plain arrays, with 6 bytes for every item pointer. The maximum  
of 6 bytes per integer in the new format guaranteed that we could convert  
any page from the old format to the new format after upgrade, so that the  
new format was never larger than the old format. But we hardly need to  
worry about that anymore, and running into that problem during upgrade,  
where an item pointer is expanded from 6 to 7 bytes such that the data  
doesn't fit on a page anymore, is implausible in practice anyway.  
  
Backpatch to all supported versions.  
  
This also includes a little test module to test these large distances  
between item pointers, without requiring a 16 TB table. It is not  
backpatched, I'm including it more for the benefit of future development  
of new posting list formats.  
  
Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi  
Reviewed-by: Masahiko Sawada, Alexander Korotkov  

commit   : 8cc6016a8cd43f84998f57e277a988be651e2e6d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    

RelationAllowsEarlyPruning() performed a catalog scan, but is used  
in two contexts where that was a bad idea:  
  
1.  In heap_page_prune_opt(), which runs very frequently in some large  
    scans.  This caused major performance problems in a field report  
    that was easy to reproduce.  
  
2.  In TestForOldSnapshot(), which runs while we hold a buffer content  
    lock.  It's not clear if this was guaranteed to be free of buffer  
    deadlock risk.  
  
The check was introduced in commit 2cc41acd8 and defended against a  
real problem: 9.6's hash indexes have no page LSN and so we can't  
allow early pruning (ie the snapshot-too-old feature).  We can remove  
the check from all later releases though: hash indexes are now logged,  
and there is no way to create UNLOGGED indexes on regular logged  
tables.  
  
If a future release allows such a combination, it might need to put  
a similar check in place, but it'll need some more thought.  
  
Back-patch to 10.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane, who spotted the second problem  
Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com  

commit   : e96f524433dbc562d708c4d09d8455b6bc953613    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:48:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:48:15 +0900    

In this case, the transfer uses a libpq connection, which is subject to  
the timeout parameters set at system level, and this can make the rewind  
operation suddenly canceled which is not good for automation.  One  
workaround to such issues would be to use PGOPTIONS to enforce the  
wanted timeout parameters, but that's annoying, and for example pg_dump,  
which can run potentially long-running queries disables all types of  
timeouts.  
  
lock_timeout and statement_timeout are the ones which can cause problems  
now.  Note that pg_rewind does not use transactions, so disabling  
idle_in_transaction_session_timeout is optional, but it feels safer to  
do so for the future.  
  
This is back-patched down to 9.5.  idle_in_transaction_session_timeout  
is only present since 9.6.  
  
Author: Alexander Kukushkin  
Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 11f6271b87fab08eea23a31ceaa6b14cdc2e8a6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    

Give it an explanatory para like the other default roles have.  
Don't imply that it can send any signal whatever.  
  
In passing, reorder the table entries and explanatory paras  
for the default roles into some semblance of consistency.  
  
Ian Barwick, tweaked a bit by me.  
  
Discussion: https://postgr.es/m/89907e32-76f3-7282-a89c-ea19c722fe5d@2ndquadrant.com  

commit   : 7570df0f3b6d873cd060b3271b5f7b90cbcfb66c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    

Turns out that returning "unrecognized signal" is confusing.  
Make it explicit that the platform lacks any support for signal names.  
(At least of the machines in the buildfarm, only HPUX lacks it.)  
  
Back-patch to v12 where we invented this function.  
  
Discussion: https://postgr.es/m/3067.1566870481@sss.pgh.pa.us  

commit   : c0222c2c9b8145a0ccbee7d801db848e871f2e14    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    

Section 4.2.7 says that unless otherwise specified, built-in  
aggregates ignore rows in which any input is null.  This is  
not true of the JSON aggregates, but it wasn't documented.  
Fix that.  
  
Of the other entries in table 9.55, some were explicit about  
ignoring nulls, and some weren't; for consistency and  
self-contained-ness, make them all say it explicitly.  
  
Per bug #15884 from Tim Möhlmann.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15884-c32d848f787fcae3@postgresql.org  

commit   : 1510339dce3c70757a87be3880e102e0511bf288    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    

An empty file name or subdirectory name leads join_path_components() to  
just produce the parent directory name, which leads to weird failures or  
recursive inclusions.  Let's throw a specific error for that.  It takes  
only slightly more code to detect all-blank names, so do so.  
  
Also, detect direct recursion, ie a file calling itself.  As coded  
this will also detect recursion via "include_dir '.'", which is  
perhaps more likely than explicitly including the file itself.  
  
Detecting indirect recursion would require API changes for guc-file.l  
functions, which seems not worth it since extensions might call them.  
The nesting depth limit will catch such cases eventually, just not  
with such an on-point error message.  
  
In passing, adjust the example usages in postgresql.conf.sample  
to perhaps eliminate the problem at the source: there's no reason  
for the examples to suggest that an empty value is valid.  
  
Per a trouble report from Brent Bates.  Back-patch to 9.5; the  
issue is old, but the code in 9.4 is enough different that the  
patch doesn't apply easily, and it doesn't seem worth the trouble  
to fix there.  
  
Ian Barwick and Tom Lane  
  
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com  

commit   : b783a38d4580d807210e26c2c09eb77b66d7286f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Aug 2019 09:11:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Aug 2019 09:11:38 +0900    

FD_SETSIZE needs to be declared before winsock2.h, or it is possible to  
run into buffer overflow issues when using --jobs.  This is similar to  
pgbench's solution done in a23c641.  
  
This has been introduced by 71d84ef, and older versions have been using  
the default value of FD_SETSIZE, defined at 64.  
  
Per buildfarm member jacana, but this impacts all Windows animals  
running the TAP tests.  I have reproduced the failure locally to check  
the patch.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20190826054000.GE7005@paquier.xyz  
Backpatch-through: 9.5  

commit   : 6bdd9fb003e26201c4ae6293a9f3b239140b6598    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    

In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of  
warn_or_exit_horribly() were changed but this was not updated.  

commit   : 97205d04e79ded73ba7fe0196f7817f89a405303    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    

Previously 'uname -r' on Msys2 reported a kernele release starting with  
2. The latest version starts with 3. In commit 1638623f we specifically  
looked for one starting with 2. This is now changed to look for any  
digit between 2 and 9.  
  
backpatch to release 10.  

commit   : 67d5af3f42b72270b0c5a2c36c1f378ab908671a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    

On msys2, 'uname -s' reports a string starting MSYS instead on MINGW  
as happens on msys1. Treat these both the same way. This reverts  
608a710195a4b in favor of a more general solution.  
  
Backpatch to all live branches.  

commit   : 63fc3b124008fa626b9f2e57f2211b9c3fb9a4ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:24 +0900    

When trying to use a high number of jobs, vacuumdb has only checked for  
a maximum number of jobs used, causing confusing failures when running  
out of file descriptors when the jobs open connections to Postgres.  
This commit changes the error handling so as we do not check anymore for  
a maximum number of allowed jobs when parsing the option value with  
FD_SETSIZE, but check instead if a file descriptor is within the  
supported range when opening the connections for the jobs so as this is  
detected at the earliest time possible.  
  
Also, improve the error message to give a hint about the number of jobs  
recommended, using a wording given by the reviewers of the patch.  
  
Reported-by: Andres Freund  
Author: Michael Paquier  
Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane  
Discussion: https://postgr.es/m/20190818001858.ho3ev4z57fqhs7a5@alap3.anarazel.de  
Backpatch-through: 9.5  

commit   : 363382521eb26106587c7dab7f439636c3a6876a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    

POSIX permits getopt() to advance optind beyond argc when the last  
argv entry is an option that requires an argument and hasn't got one.  
It seems that no major platforms actually do that, but musl does,  
so that something like "psql -f" would crash with that libc.  
Add a check that optind is in range before trying to look at the  
possibly-bogus option.  
  
Report and fix by Quentin Rameau.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/20190825100617.GA6087@fifth.space  

commit   : cd714b3507c914e78d47352d1e126b4bec4380ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    

We were setting extra_float_digits = 0 to avoid platform-dependent  
output in this test, but that's still able to expose platform-specific  
roundoff behavior in some new test cases added by commit a3d284485,  
as reported by Peter Eisentraut.  Reduce it to -1 to hide that.  
  
(Over in geometry.sql, we're using -3, which is an ancient decision  
dating to 337f73b1b.  I wonder whether that's overkill now.  But  
there's probably little value in trying to change it.)  
  
Back-patch to v12 where a3d284485 came in; there's no evidence that  
we have any platform-dependent issues here before that.  
  
Discussion: https://postgr.es/m/15551268-e224-aa46-084a-124b64095ee3@2ndquadrant.com  

commit   : 54ff1c34f11b3f899be66fa55f85dbace83be741    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    

Bleeding-edge LLVM has stopped supplying replacements for various  
C++14 library features, for people on older C++ versions.  Since we're  
not ready to require C++14 yet, just use plain old new instead of  
make_unique.  As revealed by buildfarm animal seawasp.  
  
Back-patch to 11.  
  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKGJWG7unNqmkxg7nC5o3o-0p2XP6co4r%3D9epqYMm8UY4Mw%40mail.gmail.com  

commit   : 08e68825c1d6cc87606e592a8080fece5da3fd31    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:13 +0900    

This adds a section for heap-related functions.  These were previously  
mixed with functions having a more general purpose, leading to  
confusion.  While on it, add a query example for fsm_page_contents.  
  
Backpatch down to 10, where b5e3942 introduced the subsections for  
function types in pageinspect documentation.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDyM7E1+cK3-aWejxKTGC-wVVP2B+RnJhN6inXyeRmqzw@mail.gmail.com  
Backpatch-through: 10  

commit   : ea4aa9801f9cb9f42255657c387e7594d6717cf8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 22 Aug 2019 20:19:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 22 Aug 2019 20:19:20 -0400    

Previous column name was incorrect.  
  
Reported-by: Justin Pryzby  
  
Backpatch-through: 12  

commit   : 73ebfb10d0410af6b95a288f48b9fae3648bd3c7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 22:36:45 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 22:36:45 +0200    

see d315639c82e8a2cfd1d1b98b7acf0f6c033ab955  

commit   : f87b986e7d9fb47bd7dae77c26a79698d5297ab5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 22:35:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 22:35:00 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 12 development.  
  
current through 068bc300c6ed5333d9561e55cb5f45d17de88422  

commit   : 04f576a999e052187c3ff3bac4965fcd63b34820    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    

There were some minor differences that didn't seem necessary.  
  
Discussion: https://www.postgresql.org/message-id/flat/86b67eef-bb26-c97d-3e35-64f1fbd4f9fe%402ndquadrant.com  

commit   : 39511da1c0143c246c2c759cbde673a8b2ea404f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:59:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:59:16 +0900    

The "Express" flavor of Visual Studio exists up to 2017, and the  
documentation referred to "Express" for Visual Studio 2019.  
  
Author: Takuma Hoshiai  
Discussion: https://postgr.es/m/20190820120231.f905542e685140258ca73d82@sraoss.co.jp  
Backpatch-through: 9.4  

commit   : d60ec8fe529850d10c3422086912056c5af4e61c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    

In early development patches, "replication origins" were called "identifiers";  
almost everything was renamed, but these references to the old terminology  
went unnoticed.  
  
Reported-by: Craig Ringer  

commit   : 068bc300c6ed5333d9561e55cb5f45d17de88422    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/20190819072244.GE18166@paquier.xyz  

commit   : d38753c6f79d1eb7d3096ff777ec6df0bc7e5008    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 13:45:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 13:45:53 +0900    

All those fixes are already included on HEAD thanks to for example  
c96581a and 66bde49, and have gone missing on back-branches.  
  
Author: Alexander Lakhin, Liudmila Mantrova  
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com  
Backpatch-through: 9.4  

commit   : b298e37013683f896b0a224eee50937730faeca8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 12:37:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 12:37:30 +0900    

This has been found during its translation.  
  
Author: Liudmila Mantrova  
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com  
Backpatch-through: 12  

commit   : cdc8d371e27d534626b19e0810a8de74a31e2c91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    

If the record argument is NULL and has no declared type more concrete  
than RECORD, we can't extract useful information about the desired  
rowtype from it.  In this case, see if we're in FROM with an AS clause,  
and if so extract the needed rowtype info from AS.  
  
It worked like this before v11, but commit 37a795a60 removed the  
behavior, reasoning that it was undocumented, inefficient, and utterly  
not self-consistent.  If you want to take type info from an AS clause,  
you should be using the json_to_record() family of functions not the  
json_populate_record() family.  Also, it was already the case that  
the "populate" functions would fail for a null-valued RECORD input  
(with an unfriendly "record type has not been registered" error)  
when there wasn't an AS clause at hand, and it wasn't obvious that  
that behavior wasn't OK when there was one.  However, it emerges  
that some people were depending on this to work, and indeed the  
rather off-point error message you got if you left off AS encouraged  
slapping on AS without switching to the json_to_record() family.  
  
Hence, put back the fallback behavior of looking for AS.  While at it,  
improve the run-time error you get when there's no place to obtain type  
info; we can do a lot better than "record type has not been registered".  
(We can't, unfortunately, easily improve the parse-time error message  
that leads people down this path in the first place.)  
  
While at it, I refactored the code a bit to avoid duplicating the  
same logic in several different places.  
  
Per bug #15940 from Jaroslav Sivy.  Back-patch to v11 where the  
current coding came in.  (The pre-v11 deficiencies in this area  
aren't regressions, so we'll leave those branches alone.)  
  
Patch by me, based on preliminary analysis by Dmitry Dolgov.  
  
Discussion: https://postgr.es/m/15940-2ab76dc58ffb85b6@postgresql.org  

commit   : 842ac79407a1368308beff230d3e83aad6d82b75    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    

In a vpath build, we need to point to the source directory to allow  
FOP to find the images.  

commit   : 328c3f6f96a4d7cdc368264a97d03c9b75ad54ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    

If a table inherits from multiple unrelated parents, we must disallow  
changing the type of a column inherited from multiple such parents, else  
it would be out of step with the other parents.  However, it's possible  
for the column to ultimately be inherited from just one common ancestor,  
in which case a change starting from that ancestor should still be  
allowed.  (I would not be excited about preserving that option, were  
it not that we have regression test cases exercising it already ...)  
  
It's slightly annoying that this patch looks different from the logic  
with the same end goal in renameatt(), and more annoying that it  
requires an extra syscache lookup to make the test.  However, the  
recursion logic is quite different in the two functions, and a  
back-patched bug fix is no place to be trying to unify them.  
  
Per report from Manuel Rigger.  Back-patch to 9.5.  The bug exists in  
9.4 too (and doubtless much further back); but the way the recursion  
is done in 9.4 is a good bit different, so that substantial refactoring  
would be needed to fix it in 9.4.  I'm disinclined to do that, or risk  
introducing new bugs, for a bug that has escaped notice for this long.  
  
Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com  

commit   : 3a5c08aa02677a4fef40de78e88fc95a3d6ac1e0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    

Reported-By: Heikki Linnakangas  
Author: Michael Paquier  
Discussion: https://postgr.es/m/d6ffbebb-a0d2-181c-811d-b029b2225ed7@iki.fi  
Backpatch: 12-, where pluggable table access methods were introduced  

commit   : 03813a50efa563f19110013b06e80f08d4f49cf5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    

This is a variant of the problem fixed in commit 25b692568, which  
unfortunately we failed to detect at the time.  If an update trigger  
returns the "old" tuple, as it's entitled to do, then a subsequent  
iteration of the loop in ExecBRUpdateTriggers would have "oldtuple"  
equal to "trigtuple" and would fail to notice that it shouldn't  
free that.  
  
In addition to fixing the code, extend the test case added by  
25b692568 so that it covers multiple-trigger-iterations cases.  
  
This problem does not manifest in v12/HEAD, as a result of the  
relevant code having been largely rewritten for slotification.  
However, include the test case into v12/HEAD anyway, since this  
is clearly an area that someone could break again in future.  
  
Per report from Piotr Gabriel Kosinski.  Back-patch into all  
supported branches, since the bug seems quite old.  
  
Diagnosis and code fix by Thomas Munro, test case by me.  
  
Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com  

commit   : a4504696e1ed04a112d312e0934dd324e90675e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    

Commit 4b93f5799 rearranged things in plpgsql to make it cope better with  
composite types changing underneath it intra-session.  However, I failed to  
consider the case of a composite type being dropped and recreated entirely.  
In my defense, the previous coding didn't consider that possibility at all  
either --- but it would accidentally work so long as you didn't change the  
type's field list, because the built-at-compile-time list of component  
variables would then still match the type's new definition.  The new  
coding, however, occasionally tries to re-look-up the type by OID, and  
then fails to find the dropped type.  
  
To fix this, we need to save the TypeName struct, and then redo the type  
OID lookup from that.  Of course that's expensive, so we don't want to do  
it every time we need the type OID.  This can be fixed in the same way that  
4b93f5799 dealt with changes to composite types' definitions: keep an eye  
on the type's typcache entry to see if its tupledesc has been invalidated.  
(Perhaps, at some point, this mechanism should be generalized so it can  
work for non-composite types too; but for now, plpgsql only tries to  
cope with intra-session redefinitions of composites.)  
  
I'm slightly hesitant to back-patch this into v11, because it changes  
the contents of struct PLpgSQL_type as well as the signature of  
plpgsql_build_datatype(), so in principle it could break code that is  
poking into the innards of plpgsql.  However, the only popular extension  
of that ilk is pldebugger, and it doesn't seem to be affected.  Since  
this is a regression for people who were relying on the old behavior,  
it seems worth taking the small risk of causing compatibility issues.  
  
Per bug #15913 from Daniel Fiori.  Back-patch to v11 where 4b93f5799  
came in.  
  
Discussion: https://postgr.es/m/15913-a7e112e16dedcffc@postgresql.org  

commit   : 372d6a8918e03f182242b260902dd47e5c5dd6e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    

Clarify what external tools can do to this file, and add a bit  
of detail about what ALTER SYSTEM itself does.  
  
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com  

commit   : 75b2f011f642bbc7fab8352f4bcfb6e3fc494e7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    

ALTER SYSTEM itself normally won't make duplicate entries (although  
up till this patch, it was possible to confuse it by writing case  
variants of a GUC's name).  However, if some external tool has appended  
entries to the file, that could result in duplicate entries for a single  
GUC name.  In such a situation, ALTER SYSTEM did exactly the wrong thing,  
because it replaced or removed only the first matching entry, leaving  
the later one(s) still there and hence still determining the active value.  
  
This patch fixes that by making ALTER SYSTEM sweep through the file and  
remove all matching entries, then (if not ALTER SYSTEM RESET) append the  
new setting to the end.  This means entries will be in order of last  
setting rather than first setting, but that shouldn't hurt anything.  
  
Also, make the comparisons case-insensitive so that the right things  
happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'.  
  
This has been broken since ALTER SYSTEM was invented, so back-patch  
to all supported branches.  
  
Ian Barwick, with minor mods by me  
  
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com  

commit   : b626483bd97be374ad827f800171478773ad8282    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Aug 2019 13:38:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Aug 2019 13:38:16 +0900    

This is a fix similar to 2d7d67cc, where slight plan alteration can  
cause a random failure of this regression test because of an incorect  
tuple ordering, except that this one involves lookups of pg_type.  
Similarly to the other case, add ORDER BY clauses to ensure the output  
order.  
  
The failure has been seen at least once on buildfarm member skink.  
  
Reported-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGLjR9ZBvhXcr9b-NSBHPw9aRgbjyzGE+kqLsT4vwX+nkQ@mail.gmail.com  
Backpatch-through: 12  

commit   : 6844adba54f7d96f30f834efc6d9aa1e52e5672d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    

Commit 07b39083c inserted an unconditional reference to pg_opfamily,  
which of course fails on servers predating that catalog.  Fortunately,  
the case it's trying to solve can't occur on such old servers (AFAIK).  
Hence, just skip the additional code when the source predates 8.3.  
  
Per bug #15955 from sly.  Back-patch to all supported branches,  
like the previous patch.  
  
Discussion: https://postgr.es/m/15955-1daa2e676e903d87@postgresql.org  

commit   : 4c0b9cf9e073ca2dc95a75fe983d90fd518864fb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:55:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:55:58 +0900    

This test case could fail because of an incorrect result ordering when  
looking up at pg_class entries.  This commit adds an ORDER BY to the  
culprit query.  The cause of the failure was likely caused by a plan  
switch.  By default, the planner would likely choose an index-only scan  
or an index scan, but even a small change in the startup cost could have  
caused a bitmap heap scan to be chosen, causing the failure.  
  
While on it, switch some filtering quals to a regular expression as per  
an idea of Tom Lane.  As previously shaped, the quals would have  
selected any relations whose name begins with "temp".  And that could  
cause failures if another test running in parallel began to use similar  
relation names.  
  
Per report from buildfarm member anole, though the failure was very  
rare.  This test has been introduced by 319a810, so backpatch down to  
v10.  
  
Discussion: https://postgr.es/m/20190807132422.GC15695@paquier.xyz  
Backpatch-through: 10  

commit   : a05fa2c0e77535470b6ee1029671eb41c612f4ef    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 12 Aug 2019 15:21:30 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 12 Aug 2019 15:21:30 -0700    

contrib/amcheck failed to consider the possibility that unlogged  
relations will not have any main relation fork files when running in hot  
standby mode.  This led to low-level "can't happen" errors that complain  
about the absence of a relfilenode file.  
  
To fix, simply skip verification of unlogged index relations during  
recovery.  In passing, add a direct check for the presence of a main  
fork just before verification proper begins, so that we cleanly verify  
the presence of the main relation fork file.  
  
Author: Andrey Borodin, Peter Geoghegan  
Reported-By: Andrey Borodin  
Diagnosed-By: Andrey Borodin  
Discussion: https://postgr.es/m/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1@yandex-team.ru  
Backpatch: 10-, where amcheck was introduced.  

commit   : c0c12ce391d89328640dd948b82466c308d85415    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    

As coded, the ICU-collation path in pattern_char_isalpha() failed  
to consider regular ASCII letters to be case-varying.  This led to  
like_fixed_prefix treating too much of an ILIKE pattern as being a  
fixed prefix, so that indexscans derived from an ILIKE clause might  
miss entries that they should find.  
  
Per bug #15892 from James Inform.  This is an oversight in the original  
ICU patch (commit eccfef81e), so back-patch to v10 where that came in.  
  
Discussion: https://postgr.es/m/15892-e5d2bea3e8a04a1b@postgresql.org  

commit   : de0dc0b758ed7452ceee756d9d620c4393b3cb53    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    

Take into account pg_server_to_any() may return input string "as is".  
  
Reported-by: Andrew Dunstan, Thomas Munro  
Discussion: https://postgr.es/m/0ed83a33-d900-466a-880a-70ef456c721f%402ndQuadrant.com  
Author: Alexander Korotkov, Thomas Munro  
Backpatch-through: 12  

commit   : 3218ff5c6aea5841ab547ecca26927716419fe4b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    

We have implemented jsonpath string comparison using default database locale.  
However, standard requires us to compare Unicode codepoints.  This commit  
implements that, but for performance reasons we still use per-byte comparison  
for "==" operator.  Thus, for consistency other comparison operators do per-byte  
comparison if Unicode codepoints appear to be equal.  
  
In some edge cases, when same Unicode codepoints have different binary  
representations in database encoding, we diverge standard to achieve better  
performance of "==" operator.  In future to implement strict standard  
conformance, we can do normalization of input JSON strings.  
  
Original patch was written by Nikita Glukhov, rewritten by me.  
  
Reported-by: Markus Winand  
Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at  
Author: Nikita Glukhov, Alexander Korotkov  
Backpatch-through: 12  

commit   : 6ce0366be2a3f92a46202acaba40be3aa72fa073    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    

This failed with either "tuple already updated by self" or "duplicate  
key value violates unique constraint", depending on whether the table  
had previously been analyzed or not.  The reason is that ANALYZE tried  
to insert or update the same pg_statistic rows twice, and there was no  
CommandCounterIncrement between.  So add one.  The same case works fine  
outside a transaction block, because then there's a whole transaction  
boundary between, as a consequence of the way VACUUM works.  
  
This issue has been latent all along, but the problem was unreachable  
before commit 11d8d72c2 added the ability to specify multiple tables  
in ANALYZE.  We could, perhaps, alternatively fix it by adding code to  
de-duplicate the list of VacuumRelations --- but that would add a  
lot of overhead to work around dumb commands, so it's not attractive.  
  
Per bug #15946 from Yaroslav Schekin.  Back-patch to v11.  
  
(Note: in v11 I also back-patched the test added by commit 23224563d;  
otherwise the problem doesn't manifest in the test I added, because  
"vactst" is empty when the tests for multiple ANALYZE targets are  
reached.  That seems like not a very good thing anyway, so I did this  
rather than rethinking the choice of test case.)  
  
Discussion: https://postgr.es/m/15946-5c7570a2884a26cf@postgresql.org  

commit   : 59d3789294cf6d42325e92486b053f1ee5934eb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    

Not much to be said here: commit 9fdb675fc should have checked  
constisnull, didn't.  
  
Per report from Piotr Włodarczyk.  Back-patch to v11 where  
bug was introduced.  
  
Discussion: https://postgr.es/m/CAP-dhMr+vRpwizEYjUjsiZ1vwqpohTm+3Pbdt6Pr7FEgPq9R0Q@mail.gmail.com  

commit   : edc793d374af50df76efb0a7622b78f58f0d8124    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    

Reviewed by Tom Lane and Amit Langote  
Discussion: https://postgr.es/m/20190806222735.GA9535@alvherre.pgsql  

commit   : 4116420baeae614a2711e156f0c4e58adad172ba    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    

openssl doesn't like lower case subject attribute names. Error observed  
in buildfarm results.  
  
Backpatch to release 11.  

commit   : a1008caf0ac6960cb32b8a4c9b24d371db2a32b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    

VACUUM's reference page had this text, but ANALYZE's didn't.  That's  
a clear oversight given that section 5.7 explicitly delegates the  
responsibility to define permissions requirements to the individual  
commands' man pages.  
  
Per gripe from Isaac Morland.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com  

commit   : 53d467246589de631ce1846105f990099219e737    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 Aug 2019 16:06:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 Aug 2019 16:06:45 +0300    

Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at  
Author: Markus Winand  
Backpatch-through: 12  

commit   : ca8a57b6369322b5ffd915c130da5e902d7f970c    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 7 Aug 2019 19:05:18 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 7 Aug 2019 19:05:18 +0900    

commit   : f8d30182b121f0c38695498d6d386ffa96858e76    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    

In serializable mode, heap_hot_search_buffer() incorrectly acquired a  
predicate lock on the root tuple, not the returned tuple that satisfied  
the visibility checks. As explained in README-SSI, the predicate lock does  
not need to be copied or extended to other tuple versions, but for that to  
work, the correct, visible, tuple version must be locked in the first  
place.  
  
The original SSI commit had this bug in it, but it was fixed back in 2013,  
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months  
later in commit b89e151054. Wising up from that, add a regression test  
to cover this, so that it doesn't get reintroduced again. Also, move the  
code that sets 't_self', so that it happens at the same time that the  
other HeapTuple fields are set, to make it more clear that all the code in  
the loop operate on the "current" tuple in the chain, not the root tuple.  
  
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,  
test case and some additional changes to the fix by Heikki Linnakangas.  
Backpatch to all supported versions (9.4).  
  
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de  

commit   : d8652ec55513260a1ae478f80ae3d7da6eb795e0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:17:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:17:34 +0900    

When parsing a timetz string with a dynamic timezone abbreviation or a  
timezone not specified, it was possible to generate incorrect timestamps  
based on a date which uses some non-initialized variables if the input  
string did not specify fully a date to parse.  This is already checked  
when a full timezone spec is included in the input string, but the two  
other cases mentioned above missed the same checks.  
  
This gets fixed by generating an error as this input is invalid, or in  
short when a date is not fully specified.  
  
Valgrind was complaining about this problem.  
  
Bug: #15910  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/15910-2eba5106b9aa0c61@postgresql.org  
Backpatch-through: 9.4  

commit   : 2f76f4182935c56c897463447ae18f8c2308637a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    

contrib/intarray considers "arraycol <@ constant-array" to be indexable,  
but its GiST opclass code fails to reliably find index entries for empty  
array values (which of course should trivially match such queries).  
This is because the test condition to see whether we should descend  
through a non-leaf node is wrong.  
  
Unfortunately, empty array entries could be anywhere in the index,  
as these index opclasses are currently designed.  So there's no way  
to fix this except by lobotomizing <@ indexscans to scan the whole  
index ... which is what this patch does.  That's pretty unfortunate:  
the performance is now actually worse than a seqscan, in most cases.  
We'd be better off to remove <@ from the GiST opclasses entirely,  
and perhaps a future non-back-patchable patch will do so.  
  
In the meantime, applications whose performance is adversely impacted  
have a couple of options.  They could switch to a GIN index, which  
doesn't have this bug, or they could replace "arraycol <@ constant-array"  
with "arraycol <@ constant-array AND arraycol && constant-array".  
That will provide about the same performance as before, and it will find  
all non-empty subsets of the given constant-array, which is all that  
could reliably be expected of the query before.  
  
While at it, add some more regression test cases to improve code  
coverage of contrib/intarray.  
  
In passing, adjust resize_intArrayType so that when it's returning an  
empty array, it uses construct_empty_array for that rather than  
cowboy hacking on the input array.  While the hack produces an array  
that looks valid for most purposes, it isn't bitwise equal to empty  
arrays produced by other code paths, which could have subtle odd  
effects.  I don't think this code path is performance-critical  
enough to justify such shortcuts.  (Back-patch this part only as far  
as v11; before commit 01783ac36 we were not careful about this in  
other intarray code paths either.)  
  
Back-patch the <@ fixes to all supported versions, since this was  
broken from day one.  
  
Patch by me; thanks to Alexander Korotkov for review.  
  
Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us  

commit   : 514e7e911fc205e0143167e99dcd8fe56d69e071    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    

src/test/kerberos and src/test/ldap try to run private authentication  
servers, which of course might fail.  The logs from these servers  
were being dropped into the tmp_check/ subdirectory, but they should  
be put in tmp_check/log/, because the buildfarm will only capture  
log files in that subdirectory.  Without the log output there's  
little hope of diagnosing buildfarm failures related to these servers.  
  
Backpatch to v11 where these test suites were added.  
  
Discussion: https://postgr.es/m/16017.1565047605@sss.pgh.pa.us  

commit   : 7c45b994f125257be86df27583a6502348785186    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 17:10:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 17:10:44 -0400    

commit   : de4b75c1549ac0baf45b4bcb8d49e2fac90ac43a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    

Commit bf6c614a2 rearranged the lookup of the comparison operators  
needed in a hashed subplan, and in so doing, broke the cross-type  
case: it caused the original LHS-vs-RHS operator to be used to compare  
hash table entries too (which of course are all of the RHS type).  
This leads to C functions being passed a Datum that is not of the  
type they expect, with the usual hazards of crashes and unauthorized  
server memory disclosure.  
  
For the set of hashable cross-type operators present in v11 core  
Postgres, this bug is nearly harmless on 64-bit machines, which  
may explain why it escaped earlier detection.  But it is a live  
security hazard on 32-bit machines; and of course there may be  
extensions that add more hashable cross-type operators, which  
would increase the risk.  
  
Reported by Andreas Seltenreich.  Back-patch to v11 where the  
problem came in.  
  
Security: CVE-2019-10209  

commit   : 9993fa9dd25d01e99748869b1fb1d6f4dc03960e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    

Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this  
restriction for pg_temp.function_name(arg); do likewise for types  
created in temporary schemas.  Programs that this breaks should add  
"pg_temp." schema qualification or switch to arg::type_name syntax.  
Back-patch to 9.4 (all supported versions).  
  
Reviewed by Tom Lane.  Reported by Tom Lane.  
  
Security: CVE-2019-10208  

commit   : 106c6635b5d9ca37b856bbd27560050c438a8ec9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Aug 2019 15:54:23 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 5 Aug 2019 15:54:23 +0200    

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

commit   : 159e4bf7406f0cd46aae3f3873d28bdc63c110bf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 14:30:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 14:30:05 +0900    

OWNER_TO was used for the completion, which is not a supported grammar,  
but OWNER TO is.  
  
This error has been introduced by d37b816, so backpatch down to 9.6.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com  
Backpatch-through: 9.6  

commit   : 2c133db2b42029a7df7d5d6cde48a898c6ca3ef0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 18:11:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 18:11:22 -0400    

Necessary, not optional, because dangling link prevents relnotes from  
building.  

commit   : d5f53a8e26caf7931db6ad3939cd34d36ea54d91    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:29:00 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:29:00 +0200    

This reverts commit 88bdbd3f746049834ae3cc972e6e650586ec3c9d.  
  
As committed, statement sampling used the existing duration threshold  
(log_min_duration_statement) when decide which statements to sample.  
The issue is that even the longest statements are subject to sampling,  
and so may not end up logged. An improvement was proposed, introducing  
a second duration threshold, but it would not be backwards compatible.  
So we've decided to revert this feature - the separate threshold should  
be part of the feature itself.  
  
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com  

commit   : d8453ccfbfd6bb1782e71beb28acf4025a9a01ce    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:19:54 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:19:54 +0200    

This reverts commit 9dc122585551516309c9362e673effdbf3bd79bd.  
  
As committed, statement sampling used the existing duration threshold  
(log_min_duration_statement) when decide which statements to sample.  
The issue is that even the longest statements are subject to sampling,  
and so may not end up logged. An improvement was proposed, introducing  
a second duration threshold, but it would not be backwards compatible.  
So we've decided to revert this feature - the separate threshold should  
be part of the feature itself.  
  
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com  

commit   : df521ab79547b82471126e54e9dc7fead4a5a4fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 14:05:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 14:05:35 -0400    

Perl has multiple internal representations of "undef", and just  
testing for SvTYPE(x) == SVt_NULL doesn't recognize all of them,  
leading to "cannot transform this Perl type to jsonb" errors.  
Use the approved test SvOK() instead.  
  
Report and patch by Ivan Panchenko.  Back-patch to v11 where  
this module was added.  
  
Discussion: https://postgr.es/m/1564783533.324795401@f193.i.mail.ru  

commit   : 4844c6303296d4fa2c9cc800685e4f404dfa5396    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    

src/test/kerberos and src/test/ldap need to run a private authentication  
server of the relevant type, for which they need a free TCP port.  
They were just picking a random port number in 48K-64K, which works  
except when something's already using the particular port.  Notably,  
the probability of failure rises dramatically if one simply runs those  
tests in a tight loop, because each test cycle leaves behind a bunch of  
high ports that are transiently in TIME_WAIT state.  
  
To fix, split out the code that PostgresNode.pm already had for  
identifying a free TCP port number, so that it can be invoked to choose  
a port for the KDC or LDAP server.  This isn't 100% bulletproof, since  
conceivably something else on the machine could grab the port between  
the time we check and the time we actually start the server.  But that's  
a pretty short window, so in practice this should be good enough.  
  
Back-patch to v11 where these test suites were added.  
  
Patch by me, reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/3397.1564872168@sss.pgh.pa.us  

commit   : 86544071484a48c753e719e0c7c9cf816a59a65e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    

When querying a partitioned table containing a default partition, we  
were wrongly deciding to include it in the scan too early in the  
process, failing to exclude it in some cases.  If we reinterpret the  
PruneStepResult.scan_default flag slightly, we can do a better job at  
detecting that it can be excluded.  The change is that we avoid setting  
the flag for that pruning step unless the step absolutely requires the  
default partition to be scanned (in contrast with the previous  
arrangement, which was to set it unless the step was able to prune it).  
So get_matching_partitions() must explicitly check the partition that  
each returned bound value corresponds to in order to determine whether  
the default one needs to be included, rather than relying on the flag  
from the final step result.  
  
Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>  
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp  

commit   : d58c9c0e9f408da7e9bf1901a39ab1ff12f310c0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 01:30:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 01:30:12 -0400    

commit   : a668bc75996daaa155442915c73a2c4dab2ac999    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Aug 2019 00:02:49 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Aug 2019 00:02:49 -0700    

In 5f32b29c1819 I changed the creation of HashState.hashkeys to  
actually use HashState as the parent (instead of HashJoinState, which  
was incorrect, as they were executed below HashState), to fix the  
problem of hashkeys expressions otherwise relying on slot types  
appropriate for HashJoinState, rather than HashState as would be  
correct. That reliance was only introduced in 12, which is why it  
previously worked to use HashJoinState as the parent (although I'd be  
unsurprised if there were problematic cases).  
  
Unfortunately that's not a sufficient solution, because before this  
commit, the to-be-hashed expressions referenced inner/outer as  
appropriate for the HashJoin, not Hash. That didn't have obvious bad  
consequences, because the slots containing the tuples were put into  
ecxt_innertuple when hashing a tuple for HashState (even though Hash  
doesn't have an inner plan).  
  
There are less common cases where this can cause visible problems  
however (rather than just confusion when inspecting such executor  
trees). E.g. "ERROR: bogus varno: 65000", when explaining queries  
containing a HashJoin where the subsidiary Hash node's hash keys  
reference a subplan. While normally hashkeys aren't displayed by  
EXPLAIN, if one of those expressions references a subplan, that  
subplan may be printed as part of the Hash node - which then failed  
because an inner plan was referenced, and Hash doesn't have that.  
  
It seems quite possible that there's other broken cases, too.  
  
Fix the problem by properly splitting the expression for the HashJoin  
and Hash nodes at plan time, and have them reference the proper  
subsidiary node. While other workarounds are possible, fixing this  
correctly seems easy enough. It was a pretty ugly hack to have  
ExecInitHashJoin put the expression into the already initialized  
HashState, in the first place.  
  
I decided to not just split inner/outer hashkeys inside  
make_hashjoin(), but also to separate out hashoperators and  
hashcollations at plan time. Otherwise we would have ended up having  
two very similar loops, one at plan time and the other during executor  
startup. The work seems to more appropriately belong to plan time,  
anyway.  
  
Reported-By: Nikita Glukhov, Alexander Korotkov  
Author: Andres Freund  
Reviewed-By: Tom Lane, in an earlier version  
Discussion: https://postgr.es/m/CAPpHfdvGVegF_TKKRiBrSmatJL2dR9uwFCuR+teQ_8tEXU8mxg@mail.gmail.com  
Backpatch: 12-  

commit   : 20f5cb19582e62e5664e87f7d6963cb8db1628f9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Aug 2019 09:37:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Aug 2019 09:37:48 +0900    

When piling up loading of modules using check_password_hook_type,  
loading passwordcheck would remove any trace of a previously-loaded  
hook.  Unloading the module would also cause previous hooks to be  
entirely gone.  
  
Reported-by: Rafael Castro  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/15932-78f48f9ef166778c@postgresql.org  
Backpatch-through: 9.4  

commit   : 408f759380c723b94e9fb8b523aa02509e1e1d6e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2019 15:42:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2019 15:42:50 -0400    

Since pg_dump doesn't treat the member operators and functions of operator  
classes/families (that is, the pg_amop and pg_amproc entries, not the  
underlying operators/functions) as separate dumpable objects, it missed  
their dependency information.  I think this was safe when the code was  
designed, because the default object sorting rule emits operators and  
functions before opclasses, and there were no dependency types that could  
mess that up.  However, the introduction of range types in 9.2 broke it:  
now a type can have a dependency on an opclass, allowing dependency rules  
to push the opclass before the type and hence before custom operators.  
Lacking any information showing that it shouldn't do so, pg_dump emitted  
the objects in the wrong order.  
  
Fix by teaching getDependencies() to translate pg_depend entries for  
pg_amop/amproc rows to look like dependencies for their parent opfamily.  
  
I added a regression test for this in HEAD/v12, but not further back;  
life is too short to fight with 002_pg_dump.pl.  
  
Per bug #15934 from Tom Gottfried.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/15934-58b8c8ab7a09ea15@postgresql.org  

commit   : c4b7bb3cf19f5d847544de93c36329de8e59193b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Jul 2019 00:05:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Jul 2019 00:05:21 -0700    

These were introduced by pgindent due to fixe to broken  
indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of  
function prototypes was creatively used to reduce indentation in a few  
places.  
  
As that formatting only exists in master and REL_12_STABLE, it seems  
better to fix it in both, rather than having some odd indentation in  
v12 that somebody might copy for future patches or such.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de  
Backpatch: 12-  

commit   : 394f7500ae8f4afc158273d642f5ce87af3a7309    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:43:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:43:27 +0300    

The rd_amcache allows an index AM to cache arbitrary information in a  
relcache entry. This commit moves the cleanup of rd_amcache so that it  
can also be used by table AMs. Nothing takes advantage of that yet, but  
I'm sure it'll come handy for anyone writing new table AMs.  
  
Backpatch to v12, where table AM interface was introduced.  
  
Reviewed-by: Julien Rouhaud  

commit   : 718e313244a9376d823b5efe421eb079474a6b20    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    

This has been wrong ever since pg_rewind was added. The if-branch just  
above this, where we print the same error with an extra message supplied  
by XLogReadRecord() got this right, but the variable name was wrong in the  
else-branch. As a consequence, the error printed the WAL position as  
0/0 if there was an error reading a WAL file.  
  
Backpatch to 9.5, where pg_rewind was added.  

commit   : e1947f6c3ed8bda397295f555fa9e3fe39d50143    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    

When performing ANALYZE on inheritance trees, we collect two samples for  
each relation - one for the relation alone, and one for the inheritance  
subtree (relation and its child relations). And then we build statistics  
on each sample, so for each relation we get two sets of statistics.  
  
For regular (per-column) statistics this works fine, because the catalog  
includes a flag differentiating statistics built from those two samples.  
But we don't have such flag in the extended statistics catalogs, and we  
ended up updating the same row twice, triggering this error:  
  
  ERROR:  tuple already updated by self  
  
The simplest solution is to disable extended statistics on inheritance  
trees, which is what this commit is doing. In the future we may need to  
do something similar to per-column statistics, but that requires adding a  
flag to the catalog - and that's not backpatchable. Moreover, the current  
selectivity estimation code only works with individual relations, so  
building statistics on inheritance trees would be pointless anyway.  
  
Author: Tomas Vondra  
Backpatch-to: 10-  
Discussion: https://postgr.es/m/20190618231233.GA27470@telsasoft.com  
Reported-by: Justin Pryzby  

commit   : d933816c04c64326419bbcd89dc17a4e310f950b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    

A "break" statement erroneously left behind by commit a1c1af2a1  
caused TopoSort to do the wrong thing if a lock's wait list  
contained multiple members of the same locking group.  
  
Because parallel workers don't normally need any locks not already  
taken by their leader, this is very hard --- maybe impossible ---  
to hit in production.  Still, if it did happen, the queries involved  
in an otherwise-resolvable deadlock would block until canceled.  
  
In addition to removing the bogus "break", add an Assert showing  
that the conflicting uses of the beforeConstraints[] array (for both  
counts and flags) don't overlap, and add some commentary explaining  
why not; because it's not obvious without explanation, IMHO.  
  
Original report and patch from Rui Hai Jiang; additional assert  
and commentary by me.  Back-patch to 9.6 where the bug came in.  
  
Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com  

commit   : 28bbf7a81b3a30504cc7dfdbd76b410d1f127b8e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 09:58:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 09:58:49 +0900    

When copying the definition of an index rebuilt concurrently for the new  
entry, the index information was taken directly from the old index using  
the relation cache.  In this case, predicates and expressions have  
some post-processing to prepare things for the planner, which loses some  
information including the collations added in any of them.  
  
This inconsistency can cause issues when attempting for example a table  
rewrite, and makes the new indexes rebuilt concurrently inconsistent  
with the old entries.  
  
In order to fix the problem, fetch expressions and predicates directly  
from the catalog of the old entry, and fill in IndexInfo for the new  
index with that.  This makes the process more consistent with  
DefineIndex(), and the code is refactored with the addition of a routine  
to create an IndexInfo node.  
  
Reported-by: Manuel Rigger  
Author: Michael Paquier  
Discussion: https://postgr.es/m/CA+u7OA5Hp0ra235F3czPom_FyAd-3+XwSJmX95r1+sRPOJc9VQ@mail.gmail.com  
Backpatch-through: 12  

commit   : 180825fe43ece9bf13c27929b7fdeec5a457e9c3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    

Early previews of LLVM 9 reveal that our Min() macro causes compiler  
errors in LLVM headers reached by the #include directives in  
llvmjit_inline.cpp.  Let's just undefine it.  Per buildfarm animal  
seawasp.  Back-patch to 11.  
  
Reviewed-by: Fabien Coelho, Tom Lane  
Discussion: https://postgr.es/m/20190606173216.GA6306%40alvherre.pgsql  

commit   : e396d1ee7db5027302bc8ce129b435dee13723a4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 22:02:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 22:02:30 +0900    

The table has not been updated for some commands introduced in recent  
releases, so refresh it.  While on it, reorder entries alphabetically.  
  
Backpatch all the way down for all the commands which have gone  
missing.  
  
Reported-by: Jeremy Smith  
Discussion: https://postgr.es/m/15883-afff0ea3cc2dbbb6@postgresql.org  
Backpatch-through: 9.4  

commit   : 66190f371d8a6fd7d2ab50187041ce1da44cbb3b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 08:26:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 08:26:33 +0200    

Recently released xfsprogs 5.1.0 has reflink support enabled by  
default, so the note that it's not enabled by default can be removed.  

commit   : 5ac684381df1783b0855d3b53b1c6d4736843695    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    

Per gripe from Ian Barwick  
  
Co-authored-by: Ian Barwick <ian@2ndquadrant.com>  
Discussion: https://postgr.es/m/CABvVfJWNnNKb8cHsTLhkTsvL1+G6BVcV+57+w1JZ61p8YGPdWQ@mail.gmail.com  

commit   : d095b2fe676a929837715ece04ae19e0d8a1dcc3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    

pg_timezone_names() tries to avoid showing the "Factory" zone in  
the view, mainly because that has traditionally had a very long  
"abbreviation" such as "Local time zone must be set--see zic manual page",  
so that showing it messes up psql's formatting of the whole view.  
Since tzdb version 2016g, IANA instead uses the abbreviation "-00",  
which is sane enough that there's no reason to discriminate against it.  
  
On the other hand, it emerges that FreeBSD and possibly other packagers  
are so wedded to backwards compatibility that they hack the IANA data  
to keep the old spelling --- and not just that old spelling, but even  
older spellings that IANA used back in the stone age.  This caused the  
filter logic to fail to suppress "Factory" at all on such platforms,  
though the formatting problem is definitely real in that case.  
  
To solve both problems, get rid of the hard-wired assumption about  
exactly what Factory's abbreviation is, and instead reject abbreviations  
exceeding 31 characters.  This will allow Factory to appear in the view  
if and only if it's using the modern abbreviation.  
  
In passing, simplify the code we add to zic.c to support "zic -P"  
to remove its now-obsolete hacks to not print the Factory zone's  
abbreviation.  Unlike pg_timezone_names(), there's no reason for  
that code to support old/nonstandard timezone data.  
  
Since we generally prefer to keep timezone-related behavior the  
same in all branches, and since this is arguably a bug fix,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3961.1564086915@sss.pgh.pa.us  

commit   : e31dfe99c8c686726c09c4bdf9d4e2c78fd5fc37    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    

Some platforms create a file named "localtime" in the system  
timezone directory, making it a copy or link to the active time  
zone file.  If Postgres is built with --with-system-tzdata, initdb  
will see that file as an exact match to localtime(3)'s behavior,  
and it may decide that "localtime" is the most preferred spelling of  
the active zone.  That's a very bad choice though, because it's  
neither informative, nor portable, nor stable if someone changes  
the system timezone setting.  Extend the preference logic added by  
commit e3846a00c so that we will prefer any other zone file that  
matches localtime's behavior over "localtime".  
  
On the same logic, also discriminate against "posixrules", which  
is another not-really-a-zone file that is often present in the  
timezone directory.  (Since we install "posixrules" but not  
"localtime", this change can affect the behavior of Postgres  
with or without --with-system-tzdata.)  
  
Note that this change doesn't prevent anyone from choosing these  
pseudo-zones if they really want to (i.e., by setting TZ for initdb,  
or modifying the timezone GUC later on).  It just prevents initdb  
from preferring these zone names when there are multiple matches to  
localtime's behavior.  
  
Since we generally prefer to keep timezone-related behavior the  
same in all branches, and since this is arguably a bug fix,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com  
Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us  

commit   : 01e0538e8b12591283835a2ff629428262684574    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    

Money values exceeding about 18 digits (depending on lc_monetary)  
could be inaccurately converted to numeric, due to select_div_scale()  
deciding it didn't need to compute any fractional digits.  Force  
its hand by setting the dscale of one division input to equal the  
number of fractional digits we need.  
  
In passing, rearrange the logic to not do useless work in locales  
where money values are considered integral.  
  
Per bug #15925 from Slawomir Chodnicki.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15925-da9953e2674bb5c8@postgresql.org  

commit   : ba2347a6d985afc19d4c8e8e84b16a28ed4df137    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jul 2019 21:37:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jul 2019 21:37:04 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/LGbT2ncB7tiDsndK0eXHTKmogLjJ5rO52HqXigP8bCA@mail.gmail.com  
  
Backpatch-through: 12  

commit   : 551394ff3a35090873f359995568b661c60a7376    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jul 2019 21:05:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 25 Jul 2019 21:05:51 -0400    

Reported-by: Laurenz Albe  
  
Discussion: https://postgr.es/m/39fd196ca3af345f67595087519268d9da6891b3.camel@cybertec.at  
  
Backpatch-through: 12  

commit   : 3964d3bce9ca1e45301f99800fc798768f7b57ac    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    

After starting slapd, wait until it can accept a connection before  
beginning the real test work.  This avoids occasional test failures.  
Back-patch to 11, where the LDAP tests arrived.  
  
Author: Thomas Munro  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/20190719033013.GI1859%40paquier.xyz  

commit   : c4944a93eb526f3799a36f30d46d6e765108b2b4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:50:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:50:48 -0700    

Backpatch: 12-, like the previous commit  

commit   : 8677c62eaeea002712dd71dc678a7a0566e59858    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:22:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:22:52 -0700    

Since 15d8f8312 we assert that - and since 7ef04e4d2cb2, 4da597edf1  
rely on - the slot type for an expression's  
ecxt_{outer,inner,scan}tuple not changing, unless explicitly flagged  
as such. That allows to either skip deforming (for a virtual tuple  
slot) or optimize the code for JIT accelerated deforming  
appropriately (for other known slot types).  
  
This assumption was sometimes violated for grouping sets, when  
nodeAgg.c internally uses tuplesorts, and the child node doesn't  
return a TTSOpsMinimalTuple type slot. Detect that case, and flag that  
the outer slot might not be "fixed".  
  
It's probably worthwhile to optimize this further in the future, and  
more granularly determine whether the slot is fixed. As we already  
instantiate per-phase transition and equal expressions, we could  
cheaply set the slot type appropriately for each phase.  But that's a  
separate change from this bugfix.  
  
This commit does include a very minor optimization by avoiding to  
create a slot for handling tuplesorts, if no such sorts are  
performed. Previously we created that slot unnecessarily in the common  
case of computing all grouping sets via hashing. The code looked too  
confusing without that, as the conditions for needing a sort slot and  
flagging that the slot type isn't fixed, are the same.  
  
Reported-By: Ashutosh Sharma  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAE9k0PmNaMD2oHTEAhRyxnxpaDaYkuBYkLa1dpOpn=RS0iS2AQ@mail.gmail.com  
Backpatch: 12-, where the bug was introduced in 15d8f8312  

commit   : b2453704673469ffd34ed13a642e3edc936f5a24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    

Per buildfarm.  

commit   : c58cf97f2fc464e15f0cca95b9d31b7224d48ecd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 12:10:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 12:10:54 -0400    

libpq failed to ignore Windows-style newlines in connection service files.  
This normally wasn't a problem on Windows itself, because fgets() would  
convert \r\n to just \n.  But if libpq were running inside a program that  
changes the default fopen mode to binary, it would see the \r's and think  
they were data.  In any case, it's project policy to ignore \r in text  
files unconditionally, because people sometimes try to use files with  
DOS-style newlines on Unix machines, where the C library won't hide that  
from us.  
  
Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of  
the line.  In HEAD, go a little further and make it ignore all trailing  
whitespace, to match what it's always done with leading whitespace.  
  
In HEAD, also run around and fix up everyplace where we have  
newline-chomping code to make all those places look consistent and  
uniformly drop \r.  It is not clear whether any of those changes are  
fixing live bugs.  Most of the non-cosmetic changes are in places that  
are reading popen output, and the jury is still out as to whether popen  
on Windows can return \r\n.  (The Windows-specific code in pipe_read_line  
seems to think so, but our lack of support for this elsewhere suggests  
maybe it's not a problem in practice.)  Hence, I desisted from applying  
those changes to back branches, except in run_ssl_passphrase_command()  
which is new enough and little-tested enough that we'd probably not have  
heard about any problems there.  
  
Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha.  
Back-patch the parseServiceFile() change to all supported branches,  
and the run_ssl_passphrase_command() change to v11 where that was added.  
  
Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org  

commit   : 6e5417d7737bdcc26ca7889210f275a8e46591b0    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    

Add a line to the project file setting the target SDK. Otherwise, in for  
example VS2017, if the default but optional 8.1 SDK is not installed the  
build will fail.  
  
Patch from Peifeng Qiu, slightly edited by me.  
  
Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com  
  
Backpatch to all live branches.  

commit   : 665329abe7effa688dd96b34a0130109b669d36d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    

As of Fedora 30, it seems that the system-provided macros for setting  
up user privileges in SELinux policies don't grant the ability to read  
/etc/passwd, as they formerly did.  This restriction breaks psql  
(which tries to use getpwuid() to obtain the user name it's running  
under) and thereby the contrib/sepgsql regression test.  Add explicit  
specifications that we need the right to read /etc/passwd.  
  
Mike Palmiotto, per a report from me.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/23856.1563381159@sss.pgh.pa.us  

commit   : 2e60117aa9152ca11b54e95a41f72f71a2387f33    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 13:58:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 13:58:53 +0200    

commit   : f9257cffef3bb16aba2dbbe05fd8bf0afaa6b1f2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 24 Jul 2019 18:45:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 24 Jul 2019 18:45:58 -0700    

After 277cb789836 ON CONFLICT ... SET ... RETURNING failed with  
ERROR:  virtual tuple table slot does not have system attributes  
when taking the update path, as the slot used to insert into the  
table (and then process RETURNING) was defined to be a virtual slot in  
that commit. Virtual slots don't support system columns except for  
tableoid and ctid, as the other system columns are AM dependent.  
  
Fix that by using a slot of the table's type. Add tests for system  
column accesses in ON CONFLICT ...  RETURNING.  
  
Reported-By: Roby, bisected to the relevant commit by Jeff Janes  
Author: Andres Freund  
Discussion: https://postgr.es/m/73436355-6432-49B1-92ED-1FE4F7E7E100@finefun.com.au  
Backpatch: 12-, where the bug was introduced in 277cb789836  

commit   : 24a6b6af650132094f7f8547458a3835cf01be7f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Jul 2019 07:55:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Jul 2019 07:55:28 +0900    

Oversight in 7d81bdc, which introduced a new routine in perl lacking a  
return clause.  Per buildfarm member crake.  
  
Backpatch down to 9.6 like its parent.  
  
Reported-by: Andrew Dunstan  
Discussion: https://postgr.es/m/16da29fa-d504-1380-7095-40de586dc038@2ndQuadrant.com  
Backpatch-through: 9.6  

commit   : d16e514befb5fdcf59bb404e828d3ce88a829b8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    

describeOneTableDetails issued a partition-constraint-fetching query  
for every table, even ones it knows perfectly well are not partitions.  
  
To add insult to injury, it then proceeded to leak the empty PGresult  
if the table wasn't a partition.  Doing that a lot of times might  
amount to a meaningful leak, so this seems like a back-patchable bug.  
  
Fix that, and also fix a related PGresult leak in the partition-parent  
case (though that leak would occur only if we got no row, which is  
unexpected).  
  
Minor code beautification too, to make this code look more like the  
pre-existing code around it.  
  
Back-patch the whole change into v12.  However, the fact that we already  
know whether the table is a partition dates only to commit 1af25ca0c;  
back-patching the relevant changes from that is probably more churn  
than is justified in released branches.  Hence, in v11 and v10, just  
do the minimum to fix the PGresult leaks.  
  
Noted while messing around with adjacent code for yesterday's \d  
improvements.  

commit   : fb5344c969af77bb78bc2a643fb75b9f8fea72dd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:07 +0300    

Otherwise, after a deleted page gets even older, it becomes unrecyclable  
again. B-tree has the same problem, and has had since time immemorial,  
but let's at least fix this in GiST, where this is new.  
  
Backpatch to v12, where GiST page deletion was introduced.  
  
Reviewed-by: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru  

commit   : e2e992c93145cfc0e3563fb84efd25b390a84bb9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:05 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:05 +0300    

The explicit check in gistScanPage() isn't currently really necessary, as  
a deleted page is always empty, so the loop would fall through without  
doing anything, anyway. But it's a marginal optimization, and it gives a  
nice place to attach a comment to explain how it works.  
  
Backpatch to v12, where GiST page deletion was introduced.  
  
Reviewed-by: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru  

commit   : bfa4263e7119685cddb08ed2e2b3462157d4d453    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    

Windows hosts do not normally come with expr, so instead of using that  
to test the \setshell command, use echo instead, which is fairly  
universally available.  
  
Backpatch to release 11, where this came in.  
  
Problem found by me, patch by Fabien Coelho.  

commit   : a15a40aaaedfa01f41471f74aa8ac44168603fb9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 11:26:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 11:26:24 +0900    

Using pg_receivewal with synchronous_commit = remote_apply set in the  
backend is incompatible if pg_receivewal is a synchronous standby as it  
never applies WAL, so document this problem and solutions to it.  
  
Backpatch to 9.6, where remote_apply has been added.  
  
Author: Robert Haas, Jesper Pedersen  
Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/1427a2d3-1e51-9335-1931-4f8853d90d5e@redhat.com  
Backpatch-through: 9.6  

commit   : 0ceb28da06152cbf69c7e9a71c09e9de47783472    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 10:54:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 10:54:20 +0900    

Slow buildfarm machines have run into issues with this TAP test caused  
by a race condition related to the startup of a set of standbys, where  
it is possible to finish with an unexpected order in the WAL sender  
array of the primary.  
  
This closes the race condition by making sure that any standby started  
is registered into the WAL sender array of the primary before starting  
the next one based on lookups of pg_stat_replication.  
  
Backpatch down to 9.6 where the test has been introduced.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Noah Misch  
Discussion: https://postgr.es/m/20190617055145.GB18917@paquier.xyz  
Backpatch-through: 9.6  

commit   : 3ffe655c0af03cb4d5aab18da2aaa7022d207bf3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    

If the user creates a deferred constraint in a partition, and in a  
transaction they cause the constraint's trigger execution to be deferred  
until commit time *and* drop the constraint, then when commit time comes  
the queued trigger will fail to run because the trigger object will have  
been dropped.  
  
This is explained because when a constraint gets dropped in a  
partitioned table, the recursion to drop the ones in partitions is done  
by the dependency mechanism, not by ALTER TABLE traversing the recursion  
tree as in all other cases.  In the non-partitioned case, this problem  
is avoided by checking that the table is not "in use" by alter-table;  
other alter-table subcommands that recurse to partitions do that check  
for each partition.  But the dependency mechanism doesn't have a way to  
do that.  Fix the problem by applying the same check to all partitions  
during ALTER TABLE's "prep" phase, which correctly raises the necessary  
error.  
  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Discussion: https://postgr.es/m/CAKcux6nZiO9-eEpr1ZD84bT1mBoVmeZkfont8iSpcmYrjhGWgA@mail.gmail.com  

commit   : 79e573fa4986be54c30d1313709c26c2a34488c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jul 2019 14:55:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jul 2019 14:55:23 -0400    

The logic in ATExecDropColumn that rejects dropping partition key  
columns is quite an inadequate defense, because it doesn't execute  
in cases where a column needs to be dropped due to cascade from  
something that only the column, not the whole partitioned table,  
depends on.  That leaves us with a badly broken partitioned table;  
even an attempt to load its relcache entry will fail.  
  
We really need to have explicit pg_depend entries that show that the  
column can't be dropped without dropping the whole table.  Hence,  
add those entries.  In v12 and HEAD, bump catversion to ensure that  
partitioned tables will have such entries.  We can't do that in  
released branches of course, so in v10 and v11 this patch affords  
protection only to partitioned tables created after the patch is  
installed.  Given the lack of field complaints (this bug was found  
by fuzz-testing not by end users), that's probably good enough.  
  
In passing, fix ATExecDropColumn and ATPrepAlterColumnType  
messages to be more specific about which partition key column  
they're complaining about.  
  
Per report from Manuel Rigger.  Back-patch to v10 where partitioned  
tables were added.  
  
Discussion: https://postgr.es/m/CA+u7OA4JKCPFrdrAbOs7XBiCyD61XJxeNav4LefkSmBLQ-Vobg@mail.gmail.com  
Discussion: https://postgr.es/m/31920.1562526703@sss.pgh.pa.us  

commit   : 980224b4a23056de76d902b539980868d33d1b8d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jul 2019 11:11:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jul 2019 11:11:54 -0700    

Solely relying on a relation's reltuples/relpages estimate to size the  
Bloom filters used by amcheck verification makes verification less  
effective when the estimates are very stale.  In extreme cases,  
verification options that use Bloom filters internally could be totally  
ineffective, without users receiving any clear indication that certain  
types of corruption might easily be missed.  
  
To fix, use RelationGetNumberOfBlocks() instead of relpages to size the  
downlink block Bloom filter.  Use the same RelationGetNumberOfBlocks()  
value to derive a minimum size for the heapallindexed Bloom filter,  
rather than completely trusting reltuples.  Verification will still be  
reasonably effective when the projected/estimated number of Bloom filter  
elements is at least 1/5 of the final number of elements, which is  
assured by the new sizing logic.  
  
Reported-By: Alexander Korotkov  
Discussion: https://postgr.es/m/CAH2-Wzk0ke2J42KrNYBKu0Xovjy-sU5ub7PWjgpbsKdAQcL4OA@mail.gmail.com  
Backpatch: 11-, where downlink/heapallindexed verification were added.  

commit   : 5a8ee9f2dbe040b9a0cb7f73a4376633f93b4ab4    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Jul 2019 12:28:16 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Jul 2019 12:28:16 +0200    

The current extended statistics code was a bit confused which collation  
to use.  When building the statistics, the collations defined as default  
for the data types were used (since commit 5e0928005).  The MCV code was  
however using the column collations for MCV serialization, and then  
DEFAULT_COLLATION_OID when computing estimates. So overall the code was  
using all three possible options, inconsistently.  
  
This uses the column colation everywhere - this makes it consistent with  
what 5e0928005 did for regular stats.  We however do not track the  
collations in a catalog, because we can derive them from column-level  
information.  This may need to change in the future, e.g. after allowing  
statistics on expressions.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : fc4faea17971a927daf936a4b17564140ee412f6    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Jul 2019 16:28:28 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Jul 2019 16:28:28 +0200    

The examine_opclause_expression function needs to return information on  
which side of the operator we found the Var, but the variable was called  
"isgt" which is rather misleading (it assumes the operator is either  
less-than or greater-than, but it may be equality or something else).  
Other places in the planner use a variable called "varonleft" for this  
purpose, so just adopt the same convention here.  
  
The code also assumed we don't care about this flag for equality, as  
(Var = Const) and (Const = Var) should be the same thing. But that does  
not work for cross-type operators, in which case we need to pass the  
parameters to the procedure in the right order. So just use the same  
code for all types of expressions.  
  
This means we don't need to care about the selectivity estimation  
function anymore, at least not in this code. We should only get the  
supported cases here (thanks to statext_is_compatible_clause).  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : 533522846ba050efe9df740e5916ced87144c8f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    

Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream  
IANA code, in hopes of silencing warnings from MSVC about negating  
a bool value.  
  
Discussion: https://postgr.es/m/20190719035347.GJ1859@paquier.xyz  

commit   : b990cc38dc64f3333c1c61aba247bfbaea1475f8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 11:43:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 11:43:05 +0900    

16828d5 has improved ALTER TABLE so as a column addition does not  
require a rewrite for a non-NULL default with constant expressions, but  
one spot in the documentation did not get updated consistently.  
The documentation also now clarifies the fact that this does not apply  
if the expression is volatile, where a table rewrite is still required.  
  
Reported-by: Daniel Westermann  
Author: Ian Barwick  
Reviewed-by: Michael Paquier, Daniel Westermann  
Discussion: https://postgr.es/m/DB6PR0902MB2184C7D5645CF15D75EB7957D2CF0@DB6PR0902MB2184.eurprd09.prod.outlook.com  
Backpatch-through: 11  

commit   : 5245552ddbc43b7705389cae9c5095e687a3c950    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 17:26:56 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 17:26:56 -0700    

I was careless passing a datum directly to DATE_NOT_FINITE without  
calling DatumGetDateADT() first.  
  
Backpatch-through: 9.4  

commit   : 613eabcd51c3adec50e28c1f151d574db5a05a9e    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 17:26:47 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 17:26:47 -0700    

The values 'infinity' and '-infinity' are a part of the DATE type  
itself, so a bound of the date 'infinity' is not the same as an  
unbounded/infinite range. However, it is still wrong to try to  
canonicalize such values, because adding or subtracting one has no  
effect. Fix by treating 'infinity' and '-infinity' the same as  
unbounded ranges for the purposes of canonicalization (but not other  
purposes).  
  
Backpatch to all versions because it is inconsistent with the  
documented behavior. Note that this could be an incompatibility for  
applications relying on the behavior contrary to the documentation.  
  
Author: Laurenz Albe  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/77f24ea19ab802bc9bc60ddbb8977ee2d646aec1.camel%40cybertec.at  
Backpatch-through: 9.4  

commit   : 7772dece98506233f40c6751e5adb7983a0c1635    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 18 Jul 2019 13:22:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 18 Jul 2019 13:22:54 -0700    

Commit 857f9c36cda, which taught nbtree VACUUM to avoid unnecessary  
index scans, bumped the nbtree version number from 2 to 3, while adding  
the ability for nbtree indexes to be upgraded on-the-fly.  Various  
assertions that assumed that an nbtree index was always on version 2 had  
to be changed to accept any supported version (version 2 or 3 on  
Postgres 11).  
  
However, a few assertions were missed in the initial commit, all of  
which were in code paths that cache a local copy of the metapage  
metadata, where the index had been expected to be on the current version  
(no longer version 2) as a generic sanity check.  Rather than simply  
update the assertions, follow-up commit 0a64b45152b intentionally made  
the metapage caching code update the per-backend cached metadata version  
without changing the on-disk version at the same time.  This could even  
happen when the planner needed to determine the height of a B-Tree for  
costing purposes.  The assertions only fail on Postgres v12 when  
upgrading from v10, because they were adjusted to use the authoritative  
shared memory metapage by v12's commit dd299df8.  
  
To fix, remove the cache-only upgrade mechanism entirely, and update the  
assertions themselves to accept any supported version (go back to using  
the cached version in v12).  The fix is almost a full revert of commit  
0a64b45152b on the v11 branch.  
  
VACUUM only considers the authoritative metapage, and never bothers with  
a locally cached version, whereas everywhere else isn't interested in  
the metapage fields that were added by commit 857f9c36cda.  It seems  
unlikely that this bug has affected any user on v11.  
  
Reported-By: Christoph Berg  
Bug: #15896  
Discussion: https://postgr.es/m/15896-5b25e260fdb0b081%40postgresql.org  
Backpatch: 11-, where VACUUM was taught to avoid unnecessary index scans.  

commit   : 79d3a1e52a3c1706cbabb00aec9175da7055319d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:16:50 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:16:50 +0200    

When evaluating clauses on a multivariate MCV list, we build a bitmap  
tracking how the clauses match each item of the MCV list.  When updating  
the bitmap we need to consider the current value (tracking how the item  
matches preceding clauses), match for the current clause and whether the  
clauses are connected by AND or OR.  
  
Until now the logic was copied on every place updating the bitmap, which  
was not quite readable.  So just move it to a separate function and call  
it where needed.  
  
Backpatch to 12, where the code was introduced. While not a bugfix, this  
should make maintenance and future backpatches easier.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  

commit   : 1c2acc32dc6cb15c6ea038a954af9a4db8d01f08    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 15 Jul 2019 02:00:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 15 Jul 2019 02:00:31 +0200    

There were two issues in how the extended statistics handled NULL values  
in opclauses. Firstly, the code was oblivious to the possibility that  
Const may be NULL (constisnull=true) in which case the constvalue is  
undefined. We need to treat this as a mismatch, and not call the proc.  
  
Secondly, the MCV item itself may contain NULL values too - the code  
already did check that, and updated the match bitmap accordingly, but  
failed to ensure we won't call the operator procedure anyway. It did  
work for AND-clauses, because in that case false in the bitmap stops  
evaluation of further clauses. But for OR-clauses ir was not easy to  
get incorrect estimates or even trigger a crash.  
  
This fixes both issues by extending the existing check so that it looks  
at constisnull too, and making sure it skips calling the procedure.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  

commit   : 42276976a1437c88fb6176fc1a876fd79a139eb0    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 13 Jul 2019 00:12:16 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 13 Jul 2019 00:12:16 +0200    

We expect opclauses to have exactly one Var and one Const, but the code  
was checking the Const by calling is_pseudo_constant_clause() which is  
incorrect - we need a proper constant.  
  
Fixed by using plain IsA(x,Const) to check type of the node. We need to  
do these checks in two places, so move it into a separate function that  
can be called in both places.  
  
Reported by Andreas Seltenreich, based on crash reported by sqlsmith.  
  
Backpatch to v12, where this code was introduced.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : 3944e855bc5bee32d99a9ba2245a026d4bafe282    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:13:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:13:39 +0200    

The TYPECACHE_GT_OPR is not needed (it used to be in older version of  
the MCV code), but the compiler failed to detect this as the result was  
used in a fmgr_info() call, populating a FmgrInfo entry.  
  
Backpatch to v12, where this code was introduced.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : fa7bb9345370ab69cac24b7213262f36567d9c9c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Jul 2019 19:39:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Jul 2019 19:39:54 -0700    

Author: Brad DeJong  
Discussion: https://postgr.es/m/CAJnrtnxDYOQFsDfWz2iri0T_fFL2ZbbzgCOE=4yaMcszgcsf4A@mail.gmail.com  
Backpatch: 12-  

commit   : 4ed6001d7889f534e052e67e39acc2eb477fc645    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jul 2019 10:06:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jul 2019 10:06:50 +0900    

The documentation mentioned that data checksums cannot be changed after  
initialization, which is not true as pg_checksums can do that with its  
--enable option introduced in v12.  This simply removes the sentence  
telling so.  
  
Reported-by: Basil Bourque  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/15909-e9d74271f1647472@postgresql.org  
Backpatch-through: 12  

commit   : d4f283162e8d09ca39085b2745e99543990e1d06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    

Brazil no longer observes DST.  
Historical corrections for Palestine, Hong Kong, and Italy.  

commit   : 59cea8f36be725533a0f94607f498b7628aa4b9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    

A large fraction of this diff is just due to upstream's somewhat  
random decision to rename a bunch of internal variables and struct  
fields.  However, there is an interesting new feature in zic:  
it's grown a "-b slim" option that emits zone files without 32-bit  
data and other backwards-compatibility hacks.  We should consider  
whether we wish to enable that.  

commit   : e0d13dc6fd71cc647af8aaa82179f1b878f41437    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    

This should lappend the OIDs, not lcons them; the existing code produced  
a list in reversed order.  This is harmless for single-key FKs or FKs  
where all the key columns are of the same type, which probably explains  
how it went unnoticed.  But if those conditions are not met,  
ATAddForeignKeyConstraint would make the wrong decision about whether an  
existing FK needs to be revalidated.  I think it would almost always err  
in the safe direction by revalidating a constraint that didn't need it.  
You could imagine scenarios where the pfeqop check was fooled by  
swapping the types of two FK columns in one ALTER TABLE, but that case  
would probably be rejected by other tests, so it might be impossible to  
get to the worst-case scenario where an FK should be revalidated and  
isn't.  (And even then, it's likely to be fine, unless there are weird  
inconsistencies in the equality behavior of the replacement types.)  
However, this is a performance bug at least.  
  
Noted while poking around to see whether lcons calls could be converted  
to lappend.  
  
This bug is old, dating to commit cb3a7c2b9, so back-patch to all  
supported branches.  

commit   : 178ca6b26c3d59ff330b229f11fca89001749ea1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 21:18:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 21:18:49 -0400    

Reported-by: John Naylor  
  
Discussion: https://postgr.es/m/CACPNZCs2c7yLGKhtcL=h9OmZdwQQDshFs9Bxypo=Fc5b0TVsMQ@mail.gmail.com  
  
Backpatch-through: 12  

commit   : d116ebca6ccc3712dadd024be3d14852c7e03984    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    

Reported-by: Ian Barwick  
  
Discussion: https://postgr.es/m/538950ec-b86a-1650-6078-beb7091c09c2@2ndquadrant.com  
  
Backpatch-through: 9.4  

commit   : ac37bd51a4227683529f37148d6aefc95c837abb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 14:35:05 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 14:35:05 -0700    

The logic just added by commit e3899ffd falls back on a 50:50 page split  
in the event of a new item that's just to the right of our provisional  
"many duplicates" split point.  Fix a comment that incorrectly claimed  
that the new item had to be just to the left of our provisional split  
point.  
  
Backpatch: 12-, just like commit e3899ffd.  

commit   : 2f23453e492955c32d952bc1cff651e66657d32b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 13:19:12 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 13:19:12 -0700    

Specific ever-decreasing insertion patterns could cause successive  
unbalanced nbtree page splits.  Problem cases involve a large group of  
duplicates to the left, and ever-decreasing insertions to the right.  
  
To fix, detect the situation by considering the newitem offset before  
performing a split using nbtsplitloc.c's "many duplicates" strategy.  If  
the new item was inserted just to the right of our provisional "many  
duplicates" split point, infer ever-decreasing insertions and fall back  
on a 50:50 (space delta optimal) split.  This seems to barely affect  
cases that already had acceptable space utilization.  
  
An alternative fix also seems possible.  Instead of changing  
nbtsplitloc.c split choice logic, we could instead teach _bt_truncate()  
to generate a new value for new high keys by interpolating from the  
lastleft and firstright key values.  That would certainly be a more  
elegant fix, but it isn't suitable for backpatching.  
  
Discussion: https://postgr.es/m/CAH2-WznCNvhZpxa__GqAa1fgQ9uYdVc=_apArkW2nc-K3O7_NA@mail.gmail.com  
Backpatch: 12-, where the nbtree page split enhancements were introduced.  

commit   : dd5e47a92cfce52e3e35233a33b190ea498eed84    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    

We choose a random value for delta, not balance.  Back-patch to 9.6 where  
the mistake arrived.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081752210.5867@lancre  

commit   : dffb891d78cb0db0db010c2f263b8cff72e03aaa    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Jul 2019 13:34:22 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Jul 2019 13:34:22 -0700    

Commit 578b229718e8f15fa779e20f086c4b6bb3776106 replaced it with a  
concurrent "nextval" test.  That version does not detect PostgreSQL's  
incompatibility with xlc 13.1.3, so bring back an OID-based test that  
does.  Back-patch to v12, where that commit first appeared.  
  
Discussion: https://postgr.es/m/20190707170035.GA1485546@rfd.leadboat.com  

commit   : de14e54d7bd71f9256aae08dec832af25da3fd35    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 14:43:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 14:43:48 +0900    

This adds some missing markups, fixes a couple of incorrect ones and  
clarifies some documentation in various places.  
  
Author: Liudmila Mantrova  
Discussion: https://postgr.es/m/a068f947-7a51-5df1-b3fd-1a131ae5c044@postgrespro.ru  
Backpatch-through: 12  

commit   : cee976c4e8c4d97286a015ab54aa859faf839b54    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jul 2019 16:24:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jul 2019 16:24:59 -0400    

Commit 3ca930fc3 modified get_actual_variable_range() to use a new  
"SnapshotNonVacuumable" snapshot type for selecting tuples that it  
would consider valid.  However, because that snapshot type can accept  
recently-dead tuples, this caused a bug when using a recently-created  
index: we might accept a recently-dead tuple that is an early member  
of a broken HOT chain and does not actually match the index entry.  
Then, the data extracted from the heap tuple would not necessarily be  
an endpoint value of the column; it could even be NULL, leading to  
get_actual_variable_range() itself reporting "found unexpected null  
value in index".  Even without an error, this could lead to poor  
plan choices due to an erroneous notion of the endpoint value.  
  
We can improve matters by changing the code to use the index-only  
scan technique (which didn't exist when get_actual_variable_range was  
originally written).  If any of the tuples in a HOT chain are live  
enough to satisfy SnapshotNonVacuumable, we take the data from the  
index entry, ignoring what is in the heap.  This fixes the problem  
without changing the live-vs-dead-tuple behavior from what was  
intended by commit 3ca930fc3.  
  
A side benefit is that for static tables we might not have to touch  
the heap at all (when the extremal value is in an all-visible page).  
In addition, we can save some overhead by not having to create a  
complete ExecutorState, and we don't need to run FormIndexDatum,  
avoiding more cycles as well as the possibility of failure for  
indexes on expressions.  (I'm not sure that this code would ever  
be used to determine the extreme value of an expression, in the  
current state of the planner; but it's definitely possible that  
lower-order columns of the selected index could be expressions.  
So one could construct perhaps-artificial examples in which the  
old code unexpectedly failed due to trying to compute an  
expression's value for a now-dead row.)  
  
Per report from Manuel Rigger.  Back-patch to v11 where commit  
3ca930fc3 came in.  
  
Discussion: https://postgr.es/m/CA+u7OA7W4NWEhCvftdV6_8bbm2vgypi5nuxfnSEJQqVKFSUoMg@mail.gmail.com  

commit   : 30a268ed2e2944b3902d3e10a9876e498a0c12b9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 12 Jul 2019 19:11:45 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 12 Jul 2019 19:11:45 +1200    

match_clause_to_partition_key incorrectly would return  
PARTCLAUSE_UNSUPPORTED if a bool qual could not be matched to the current  
partition key.  This was a problem, as it causes the calling function to  
discard the qual and not try to match it to any other partition key.  If  
there was another partition key which did match this qual, then the qual  
would not be checked again and we could fail to prune some partitions.  
  
The worst this could do was to cause partitions not to be pruned when they  
could have been, so there was no danger of incorrect query results here.  
  
Fix this by changing match_boolean_partition_clause to have it return a  
PartClauseMatchStatus rather than a boolean value.  This allows it to  
communicate if the qual is unsupported or if it just does not match this  
particular partition key, previously these two cases were treated the  
same.  Now, if match_clause_to_partition_key is unable to match the qual  
to any other qual type then we can simply return the value from the  
match_boolean_partition_clause call so that the calling function properly  
treats the qual as either unmatched or unsupported.  
  
Reported-by: Rares Salcudean  
Reviewed-by: Amit Langote  
Backpatch-through: 11 where partition pruning was introduced  
Discussion: https://postgr.es/m/CAHp_FN2xwEznH6oyS0hNTuUUZKp5PvegcVv=Co6nBXJ+mC7Y5w@mail.gmail.com  

commit   : 1ed89826b82c693c311d9974f3f3138013f1b929    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 11 Jul 2019 18:18:15 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 11 Jul 2019 18:18:15 +0300    

Reported-by: Thom Brown  
Discussion: https://postgr.es/m/CAA-aLv4Tggy6Z3kaG9n%2B3SHwOVGN2Yj_MJXfdfwjH_jBNZzJNA%40mail.gmail.com  
Backpatch-through: 12  

commit   : ff597b656febe152b1650fc5619e57fbd1364c2c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Jul 2019 14:24:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Jul 2019 14:24:36 -0400    

It is now always displayed in PG 12+.  
  
Discussion: https://postgr.es/m/b6ec6167-5dd5-6347-ac1d-1fd49382019f@2ndquadrant.com  
  
Author: Ian Barwick  
  
Backpatch-through: 12  

commit   : 220857a87508fdac3fd4caf5f344a8fe9e70702d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 Jul 2019 08:58:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 Jul 2019 08:58:41 -0400    

Per gripe from Phil Bayer.  
  
Authors: Amit Langote and others  
Discussion: https://postgr.es/m/156236160709.1192.4498528196556144085@wrigleys.postgresql.org  

commit   : a5c2f3a346fcda21d3dc9227b2c07854a7973729    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 10 Jul 2019 15:43:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 10 Jul 2019 15:43:53 +0300    

This commit contains assorted fixes for jsonpath documentation including:  
grammar fixes, incorrect examples fixes as well as wording improvements.  
  
Discussion: https://postgr.es/m/CAA-aLv4VVX%3Db9RK5hkfPXJczqaiTdqO04teW9i0wiQVhdKcqzw%40mail.gmail.com  
Author: Liudmila Mantrova  
Reviewed-by: Alexander Korotkov  
Reported-by: Thom Brown  
Backpatch-through: 12  

commit   : 4d713595914beb705539ca5cd09c8b3a95f65c70    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jul 2019 15:15:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jul 2019 15:15:03 +0900    

This can cause valgrind to complain, as the flag marking a buffer as a  
temporary copy was not getting initialized.  
  
While on it, fill in with zeros newly-created buffer pages.  This does  
not matter when loading a block from a temporary file, but it makes the  
push of an index tuple into a new buffer page safer.  
  
This has been introduced by 1d27dcf, so backpatch all the way down to  
9.4.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/15899-0d24fb273b3dd90c@postgresql.org  
Backpatch-through: 9.4  

commit   : b8ef33b2d14519da0d038e9d63f51a6714ef764a    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 10 Jul 2019 16:02:18 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 10 Jul 2019 16:02:18 +1200    

86b85044e abstracted calls to heap functions in COPY FROM to support a  
generic table AM.  However, when performing a copy into a partitioned  
table, this commit neglected to call table_finish_bulk_insert for each  
partition.  Before 86b85044e, when we always called the heap functions,  
there was no need to call heapam_finish_bulk_insert for partitions since  
it only did any work when performing a copy without WAL.  For partitioned  
tables, this was unsupported anyway, so there was no issue.  With  
pluggable storage, we can't make any assumptions about what the table AM  
might want to do in its equivalent function, so we'd better ensure we  
always call table_finish_bulk_insert each partition that's received a row.  
  
For now, we make the table_finish_bulk_insert call whenever we evict a  
CopyMultiInsertBuffer out of the CopyMultiInsertInfo.  This does mean  
that it's possible that we call table_finish_bulk_insert multiple times  
per partition, which is not a problem other than being an inefficiency.  
Improving this requires a more invasive patch, so let's leave that for  
another day.  
  
This also changes things so that we no longer needlessly call  
table_finish_bulk_insert when performing a COPY FROM for a non-partitioned  
table when not using multi-inserts.  
  
Reported-by: Robert Haas  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com  

commit   : e33a1435be55f1f9aecff0337ed96f7e5092b146    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Jul 2019 07:59:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Jul 2019 07:59:51 +0530    

Reported-by: Ashwin Agrawal  
Author: Ashwin Agrawal  
Reviewed-by: Amit Kapila  
Backpatch-through: 12, where it was introduced  
Discussion: https://postgr.es/m/CALfoeisgdZhYDrJOukaBzvXfJOK2FQ0szVMK7dzmcy6w93iDUA@mail.gmail.com  

commit   : abbb2e14321313374c5fff3d3ecb626d98ee353e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 10 Jul 2019 10:15:43 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 10 Jul 2019 10:15:43 +1200    

Otherwise the executor can't see trigger transition tables during  
EPQ evaluation.  Fixes bug #15900 and almost certainly also #15720.  
Back-patch to 10, where trigger transition tables landed.  
  
Author: Alex Aktsipetrov  
Reviewed-by: Thomas Munro, Tom Lane  
Discussion: https://postgr.es/m/15900-bc482754fe8d7415%40postgresql.org  
Discussion: https://postgr.es/m/15720-38c2b29e5d720187%40postgresql.org  

commit   : ae0a2945b45ce63b7945284a7ddbb3e1c286fe95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Jul 2019 17:16:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Jul 2019 17:16:36 -0400    

We were creating the cloned triggers with an empty list of arguments,  
losing the ones that had been specified by the user when creating the  
trigger in the partitioned table.  Repair.  
  
This was forgotten in commit 86f575948c77.  
  
Author: Patrick McHardy  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20190709130027.amr2cavjvo7rdvac@access1.trash.net  
Discussion: https://postgr.es/m/15752-123bc90287986de4@postgresql.org  

commit   : 48d6d5a2afa59c4cf83cad6719cbbf298ef27c08    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jul 2019 15:47:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jul 2019 15:47:09 +0200    

commit   : 5526baf54902a56c5bc1b4abe625acb33d7357bf    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 9 Jul 2019 18:11:01 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 9 Jul 2019 18:11:01 +1200    

Otherwise the regressplans.sh tests generate extremely slow nested  
loop joins.  Back-patch to 11 where the hash join tests came in.  
  
Reported-by: Michael Paquier  
Discussion: https://postgr.es/m/20190708055256.GB2709%40paquier.xyz  

commit   : d0217d5ef2b8c44fa786f7f96c514684a0a04b28    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 23:04:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 23:04:02 -0400    

Discussion: https://postgr.es/m/20190706202425.GA16933@telsasoft.com  
  
Author: Justin Pryzby  
  
Backpatch-through: 12  

commit   : 0d67263563517131c5cf9ba6df46fc2541bc7d9e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jul 2019 14:28:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jul 2019 14:28:42 +0200    

Document that the data types of replicated tables do not need to  
match.  The documentation previously claimed that they had to match.  
  
Author: Robert Treat <rob@xzilla.net>  
Discussion: https://www.postgresql.org/message-id/flat/CAJSLCQ13==D8Ka2YLyctTm0Y+8MhGYcX_zj7fU0rqRzhcV++3w@mail.gmail.com  

commit   : 58006f8041fffc9260b92fc2cb3a571aaa6c6d22    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:51:13 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:51:13 +0200    

Author: "Zhang, Jie" <zhangjie2@cn.fujitsu.com>  

commit   : cf665ad4c89eb9b20285dc04aec906d46ed810d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Jul 2019 11:25:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Jul 2019 11:25:37 -0400    

This code failed to account for the possibility that malloc() would  
change errno, resulting in wrong output for %m, not to mention the  
possibility of message truncation.  Such a change is obviously  
expected when malloc fails, but there's reason to fear that on some  
platforms even a successful malloc call can modify errno.  
  
Discussion: https://postgr.es/m/2576.1527382833@sss.pgh.pa.us  

commit   : c8e0997239840888a974624b0ab020177357f0ae    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 15:02:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 15:02:53 +0200    

commit   : d8ec5ebaea4455a5b19fa1bc8ec6eb299e93e835    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 14:58:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 14:58:08 +0200    

In normal interactive mode, psql's log messages accidentally got a  
"psql:" prefix that was not supposed to be there.  This only happened  
if there was no .psqlrc file being read, so it wasn't discovered for a  
while.  Fix this by adding the appropriate logging format  
configuration call in the right code path.  
  
Discussion: https://www.postgresql.org/message-id/7586.1560540361@sss.pgh.pa.us  

commit   : e5eba10d79bd8d919a5e8594d809cd99abd09f01    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 6 Jul 2019 11:45:39 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 6 Jul 2019 11:45:39 +0530    

Reported-by: Ashwin Agrawal  
Author: Ashwin Agrawal  
Reviewed-by: Amit Kapila  
Backpatch-through: 12, where it was introduced  
Discussion: https://postgr.es/m/CALfoeisgdZhYDrJOukaBzvXfJOK2FQ0szVMK7dzmcy6w93iDUA@mail.gmail.com  

commit   : a5dc37866add6552834ec5af6a0053f521fbcc62    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 18:06:02 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 18:06:02 +0200    

The itemlen variable used to be referenced in multiple places, but since  
reworking the serialization code it's used only in one assert. Fixed by  
removing the variable and calling the macro from the assert directly.  
  
Backpatch to 12, where this code was introduced.  
  
Reported-by: Jeff Janes  
Discussion: https://postgr.es/m/CAMkU=1zc_ovH9NZd_9ovuiEWkF9yX06URUDdXCmgDydf-bqB5A@mail.gmail.com  

commit   : e74d141d0d97a7a9f059cdb3cd91ff52599a629b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 00:45:20 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 00:45:20 +0200    

The serialization format of multivariate MCV lists included alignment in  
order to allow direct access to part of the serialized data, but despite  
multiple fixes (see for example commits d85e0f366a and ea4e1c0e8f) this  
proved to be problematic.  
  
This commit abandons alignment in the serialized format, and just copies  
everything during deserialization.  We now also track amount of memory  
needed after deserialization (including alignment), which allows us to  
deserialize the MCV list in a single pass.  
  
Bump catversion, as this affects contents of pg_statistic_ext_data.  
  
Backpatch to 12, where multi-column MCV lists were introduced.  
  
Author: Tomas Vondra  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/2201.1561521148@sss.pgh.pa.us  

commit   : cc052b423ad7dc92abb3461a096408c3997c36e1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:43:04 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:43:04 +0200    

The function pg_mcv_list_items() returns values stored in MCV items. The  
items may contain columns with different data types, so the function was  
generating text array-like representation, but in an ad-hoc way without  
properly escaping various characters etc.  
  
Fixed by simply building a text[] array, which also makes it easier to  
use from queries etc.  
  
Requires changes to pg_proc entry, so bump catversion.  
  
Backpatch to 12, where multi-column MCV lists were introduced.  
  
Author: Tomas Vondra  
Reviewed-by: Dean Rasheed  
Discussion: https://postgr.es/m/20190618205920.qtlzcu73whfpfqne@development  

commit   : 57f459cf6c48e78aa321ac88418815fc65197517    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:02:02 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:02:02 +0200    

When building multi-column MCV lists, we compute base frequency for each  
item, i.e. a product of per-column frequencies for values from the item.  
As a value may be in multiple groups, the code was scanning the whole  
array of groups while adding items to the MCV list.  This works fine as  
long as the number of distinct groups is small, but it's easy to trigger  
trigger O(N^2) behavior, especially after increasing statistics target.  
  
This commit precomputes frequencies for values in all columns, so that  
when computing the base frequency it's enough to make a simple bsearch  
lookup in the array.  
  
Backpatch to 12, where multi-column MCV lists were introduced.  
  
Discussion: https://postgr.es/m/20190618205920.qtlzcu73whfpfqne@development  

commit   : 1970da1a0a7e9793d1676341fcb0c9a01f3db0dc    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jul 2019 08:33:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jul 2019 08:33:51 +0200    

commit   : 1dd8cf1b46a2e4ef68fc39771c21b8b737cf58b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 18:08:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 18:08:53 -0400    

A function that is declared to return a named composite type must  
return tuple datums that are physically marked as having that type.  
The plpgsql code path that allowed directly returning an expanded-record  
datum forgot to check that, so that an expanded record marked as type  
RECORDOID could be returned if it had a physically-compatible tupdesc.  
This'd be harmless, I think, if the record value never escaped the  
current session --- but it's possible for it to get stored into a table,  
and then subsequent sessions can't interpret the anonymous record type.  
  
Fix by flattening the record into a tuple datum and overwriting its  
type/typmod fields, if its declared type doesn't match the function's  
declared type.  (In principle it might be possible to just change the  
expanded record's stored type ID info, but there are enough tricky  
consequences that I didn't want to mess with that, especially not in  
a back-patched bug fix.)  
  
Per bug report from Steve Rogerson.  Back-patch to v11 where the bug  
was introduced.  
  
Discussion: https://postgr.es/m/cbaecae6-7b87-584e-45f6-4d047b92ca2a@yewtc.demon.co.uk  

commit   : 0cce43a716b40c555892b1d22b41d390ef524ec8    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 3 Jul 2019 23:45:25 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 3 Jul 2019 23:45:25 +1200    

d4c3a156c added code to remove columns that were not part of a table's  
PRIMARY KEY constraint from the GROUP BY clause when all the primary key  
columns were present in the group by.  This is fine to do since we know  
that there will only be one row per group coming from this relation.  
However, the logic failed to consider inheritance parent relations.  These  
can have child relations without a primary key, but even if they did, they  
could duplicate one of the parent's rows or one from another child  
relation.  In this case, those additional GROUP BY columns are required.  
  
Fix this by disabling the optimization for inheritance parent tables.  
In v11 and beyond, partitioned tables are fine since partitions cannot  
overlap and before v11 partitioned tables could not have a primary key.  
  
Reported-by: Manuel Rigger  
Discussion: http://postgr.es/m/CA+u7OA7VLKf_vEr6kLF3MnWSA9LToJYncgpNX2tQ-oWzYCBQAw@mail.gmail.com  
Backpatch-through: 9.6  

commit   : f2d069ce95b13f7ebfc4998ed708e3693166f46d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jul 2019 08:57:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 3 Jul 2019 08:57:22 +0900    

This fixes at the same time a set of inconsistencies in the  
documentation and the scripts related to the versions of Windows SDK  
supported.  
  
Author: Haribabu Kommi  
Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael  
Paquier  
Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com  
Backpatch-through: 9.4  

commit   : 91be5387c20dbd9a015b37064cb789a368974b00    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:44:30 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:44:30 +0100    

Author: Alexey Kondratov <a.kondratov@postgrespro.ru>  

commit   : 7956d7ac9811a6e97b3aef2ad00272c0b72dc7da    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:18:43 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:18:43 +0100    

These are no longer needed/allowed with the new logging API.  

commit   : a4ce93395ef7bced5fae3fbb46d52d0cf6eba2c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 14:04:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 14:04:42 -0400    

Commit 4f3b38fe2 supposed that complete_from_const() is equivalent to  
the one-element-list case of complete_from_list(), but that's not  
really true at all.  complete_from_const() supposes that the completion  
is certain enough to justify wiping out whatever the user typed, while  
complete_from_list() will only provide completions that match the  
word-so-far.  
  
In practice, given the lame parsing technology used by tab-complete.c,  
it's fairly hard to believe that we're *ever* certain enough about  
a completion to justify auto-correcting user input that doesn't match.  
  
Hence, remove the inappropriate unification of the two cases.  
As things now stand, complete_from_const() is used only for the  
situation where we have no matches and we need to keep readline  
from applying its default complete-with-file-names behavior.  
  
This (mis?) behavior actually exists much further back, but  
I'm hesitant to change it in released branches.  It's not too  
late for v12, though, especially seeing that the aforesaid  
commit is new in v12.  
  
Per gripe from Ken Tanzer.  
  
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com  

commit   : 4f3648de2a0bcd6eae89cb5cb0d177a672c9e239    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 13:35:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 13:35:14 -0400    

Don't think that the context "UPDATE tab SET var =" is a GUC-setting  
command.  
  
If we have "SET var =" but the "var" is not a known GUC variable,  
don't offer any completions.  The most likely explanation is that  
we've misparsed the context and it's not really a GUC-setting command.  
  
Per gripe from Ken Tanzer.  Back-patch to 9.6.  The issue exists  
further back, but before 9.6 the code looks very different and it  
doesn't actually know whether the "var" name matches anything,  
so I desisted from trying to fix it.  
  
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com  

commit   : d4b090f54fe8147157485b2c9b7753731e611354    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 19:46:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 19:46:04 -0400    

This reverts commit f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667,  
in the v12 branch only.  We don't want to ship v12 with that,  
since it causes occasional test failures (as a result of statistics  
transmission not being entirely reliable).  
  
I'll leave it in HEAD though, in hopes that we'll eventually  
capture an instance of the original problematic behavior.  

commit   : 9e1c9f959422192bbe1b842a2a1ffaf76b080196    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:37:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:37:52 -0400    

pgperltidy and reformat-dat-files too, though the latter didn't  
find anything to change.  

commit   : 145b18688c04963efcab8ef3e7e10659bf783eb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:09:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:09:06 -0400    

Looks like one copy of this text didn't get updated.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20190701155932.GA22866@telsasoft.com  

commit   : f5db56fc4d6e95c582b61c99328ea0702b869fa0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:44:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:44:56 +1200    

This reverts commits 4de60244e and b2d69806d. Further thought is  
required to make this work properly.  

commit   : b2d69806d8cc902802a7b56ba37fb7c55e58b0ed    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:07:15 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:07:15 +1200    

4de60244e added the call to table_finish_bulk_insert to the  
CopyMultiInsertBufferCleanup function.  We use a CopyMultiInsertBuffer even  
for non-partitioned tables, so having the cleanup do that meant we would  
call table_finsh_bulk_insert twice when performing COPY FROM with  
a non-partitioned table.  
  
Here we can just remove the direct call in CopyFrom and let  
CopyMultiInsertBufferCleanup handle the call instead.  

commit   : 4de60244e2fcdeb100afc7f8bf5c28b32923a637    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 01:23:26 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 01:23:26 +1200    

86b85044e abstracted calls to heap functions in COPY FROM to support a  
generic table AM.  However, when performing a copy into a partitioned  
table, this commit neglected to call table_finish_bulk_insert for each  
partition.  Before 86b85044e, when we always called the heap functions,  
there was no need to call heapam_finish_bulk_insert for partitions since  
it only did any work when performing a copy without WAL. For partitioned  
tables, this was unsupported anyway, so there was no issue. With pluggable  
storage, we can't make any assumptions about what the table AM might want  
to do in its equivalent function, so we'd better ensure we always call  
table_finish_bulk_insert each partition that's received a row.  
  
For now, we make the table_finish_bulk_insert call whenever we evict a  
CopyMultiInsertBuffer out of the CopyMultiInsertInfo.  This does mean  
that it's possible that we call table_finish_bulk_insert multiple times  
per partition, which is not a problem other than being an inefficiency.  
Improving this requires a more invasive patch, so let's leave that for  
another day.  
  
In passing, move the table_finish_bulk_insert for the target of the COPY  
command so that it's only called when we're actually performing bulk  
inserts.  We don't need to call this when inserting 1 row at a time.  
  
Reported-by: Robert Haas  
Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com  

commit   : 95bbe5d82e428db342fa3ec60b95f1b9873741e5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:34:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:34:31 +0200    

commit   : 1b29e990e352885642149262859b83c19d362405    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:07:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:07:14 +0200    

commit   : c74d49d41c9e0fabeb1179dcabfb3137833ed831    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jul 2019 10:00:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jul 2019 10:00:23 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/af27d1b3-a128-9d62-46e0-88f424397f44@gmail.com  

commit   : 459c3cdb4ad8323bfe6bcae0186a3831e0c89c94    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 30 Jun 2019 17:34:17 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 30 Jun 2019 17:34:17 -0700    

UBSan complains about this.  Instead, cast to a suitable type requiring  
only 4-byte alignment.  DatumGetAnyArrayP() already assumes one can cast  
between AnyArrayType and ArrayType, so this doesn't introduce a new  
assumption.  Back-patch to 9.5, where AnyArrayType was introduced.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190629210334.GA1244217@rfd.leadboat.com  

commit   : da53be23d1c5e529675e958eaee54cfed4e4dbac    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 30 Jun 2019 23:49:13 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 30 Jun 2019 23:49:13 +0100    

The logic in reorder_grouping_sets to order grouping set elements to  
match a pre-specified sort ordering was defective, resulting in  
unnecessary sort nodes (though the query output would still be  
correct). Repair, simplifying the code a little, and add a test.  
  
Per report from Richard Guo, though I didn't use their patch. Original  
bug seems to have been my fault.  
  
Backpatch back to 9.5 where grouping sets were introduced.  
  
Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2LsWw0WO1A@mail.gmail.com  

commit   : c000a47ad1fdd4fb92c7068279d97e0c3db4f8eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 14:05:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 14:05:24 -0400    

There's nothing to build here, and that was confusing AddContrib().  
Per buildfarm.  

commit   : 681cca86f5071379c4a8599ef9387b666b7e6879    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 13:34:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 13:34:45 -0400    

Up to now, pg_regress --config-auth had a hard-wired assumption  
that the target cluster uses the default bootstrap superuser name.  
pg_dump's 010_dump_connstr.pl TAP test uses non-default superuser  
names, and was klugily getting around the restriction by listing  
the desired superuser name as a role to "create".  This is pretty  
confusing (or at least, it confused me).  Let's make it clearer by  
allowing --config-auth mode to be told the bootstrap superuser name.  
Repurpose the existing --user switch for that, since it has no  
other function in --config-auth mode.  
  
Per buildfarm.  I don't have an environment at hand in which I can  
test this fix, but the buildfarm should soon show if it works.  
  
Discussion: https://postgr.es/m/3142.1561840611@sss.pgh.pa.us  

commit   : c91504b958e1647f87ffb7168e61db75ca09b928    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 12:51:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 12:51:08 -0400    

This test script is unsafe to run in "make installcheck" mode for  
(at least) two reasons: it creates and destroys some role names  
that don't follow the "regress_xxx" naming convention, and it  
sets and then resets the application_name GUC attached to every  
existing role.  While we've not had complaints, these surely are  
not good things to do within a production installation, and  
regress.sgml pretty clearly implies that we won't do them.  
  
Rather than lose test coverage altogether, let's just move this  
script somewhere where it will get run by "make check" but not  
"make installcheck".  src/test/modules/ already has that property.  
  
Since it seems likely that we'll want other regression tests in  
future that also exceed the constraints of "make installcheck",  
create a generically-named src/test/modules/unsafe_tests/  
directory to hold them.  
  
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us  

commit   : 2e810508f6b0d89621094445620a1bea3ceff3f1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 13:25:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 13:25:33 +0200    

Using PG_RETURN_LSN() from non-fmgr pg_lsn_in_internal() happened to  
work on some platforms, but should just be a plain "return".  

commit   : 21f428ebde39339487c271a830fed135d6032d73    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 10:15:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 10:15:25 +0200    

Instead of calling pg_lsn_in() in check_recovery_target_lsn and  
timestamptz_in() in check_recovery_target_time, reorganize the  
respective code so that we don't raise any errors in the check hooks.  
The previous code tried to use PG_TRY/PG_CATCH to handle errors in a  
way that is not safe, so now the code contains no ereport() calls and  
can operate safely within the GUC error handling system.  
  
Moreover, since the interpretation of the recovery_target_time string  
may depend on the time zone, we cannot do the final processing of that  
string until all the GUC processing is done.  Instead,  
check_recovery_target_time() now does some parsing for syntax  
checking, but the actual conversion to a timestamptz value is done  
later in the recovery code that uses it.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/20190611061115.njjwkagvxp4qujhp%40alap3.anarazel.de  

commit   : 666cbae16da46b833f57ef8b12ff0bf215684d9c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 12 Jun 2019 11:29:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 12 Jun 2019 11:29:53 +0200    

The date/time values 'current', 'invalid', and 'undefined' were  
removed a long time ago, but the code still contains explicit error  
handling for the transition.  To simplify the code and avoid having to  
handle these values everywhere, just remove the recognition of these  
tokens altogether now.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

commit   : 54100f5c6052404f68de9ce7310ceb61f1c291f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:34:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:34:00 -0400    

In commit 18555b132 we tentatively established a rule that regression  
tests should use names containing "regression" for databases, and names  
starting with "regress_" for all other globally-visible object names, so  
as to circumscribe the side-effects that "make installcheck" could have  
on an existing installation.  
  
This commit adds a simple enforcement mechanism for that rule: if the code  
is compiled with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS defined, it  
will emit a warning (not an error) whenever a database, role, tablespace,  
subscription, or replication origin name is created that doesn't obey the  
rule.  Running one or more buildfarm members with that symbol defined  
should be enough to catch new violations, at least in the regular  
regression tests.  Most TAP tests wouldn't notice such warnings, but  
that's actually fine because TAP tests don't execute against an existing  
server anyway.  
  
Since it's already the case that running src/test/modules/ tests in  
installcheck mode is deprecated, we can use that as a home for tests  
that seem unsafe to run against an existing server, such as tests that  
might have side-effects on existing roles.  Document that (though this  
commit doesn't in itself make it any less safe than before).  
  
Update regress.sgml to define these restrictions more clearly, and  
to clean up assorted lack-of-up-to-date-ness in its descriptions of  
the available regression tests.  
  
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us  

commit   : ca129e58c01f29ef24a734313ff315933b3d5b67    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:09:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:09:03 -0400    

In commit 18555b132 we tentatively established a rule that regression  
tests should use names containing "regression" for databases, and names  
starting with "regress_" for all other globally-visible object names, so  
as to circumscribe the side-effects that "make installcheck" could have on  
an existing installation.  However, no enforcement mechanism was created,  
so it's unsurprising that some new violations have crept in since then.  
  
In fact, a whole new *category* of violations has crept in, to wit we now  
also have globally-visible subscription and replication origin names, and  
"make installcheck" could very easily clobber user-created objects of  
those types.  So it's past time to do something about this.  
  
This commit sanitizes the tests enough that they will pass (i.e. not  
generate any visible warnings) with the enforcement mechanism I'll add  
in the next commit.  There are some TAP tests that still trigger the  
warnings, but the warnings do not cause test failure.  Since these tests  
do not actually run against a pre-existing installation, there's no need  
to worry whether they could conflict with user-created objects.  
  
The problem with rolenames.sql testing special role names like "user"  
is still there, and is dealt with only very cosmetically in this patch  
(by hiding the warnings :-().  What we actually need to do to be safe is  
to take that test script out of "make installcheck" altogether, but that  
seems like material for a separate patch.  
  
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us  

commit   : a1e61badf97bc446053145ba40de6db835678ce3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 10:30:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 10:30:08 -0400    

Since we generate such names internally, it seems like a good idea  
to have a policy of disallowing them for user use, as we do for many  
other object types.  Otherwise attempts to use them will randomly  
fail due to collisions with internally-generated names.  
  
Discussion: https://postgr.es/m/3606.1561747369@sss.pgh.pa.us  

commit   : c0faa727507ed34db0d02769d21bbaaf9605e2e4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 29 Jun 2019 11:14:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 29 Jun 2019 11:14:21 +0900    

libpq/libpq-be.h is included by libpq/libpq.h so there is no need to  
explicitly include it separately.  
  
Author: Daniel Gustafsson  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/A4852E46-9ED1-4861-A23B-22A83E34A084@yesql.se  

commit   : 23cccb17fe0bbb5df86780da5c346cc060c21421    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Jun 2019 14:51:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Jun 2019 14:51:08 -0400    

We forgot to map column numbers to/from the default partition for  
various operations, leading to valid cases failing with spurious  
errors, such as  
ERROR:  attribute N of type some_partition has been dropped  
  
It was also possible that the search for conflicting rows in the default  
partition when attaching another partition would fail to detect some.  
Secondarily, it was also possible that such a search should be skipped  
(because the constraint was implied) but wasn't.  
  
Fix all this by mapping column numbers when necessary.  
  
Reported by: Daniel Wilches  
Author: Amit Langote  
Discussion: https://postgr.es/m/15873-8c61945d6b3ef87c@postgresql.org  

commit   : 74b7cc8c02137f059703972aa14445b1e073f005    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 28 Jun 2019 11:11:26 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 28 Jun 2019 11:11:26 +1200    

The stated reason for acquiring predicate locks on heap pages hasn't  
existed since commit c01262a8, so fix the comment.  Perhaps in a later  
release we'll also be able to change the code to use tuple locks.  
  
Back-patch all the way.  
  
Reviewed-by: Ashwin Agrawal  
Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com  

commit   : 69fd82fedd746b82427097883daf2921dd77584e    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 27 Jun 2019 17:41:29 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 27 Jun 2019 17:41:29 +0200    

Commit 83e176ec1 moved row sampling functions from analyze.c to  
utils/misc/sampling.c, but failed to update comment referring to  
the sampling algorithm from Jeff Vitter's paper. Correct the  
comment by pointing to utils/misc/sampling.c.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK154gp%2BQd%3DcorQOv%2BPmbyVyZBjp_%2Bhb766UJeD1e_ie6XQ%40mail.gmail.com  

commit   : 050098b14e33a5d3dfabf172ebbddd20c6bb4665    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Jun 2019 11:57:10 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Jun 2019 11:57:10 -0400    

Evidenced by failure under RELCACHE_FORCE_RELEASE (buildfarm member  
prion).  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqGV=k_Eh4jBiQw66ivvdG+EUkrEYeHTYL1SvDj_YOYV0g@mail.gmail.com  

commit   : f2f0082ef5969b57d0b52d0c2e891872ed1b0a51    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Jun 2019 15:57:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Jun 2019 15:57:14 +0200    

Function was renamed/replaced in  
c2fe139c201c48f1133e9fbea2dd99b8efe2fadd but the header comment was  
not updated.  

commit   : 322c5bfdc3d76f6463768ecd8fced30c881b8be5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Jun 2019 08:25:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Jun 2019 08:25:26 +0900    

fe0a0b5 has removed the last use of this routine from pgcrypto, leading  
to a useless symbol definition and an extra configure check.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/20190626142544.GN1714@paquier.xyz  

commit   : 55ed3defc966cf718fe1e8c0efe964580bb23351    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jun 2019 18:38:51 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jun 2019 18:38:51 -0400    

When a partitioned tables contains foreign tables as partitions, it is  
not possible to implement unique or primary key indexes -- but when  
regular indexes are created, there is no reason to do anything other  
than ignoring such partitions.  We were raising errors upon encountering  
the foreign partitions, which is unfriendly and doesn't protect against  
any actual problems.  
  
Relax this restriction so that index creation is allowed on partitioned  
tables containing foreign partitions, becoming a no-op on them.  (We may  
later want to redefine this so that the FDW is told to create the  
indexes on the foreign side.)  This applies to CREATE INDEX, as well as  
ALTER TABLE / ATTACH PARTITION and CREATE TABLE / PARTITION OF.  
  
Backpatch to 11, where indexes on partitioned tables were introduced.  
  
Discussion: https://postgr.es/m/15724-d5a58fa9472eef4f@postgresql.org  
Author: Álvaro Herrera  
Reviewed-by: Amit Langote  

commit   : 65e6d42140c8d9918638b9f73528288ab980af82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 23:06:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 23:06:17 -0400    

contrib/amcheck didn't get the memo either.  

commit   : c360477d2e2f65fdea64aa8bc94a6286d0883f7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 22:53:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 22:53:42 -0400    

Commit 1c5d9270e had not gotten the word about this.  (For previous  
context, see 18555b132.)  

commit   : d993e0fb82ffaa15be72c1ac10403bfa06708069    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Jun 2019 10:44:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Jun 2019 10:44:46 +0900    

Up to now, the MSVC build scripts are able to support only one fixed  
version of OpenSSL, and they lacked logic to detect the version of  
OpenSSL a given compilation of Postgres is linking to (currently 1.0.2,  
the latest LTS of upstream which will be EOL'd at the end of 2019).  
  
This commit adds more logic to detect the version of OpenSSL used by a  
build and makes use of it to add support for compilation with OpenSSL  
1.1.0 which requires a new set of compilation flags to work properly.  
  
The supported OpenSSL installers have changed their library layer with  
various library renames with the upgrade to 1.1.0, making the logic a  
bit more complicated.  The scripts are now able to adapt to the new  
world order.  
  
Reported-by: Sergey Pashkov  
Author: Juan José Santamaría Flecha, Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/15789-8fc75dea3c5a17c8@postgresql.org  

commit   : ce59b75d449d9152667ce3e9eab33ef2872bfd98    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Jun 2019 09:09:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Jun 2019 09:09:27 +0900    

a96c41f has introduced the option for heap, but it still lacked the  
variant to control the behavior for toast relations.  
  
While on it, refactor the tests so as they stress more scenarios with  
the various values that vacuum_index_cleanup can use.  It would be  
useful to couple those tests with pageinspect to check that pages are  
actually cleaned up, but this is left for later.  
  
Author: Masahiko Sawada, Michael Paquier  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com  

commit   : 0089c3059cb6b3dd20cf072f26d1a7a33412df39    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:29:53 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:29:53 +1200    

It's useful to be able to pass down options like -s and -j.  
  
Back-patch to 9.5, like commit a76200de.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2Be1M8-BbL%3DPqhTp6oO6XPO6%2Bs9WGQMLfbuZ%3DG9CtzyXg%40mail.gmail.com  

commit   : a2dec374807565f6337915fb236bb3ae37af0644    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:17:04 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:17:04 +1200    

As of commit e5253fdc, it is no longer true that the leader always  
executes the subplan of a Gather Merge node.  Remove comment to that  
effect.  
  
Back-patch to 11.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJEaZJYezXAOutuiWT%2BfxCA44%2BoKtVPAND2ubLiigR%3D-w%40mail.gmail.com  

commit   : ccfcc8fdbd9bdbfd18fda5d7c698af8d175f5319    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 17:19:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 17:19:32 -0400    

Move ATExecAlterColumnGenericOptions away from where it was unthinkingly  
dropped, in the middle of a lot of ALTER COLUMN TYPE code.  I don't have  
any high principles about where to put it instead, so let's just put it  
after ALTER COLUMN TYPE and before ALTER OWNER, matching existing  
decisions about how to order related code stanzas.  
  
Also add the minimal function header comment that the original author  
was too cool to bother with.  
  
Along the way, upgrade header comments for nearby ALTER COLUMN TYPE  
functions.  
  
Discussion: https://postgr.es/m/14787.1561403130@sss.pgh.pa.us  

commit   : 82be666ee36842af2a1b81e570bd5578f264de65    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:15:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:15:43 +0200    

commit   : 2cadefbb97ff8e5566476780dc200db06af6ba09    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:50 +0200    

commit   : eb8d05bfeca416a970cc33af5915ec7b4f4a2f69    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:29 +0200    

commit   : f946a409143d01951411382fbc3c91c7eb640094    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 16:43:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 16:43:05 -0400    

This patch reverts all the code changes of commit e76de8861, which turns  
out to have been seriously misguided.  We can't wait till later to compute  
the definition string for an index; we must capture that before applying  
the data type change for any column it depends on, else ruleutils.c will  
deliverr wrong/misleading results.  (This fine point was documented  
nowhere, of course.)  
  
I'd also managed to forget that ATExecAlterColumnType executes once per  
ALTER COLUMN TYPE clause, not once per statement; which resulted in the  
code being basically completely broken for any case in which multiple ALTER  
COLUMN TYPE clauses are applied to a table having non-constraint indexes  
that must be rebuilt.  Through very bad luck, none of the existing test  
cases nor the ones added by e76de8861 caught that, but of course it was  
soon found in the field.  
  
The previous patch also had an implicit assumption that if a constraint's  
index had a dependency on a table column, so would the constraint --- but  
that isn't actually true, so it didn't fix such cases.  
  
Instead of trying to delete unneeded index dependencies later, do the  
is-there-a-constraint lookup immediately on seeing an index dependency,  
and switch to remembering the constraint if so.  In the unusual case of  
multiple column dependencies for a constraint index, this will result in  
duplicate constraint lookups, but that's not that horrible compared to all  
the other work that happens here.  Besides, such cases did not work at all  
before, so it's hard to argue that they're performance-critical for anyone.  
  
Per bug #15865 from Keith Fiske.  As before, back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org  

commit   : b00326df7ad4ab7d21aad3b6fe6558ea6b61897d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 Jun 2019 10:31:58 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 Jun 2019 10:31:58 -0700    

Oversight in commit dd299df8.  

commit   : f31111bbe81db0e84fb486c6423a234c47091b30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 12:36:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 12:36:51 -0400    

Commit d7f8d26d9 added a test case that created a user, but forgot  
to drop it again.  This is no good; for one thing, it causes repeated  
"make installcheck" runs to fail.  

commit   : 12e037e2090b1a6446376814ea0419463b02c254    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Jun 2019 10:39:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Jun 2019 10:39:12 +0200    

As part of REINDEX CONCURRENTLY, this formerly internal-only error  
message becomes potentially user-visible (see regression tests), so  
change from errmsg_internal() to errmsg(), and update comment.  

commit   : 9a81c9fa3f6a2f57b9db2a1ce5584c85fc1d977e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Jun 2019 12:02:19 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Jun 2019 12:02:19 -0700    

This code is new in v12, and the defect probably was not user-visible.  

commit   : d7f8d26d9f4c0a574250ec53a03b3dc08d13796c    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 23 Jun 2019 18:50:08 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 23 Jun 2019 18:50:08 +0100    

The multivariate MCV estimation code may run user-defined operators on  
the values in the MCV list, which means that those operators may  
potentially leak the values from the MCV list. Guard against leaking  
data to unprivileged users by checking that the user has SELECT  
privileges on the table or all of the columns referred to by the  
statistics.  
  
Additionally, if there are any securityQuals on the RTE (either due to  
RLS policies on the table, or accessing the table via a security  
barrier view), not all rows may be visible to the current user, even  
if they have table or column privileges. Thus we further insist that  
the operator be leakproof in this case.  
  
Dean Rasheed, reviewed by Tomas Vondra.  
  
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui=Vdx4N==VV5XOK5dsXfnGgVOz_JhAicB=ZA@mail.gmail.com  

commit   : 89ff7c08eee355195eba6f544d28584e61200665    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 23 Jun 2019 22:19:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 23 Jun 2019 22:19:59 +1200    

Author: Vik Fearing  
Discussion: https://postgr.es/m/150d3e9f-c7ec-3fb3-4fdb-def47c4144af%402ndquadrant.com  

commit   : 1323bfce55109dd54ee164828aab7983d3020a25    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jun 2019 20:31:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jun 2019 20:31:50 -0400    

Original MIPS-I processors didn't have the LL/SC instructions (nor any  
other userland synchronization primitive).  If the build toolchain  
targets that ISA variant by default, as an astonishingly large fraction  
of MIPS platforms still do, the assembler won't take LL/SC without  
coercion in the form of a ".set mips2" instruction.  But we issued that  
unconditionally, making it an ISA downgrade for chips later than MIPS2.  
That breaks things for the latest MIPS r6 ISA, which encodes these  
instructions differently.  Adjust the code so we don't change ISA level  
if it's >= 2.  
  
Note that this patch doesn't change what happens on an actual MIPS-I  
processor: either the kernel will emulate these instructions  
transparently, or you'll get a SIGILL failure.  That tradeoff seemed  
fine in 2002 when this code was added (cf 3cbe6b247), and it's even  
more so today when MIPS-I is basically extinct.  But let's add a  
comment about that.  
  
YunQiang Su (with cosmetic adjustments by me).  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/15844-8f62fe7e163939b3@postgresql.org  

commit   : 660a2b19038b2f6b9f6bcb2c3297a47d5e3557a8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 21 Jun 2019 20:34:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 21 Jun 2019 20:34:23 -0700    

This fixes some TAP suites when using msys Perl and a builddir located  
in an msys mount point other than "/".  For example, builddir=/c/pg  
exhibited the problem, since /c/pg falls in mount point "/c".  
Back-patch to 9.6, where tests first started to perform such  
translations.  In back branches, offer both new and old APIs.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/20190610045838.GA238501@rfd.leadboat.com  

commit   : 25b93a2967a4ebfb90168ca087026cc697fc4b77    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 21 Jun 2019 10:57:07 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 21 Jun 2019 10:57:07 +1200    

Commit 6753333f switched from a semaphore-based wait to a latch-based  
wait for ProcSleep()/ProcWakeup(), but left behind some stray references  
to semaphores.  
  
Back-patch to 9.5.  
  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/CA+hUKGLs5H6zhmgTijZ1OaJvC1sG0=AFXc1aHuce32tKiQrdEA@mail.gmail.com  

commit   : 20e1cc898da6f82b5680973c107e8a96d46caf01    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:28:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:28:12 +0900    

This makes the whole user experience more consistent when bumping into  
failures, and more in line with the rewording done via 508300e.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20190514153252.GA22168@alvherre.pgsql  

commit   : 252f9a2580b013fe45ba28bb6d7a4994abc93bb5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:04:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:04:56 +0900    

Author: Ian Barwick  
Discussion: https://postgr.es/m/087a6961-1aaf-e36c-b712-bd5a644da20a@2ndquadrant.com  

commit   : cd917ffb9a43e9e4699c2a89d495ee02a8701034    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:49:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:49:03 +0200    

Make wording more accurate and add strerror() information.  
  
Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com  

commit   : aba78ab4a9509e7ed92acefd707a99425568f49f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:43:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:43:31 +0200    

Currently, calling pg_upgrade with an invalid command-line option  
aborts pg_upgrade but leaves a pg_upgrade_internal.log file lying  
around.  Reorder things a bit so that that file is not created until  
all the options have been parsed.  
  
Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com  

commit   : dfd79e2d0e8f399785ca2f7c659b45fd620cba17    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:12 +0300    

The description is ended part way and PASSING clause is not implemented yet.  
But the variables might be passed as parameters to several jsonpath functions.  
So, complete the description based on the current implementation, leaving  
description of PASSING clause in TODO.  
  
Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com  
Author: Kyotaro Horiguchi, Alexander Korotkov  

commit   : 1ff8dc9f19ddf00e3ad69d7141f78341769cd8a3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:05 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:05 +0300    

Reference posix regex documentation section and list supported flags.  
  
Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com  
Author: Kyotaro Horiguchi, Alexander Korotkov  

commit   : 261a5c1928566f938cbda0f62dc16f6a2d1e871d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:40:58 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:40:58 +0300    

SQL/JSON standard defines that jsonpath 'like_regex' predicate should support  
the same set of flags as XQuery/XPath.  It appears that implementation of 'q'  
flag was missed.  This commit fixes that.  
  
Discussion: https://postgr.es/m/CAPpHfdtyfPsxLYiTjp5Ov8T5xGsB5t3CwE5%2B3PS%3DLLwA%2BxTJog%40mail.gmail.com  
Author: Nikita Glukhov, Alexander Korotkov  

commit   : d8594d123c155aeecd47fc2450f62f5100b2fbf0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:35:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:35:41 +0200    

The list of combining characters to ignore for calculating the display  
width of a string (used for example by psql) was wildly outdated and  
incorrect.  
  
Discussion: https://www.postgresql.org/message-id/flat/bbb19114-af1e-513b-08a9-61272794bd5c%402ndquadrant.com  

commit   : ac5bb8f275dd9b2746fe6d433f1c08c1c3bd3d61    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:26:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:26:42 +0200    

The SVG output produced by external tools needs some postprocessing.  
This is implemented by this new XSL stylesheet.  
  
Issues are:  
  
- SVG produced by Ditaa does not add a viewBox attribute to the svg  
  element, needed to make the image scalable.  
  
- SVG produced by Graphviz uses a stroke="transparent" attribute,  
  which is not valid SVG.  It appears to mostly work, but FOP  
  complains.  
  
Other tweaks can be added over time.  
  
This reverts 7dc78d8ef3e62f7e06d7767c63dcede048377b9a and  
29046c44f36099f4c979b1491fcf27db2f9184f9, which applied these fixes  
manually.  

commit   : 66013fe73095f851c151a17ccc7553abe6246891    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:59:26 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:59:26 +0200    

Author: Daniel Gustafsson  

commit   : 992fe54e77f66ed67b6480fcf7dd208b2cd28aac    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:38:23 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:38:23 +0200    

Commit a1ef920e27ba6ab3602aaf6d6751d8628fac1af8 replaced the use of  
slave with standby, but overlooked this comment.  
  
Author: Daniel Gustafsson  

commit   : 414cca40d506dd3f17b49ae3139853139192c2ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:18:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:18:50 +0900    

fc49e24 has removed the last use of this compile-time variable as WAL  
segment size is something that can now be set at initdb time, still this  
commit has forgotten some references to it.  
  
Discussion: https://postgr.es/m/20190617073228.GE18917@paquier.xyz  

commit   : 3c28fd2281223580b88473e5145b752cc7cbadf9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:02:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:02:19 +0900    

This record uses one metadata buffer and registers some data associated  
to the buffer, but when parsing the record for its description a direct  
access to the record data was done, but there is none.  This leads  
usually to an incorrect description, but can also cause crashes like in  
pg_waldump.  Instead, fix things so as the parsing uses the data  
associated to the metadata block.  
  
This is an oversight from 3d92796, so backpatch down to 11.  
  
Author: Michael Paquier  
Description: https://postgr.es/m/20190617013059.GA3153@paquier.xyz  
Backpatch-through: 11  

commit   : 23224563d97913aa824d04c498d59ad4d85fda38    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 18 Jun 2019 15:51:04 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 18 Jun 2019 15:51:04 -0700    

This fixes an embarrassing oversight I (Andres) made in 737a292b,  
namely missing two place where liverows/deadrows were used when  
converting those variables to pointers, leading to incrementing the  
pointer, rather than the value.  
  
It's not that actually that easy to trigger a crash: One needs tuples  
deleted by the current transaction, followed by a tuple deleted in  
another session, all in one page. Which is presumably why this hasn't  
been noticed before.  
  
Reported-By: Steve Singer  
Author: Steve Singer  
Discussion: https://postgr.es/m/c7988239-d42c-ddc4-41db-171b23b35e4f@ssinger.info  

commit   : 8b21b416ed621501db3be38817c298c57470524f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 18 Jun 2019 18:23:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 18 Jun 2019 18:23:16 -0400    

This puts back reverted commit de87a084c0a5, with some bug fixes.  
  
When two (or more) transactions are waiting for transaction T1 to release a  
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a  
spurious deadlock can be reported among the waiting transactions when T1  
finishes.  The simplest example case seems to be:  
  
T1: select id from job where name = 'a' for key share;  
Y: select id from job where name = 'a' for update; -- starts waiting for T1  
Z: select id from job where name = 'a' for key share;  
T1: update job set name = 'b' where id = 1;  
Z: update job set name = 'c' where id = 1; -- starts waiting for T1  
T1: rollback;  
  
At this point, transaction Y is rolled back on account of a deadlock: Y  
holds the heavyweight tuple lock and is waiting for the Xmax to be released,  
while Z holds part of the multixact and tries to acquire the heavyweight  
lock (per protocol) and goes to sleep; once T1 releases its part of the  
multixact, Z is awakened only to be put back to sleep on the heavyweight  
lock that Y is holding while sleeping.  Kaboom.  
  
This can be avoided by having Z skip the heavyweight lock acquisition.  As  
far as I can see, the biggest downside is that if there are multiple Z  
transactions, the order in which they resume after T1 finishes is not  
guaranteed.  
  
Backpatch to 9.6.  The patch applies cleanly on 9.5, but the new tests don't  
work there (because isolationtester is not smart enough), so I'm not going  
to risk it.  
  
Author: Oleksii Kliukin  
Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com  
Discussion: https://postgr.es/m/2815.1560521451@sss.pgh.pa.us  

commit   : aca127c105aae551620d607e88d76930e6b9a2cf    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Jun 2019 22:38:30 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Jun 2019 22:38:30 +1200    

WHERE EXISTS (...) queries cannot be executed by Parallel Hash Join  
with jointype JOIN_UNIQUE_INNER, because there is no way to make a  
partial plan totally unique.  The consequence of allowing such plans  
was duplicate results from some EXISTS queries.  
  
Back-patch to 11.  Bug #15857.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane  
Reported-by: Vladimir Kriukov  
Discussion: https://postgr.es/m/15857-d1ba2a64bce0795e%40postgresql.org  

commit   : 0ab7110bcbcce5ff58afb32e7871c54e87502139    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jun 2019 17:12:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jun 2019 17:12:29 -0400    

commit   : 91acff7a538e6e6a8175450a38c7fa1d9a290011    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Jun 2019 15:07:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Jun 2019 15:07:14 +0200    

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

commit   : b67421178880f9df337dc19b8601b54b99efbc78    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 22:13:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 22:13:57 +0900    

When a client connects to a rogue server sending specifically-crafted  
messages, this can suffice to execute arbitrary code as the operating  
system account used by the client.  
  
While on it, fix one error handling when decoding an incorrect salt  
included in the first message received from server.  
  
Author: Michael Paquier  
Reviewed-by: Jonathan Katz, Heikki Linnakangas  
Security: CVE-2019-10164  
Backpatch-through: 10  

commit   : 09ec55b933091cb5b0af99978718cb3d289c71b6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 21:48:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 21:48:17 +0900    

Any authenticated user can overflow a stack-based buffer by changing the  
user's own password to a purpose-crafted value.  This often suffices to  
execute arbitrary code as the PostgreSQL operating system account.  
  
This fix is contributed by multiple folks, based on an initial analysis  
from Tom Lane.  This issue has been introduced by 68e61ee, so it was  
possible to make use of it at authentication time.  It became more  
easily to trigger after ccae190 which has made the SCRAM parsing more  
strict when changing a password, in the case where the client passes  
down a verifier already hashed using SCRAM.  Back-patch to v10 where  
SCRAM has been introduced.  
  
Reported-by: Alexander Lakhin  
Author: Jonathan Katz, Heikki Linnakangas, Michael Paquier  
Security: CVE-2019-10164  
Backpatch-through: 10  

commit   : 3412030205211079f9b0510e2244083e4ee7b15a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 16:13:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 16:13:16 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/0a5419ea-1452-a4e6-72ff-545b1a5a8076@gmail.com  

commit   : 9d20b0ec8f2af43041b1a65e5fcd91acc47e9ace    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 16 Jun 2019 22:24:21 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 16 Jun 2019 22:24:21 -0400    

This reverts commits 3da73d6839dc and de87a084c0a5.  
  
This code has some tricky corner cases that I'm not sure are correct and  
not properly tested anyway, so I'm reverting the whole thing for next  
week's releases (reintroducing the deadlock bug that we set to fix).  
I'll try again afterwards.  
  
Discussion: https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org  

commit   : 16c4e76f1b0a0145572551b7e919b967e406a0b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 14:02:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 14:02:22 -0400    

Now that we've back-patched that, it shouldn't be mentioned in v12  
anymore.  

commit   : 6973b058bc8d32e104bed99c134a4fab4b5dfe13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 11:00:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 11:00:23 -0400    

We don't need to restrict column privileges on pg_statistic_ext;  
all of that data is OK to read publicly.  What we *do* need to do,  
which was overlooked by 6cbfb784c, is revoke public read access on  
pg_statistic_ext_data; otherwise we still have the same security  
hole we started with.  
  
Catversion bump to ensure that installations calling themselves  
beta2 will have this fix.  
  
Diagnosis/correction by Dean Rasheed and Tomas Vondra, but I'm  
going to go ahead and push this fix ASAP so we get more buildfarm  
cycles on it.  
  
Discussion: https://postgr.es/m/8833.1560647898@sss.pgh.pa.us  

commit   : fc8cf3df478e054b892f6698b6d336e72f3a7328    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 16 Jun 2019 12:04:40 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 16 Jun 2019 12:04:40 +0200    

The GRANT in system_views allowed SELECT privileges on various columns in  
the pg_statistic_ext catalog, but tableoid was not included in the list.  
That made pg_dump fail because it's accessing this column when building  
the list of extended statistics to dump.  
  
Discussion: https://postgr.es/m/8833.1560647898%40sss.pgh.pa.us  

commit   : 7f44efa10b6ea3e5fd125e2800f357f38ab1068c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 15 Jun 2019 21:38:53 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 15 Jun 2019 21:38:53 +0200    

The example was incorrectly using parantheses around the list of columns, so  
just drop them.  
  
Reported-By: Robert Haas  
Discussion: https://postgr.es/m/CA%2BTgmoZZEMAqWMAfvLHZnK57SoxOutgvE-ALO94WsRA7zZ7wyQ%40mail.gmail.com  

commit   : aa087ec64f703a52f3c48c70117bb02e578f1802    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:25:04 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:25:04 +0200    

Regular per-column statistics are stored in pg_statistics catalog, which  
is however rather difficult to read, so we also have pg_stats view with  
a human-reablable version of the data.  
  
For extended statistic the catalog was fairly easy to read, so we did  
not have such human-readable view so far.  Commit 9b6babfa2d however did  
split the catalog into two, which makes querying harder.  Furthermore,  
we want to show the multi-column MCV list in a way similar to per-column  
stats (and not as a bytea value).  
  
This commit introduces pg_stats_ext view, joining the two catalogs and  
massaging the data to produce human-readable output similar to pg_stats.  
It also considers RLS and access privileges - the data is shown only when  
the user has access to all columns the extended statistic is defined on.  
  
Bumped CATVERSION due to adding new system view.  
  
Author: Dean Rasheed, with improvements by me  
Reviewed-by: Dean Rasheed, John Naylor  
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com  

commit   : 6cbfb784c3c91146148a76d50cda6f69ae6a79fb    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:19:21 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:19:21 +0200    

Since extended statistic got introduced in PostgreSQL 10, there was a  
single catalog pg_statistic_ext storing both the definitions and built  
statistic.  That's however problematic when a user is supposed to have  
access only to the definitions, but not to user data.  
  
Consider for example pg_dump on a database with RLS enabled - if the  
pg_statistic_ext catalog respects RLS (which it should, if it contains  
user data), pg_dump would not see any records and the result would not  
define any extended statistics.  That would be a surprising behavior.  
  
Until now this was not a pressing issue, because the existing types of  
extended statistic (functional dependencies and ndistinct coefficients)  
do not include any user data directly.  This changed with introduction  
of MCV lists, which do include most common combinations of values.  
  
The easiest way to fix this is to split the pg_statistic_ext catalog  
into two - one for definitions, one for the built statistic values.  
The new catalog is called pg_statistic_ext_data, and we're maintaining  
a 1:1 relationship with the old catalog - either there are matching  
records in both catalogs, or neither of them.  
  
Bumped CATVERSION due to changing system catalog definitions.  
  
Author: Dean Rasheed, with improvements by me  
Reviewed-by: Dean Rasheed, John Naylor  
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com  

commit   : e3846a00c2f87402dcedf7f07950ab2d89cf5827    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    

tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate  
zone with its own abbreviation. Unfortunately, our code for choosing a  
timezone in initdb has an arbitrary preference for names earlier in  
the alphabet, and so it would choose the spelling "UCT" over "UTC"  
when the system is running on a UTC zone.  
  
Commit 23bd3cec6 was backpatched in order to address this issue, but  
that code helps only when /etc/localtime exists as a symlink, and does  
nothing to help on systems where /etc/localtime is a copy of a zone  
file (as is the standard setup on FreeBSD and probably some other  
platforms too) or when /etc/localtime is simply absent (giving UTC as  
the default).  
  
Accordingly, add a preference for the spelling "UTC", such that if  
multiple zone names have equally good content matches, we prefer that  
name before applying the existing arbitrary rules. Also add a slightly  
lower preference for "Etc/UTC"; lower because that preserves the  
previous behaviour of choosing the shorter name, but letting us still  
choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does  
not (not common, but I've seen it happen).  
  
Backpatch all the way, because the tzdb change that sparked this issue  
is in those branches too.  

commit   : a193cbec1199e4e529c46645b7aecbf38956048b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:21:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:21:52 -0400    

Commit 7e413a0f82c8 added that option to pg_dump, but neglected to teach  
pg_dumpall how to pass it along.  Repair.  
  
Author: Fabien Coelho  
Reported-by: Peter Eisentraut  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/45f50c59-ddbb-8cf2-eedb-81003f603528@2ndquadrant.com  

commit   : 313f56ce2d1b9dfd3483e4f39611baa27852835a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:02:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:02:26 -0400    

Fixes some problems introduced by 6e5f8d489acc:  
  
* When reusing conninfo data from the previous connection in \connect,  
  the host address should only be reused if it was specified as  
  hostaddr; if it wasn't, then 'host' is resolved afresh.  We were  
  reusing the same IP address, which ignores a possible DNS change  
  as well as any other addresses that the name resolves to than the  
  one that was used in the original connection.  
  
* PQhost, PQhostaddr: Don't present user-specified hostaddr when we have  
  an inet_net_ntop-produced equivalent address.  The latter has been  
  put in canonical format, which is cleaner (so it produces "127.0.0.1"  
  when given "host=2130706433", for example).  
  
* Document the hostaddr-reusing aspect of \connect.  
  
* Fix some code comments  
  
Author: Fabien Coelho  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com  

commit   : 3da73d6839dc47f1f47ca57974bf28e5abd9b572    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 11:33:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 11:33:40 -0400    

Introduced in de87a084c0a5.  

commit   : b9a0724cf7a3ecf19aaaa098ffd26e52bb800c5c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 14 Jun 2019 09:30:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 14 Jun 2019 09:30:31 -0400    

Add mention of single-child optimization for partitions and UNION ALL.  
  
Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f8R8riwBXw==7ijV=UZNuhP+3qXgDBKSiM+=_cTf4mXXw@mail.gmail.com  

commit   : 08d2d58a2a1c8ef8d39e8132d39ee14a1d029500    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 14 Jun 2019 20:49:59 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 14 Jun 2019 20:49:59 +0900    

Commit aa09cd242 modified estimate_path_cost_size() so that it reuses  
cached costs of a basic foreign path for a given foreign-base/join  
relation when costing pre-sorted foreign paths for that relation, but it  
incorrectly re-computed retrieved_rows, an estimated number of rows  
fetched from the remote side, which is needed for costing both the basic  
and pre-sorted foreign paths.  To fix, handle retrieved_rows the same way  
as the cached costs: store in that relation's fpinfo the retrieved_rows  
estimate computed for costing the basic foreign path, and reuse it when  
costing the pre-sorted foreign paths.  Also, reuse the rows/width  
estimates stored in that relation's fpinfo when costing the pre-sorted  
foreign paths, to make the code consistent.  
  
In commit ffab494a4, to extend the costing mentioned above to the  
foreign-grouping case, I made a change to add_foreign_grouping_paths() to  
store in a given foreign-grouped relation's RelOptInfo the rows estimate  
for that relation for reuse, but this patch makes that change unnecessary  
since we already store the row estimate in that relation's fpinfo, which  
this patch reuses when costing a foreign path for that relation with the  
sortClause ordering; remove that change.  
  
In passing, fix thinko in commit 7012b132d: in estimate_path_cost_size(),  
the width estimate for a given foreign-grouped relation to be stored in  
that relation's fpinfo was reset incorrectly when costing a basic foreign  
path for that relation with local stats.  
  
Apply the patch to HEAD only to avoid destabilizing existing plan choices.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK17jaJLPDEkgnP2VmkOg=5wT8YQ1CqssU8JRpZ_NSE+dqQ@mail.gmail.com  

commit   : be2e024bd6527b050da4ad02c921869fed84bb5d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:53:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:53:20 -0400    

Reported-by: Robert Haas  
  
Discussion: https://postgr.es/m/CA+TgmoY==TZwk-4cM3Usebq1f=j7Hpm1brFbk1v48h45wsWzzg@mail.gmail.com  

commit   : 18ef7a34fe616dc63f7de672a5ab7dd88137dc5c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:07:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:07:25 -0400    

It was previously incorrectly placed in the server application section.  
  
Reported-by: Tatsuo Ishii  
  
Discussion: https://postgr.es/m/20190526.215341.1023150119477784132.t-ishii@sraoss.co.jp  

commit   : f43608bda2111a1fda514d1bed4df313ee2bbec3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:34:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:34:34 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com  

commit   : 96719e52b1abd3a8c712d06a809b7e6c97c2e3a0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:00:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:00:36 +0900    

In order to separate OpenSSL's SHA symbols, this header has been using  
USE_SSL, which is equivalent to USE_OPENSSL.  There is now only one SSL  
implementation included in the tree, so this works fine, but when  
adding a new SSL implementation this would run into failures.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/0DF29010-CE26-4F51-85A6-9C8ABF5536F9@yesql.se  

commit   : d25ea0127598dd0ad27a029215172f396fbd1009    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 18:10:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 18:10:08 -0400    

If an EquivalenceClass member expression includes variables from  
multiple appendrels, then instead of producing one substituted  
expression per child relation as intended, we'd create additional  
child expressions for combinations of children of different appendrels.  
This happened because the child expressions generated while considering  
the first appendrel were taken as sources during substitution of the  
second appendrel, and so on.  The extra expressions are useless, and are  
harmless unless there are too many of them --- but if you have several  
appendrels with a thousand or so members each, it gets bad fast.  
  
To fix, consider only original (non-em_is_child) EC members as candidates  
to be expanded.  This requires the ability to substitute directly from a  
top parent relation's Vars to those of an indirect descendant relation,  
but we already have that in adjust_appendrel_attrs_multilevel().  
  
Per bug #15847 from Feike Steenbergen.  This is a longstanding misbehavior,  
but it's only worth worrying about when there are more appendrel children  
than we've historically considered wise to use.  So I'm not going to take  
the risk of back-patching this.  
  
Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org  

commit   : de87a084c0a5ac927017cd0834b33a932651cfc9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Jun 2019 17:28:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Jun 2019 17:28:24 -0400    

When two (or more) transactions are waiting for transaction T1 to release a  
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a  
spurious deadlock can be reported among the waiting transactions when T1  
finishes.  The simplest example case seems to be:  
  
T1: select id from job where name = 'a' for key share;  
Y: select id from job where name = 'a' for update; -- starts waiting for X  
Z: select id from job where name = 'a' for key share;  
T1: update job set name = 'b' where id = 1;  
Z: update job set name = 'c' where id = 1; -- starts waiting for X  
T1: rollback;  
  
At this point, transaction Y is rolled back on account of a deadlock: Y  
holds the heavyweight tuple lock and is waiting for the Xmax to be released,  
while Z holds part of the multixact and tries to acquire the heavyweight  
lock (per protocol) and goes to sleep; once X releases its part of the  
multixact, Z is awakened only to be put back to sleep on the heavyweight  
lock that Y is holding while sleeping.  Kaboom.  
  
This can be avoided by having Z skip the heavyweight lock acquisition.  As  
far as I can see, the biggest downside is that if there are multiple Z  
transactions, the order in which they resume after X finishes is not  
guaranteed.  
  
Backpatch to 9.6.  The patch applies cleanly on 9.5, but the new tests don't  
work there (because isolationtester is not smart enough), so I'm not going  
to risk it.  
  
Author: Oleksii Kliukin  
Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com  

commit   : 3c8f8f6ebefb3c2debd1cad1ba445a729290dac7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    

Also MyReplicationSlot, in branches where it wasn't already.  
  
This was discussed in the thread that resulted in c572599c6, but  
for some reason nobody pulled the trigger.  Now that we have another  
request for the same thing, we should just do it.  
  
Craig Ringer  
  
Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com  
Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at  

commit   : b9768458154de6c001af23efc02514f120c6094f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Jun 2019 14:16:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Jun 2019 14:16:18 -0400    

Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql  
Reviewed-by: Michaël Paquier  

commit   : 4f41a7227511a3f96148b7f3d4ae6f0c350bc7b2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 09:15:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 09:15:57 -0400    

This item prevents unauthorized locking of relations, and the previous  
wording was unclear.  
  
Reported-by: Michael Paquier  
  
Discussion: https://postgr.es/m/20190522072651.GC1278@paquier.xyz  

commit   : 8b6da83d162cb0ac9f6d21082727bbd45c972c53    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 13 Jun 2019 17:59:09 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 13 Jun 2019 17:59:09 +0900    

Previously, in postgresPlanForeignModify, we planned an UPDATE operation  
on a foreign table so that we transmit only columns that were explicitly  
targets of the UPDATE, so as to avoid unnecessary data transmission, but  
if there were BEFORE ROW UPDATE triggers on the foreign table, those  
triggers might change values for non-target columns, in which case we  
would miss sending changed values for those columns.  Prevent optimizing  
away transmitting all columns if there are BEFORE ROW UPDATE triggers on  
the foreign table.  
  
This is an oversight in commit 7cbe57c34 which added triggers on foreign  
tables, so apply the patch all the way back to 9.4 where that came in.  
  
Author: Shohei Mochizuki  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/201905270152.x4R1q3qi014550@toshiba.co.jp  

commit   : 7dc6ae37def50b5344c157eee5e029a09359f8ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 23:05:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 23:05:40 -0400    

This wasn't incorrect SQL, but it was doing cm-to-inch conversion  
backward, so it might confuse readers.  
  
Per bug #15849 from TAKATSUKA Haruka.  
  
Discussion: https://postgr.es/m/15849-37ad0c561a836107@postgresql.org  

commit   : 9729c9360886bee7feddc6a1124b0742de4b9f3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    

datatype.sgml failed to explain that boolin() accepts any unique  
prefix of the basic input strings.  Indeed it was actively misleading  
because it called out a few minimal prefixes without mentioning that  
there were more valid inputs.  
  
I also felt that it wasn't doing anybody any favors by conflating  
SQL key words, valid Boolean input, and string literals containing  
valid Boolean input.  Rewrite in hopes of reducing the confusion.  
  
Per bug #15836 from Yuming Wang, as diagnosed by David Johnston.  
Back-patch to supported branches.  
  
Discussion: https://postgr.es/m/15836-656fab055735f511@postgresql.org  

commit   : 4bfb79ff6b1fd400b3dbc761921472173675a968    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 22:48:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 22:48:04 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-Wzn-aH4ToZEWR05ELSSp7bO_JMn=sMPfUhNruwVmCXKh-w@mail.gmail.com  

commit   : 3d99a81397abb8bb7b95aee794d6644e174e174f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 19:42:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 19:42:38 -0400    

Given a query in which multiple JOIN nodes used the same alias  
(which'd necessarily be in different sub-SELECTs), ruleutils.c  
would assign the JOIN nodes distinct aliases for clarity ...  
but then it forgot to print the modified aliases when dumping  
the JOIN nodes themselves.  This results in a dump/reload hazard  
for views, because the emitted query is flat-out incorrect:  
Vars will be printed with table names that have no referent.  
  
This has been wrong for a long time, so back-patch to all supported  
branches.  
  
Philip Dubé  
  
Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com  

commit   : ddc053dc503a773267a4d035418e0c81ce3b4851    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 13 Jun 2019 10:35:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 13 Jun 2019 10:35:11 +1200    

Reported-by: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com  
Backpatch-through: 10  

commit   : 968072837173a0c0fa426114b17177f997b85473    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:46:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:46:38 -0400    

Reported-by: Adrien Nayrat  
  
Discussion: https://postgr.es/m/9d6a7515-bcd8-05be-d2a5-e81dc11023cd@anayrat.info  

commit   : 6a631a454664c145b7da88c9ef3976f8ac3ab0b1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:36:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:36:43 -0400    

Reported-by: Andres Freund  
  
Discussion: https://postgr.es/m/20190528155823.3e4cezblxjxotq2q@alap3.anarazel.de  

commit   : e76de886157b7f974d4d247908b242607cfbf043    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 12:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 12:29:24 -0400    

ATExecAlterColumnType failed to consider the possibility that an index  
that needs to be rebuilt might be a child of a constraint that needs to be  
rebuilt.  We missed this so far because usually a constraint index doesn't  
have a direct dependency on its table, just on the constraint object.  
But if there's a WHERE clause, then dependency analysis of the WHERE  
clause results in direct dependencies on the column(s) mentioned in WHERE.  
This led to trying to drop and rebuild both the constraint and its  
underlying index.  
  
In v11/HEAD, we successfully drop both the index and the constraint,  
and then try to rebuild both, and of course the second rebuild hits a  
duplicate-index-name problem.  Before v11, it fails with obscure messages  
about a missing relation OID, due to trying to drop the index twice.  
  
This is essentially the same kind of problem noted in commit  
20bef2c31: the possible dependency linkages are broader than what  
ATExecAlterColumnType was designed for.  It was probably OK when  
written, but it's certainly been broken since the introduction of  
partial exclusion constraints.  Fix by adding an explicit check  
for whether any of the indexes-to-be-rebuilt belong to any of the  
constraints-to-be-rebuilt, and ignoring any that do.  
  
In passing, fix a latent bug introduced by commit 8b08f7d48: in  
get_constraint_index() we must "continue" not "break" when rejecting  
a relation of a wrong relkind.  This is harmless today because we don't  
expect that code path to be taken anyway; but if there ever were any  
relations to be ignored, the existing coding would have an extremely  
undesirable dependency on the order of pg_depend entries.  
  
Also adjust a couple of obsolete comments.  
  
Per bug #15835 from Yaroslav Schekin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15835-32d9b7a76c06a7a9@postgresql.org  

commit   : ceac4505d3428a8414b4f3d6708ea81506811a5f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Jun 2019 11:30:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Jun 2019 11:30:11 +0900    

For a non-superuser, changing a comment on a domain constraint was  
leading to a cache lookup failure as the code tried to perform the  
ownership lookup on the constraint OID itself, thinking that it was a  
type, but this check needs to happen on the type the domain constraint  
relies on.  As the type a domain constraint relies on can be guessed  
directly based on the constraint OID, first fetch its type OID and  
perform the ownership on it.  
  
This is broken since 7eca575, which has split the handling of comments  
for table constraints and domain constraints, so back-patch down to  
9.5.  
  
Reported-by: Clemens Ladisch  
Author: Daniel Gustafsson, Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/15833-808e11904835d26f@postgresql.org  
Backpatch-through: 9.5  

commit   : e788e849addd56007a0e75f3b5514f294a0f3bca    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 12 Jun 2019 08:08:57 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 12 Jun 2019 08:08:57 +1200    

A few questionable partitioning designs have been cropping up lately  
around the mailing lists.  Generally, these cases have been partitioning  
using too many partitions which have caused performance or OOM problems for  
the users.  
  
Since we have very little else to guide users into good design, here we  
add a new section to the partitioning documentation with some best  
practise guidelines for good design.  
  
Reviewed-by: Justin Pryzby, Amit Langote, Alvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f-2rx+E9mG3xrCVHupefMjAp1+tpczQa9SEOZWyU7fjEA@mail.gmail.com  
Backpatch-through: 10  

commit   : 6f34fcbbd5ad5a6546710e7b90e6331cacfd36dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jun 2019 13:33:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jun 2019 13:33:08 -0400    

json_to_record(), when an output column is declared as type json or jsonb,  
should emit the corresponding field of the input JSON object.  But it got  
this slightly wrong when the field is just a string literal: it failed to  
escape the contents of the string.  That typically resulted in syntax  
errors if the string contained any double quotes or backslashes.  
  
jsonb_to_record() handles such cases correctly, but I added corresponding  
test cases for it too, to prevent future backsliding.  
  
Improve the documentation, as it provided only a very hand-wavy  
description of the conversion rules used by these functions.  
  
Per bug report from Robert Vollmert.  Back-patch to v10 where the  
error was introduced (by commit cf35346e8).  
  
Note that PG 9.4 - 9.6 also get this case wrong, but differently so:  
they feed the de-escaped contents of the string literal to json[b]_in.  
That behavior is less obviously wrong, so possibly it's being depended on  
in the field, so I won't risk trying to make the older branches behave  
like the newer ones.  
  
Discussion: https://postgr.es/m/D6921B37-BD8E-4664-8D5F-DB3525765DCD@vllmrt.net  

commit   : 9f05c44ba4a4a6a857b957734bb369a2bb4dd62b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 11 Jun 2019 12:22:11 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 11 Jun 2019 12:22:11 -0400    

The docs have always been slightly inaccurate, but got particularly so  
in a874fe7b4c89, which made DISCARD ALL occur before everything else;  
reorder.  
  
Author: Jan Chochol  
Discussion: https://postgr.es/m/CAEASf_3TzBbnXm64HpnD5zCZEh8An9jN8ubMR=De-vOXHMHGeA@mail.gmail.com  

commit   : fff2a7d7bd09db38e1bafc1303c29b10a9805dc0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    

Vignesh found this bug in the check function for  
default_table_access_method's check hook, but that was just copied  
from older GUCs. Investigation by Michael and me then found the bug in  
further places.  
  
When not connected to a database (e.g. in a walsender connection), we  
cannot perform (most) GUC checks that need database access. Even when  
only shared tables are needed, unless they're  
nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed  
without pg_class etc. being present.  
  
Fix by extending the existing IsTransactionState() checks to also  
check for MyDatabaseOid.  
  
Reported-By: Vignesh C, Michael Paquier, Andres Freund  
Author: Vignesh C, Andres Freund  
Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com  
Backpatch: 9.4-  

commit   : 92a88644d2b7208e98d9e913c3a574c5c2fe7b78    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 11 Jun 2019 13:39:31 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 11 Jun 2019 13:39:31 +0900    

Reorder header files in postgres_fdw.c and connection.c in alphabetical  
order.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/CAPmGK17ZmNb-EELqu8LmMh2t2uFdbfWNVDEfDO5-bpejHPONMQ@mail.gmail.com  

commit   : 727e45c8a457ab7378494ff33bf3b50607d303a8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 11 Jun 2019 12:58:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 11 Jun 2019 12:58:51 +0900    

Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoAA_gvZ002U6kovOHu0FsM7ieoCzdSqWBd7_KaQL0UMKg@mail.gmail.com  

commit   : 132a1c101a205ee52ec7d731abcb8593a6354097    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Jun 2019 20:04:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Jun 2019 20:04:44 -0400    

All of the other code thinks that the 8th parameter is the number of  
blocks, but this declaration thinks that it's the ending block number.  
Repair this inconsistency.  
  
Patch by me, reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+TgmoY49ManQWnJtiwkuytXBkmyTuDFqb74Pr4Zn2Nq9TuNBQ@mail.gmail.com  

commit   : 33a53130a89447e171a8268ae0b221bb48af6468    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Jun 2019 18:56:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Jun 2019 18:56:23 -0400    

Using PARTITION OF can result in column ordering being changed from the  
database being dumped, if the partition uses a column layout different  
from the parent's.  It's not pg_dump's job to editorialize on table  
definitions, so this is not acceptable; back-patch all the way back to  
pg10, where partitioned tables where introduced.  
  
This change also ensures that partitions end up in the correct  
tablespace, if different from the parent's; this is an oversight in  
ca4103025dfe (in pg12 only).  Partitioned indexes (in pg11) don't have  
this problem, because they're already created as independent indexes and  
attached to their parents afterwards.  
  
This change also has the advantage that the partition is restorable from  
the dump (as a standalone table) even if its parent table isn't  
restored.  
  
The original commits (3b23552ad8bb in branch master) failed to cover  
subsidiary column elements correctly, such as NOT NULL constraint and  
CHECK constraints, as reported by Rushabh Lathia (initially as a failure  
to restore serial columns).  They were reverted.  This recapitulation  
commit fixes those problems.  
  
Add some pg_dump tests to verify these things more exhaustively,  
including constraints with legacy-inheritance tables, which were not  
tested originally.  In branches 10 and 11, add a local constraint to the  
pg_dump test partition that was added by commit 2d7eeb1b1492 to master.  
  
Author: Álvaro Herrera, David Rowley  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com  
Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql  
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com  

commit   : b6987a885ba9216e1f4319441303ee115556922c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 20:14:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 20:14:19 +0300    

Descriptions of pg_trgm GUC options have % replaced with %% like it was  
a printf-like format.  But that's not needed since they are just plain strings.  
This commit fixed that.  Backpatch to last supported version since this error  
present from the beginning.  
  
Reported-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoAgPKODUsu9gqUFiNqEOAqedStxJ-a0sapsJXWWAVp%3Dxg%40mail.gmail.com  
Backpatch-through: 9.4  

commit   : ba3783e0244e3502d1b08896ffc72b3a88dbdb83    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:38:13 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:38:13 +0300    

be8a7a68 introduced pg_trgm.strict_word_similarity_threshold GUC, but missed  
docs for that.  This commit fixes that.  
  
Discussion: https://postgr.es/m/fc907f70-448e-fda3-3aa4-209a59597af0%402ndquadrant.com  
Author: Ian Barwick  
Reviewed-by: Masahiko Sawada, Michael Paquier  
Backpatch-through: 9.6  

commit   : 852ddfbbe2121c905f2ecd750b1ec4cbfbea9f76    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:28:47 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:28:47 +0300    

5871b884 introduced pg_trgm.word_similarity_threshold GUC, but its documentation  
contains wrong indentation.  This commit fixes that.  Backpatch for easier  
backpatching of other documentation fixes.  
  
Discussion: https://postgr.es/m/4c735d30-ab59-fc0e-45d8-f90eb5ed3855%402ndquadrant.com  
Author: Ian Barwick  
Backpatch-through: 9.6  

commit   : ae78a9456c8986a8869ec470b40e177b5617a2f1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 15:50:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 15:50:54 -0700    

commit   : 44982e7d09cf9b1a08fded7fb0ca9a60dae869a5    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 14:00:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 14:00:36 -0700    

One would have needed out-of-tree code to observe the defects.  Remove  
unreferenced fields instead of completing their support functions.  
Since in-tree code can't reach _readIntoClause(), no catversion bump.  

commit   : cf4263cc6c3a2310de4f1540745990e62fa2312c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:33:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:33:52 +0900    

This makes the header more consistent with the surroundings, with  
declarations associated to a given file grouped together.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/20190608012439.GB7228@paquier.xyz  

commit   : b880e22de4b2543f1c1db758bca4b2135525e87a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:25:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:25:56 +0900    

Author: Guillaume Lelarge  
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com  

commit   : a806b14a1139d3443a7c2c263abb9ff8e4a65694    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    

Removing shared memory and semaphores in response to server start  
failure often masks the real problem, a live process associated with the  
data directory; see commit 5a907404b52753c4d6c6a7c21765aeaa42fd6a3b.  
Since 9.6, it's rarely necessary to kill subprocesses manually.  (When  
it is necessary, that commit's HINT will say as much, in all supported  
versions.)  

commit   : f2c71cb71fe186dcf8ebec967f98d1c7c4777943    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    

The documentation used "nonexistent" exclusively, and the source tree  
used it three times as often as "nonexistant".  

commit   : 31d250e049b4e3d51a635edaa2221c11815e40e7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    

commit   : 92c4abc73693690ce9ff13ede160f0dcb0a2de7b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 8 Jun 2019 08:16:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 8 Jun 2019 08:16:38 +0530    

There were a number of issues in the recent commits which include typos,  
code and comments mismatch, leftover function declarations.  Fix them.  
  
Reported-by: Alexander Lakhin  
Author: Alexander Lakhin, Amit Kapila and Amit Langote  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/ef0c0232-0c1d-3a35-63d4-0ebd06e31387@gmail.com  

commit   : 35b2d4bc0eb5d61a2a294ccb6b2e4abdad307604    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 8 Jun 2019 09:59:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 8 Jun 2019 09:59:02 +0900    

The file has been introduced in src/backend/libpq/ as of b0b39f72, but  
all backend-side headers of libpq are located in src/include/libpq/.  
Note that the identification path on top of the file referred to  
src/include/libpq/ from the start.  
  
Author: Michael Paquier  
Reviewed-by: Stephen Frost  
Discussion: https://postgr.es/m/20190607043415.GE1736@paquier.xyz  

commit   : 84d4de97e8d14469974eb488730a13f942aa787a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Jun 2019 20:48:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Jun 2019 20:48:39 +0900    

It was not clear from the code why it is necessary.  And we need a clean  
shutdown to avoid random checksum failures caused by torn pages.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDum5MbAb7F=pa9dOD1W2tukuDMPzWT7NjZceNoWB_6Qw@mail.gmail.com  

commit   : 77b68e3a4f854d95350a3366ecfc8b3b506ebaa7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Jun 2019 12:42:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Jun 2019 12:42:27 +0300    

It's harmless to call PQfreemem() with a NULL argument, so the only  
consequence was that if allocating 'schema' failed, but allocating 'table'  
or 'field' succeeded, we would leak a bit of memory. That's highly  
unlikely to happen, so this is just academical, but let's get it right.  
  
Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the  
PQfreemem() calls were introduced.  
  
Discussion: https://www.postgresql.org/message-id/15838-3221652c72c5e69d@postgresql.org  

commit   : a36c84c3e4a9bee6baa740848f67a5db3fa279b0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Jun 2019 00:44:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Jun 2019 00:44:17 -0400    

In commit 87259588d0ab I (Álvaro) tried to rationalize the determination  
of tablespace to use for partitioned tables, but failed to handle the  
default_tablespace case.  Repair and add proper tests.  
  
Author: Amit Langote, Rushabh Lathia  
Reported-by: Rushabh Lathia  
Reviewed-by: Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/CAGPqQf0cYjm1=rjxk_6gU0SjUS70=yFUAdCJLwWzh9bhNJnyVg@mail.gmail.com  

commit   : d8261595bc6f5189896cdce6861915ac23830e7c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 7 Jun 2019 05:23:52 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 7 Jun 2019 05:23:52 +0530    

When this code was initially introduced in commit d1b7c1ff, the structure  
used was SharedPlanStateInstrumentation, but later when it got changed to  
Instrumentation structure in commit b287df70, we forgot to update the  
comment.  
  
Reported-by: Wu Fei  
Author: Wu Fei  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local  

commit   : e8bdea58f960eac669ebac01dc3865606dd7b453    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 Jun 2019 12:18:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 Jun 2019 12:18:14 -0400    

Mark one message not for translation, and prefer "cannot" over "may  
not", per commentary from Robert Haas.  
  
Discussion: https://postgr.es/m/20190430145813.GA29872@alvherre.pgsql  

commit   : 438e51987dcc21ca7ce28c6d1a4e58b0249eb690    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 6 Jun 2019 22:10:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 6 Jun 2019 22:10:52 +0900    

Oversight in commit 280e5f1.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20190606.200612.110313249.horikyota.ntt@gmail.com  

commit   : f65eced25118aab29804debc4e0b9a67f4d043ad    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:55:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:55:16 +0200    

Previously, running pg_waldump with an invalid option (pg_waldump  
--foo) would print the help output and exit successfully.  This was  
because it tried to process the option letter '?' as a normal option,  
but that letter is used by getopt() to report an invalid option.  
  
To fix, process help and version options separately, like we do  
everywhere else.  Also add a basic test suite for pg_waldump and run  
the basic option handling tests, which would have caught this.  

commit   : cd96389d713787b025c84869ba417c6f2f008a86    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Jun 2019 09:46:52 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Jun 2019 09:46:52 +0300    

We used the same slot to store a tuple from the index, and to store a  
tuple from the table. That's not OK. It worked with the heap, because  
heapam_getnextslot() stores a HeapTuple to the slot, and doesn't care how  
large the tts_values/nulls arrays are. But when I played with a toy table  
AM implementation that used a virtual tuple, it caused memory overruns.  
  
In the passing, tidy up comments on the ioss_PscanLen fields.  

commit   : 6c0c28383749c0ade89ac70ba6dbce9af140c0a9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 6 Jun 2019 12:36:37 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 6 Jun 2019 12:36:37 +1200    

Document that CREATE INDEX CONCURRENTLY is not currently supported for  
indexes on partitioned tables.  
  
Discussion: https://postgr.es/m/CAKJS1f_CErd2z9L21Q8OGLD4TgH7yw1z9MAtHTSO13sXVG-yow@mail.gmail.com  
Backpatch-through: 11  

commit   : b250898c76f3a04421656f1bd8c5c520de02046d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:08:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:08:50 +0200    

Formal tables should generally have an xref in the text that points to  
them.  Add them here.  

commit   : e24a815c1c8550fcba5cc5aeb0d130db46570872    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 21:05:41 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 21:05:41 +1200    

When performing REINDEX TABLE CONCURRENTLY, if all of the table's indexes  
could not be reindexed, a NOTICE message claimed that the table had no  
indexes.  This was confusing, so let's change the NOTICE text to something  
less confusing.  
  
In passing, also mention in the comment before ReindexRelationConcurrently  
that materialized views are supported too and also explain what the return  
value of the function means.  
  
Author: Ashwin Agrawal  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CALfoeithHvi13p_VyR8kt9o6Pa7Z=Smi6Nfc2anHnQx5Lj8bTQ@mail.gmail.com  

commit   : 56b3b3838284f53c83556592e60688522155f57f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 18:28:38 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 18:28:38 +1200    

86b85044e rewrote how COPY FROM works to allow multiple tuple buffers to  
exist to once thus allowing multi-inserts to be used in more cases with  
partitioned tables.  That commit neglected to update the estate's  
es_result_relation_info when flushing the insert buffer to the partition  
making it possible for the index tuples to be added into an index on the  
wrong partition.  
  
Fix this and also add an Assert in ExecInsertIndexTuples to help ensure  
that we never make this mistake again.  
  
Reported-by: Haruka Takatsuka  
Author: Ashutosh Sharma  
Discussion: https://postgr.es/m/15832-b1bf336a4ee246b5@postgresql.org  

commit   : f7e954ad1cf99a65b1785d999058898a6d56e014    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Jun 2019 15:01:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Jun 2019 15:01:14 +0900    

When merging two attributes, we are sure that at least one remains.  
However, when deleting one element in the attribute list we may finish  
with an empty list returned as NIL by list_delete_cell(), but the code  
failed to track that, which is not project-like.  Adjust the call so as  
we check for an empty list, and make use of it in an assertion.  
  
This has been introduced by e7b3349, when adding support for CREATE  
TABLE OF.  
  
Author: Mark Dilger  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/CAE-h2TpPDqSWgOvfvSziOaMngMPwW+QZcmPpY8hQ_KOJ2+3hXQ@mail.gmail.com  

commit   : 5efd604ec0a3bdde98fe19d8cada69ab4ef80db3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 Jun 2019 16:42:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 Jun 2019 16:42:40 -0400    

Continuous operation cannot be achieved without applying this technique,  
so it needs to be properly described.  
  
Author: Álvaro Herrera  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/8756.1556302759@sss.pgh.pa.us  

commit   : ece9dc40d6d77a8607e72931510e30cfdfb78fd4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 13:57:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 13:57:38 +0200    

Verbatim environment tags should not be indented.  

commit   : c880096dc1e14b62610aa34bc98db226fa134260    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 09:16:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 09:16:02 +0200    

This allows determining which command is running, similar to  
pg_stat_progress_cluster.  
  
Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com  

commit   : 041a2642e51eb008351435709dcb054760a43bb9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Jun 2019 09:48:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Jun 2019 09:48:25 +0900    

The defined callback definitions have been using references to heap for  
a couple of variables and comments.  This makes the whole interface more  
consistent by using "table" which is more generic.  
  
A variable storing index information was misspelled as well.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190601190946.GB1905@paquier.xyz  

commit   : 2cd4e835701e15f5e32dd8bde488f8669ddf7ae8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 18:06:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 18:06:04 -0400    

A parallel worker process should not be making any decisions of its  
own about whether to auto-explain.  If the parent session process  
passed down flags asking for instrumentation data, do that, otherwise  
not.  Trying to enable instrumentation anyway leads to bugs like the  
"could not find key N in shm TOC" failure reported in bug #15821  
from Christian Hofstaedtler.  
  
We can implement this cheaply by piggybacking on the existing logic  
for not doing anything when we've chosen not to sample a statement.  
  
While at it, clean up some tin-eared coding related to the sampling  
feature, including an off-by-one error that meant that asking for 1.0  
sampling rate didn't actually result in sampling every statement.  
  
Although the specific case reported here only manifested in >= v11,  
I believe that related misbehaviors can be demonstrated in any version  
that has parallel query; and the off-by-one error is certainly there  
back to 9.6 where that feature was added.  So back-patch to 9.6.  
  
Discussion: https://postgr.es/m/15821-5eb422e980594075@postgresql.org  

commit   : eaf0292c3ba7acac2735f99a8988bd49a26112f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 16:59:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 16:59:16 -0400    

It's not really supported to call systable_getnext() in a different  
memory context than systable_beginscan() was called in, and it's  
*definitely* not safe to do so and then reset that context between  
calls.  I'm not very clear on how this code survived  
CLOBBER_CACHE_ALWAYS testing ... but Alexander Lakhin found a case  
that would crash it pretty reliably.  
  
Per bug #15828.  Fix, and backpatch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/15828-f6ddd7df4852f473@postgresql.org  

commit   : 05d36b68ed011d112ee287b1fedd981c73a48f85    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 Jun 2019 21:33:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 Jun 2019 21:33:01 +0200    

Reviewed-by: Oleg Bartunov <obartunov@postgrespro.ru>  

commit   : 1fb6f62a84041b668fd9e85a2f33bb3a0fd28fdc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 13:44:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 13:44:03 +0900    

Author: Andrea Gelmini  
Reviewed-by: Michael Paquier, Justin Pryzby  
Discussion: https://postgr.es/m/20190528181718.GA39034@glet  

commit   : 0240a00fbd4fd14f577edf8d36a032237fd0b9cb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 11:02:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 11:02:32 +0900    

The following issues have been spotted:  
- CREATE INDEX .. USING suggests both index and table AMs, but it should  
consider only index AMs.  
- CREATE TABLE .. USING has no completion support.  USING was not being  
included in the completion list where it should, and follow-up  
suggestions for table AMs have been missing as well.  
- CREATE ACCESS METHOD .. TYPE suggests only INDEX, with TABLE missing.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190601191007.GC1905@paquier.xyz  

commit   : f4755a2c01486519cfce5b21ab04529ad26f5ed1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 13:45:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 13:45:01 -0400    

Teach it to scrape -I and -D switches from CPPFLAGS in Makefile.global.  
This is useful for testing on, eg, FreeBSD, where you won't get far  
without "-I/usr/local/include".  
  
Also, expand the set of blacklisted-for-unportability atomics headers,  
based on noting that arch-x86.h fails to compile on an ARM box.  The  
other ones I'd omitted seem to compile all right on architectures they  
don't belong to, but that's surely too shaky to rely on.  Let's do  
like we did for the src/include/port/ headers, and ignore all except  
the variant that's pulled in by the arch-independent header.  

commit   : 032627ee7837f0baa539df7247e003dbaded2c90    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 12:23:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 12:23:39 -0400    

Perl likes to redefine the _() macro:  
  
#ifdef CAN_PROTOTYPE  
#define	_(args) args  
#else ...  
  
There was lots not to like about the way we dealt with this before:  
  
1. Instead of taking care of the conflict centrally in plperl.h, we  
expected every one of its ever-growing number of includers to do so.  
This is duplicative and error-prone in itself, plus it means that  
plperl.h fails to meet the expectation of being compilable standalone,  
resulting in macro-redefinition warnings in cpluspluscheck.  
  
2. We left _() with its Perl definition, meaning that if someone tried  
to use it in any Perl-related extension, it would silently fail to  
provide run-time translation.  I don't see any live bugs of this ilk,  
but it's clearly a hard-to-notice bug waiting to happen.  
  
So fix that by centralizing the cleanup logic, making it match what  
we're already doing for other macro conflicts with Perl.  Since we only  
expect plperl.h to be included by extensions not core code, we should  
redefine _() as dgettext() not gettext().  

commit   : 135063e6f6ee61c7243801e9f4d702921ed53e06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:13:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:13:23 -0400    

commit   : 10a53cae9993abae159abdc6a76e46f6aac120d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:07:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:07:54 -0400    

Declaring a function "inline" still doesn't work with Windows compilers  
(C99? what's that?), unless the macro provided by pg_config.h is  
in-scope, which it is not in our ECPG test programs.  So the workaround  
I tried to use in commit 7640f9312 doesn't work for Windows.  Revert  
the change in printf_hack.h, and instead just blacklist that file  
in cpluspluscheck --- since it's a not-installed test file, we don't  
really need to verify its C++ cleanliness anyway.  

commit   : 4b3f1dd71b74f82dedbf37c331d0a444368c4009    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 2 Jun 2019 00:29:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 2 Jun 2019 00:29:49 -0400    

This test module was not getting invoked, other than at compile time,  
limiting its usefulness -- and keeping its coverage at 0%.  Add a  
minimal regression test to ensure it runs on make check-world; this  
makes it 92% covered (line-wise), which seems sufficient.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20190529193256.GA17603@alvherre.pgsql  

commit   : 0b8e0532c65c3a2d4b0e9c254efa022767bacceb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Jun 2019 15:33:47 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Jun 2019 15:33:47 -0400    

Support of CHECK OPTION for updatable views has been added in 9.4, but  
the documentation of information_schema never got the call even if the  
information displayed is correct.  
  
Author: Gilles Darold  
Discussion: https://postgr.es/m/75d07704-6c74-4f26-656a-10045c01a17e@darold.net  
Backpatch-through: 9.4  

commit   : 6f54b80edd88abd5665aa12fbcf10f846dd80939    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 16:32:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 16:32:07 -0400    

Formerly, cpluspluscheck was only meant to examine headers that  
we thought of as exported --- but its notion of what we export  
was well behind the times.  Let's just make it check *all* .h  
files, except for a well-defined blacklist, instead.  
  
While at it, improve its ability to use a C++ compiler other than g++,  
by scraping the CXX setting from Makefile.global and making it possible  
to override the warning options used (per suggestion from Andres Freund).  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : b1cd7ce23f40e1e443b3f2ab127bbe8348add678    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 31 May 2019 12:36:17 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 31 May 2019 12:36:17 -0700    

Previously cpluspluscheck wouldn't work in vpath builds, this commit  
fixes that. To make it easier to invoke, there's a top-level  
cpluspluscheck target.  
  
Discussion: https://postgr.es/20190530220244.kiputcbl4gkl2oo6@alap3.anarazel.de  

commit   : 72b6223f766d6ba9076d7b1ebdf05df75e83ba5c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 May 2019 13:30:05 -0400    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 May 2019 13:30:05 -0400    

Author: Antonin Houska  
Discussion: https://postgr.es/m/22370.1559293357@localhost  

commit   : ec66ec8b21d3d779047313ac214fba7bcd29a97c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:47:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:47:19 -0400    

Mea culpa for not rechecking check-world at the last step :-(  
Per buildfarm.  

commit   : 4f67858d3f210658d42f44fc674d2850581e572e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:38:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:38:53 -0400    

There's probably no need to back-patch this, since it seems unlikely  
that anybody would be inserting C++ code into ecpg's preprocessor.  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : 3f61b3205f1a8bd27909be97341f002db8842093    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:34:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:34:54 -0400    

Rename some exposed parameters so that they don't conflict with  
C++ reserved words.  
  
Back-patch to all supported versions.  
  
George Tarasov  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : 7640f9312321ceba2af61f7017da7e64f0f7b667    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 11:45:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 11:45:33 -0400    

We have a longstanding project convention that all .h files should  
be includable with no prerequisites other than postgres.h.  This is  
tested/relied-on by cpluspluscheck.  However, cpluspluscheck has not  
historically been applied to most headers outside the src/include  
tree, with the predictable consequence that some of them don't work.  
Fix that, usually by adding missing #include dependencies.  
  
The change in printf_hack.h might require some explanation: without  
it, my C++ compiler whines that the function is unused.  There's  
not so many call sites that "inline" is going to cost much, and  
besides all the callers are in test code that we really don't care  
about the size of.  
  
There's no actual bugs being fixed here, so I see no need to back-patch.  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : 9e58705a7f9728f10b2e0f0c9adc6e6ecff7486e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 10:40:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 10:40:00 -0400    

While C is happy to cast "const void *" to "const unsigned char *"  
silently, C++ insists on an explicit cast.  Since we put these  
functions into header files, cpluspluscheck whines about that.  
Add the cast to pacify it.  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : d22f885f895add7e0184b08a78ba92ff091e36c4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 31 May 2019 10:08:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 31 May 2019 10:08:37 -0400    

New in 147e3722f7e5.  

commit   : fc115d0f9fc656967260815c031e0f25741428ae    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 May 2019 16:58:17 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 May 2019 16:58:17 -0400    

This makes the tool consistent with the option set of oid2name, which  
has been historically using -f for filenodes, and has more recently  
gained long options and --filenode via 1aaf532.  
  
Reported-by: Peter Eisentraut  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/97045260-fb9e-e145-a950-cf7d28c4eaea@2ndquadrant.com  

commit   : 13002bf0bcdf4900987684ca6ef7665a25aa692b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 30 May 2019 13:44:38 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 30 May 2019 13:44:38 -0700    

Interestingly only C++ compilers have, so far, complained about this  
odd forward declaration. This originated when IndexBuildCallback was  
defined in another file, but now is completely unnecessary (but was  
wrong before too, cpluspluscheck just wouldn't have noticed).  
  
Reported-By: Tom Lane  
Discussion: https://postgr.es/m/53941.1559239260@sss.pgh.pa.us  

commit   : fe415ff10408a1487d5773b47459306476ec58f0    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 May 2019 16:16:12 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 May 2019 16:16:12 +0200    

Most errors reported in extended statistics are internal issues, and so  
should use elog(). The MCV list code was already following this rule, but  
the functional dependencies and ndistinct coefficients were using a mix  
of elog() and ereport(). Fix this by changing most places to elog(), with  
the exception of input functions.  
  
This is a mostly cosmetic change, it makes the life a little bit easier  
for translators, as elog() messages are not translated. So backpatch to  
PostgreSQL 10, where extended statistics were introduced.  
  
Author: Tomas Vondra  
Backpatch-through: 10 where extended statistics were added  
Discussion: https://postgr.es/m/20190503154404.GA7478@alvherre.pgsql  

commit   : 56b78626c7288fad498c0fae7fe4fd1f240ed13f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:37:37 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:37:37 -0400    

Author: Guillaume Lelarge  
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com  

commit   : f73293aba4d43e48707e361b2b1ef1465fef46e0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:19:06 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:19:06 -0400    

This got forgotten in f56f8f which has added foreign key support for  
partitioned tables.  In passing, add a mention about caveats applying to  
tables partitioned using inheritance regarding indexes and foreign keys.  
  
Author: Paul A Jungwirth  
Reviewed-by: Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/CA+renyUuSmYgmZjKc_DfUNVZ0uttF91-FwhDVW3F7WEPj0jL5w@mail.gmail.com  

commit   : d890fa812dd4620db0d092da1cd7cba01494cd21    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 23:44:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 23:44:22 -0400    

commit   : a100974751baec7e13a527bf0c378ce8ef2787b6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 17:34:38 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 17:34:38 -0400    

I introduced the typo in source code in the course of 75445c1515ff.  
Repair.  

commit   : 40b132c1afbb4b1494aa8e48cc35ec98d2b90777    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:59:00 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:59:00 -0700    

When this suite runs installcheck, redirect file creations from  
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a  
race condition in "make -j check-world".  If the pg_upgrade suite wrote  
to a given src/test/regress/results file in parallel with the regular  
src/test/regress invocation writing it, a test failed spuriously.  Even  
without parallelism, in "make -k check-world", the suite finishing  
second overwrote the other's regression.diffs.  This revealed test  
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.  
  
Buildfarm client REL_10, released fifty-four days ago, supports saving  
regression.diffs from its new location.  When an older client reports a  
pg_upgradeCheck failure, it will no longer include regression.diffs.  
Back-patch to 9.5, where pg_upgrade moved to src/bin.  
  
Reviewed (in earlier versions) by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com  

commit   : 10b72deafea5972edcafb9eb3f97154f32ccd340    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:58:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:58:30 -0700    

This allows "vcregress upgradecheck" to pass twice in immediate  
succession, and it's more like how $(prove_check) works.  Back-patch to  
9.5, where pg_upgrade moved to src/bin.  
  
Discussion: https://postgr.es/m/20190520012436.GA1480421@rfd.leadboat.com  

commit   : d5ec46bf224d2ea1b010b2bc10a65e44d4456553    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 28 May 2019 09:06:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 28 May 2019 09:06:40 -0700    

Mea culpa.  

commit   : a94fd139df975a006d1697d2a7180d3656222d4d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 May 2019 08:26:24 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 May 2019 08:26:24 -0400    

This code block was copied/adapted from other similar places but  
somehow the comment placement was changed so that it makes less sense.  

commit   : 3ceaed106d95e76c7dbfd41f5d83a163fd0d25c8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 May 2019 07:17:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 May 2019 07:17:34 -0400    

Reported-by: Gaby Schilders  

commit   : af94ea7406f332567331a9b2525fae4b57c96061    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 May 2019 06:33:30 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 May 2019 06:33:30 -0400    

Author: Gurjeet Singh  
Discussion: https://postgr.es/m/CABwTF4U_5kEnH93PXZEuEsZHuoSSuBEOqC6pian8vDfLZSQJNA@mail.gmail.com  

commit   : 00ef6e3b28a8220f2dba881dbf56e3ba62f851bd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 May 2019 12:26:16 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 May 2019 12:26:16 -0400    

The old text still had an implicit reference to the virtual behavior,  
which was not in the final patch.  
  
Author: Tobias Bussmann <t.bussmann@gmx.net>  

commit   : 39fe881d3cf315d8d2ea9ee4ea1e3e39a82d5cc7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:39:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:39:11 -0400    

ecpg_build_params() failed to check for ecpg_alloc failure in one  
newly-added code path, and leaked a temporary string in another path.  
Errors in commit a1dc6ab46, spotted by Coverity.  

commit   : 331695a4d9ca40864240aca721dc588a206ff395    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:06:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:06:37 -0400    

ecpg_register_prepared_stmt() is pretty obviously checking the wrong  
variable while trying to detect malloc failure.  Error in commit  
a1dc6ab46, spotted by Coverity.  

commit   : 9679345f3c5ec071f63db358581e28f06c8744a7    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sun, 26 May 2019 18:28:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sun, 26 May 2019 18:28:18 +0530    

Reported-by: Alexander Lakhin  
Author: Alexander Lakhin  
Reviewed-by: Amit Kapila and Tom Lane  
Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com  

commit   : 41205719d34969018f708baa70d9d06dae0c0d08    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 26 May 2019 08:08:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 26 May 2019 08:08:05 +0200    

Change extension for Graphviz files from .dot to .gv.  The latter  
appears to be the generally preferred one nowadays.  
  
Discussion: https://www.postgresql.org/message-id/flat/71fe76d2-c7d7-2acc-6762-bbf9e61c566e%402ndquadrant.com  

commit   : 02aa15de1b3821b0288a13dec71ce99f2e31fda5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 May 2019 15:40:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 May 2019 15:40:53 +0530    

Reported-by: Euler Taveira  
Author: Euler Taveira  
Discussion: https://postgr.es/m/CAHE3wgjiA8DdnUzH9WqBLxdrUVvjDkKNdHx-MkEg9uV+HtpMfg@mail.gmail.com  

commit   : 591fb289c3eef010ee1bb271a54fab7da385c4cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 May 2019 11:16:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 May 2019 11:16:06 -0400    

Per bug #15819 from Koizumi Satoru.  
  
Discussion: https://postgr.es/m/15819-e6191bef1f7334c0@postgresql.org  

commit   : 4c9210f34c621639f896d57cf7bfb5e9be139c91    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:23:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:23:59 +1200    

Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com  

commit   : 7988cb446d20512ec9d091db66dba6adee3f3d4b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:17:41 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:17:41 +1200    

Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com  

commit   : 73b8c3bd2889fed986044e15aefd0911f96ccdd3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 16:25:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 16:25:48 -0700    

Some of the wrapper functions didn't match the callback names. Many of  
them due to staying "consistent" with historic naming of the wrapped  
functionality. We decided that for most cases it's more important to  
be for tableam to be consistent going forward, than with the past.  
  
The one exception is beginscan/endscan/...  because it'd have looked  
odd to have systable_beginscan/endscan/... with a different naming  
scheme, and changing the systable_* APIs would have caused way too  
much churn (including breaking a lot of external users).  
  
Author: Ashwin Agrawal, with some small additions by Andres Freund  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com  

commit   : 54487d1560619a0027e0651d1b8d715ca8fc388c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 May 2019 08:19:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 May 2019 08:19:21 +0900    

The access method name "amname" can be dumped as of 3b925e90, but  
queries for backends older than 9.5 forgot to map it to a dummy NULL  
value, causing the column to not be mapped to a number.  As a result,  
pg_dump was throwing some spurious errors in its stderr output coming  
from libpq:  
pg_dump: column number -1 is out of range 0..36  
  
Fix this issue by adding a mapping of "amname" to NULL to all the older  
queries.  
  
Discussion: https://postgr.es/m/20190522083038.GA16837@paquier.xyz  
Author: Michael Paquier  
Reviewed-by: Dmitry Dolgov, Andres Freund, Tom Lane  

commit   : f916221df5652b95c402847905bdf48950b5b281    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 14:46:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 14:46:52 -0700    

On master (after 700538) the old version's installed psql was used -  
even when the old version might not actually be installed / might be  
installed into a temporary directory. As commonly the case when just  
executing make check for pg_upgrade, as $oldbindir is just the current  
version's $bindir.  
  
In the back branches, with --install specified, psql from the new  
version's temporary installation was used, without --install (e.g for  
NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was  
used (which might or might not exist).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190522175150.c26f4jkqytahajdg@alap3.anarazel.de  

commit   : 44e95b5728a4569c494fa4ea4317f8a2f50a206b    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 May 2019 15:26:01 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 May 2019 15:26:01 +0100    

When there were duplicate columns in the hash key list, the array  
sizes could be miscomputed, resulting in access off the end of the  
array. Adjust the computation to ensure the array is always large  
enough.  
  
(I considered whether the duplicates could be removed in planning, but  
I can't rule out the possibility that duplicate columns might have  
different hash functions assigned. Simpler to just make sure it works  
at execution time regardless.)  
  
Bug apparently introduced in fc4b3dea2 as part of narrowing down the  
tuples stored in the hashtable. Reported by Colm McHugh of Salesforce,  
though I didn't use their patch. Backpatch back to version 10 where  
the bug was introduced.  
  
Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com  

commit   : 156c0c2dff403fd115f3a5f6d73ab80959c84129    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 10:48:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 10:48:17 +0900    

This uses a method similar to 68a7c24f and now b8c6014 (applied for  
database creation), which guarantees that GRANT commands using the WITH  
GRANT OPTION are dumped in a way so as cascading dependencies are  
respected.  Note that tablespaces do not have support for initial  
privileges via pg_init_privs, so the same method needs to be applied  
again.  It would be nice to merge all the logic generating ACL queries  
in dumps under the same banner, but this requires extending the support  
of pg_init_privs to objects that cannot use it yet, so this is left as  
future work.  
  
Discussion: https://postgr.es/m/20190522071555.GB1278@paquier.xyz  
Author: Michael Paquier  
Reviewed-by: Nathan Bossart  
Backpatch-through: 9.6  

commit   : 657c2384c6c79c6ed0d6f71f811b2fc7c41f104a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 09:36:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 09:36:28 +0900    

This has been forgotten in 578b229, which has removed support for WITH  
OIDS.  
  
Discussion: https://postgr.es/m/CALAY4q99FcFCoG6ddke0V-AksGe82L_+bhDWgEfgZBakB840zA@mail.gmail.com  
Author: Surafel Temesgen  

commit   : db6e2b4c52ade524f3db419d75084728e96e1f9c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:36:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:36:19 -0400    

Make all the perl code look nice, too (for some value of "nice").  

commit   : 8255c7a5eeba8f1a38b7a431c04909bde4f5e67d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:04:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:04:48 -0400    

Switch to 2.1 version of pg_bsd_indent.  This formats  
multiline function declarations "correctly", that is with  
additional lines of parameter declarations indented to match  
where the first line's left parenthesis is.  
  
Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com  

commit   : be76af171cdb3e7465c4ef234af403f97ad79b7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 12:55:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 12:55:34 -0400    

This is still using the 2.0 version of pg_bsd_indent.  
I thought it would be good to commit this separately,  
so as to document the differences between 2.0 and 2.1 behavior.  
  
Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us