PostgreSQL 12.0 commit log

commit   : ad1f2885b8c82e0c2d56d7974f012cbecce17a17    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2019 16:03:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2019 16:03:42 -0400    

commit   : b60f9afcf4bfe6b1ff73b49b9bab20dde356c7f4    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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 <[email protected]>    
date     : Mon, 30 Sep 2019 14:31:12 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 737f226842748cf946cad3bd30aadfd0c03ad16f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 30 Sep 2019 13:44:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
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/[email protected]  
  
Backpatch-through: 12  

commit   : 9d42df74a3ad0379fe90e56c92eecac6957876f3    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 30 Sep 2019 12:03:28 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Mon, 30 Sep 2019 10:18:15 +0900    
  
committer: Fujii Masao <[email protected]>    
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/[email protected]  

commit   : 2ce9bca36458a1f1907c82eb2e9bd642cb1fca26    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 29 Sep 2019 16:27:18 -0700    
  
committer: Andres Freund <[email protected]>    
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/[email protected]  
Backpatch: 11, just as 5567d12ce03  

commit   : 6cf74f1bbd6545321d9e2929c7618550863f72d1    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 29 Sep 2019 15:24:54 -0700    
  
committer: Andres Freund <[email protected]>    
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/[email protected]  
Backpatch: 12-, where 675af5c01e297 was merged.  

commit   : 3c70de2e12b9ef10925a57a350dffc01b95e067e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 29 Sep 2019 23:46:15 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Sun, 29 Sep 2019 23:38:51 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 29 Sep 2019 23:38:51 +0200    

commit   : 63d3e1142a0554c33818741d44926fc036a0499b    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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 <[email protected]>    
date     : Sun, 29 Sep 2019 23:29:45 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 29 Sep 2019 23:29:45 +0200    

Reported-by: Justin Pryzby <[email protected]>  

commit   : a7e5ae53cbe7bd88102b38d5f6e15f5adc94e15c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 29 Sep 2019 23:07:22 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Sun, 29 Sep 2019 09:50:36 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Sat, 28 Sep 2019 15:54:02 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/20190924101859.09383b4f%40fafnir.local.vm  

commit   : 9de7ea6aca5a394dbddac4b13b475b313e352b3f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : e40f3c7472036f5a06897a11ac79fd26ec2ccf7d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Sep 2019 11:28:25 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : b34bc87030655a677b0a4d6317bfe3a6a7d10546    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : a37980d4282436b4019a8e427b02919b04cb625a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 27 Sep 2019 16:21:47 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net  

commit   : 268c4e9d4d88f5b4baca88ef31e914a1ac1fb7e9    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2019 12:53:57 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 27 Sep 2019 12:53:57 +0900    

Author: Justin Pryzby  
Reviewed-by: Tatsuro Yamada  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 12  

commit   : fb341a7db9ba03f365bd02dc47123fbad6cc3761    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    
  
committer: Amit Kapila <[email protected]>    
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 <[email protected]>    
date     : Thu, 26 Sep 2019 21:29:14 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 26 Sep 2019 21:29:14 +0200    

commit   : 79504cfe1b23cd22c78dd5786f81f40905c5cce0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 26 Sep 2019 21:27:34 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 26 Sep 2019 21:27:34 +0200    

commit   : baca53d3dca701e6a8b04a1b2dd0ed603289fbf0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 26 Sep 2019 16:35:10 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 26 Sep 2019 16:35:10 +0200    

Author: Liudmila Mantrova <[email protected]>  
Reported-by: Jeff Janes <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CAMkU%3D1wP-SO4KpiLxHJuPezTJCmK%3DJqefLXrr3eXFO7Qku%2BtMg%40mail.gmail.com  

commit   : b4d615aaa1ecedcf1e2ca415cd2893d1f18aeeca    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 26 Sep 2019 10:51:39 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Thu, 26 Sep 2019 09:42:19 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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/[email protected]  

commit   : 658d391d87c13a4b27425a2fd014f2162956ad4d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 25 Sep 2019 17:30:42 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Wed, 25 Sep 2019 13:44:43 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Wed, 25 Sep 2019 10:08:26 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 9.6  

commit   : 8728552b291b8fe3778346fb4d4b7d1c8743f708    
  
author   : Alexander Korotkov <[email protected]>    
date     : Wed, 25 Sep 2019 01:47:36 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Mon, 23 Sep 2019 16:24:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 16:24:42 -0400    

commit   : 53c89aed7b38ab412fddc1d6118822ce5d962acd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 13:04:52 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : a25fb9ceb1a63d4383370d4a017aa572d8e99b42    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 10:40:42 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Mon, 23 Sep 2019 10:32:02 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 8cdd1c4d07a70df0963a26da2533d4c10852504f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 23 Sep 2019 15:30:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Mon, 23 Sep 2019 13:37:33 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 23 Sep 2019 13:37:33 +0200    

commit   : 84eb871647b3cc88c89d26d25f0cd84a8ac200fe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 23 Sep 2019 09:04:20 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 308813846e737f7d92ffb4e033d65e3df6cbddba    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 22 Sep 2019 14:21:07 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Sat, 21 Sep 2019 23:22:15 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 21 Sep 2019 23:22:15 +0200    

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

commit   : 87b601605467812c48675a0ec127707bf381cda2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 21 Sep 2019 22:51:54 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 21 Sep 2019 22:51:54 +0200    

current through 25f9368304e41c8837f59e94b161f07ac4c7d622  

commit   : d9110d7e14819c10049c9beb1034958787c77e79    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 21 Sep 2019 16:56:30 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : d3c61e88d94cba2070574dccbfba06bbc738c876    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 21 Sep 2019 16:29:17 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 25f9368304e41c8837f59e94b161f07ac4c7d622    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 21 Sep 2019 15:23:53 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 2966e30e553b12d2d25aea184f52f9c6ffbcee51    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Fri, 20 Sep 2019 14:22:58 -0400    
  
committer: Tom Lane <[email protected]>    
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%[email protected]  

commit   : 08e04a5f99d50285edf8e89a18da67ce2d75d676    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2019 12:47:21 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Fri, 20 Sep 2019 12:53:58 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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 <[email protected]>    
date     : Fri, 20 Sep 2019 15:31:12 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    
  
committer: Amit Kapila <[email protected]>    
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 <[email protected]>    
date     : Fri, 20 Sep 2019 01:46:49 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Fri, 20 Sep 2019 01:10:56 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Thu, 19 Sep 2019 11:22:21 -0400    
  
committer: Tom Lane <[email protected]>    
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%[email protected]  

commit   : 596cf9e806826936869f62232bd011687c467965    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 19 Sep 2019 15:03:23 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Thu, 19 Sep 2019 11:46:40 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 19 Sep 2019 11:46:40 +0200    

commit   : a4188a65be9426136fc176430ea646cb0fa04fff    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 19 Sep 2019 14:40:09 +0530    
  
committer: Amit Kapila <[email protected]>    
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 <[email protected]>    
date     : Thu, 19 Sep 2019 09:58:43 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 19 Sep 2019 09:58:43 +0200    

Improve the LDAP DNS SRV item.  

commit   : fbd1cb2fd9796a08a198d929774280ecce933057    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 19 Sep 2019 09:02:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Thu, 19 Sep 2019 13:19:00 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 9.4  

commit   : 62ed5e77f3dc6d8c65d917b60dc8512ddd6fd18e    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    
  
committer: Amit Kapila <[email protected]>    
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 <[email protected]>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected]  

commit   : 68c3c493674d81131c8f2685b91ec8de4fdcb862    
  
author   : Etsuro Fujita <[email protected]>    
date     : Wed, 18 Sep 2019 18:50:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
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 <[email protected]>    
date     : Tue, 17 Sep 2019 15:39:51 -0400    
  
committer: Tom Lane <[email protected]>    
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%[email protected]  
Reference: https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#flags  

commit   : 27bc87985c4135f27bdcddd905baad3b62a3f03a    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 15 Sep 2019 11:51:57 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Sun, 15 Sep 2019 13:16:59 +0100    
  
committer: Dean Rasheed <[email protected]>    
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 <[email protected]>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    
  
committer: Noah Misch <[email protected]>    
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/[email protected]  

commit   : 5b5b0f721d9cece8fb68ecdd1d53c3bffe6e753c    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    
  
committer: Noah Misch <[email protected]>    
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/[email protected]  

commit   : 96b5033e117141eecf3782ee555f39b3006a732f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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 <[email protected]>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected]  

commit   : da47e43dc32e3c5916396f0cbcfa974b371e4875    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 14:51:13 -0300    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected] 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/[email protected]  

commit   : 6eb9b20bb7dd770c78bf43b205b98e15972e2341    
  
author   : Alexander Korotkov <[email protected]>    
date     : Fri, 13 Sep 2019 17:21:20 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Fri, 13 Sep 2019 17:12:20 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Thu, 12 Sep 2019 15:45:07 -0700    
  
committer: Peter Geoghegan <[email protected]>    
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 <[email protected]>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : fef55c569eeda4286451f4fb884ad7d3b1de29fd    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    
  
committer: Amit Kapila <[email protected]>    
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/[email protected]  

commit   : dc92bf5cad7ccae294ec7055382c7727726702cc    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 11 Sep 2019 11:07:25 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 9.4  

commit   : b1016834d325dff5eb168e5f6f261462eb6f1d56    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 10 Sep 2019 12:04:57 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 97fb88ea4a646343d5f0a8cd65b7e5f598785cb4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Sep 2019 22:53:51 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 84bb33c4804ea26b3f23df875701731bd01d3f0a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Sep 2019 16:24:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Sep 2019 16:24:29 -0400    

commit   : 5348e22b969f6af8bd4400256a6a190721a01f34    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 9668b02f80425dc72116101cb368c6ac1cc210a1    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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/[email protected]  
  
Backpatch to all live branches.  

commit   : 7d49803259de7514e16dfdf2b6a36e7b514f0505    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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/[email protected]  

commit   : 3fb307bc4a76815f96fec28a0d1525ab3fbbcfb4    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 9 Sep 2019 05:21:30 -0700    
  
committer: Andres Freund <[email protected]>    
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/[email protected]  
Backpatch: 12-, where the EPQ changes were introduced  

commit   : c6ce5f71b08235f9ed8e0206267ae560ea1ebc91    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Mon, 9 Sep 2019 11:34:06 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  

commit   : 2403e54fff3b47735fc1a77c51e407c3596d3331    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  
Reviewed-by: Fabien COELHO <[email protected]>  

commit   : 422910423b6cba6abc3790b8f20854c9e78e04a4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    

commit   : eecd7c3d2b44094d00e967c7283fc2236d8def5d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : b6a4d0498757a6e345e07b2a84eb8333f5e5235e    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 Sep 2019 11:21:24 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    

commit   : ce35a265a438813cd337307b6997a58ac87bf9c9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    

commit   : 69116b743af01bd0ab87b5dfc7395029002e23a1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    

commit   : 700a1ac073730eca8b2d2235ced133f563a26a1b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Sep 2019 15:15:38 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : ce5542d4025321273d7d0915fb76977937da6994    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    
  
committer: Robert Haas <[email protected]>    
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 <[email protected]>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    
  
committer: Fujii Masao <[email protected]>    
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 <[email protected]>    
date     : Wed, 4 Sep 2019 15:46:45 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Wed, 4 Sep 2019 13:23:41 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 6ef121647f7f29b59b86eca3dee9b90548245a3a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 5380719f931a101a6e83efc7a1664e42bd6bf6c3    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 3 Sep 2019 12:31:03 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 10  

commit   : aad0926ebbe96fbbc3c963b58f2abbcf81895a06    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 8ff5de1c7aa2439ae69f53efd61390026505aee4    
  
author   : Etsuro Fujita <[email protected]>    
date     : Thu, 29 Aug 2019 18:45:01 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Thu, 29 Aug 2019 18:45:01 +0900    

commit   : 6b7819a0bd01ebe4ede13bf84dbd51b524eb128a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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 <[email protected]>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    
  
committer: Thomas Munro <[email protected]>    
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 <[email protected]>    
date     : Wed, 28 Aug 2019 11:48:15 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 7570df0f3b6d873cd060b3271b5f7b90cbcfb66c    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : c0222c2c9b8145a0ccbee7d801db848e871f2e14    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 1510339dce3c70757a87be3880e102e0511bf288    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : b783a38d4580d807210e26c2c09eb77b66d7286f    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 27 Aug 2019 09:11:38 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 9.5  

commit   : 6bdd9fb003e26201c4ae6293a9f3b239140b6598    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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 <[email protected]>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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 <[email protected]>    
date     : Mon, 26 Aug 2019 11:14:24 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 9.5  

commit   : 363382521eb26106587c7dab7f439636c3a6876a    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : cd714b3507c914e78d47352d1e126b4bec4380ad    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 54ff1c34f11b3f899be66fa55f85dbace83be741    
  
author   : Thomas Munro <[email protected]>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    
  
committer: Thomas Munro <[email protected]>    
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 <[email protected]>    
date     : Fri, 23 Aug 2019 20:41:13 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Thu, 22 Aug 2019 20:19:20 -0400    
  
committer: Bruce Momjian <[email protected]>    
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 <[email protected]>    
date     : Thu, 22 Aug 2019 22:36:45 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 22 Aug 2019 22:36:45 +0200    

see d315639c82e8a2cfd1d1b98b7acf0f6c033ab955  

commit   : f87b986e7d9fb47bd7dae77c26a79698d5297ab5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 22 Aug 2019 22:35:00 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Thu, 22 Aug 2019 09:59:16 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 9.4  

commit   : d60ec8fe529850d10c3422086912056c5af4e61c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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 <[email protected]>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    

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

commit   : d38753c6f79d1eb7d3096ff777ec6df0bc7e5008    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Aug 2019 13:45:53 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Tue, 20 Aug 2019 12:37:30 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 842ac79407a1368308beff230d3e83aad6d82b75    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    

Reported-By: Heikki Linnakangas  
Author: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 12-, where pluggable table access methods were introduced  

commit   : 03813a50efa563f19110013b06e80f08d4f49cf5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 372d6a8918e03f182242b260902dd47e5c5dd6e5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 75b2f011f642bbc7fab8352f4bcfb6e3fc494e7a    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : b626483bd97be374ad827f800171478773ad8282    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 14 Aug 2019 13:38:16 +0900    
  
committer: Michael Paquier <[email protected]>    
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 <[email protected]>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 4c0b9cf9e073ca2dc95a75fe983d90fd518864fb    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 13 Aug 2019 10:55:58 +0900    
  
committer: Michael Paquier <[email protected]>    
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/[email protected]  
Backpatch-through: 10  

commit   : a05fa2c0e77535470b6ee1029671eb41c612f4ef    
  
author   : Peter Geoghegan <[email protected]>    
date     : Mon, 12 Aug 2019 15:21:30 -0700    
  
committer: Peter Geoghegan <[email protected]>    
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/[email protected]  
Backpatch: 10-, where amcheck was introduced.  

commit   : c0c12ce391d89328640dd948b82466c308d85415    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : de0dc0b758ed7452ceee756d9d620c4393b3cb53    
  
author   : Alexander Korotkov <[email protected]>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    
  
committer: Alexander Korotkov <[email protected]>    
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 <[email protected]>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 59d3789294cf6d42325e92486b053f1ee5934eb8    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    
  
committer: Tom Lane <[email protected]>    
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 <[email protected]>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    

Reviewed by Tom Lane and Amit Langote  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4116420baeae614a2711e156f0c4e58adad172ba    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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 <[email protected]>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2019 18:09:28 -0400