PostgreSQL 10.2 commit log

commit   : 2840d201c6a62beb86d9671a66eeec56183d261b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 16:01:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 16:01:02 -0500    

commit   : cbe0dd581e7c7a815f6df6d849449225c902b17c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 14:43:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 14:43:40 -0500    

Security: CVE-2018-1052, CVE-2018-1053  

commit   : dc6fb453a33659c5b8e916c67121eba5d78c52b4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Feb 2018 12:27:10 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Feb 2018 12:27:10 -0500    

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

commit   : 6ba52aeb24e62586b51e77723d87627c18a844ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 10:58:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 10:58:27 -0500    

pg_upgrade has always attempted to ensure that the transient dump files  
it creates are inaccessible except to the owner.  However, refactoring  
in commit 76a7650c4 broke that for the file containing "pg_dumpall -g"  
output; since then, that file was protected according to the process's  
default umask.  Since that file may contain role passwords (hopefully  
encrypted, but passwords nonetheless), this is a particularly unfortunate  
oversight.  Prudent users of pg_upgrade on multiuser systems would  
probably run it under a umask tight enough that the issue is moot, but  
perhaps some users are depending only on pg_upgrade's umask changes to  
protect their data.  
  
To fix this in a future-proof way, let's just tighten the umask at  
process start.  There are no files pg_upgrade needs to write at a  
weaker security level; and if there were, transiently relaxing the  
umask around where they're created would be a safer approach.  
  
Report and patch by Tom Lane; the idea for the fix is due to Noah Misch.  
Back-patch to all supported branches.  
  
Security: CVE-2018-1053  

commit   : fe921a360a4858f537c99d1872d3c3a5a09d6df0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 10:37:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Feb 2018 10:37:30 -0500    

Failure to advance the list pointer while reading partition expressions  
from a list results in invoking an input function with inappropriate data,  
possibly leading to crashes or, with carefully crafted input, disclosure  
of arbitrary backend memory.  
  
Bug discovered independently by Álvaro Herrera and David Rowley.  
This patch is by Álvaro but owes something to David's proposed fix.  
Back-patch to v10 where the issue was introduced.  
  
Security: CVE-2018-1052  

commit   : 20446a4a04240ce9880331eea3082c906ede4f26    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Feb 2018 11:29:23 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Feb 2018 11:29:23 -0500    

Reported-by: Shay Rojansky <roji@roji.org>  

commit   : 1be67528e1088d8660acd13cb5eb6824a797ae08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Feb 2018 15:13:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Feb 2018 15:13:44 -0500    

commit   : a643f5c2adc7698d0cfa1f3648074b1a27c6168d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Feb 2018 11:09:24 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Feb 2018 11:09:24 -0500    

Author: Alexander Lakhin <exclusion@gmail.com>  

commit   : 6dbae688d8526e4f277c4a7bf85497e03a947e59    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Feb 2018 10:19:57 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 3 Feb 2018 10:19:57 -0500    

commit   : dcc1e61cb23606bf3e90079a0529821939c0e9c6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Feb 2018 21:10:59 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Feb 2018 21:10:59 -0500    

The index entry was pointing to a slightly wrong location.  

commit   : 34653bc9833d9c95ed1c52bed1ff01c6193de17b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Feb 2018 18:26:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Feb 2018 18:26:07 -0500    

Commit 445dbd82a basically missed the point of commit d46633506,  
which was that we shouldn't allow shm_toc_lookup() failure to lead  
to a core dump or assertion crash, because the odds of such a  
failure should never be considered negligible.  It's correct that  
we can't expect the PARALLEL_KEY_ERROR_QUEUE TOC entry to be there  
if we have no workers.  But if we have no workers, we're not going  
to do anything in this function with the lookup result anyway,  
so let's just skip it.  That lets the code use the easy-to-prove-safe  
noError=false case, rather than anything requiring effort to review.  
  
Back-patch to v10, like the previous commit.  
  
Discussion: https://postgr.es/m/3647.1517601675@sss.pgh.pa.us  

commit   : 1597948c962a1407c01fc492c44917c097efa92e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Feb 2018 14:20:50 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Feb 2018 14:20:50 -0500    

Investigation of 2d2d06b7e27e3177d5bef0061801c75946871db3 revealed that  
identity values were not applied in some further cases, including  
logical replication subscribers, VALUES RTEs, and ALTER TABLE ... ADD  
COLUMN.  To fix all that, apply the identity column expression in  
build_column_default() instead of repeating the same logic at each call  
site.  
  
For ALTER TABLE ... ADD COLUMN ... IDENTITY, the previous coding  
completely ignored that existing rows for the new column should have  
values filled in from the identity sequence.  The coding using  
build_column_default() fails for this because the sequence ownership  
isn't registered until after ALTER TABLE, and we can't do it before  
because we don't have the column in the catalog yet.  So we specially  
remember in ColumnDef the sequence name that we decided on and build a  
custom NextValueExpr using that.  
  
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>  

commit   : b94988fad56167915231d3d2b275c471914301fe    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 1 Feb 2018 15:21:13 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 1 Feb 2018 15:21:13 -0500    

Report and suggested fix by Lixian Zou.  Amit Kapila put it  
in the form of a patch and reviewed.  
  
Discussion: http://postgr.es/m/151739848647.1239.12528851873396651946@wrigleys.postgresql.org  

commit   : 94a2b075779b599c6ee21f04cfafdd68cd84797d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 17:52:47 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 17:52:47 -0500    

Fix wording from commit 1cf1112990cff432b53a74a0ac9ca897ce8a7688  
  
Reported-by: Robert Haas  
  
Backpatch-through: 10  

commit   : b2e6dfeacfdcf493073c8a7e7deadd34e4d5ea03    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 17:09:59 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 17:09:59 -0500    

The previous docs added in PG 10 were not clear enough for someone who  
didn't understand the PG 10 version change, so give more specific  
examples.  
  
Reported-by: jim@room118solutions.com  
  
Discussion: https://postgr.es/m/20171218213041.25744.8414@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 5b648388b832620af403ad9cafae04eee46bd49f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 17:00:17 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 17:00:17 -0500    

The previous wording added in PG 10 wasn't specific enough about the  
behavior of statement and row triggers when using inheritance.  
  
Reported-by: ian@thepathcentral.com  
  
Discussion: https://postgr.es/m/20171129193934.27108.30796@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 19eb7f84e75f592c7a7134d2d02105a3d44ff7e7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 16:54:33 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 16:54:33 -0500    

Also remove outdated comment about SPI subtransactions.  
  
Reported-by: gregory@arenius.com  
  
Discussion: https://postgr.es/m/151726276676.1240.10501743959198501067@wrigleys.postgresql.org  
  
Backpatch-through: 9.3  

commit   : a9fd6c321672c14940461ee47c52434bcf2ecdf9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Jan 2018 16:45:37 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Jan 2018 16:45:37 -0500    

Along the way, also fix code indentation.  
  
Alexander Lakhin, reviewed by Michael Paquier  
  
Discussion: http://postgr.es/m/45c44aa7-7cfa-7f3b-83fd-d8300677fdda@gmail.com  

commit   : 0ae0f0777bf181df42368464600059d62b3a4e4d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 16:43:32 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 16:43:32 -0500    

Commit 9521ce4a7a1125385fb4de9689f345db594c516a from Sep 13, 2017 and  
backpatched through 9.5 used rsync examples with datadir.  The reporter  
has pointed out, and testing has verified, that clusterdir must be used,  
so update the docs accordingly.  
  
Reported-by: Don Seiler  
  
Discussion: https://postgr.es/m/CAHJZqBD0u9dCERpYzK6BkRv=663AmH==DFJpVC=M4Xg_rq2=CQ@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : 1787c332dbb7629b893e52afcf37076ebe4db9a3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Jan 2018 16:28:11 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Jan 2018 16:28:11 -0500    

Previously, only 128 was mentioned, but the others are also supported.  
  
Thomas Munro, reviewed by Michael Paquier and extended a bit by me.  
  
Discussion: http://postgr.es/m/CAEepm=1XbBHXYJKofGjnM2Qfz-ZBVqhGU4AqvtgR+Hegy4fdKg@mail.gmail.com  

commit   : 3dcc7ceec034788b6ef89f90eb1be869e0c40a05    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 16:25:21 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Jan 2018 16:25:21 -0500    

Technically, pg_upgrade's --old-datadir and --new-datadir are  
configuration directories, not necessarily data directories.  This is  
reflected in the 'postgres' manual page, so do the same for pg_upgrade.  
  
Reported-by: Yves Goergen  
  
Bug: 14898  
  
Discussion: https://postgr.es/m/20171110220912.31513.13322@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 86fba28657858307bb27d4d7e3a9ef053ac0c2b4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Jan 2018 15:43:11 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Jan 2018 15:43:11 -0500    

The old code generated always generated a constraint of the form  
col = ANY(ARRAY[val1, val2, ...]), but that's invalid when col is an  
array type.  Instead, generate col = val when there's only one value,  
col = val1 OR col = val2 OR ... when there are multiple values and  
col is of array type, and the old form when there are multiple values  
and col is not of an array type.  
  
As a side benefit, this makes constraint exclusion able to prune  
a list partition declared to accept a single Boolean value, which  
didn't work before.  
  
Amit Langote, reviewed by Etsuro Fujita  
  
Discussion: http://postgr.es/m/97267195-e235-89d1-a41a-c110198dfce9@lab.ntt.co.jp  

commit   : 167a22b2a624531fe106e1564bc5f62e275a036d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 30 Jan 2018 16:50:30 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 30 Jan 2018 16:50:30 -0500    

pg_hba_file_rules erroneously reported this as scram-sha256.  Fix that.  
  
To avoid future errors and confusion, also adjust documentation links  
and internal symbols to have a separator between "sha" and "256".  
  
Reported-by: Christophe Courtois <christophe.courtois@dalibo.com>  
Author: Michael Paquier <michael.paquier@gmail.com>  

commit   : 92123c6ea212a32097d34c91ea6b52f0c3a5b8c3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 30 Jan 2018 14:27:38 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 30 Jan 2018 14:27:38 -0500    

Commit 4bbf6edfbd5d03743ff82dda2f00c738fb3208f5 added a test case,  
but it turns out that the test case doesn't reliably test for the  
bug, and in the context of the regression test suite did not because  
ANALYZE had not been run.  
  
Report and patch by Etsuro Fujita.  I added a comment along lines  
previously suggested by Tom Lane.  
  
Discussion: http://postgr.es/m/5A6195D8.8060206@lab.ntt.co.jp  

commit   : d1aac2998789e16343befd8b3de8ad12b6dc4355    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Jan 2018 11:02:09 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Jan 2018 11:02:09 -0800    

In cases where simplehash tables where filled with either a lot of  
conflicting hash-values, or values that hash to consecutive  
values (i.e. build "chains") the growth heuristics in  
d4c62a6b623d6eef88218158e9fa3cf974c6c7e5 could trigger rather  
explosively.  
  
To fix that, address some of the reasons (see previous commit) of why  
the growth heuristics where needed, and only allow growth when the  
table isn't too empty. While that means there's a few cases of bad  
input that can be slower, that seems a lot better than running very  
quickly out of memory.  
  
Author: Tomas Vondra and Andres Freund, with additional input by  
    Thomas Munro, Tom Lane Todd A. Cook  
Reported-By: Todd A. Cook, Tomas Vondra, Thomas Munro  
Discussion: https://postgr.es/m/20171127185700.1470.20362@wrigleys.postgresql.org  
Backpatch: 10, where simplehash was introduced  

commit   : d18d4bca81f80686238551d1cc460510c3c30544    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Jan 2018 11:02:09 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Jan 2018 11:02:09 -0800    

The changes in b81b5a96f424531b97cdd1dba97d9d1b9c9d372e did not fully  
address the issue, because the bit-mixing of the IV into the final  
hash-key didn't prevent clustering in the input-data survive in the  
output data.  
  
This didn't cause a lot of problems because of the additional growth  
conditions added d4c62a6b623d6eef88218158e9fa3cf974c6c7e5. But as we  
want to rein those in due to explosive growth in some edges, this  
needs to be fixed.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20171127185700.1470.20362@wrigleys.postgresql.org  
Backpatch: 10, where simplehash was introduced  

commit   : c0fda304df276606e6b3c9ce5c63c187fe775602    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 22 Sep 2017 13:38:42 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 22 Sep 2017 13:38:42 -0700    

The function already existed in tidbitmap.c but more users requiring  
fast hashing of 32bit ints are coming up.  
  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/20170914061207.zxotvyopetm7lrrp@alap3.anarazel.de  
    https://postgr.es/m/15ae5ae2-bc74-ebef-f9d6-34b16423cc04@blackducksoftware.com  
Original-Commit: 791961f59b792fbd4f0a992d3ccab47298e79103  

commit   : 1b2a3860d3ea81825e9bbad2c7dbf66db87445c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jan 2018 13:39:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jan 2018 13:39:07 -0500    

create_plan_recurse lacked any stack depth check.  This is not per  
our normal coding rules, but I'd supposed it was safe because earlier  
planner processing is more complex and presumably should eat more  
stack.  But bug #15033 from Andrew Grossman shows this isn't true,  
at least not for queries having the form of a many-thousand-way  
INTERSECT stack.  
  
Further testing showed that recurse_set_operations is also capable  
of being crashed in this way, since it likewise will recurse to the  
bottom of a parsetree before calling any support functions that  
might themselves contain any stack checks.  However, its stack  
consumption is only perhaps a third of create_plan_recurse's.  
  
It's possible that this particular problem with create_plan_recurse can  
only manifest in 9.6 and later, since before that we didn't build a Path  
tree for set operations.  But having seen this example, I now have no  
faith in the proposition that create_plan_recurse doesn't need a stack  
check, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20180127050845.28812.58244@wrigleys.postgresql.org  

commit   : 76e117dbed8c0fee084fbfc06f15c6c377690f59    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 28 Jan 2018 16:14:31 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 28 Jan 2018 16:14:31 +0000    

25fff40798fc4ac11a241bfd9ab0c45c085e2212 introduced  
default monitoring roles. Apply these corrections:  
  
* Allow access to pg_stat_get_wal_senders()  
  by role pg_read_all_stats  
  
* Correct comment in pg_stat_get_wal_receiver()  
  to show it is no longer superuser-only.  
  
Author: Feike Steenbergen  
Reviewed-by: Michael Paquier  
  
Apply to HEAD, then later backpatch to 10  

commit   : 2d71b2700b20f2a2274d69598c6fc979cba7f9b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jan 2018 16:42:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jan 2018 16:42:28 -0500    

DST law changes in Brazil, Sao Tome and Principe.  Historical corrections  
for Bolivia, Japan, and South Sudan.  The "US/Pacific-New" zone has been  
removed (it was only a link to America/Los_Angeles anyway).  

commit   : 78433f41fa1d34d67d48f28f783056c394e8512e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jan 2018 13:52:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jan 2018 13:52:24 -0500    

Commit 09529a70b changed nodeIndexscan.c and nodeIndexonlyscan.c to  
postpone initialization of the indexscan proper until the first tuple  
fetch.  It overlooked the question of mark/restore behavior, which means  
that if some caller attempts to mark the scan before the first tuple fetch,  
you get a null pointer dereference.  
  
The only existing user of mark/restore is nodeMergejoin.c, which (somewhat  
accidentally) will never attempt to set a mark before the first inner tuple  
unless the inner child node is a Material node.  Hence the case can't arise  
normally, so it seems sufficient to document the assumption at both ends.  
However, during an EvalPlanQual recheck, ExecScanFetch doesn't call  
IndexNext but just returns the jammed-in test tuple.  Therefore, if we're  
doing a recheck in a plan tree with a mergejoin with inner indexscan,  
it's possible to reach ExecIndexMarkPos with iss_ScanDesc still null,  
as reported by Guo Xiang Tan in bug #15032.  
  
Really, when there's a test tuple supplied during an EPQ recheck, touching  
the index at all is the wrong thing: rather, the behavior of mark/restore  
ought to amount to saving and restoring the es_epqScanDone flag.  We can  
avoid finding a place to actually save the flag, for the moment, because  
given the assumption that no caller will set a mark before fetching a  
tuple, es_epqScanDone must always be set by the time we try to mark.  
So the actual behavior change required is just to not reach the index  
access if a test tuple is supplied.  
  
The set of plan node types that need to consider this issue are those  
that support EPQ test tuples (i.e., call ExecScan()) and also support  
mark/restore; which is to say, IndexScan, IndexOnlyScan, and perhaps  
CustomScan.  It's tempting to try to fix the problem in one place by  
teaching ExecMarkPos() itself about EPQ; but ExecMarkPos supports some  
plan types that aren't Scans, and also it seems risky to make assumptions  
about what a CustomScan wants to do here.  Also, the most likely future  
change here is to decide that we do need to support marks placed before  
the first tuple, which would require additional work in IndexScan and  
IndexOnlyScan in any case.  Hence, fix the EPQ issue in nodeIndexscan.c  
and nodeIndexonlyscan.c, accepting the small amount of code duplicated  
thereby, and leave it to CustomScan providers to fix this bug if they  
have it.  
  
Back-patch to v10 where commit 09529a70b came in.  In earlier branches,  
the index_markpos() call is a waste of cycles when EPQ is active, but  
no more than that, so it doesn't seem appropriate to back-patch further.  
  
Discussion: https://postgr.es/m/20180126074932.3098.97815@wrigleys.postgresql.org  

commit   : 56067dee74a096af951386740bf8a1ab5f1ce590    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 27 Jan 2018 13:13:52 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 27 Jan 2018 13:13:52 +0100    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : 51fc1b09a3baa5361a15c4d4ec4faa74a3a3cee0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jan 2018 09:51:15 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jan 2018 09:51:15 -0500    

This can cause it to produce incorrect output.  
  
Report and patch by Masahiko Sawada.  
  
Discussion: http://postgr.es/m/CAD21AoBc5Asx7pXdUWu6NqU_g=Ysn95EGL9SMeYhLLduYoO_OA@mail.gmail.com  

commit   : 48de935b08895d6562f27105ff3bd2b7ef8e5775    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 24 Jan 2018 15:13:04 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 24 Jan 2018 15:13:04 -0500    

This was done to match the surrounding indentation.  Text added in PG  
10.  
  
Backpatch-through: 10  

commit   : 56c00634b4e4df800cb7dd809edb083a4ca997f8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 Jan 2018 18:22:56 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 Jan 2018 18:22:56 -0500    

Reported-by: Mark Wood  
  
Bug: 14912  
  
Discussion: https://postgr.es/m/20171116171735.1474.30450@wrigleys.postgresql.org  
  
Author: David G. Johnston  
  
Backpatch-through: 10  

commit   : c5e59bb602e5b0bf15a8eb001eac8b31892ea037    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jan 2018 16:50:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jan 2018 16:50:34 -0500    

If we're inside a lateral subquery, there may be no unparameterized paths  
for a particular child relation of an appendrel, in which case we *must*  
be able to create similarly-parameterized paths for each other child  
relation, else the planner will fail with "could not devise a query plan  
for the given query".  This means that there are situations where we'd  
better be able to reparameterize at least one path for each child.  
  
This calls into question the assumption in reparameterize_path() that  
it can just punt if it feels like it.  However, the only case that is  
known broken right now is where the child is itself an appendrel so that  
all its paths are AppendPaths.  (I think possibly I disregarded that in  
the original coding on the theory that nested appendrels would get folded  
together --- but that only happens *after* reparameterize_path(), so it's  
not excused from handling a child AppendPath.)  Given that this code's been  
like this since 9.3 when LATERAL was introduced, it seems likely we'd have  
heard of other cases by now if there were a larger problem.  
  
Per report from Elvis Pranskevichus.  Back-patch to 9.3.  
  
Discussion: https://postgr.es/m/5981018.zdth1YWmNy@hammer.magicstack.net  

commit   : bfe23f83f7daa8d8455c2268e647391c481d0ed3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jan 2018 15:22:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jan 2018 15:22:13 -0300    

autovacuum.c no longer needs dsa.h, since commit 31ae1638ce3.  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoCWvYyXrvdANSHWWWEWJH5TeAWAkJ_2gqrHhukG+OBo1g@mail.gmail.com  

commit   : 5ca17d655f96fd442b6857f26f5660f541d93c38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jan 2018 12:41:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jan 2018 12:41:35 -0500    

Overlooked in commit f13ea95f9.  Noted by Nick Barnes.  
  
Discussion: https://postgr.es/m/20180123093723.7407.3386@wrigleys.postgresql.org  

commit   : 383e4268ff8c5a521b9fec37c017380852b4a19a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 23 Jan 2018 11:13:42 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 23 Jan 2018 11:13:42 -0500    

Commit 28724fd90d2f85a0573a8107b48abad062a86d83 fixed things so that  
if a background worker fails to start due to fork() failure or because  
it is terminated before startup succeeds, BGWH_STOPPED will be  
reported.  However, that only helps if the code that uses the  
background worker machinery notices the change in status, and the code  
in parallel.c did not.  
  
To fix that, do two things.  First, make sure that when a worker  
exits, it triggers the leader to read from error queues.  That way, if  
a worker which has attached to an error queue exits uncleanly, the  
leader is sure to throw some error, either the contents of the  
ErrorResponse sent by the worker, or "lost connection to parallel  
worker" if it exited without sending one.  To cover the case where  
the worker never starts up in the first place or exits before  
attaching to the error queue, the ParallelContext now keeps track  
of which workers have sent at least one message via the error  
queue.  A worker which sends no messages by the time the parallel  
operation finishes will be checked to see whether it exited before  
attaching to the error queue; if so, a new error message, "parallel  
worker failed to initialize", will be reported.  If not, we'll  
continue to wait until it either starts up and exits cleanly, starts  
up and exits uncleanly, or fails to start, and then take the  
appropriate action.  
  
Patch by me, reviewed by Amit Kapila.  
  
Discussion: http://postgr.es/m/CA+TgmoYnBgXgdTu6wk5YPdWhmgabYc9nY_pFLq=tB=FSLYkD8Q@mail.gmail.com  

commit   : 5aaa86666f4b8f78ed22505a1b0350ee1aafb3db    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 Jan 2018 10:18:21 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 Jan 2018 10:18:21 -0500    

Backpatch-through: 9.3  

commit   : 46246fd9df7d3ca58de23fcfc87326830ac707d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jan 2018 12:06:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jan 2018 12:06:18 -0500    

_tocEntryRequired() expects that it can identify ACL, SECURITY LABEL,  
and COMMENT TOC entries that are for large objects by seeing whether  
the tag for them starts with "LARGE OBJECT ".  While that works fine  
for actual large objects, which are indeed tagged that way, it's  
subject to false positives unless every such entry's tag starts with an  
appropriate type ID.  And in fact it does not work for ACLs, because  
up to now we customarily tagged those entries with just the bare name  
of the object.  This means that an ACL for an object named  
"LARGE OBJECT something" would be misclassified as data not schema,  
with undesirable results in a schema-only or data-only dump ---  
although pg_upgrade seems unaffected, due to the special case for  
binary-upgrade mode further down in _tocEntryRequired().  
  
We can fix this by changing all the dumpACL calls to use the label  
strings already in use for comments and security labels, which do  
follow the convention of starting with an object type indicator.  
  
Well, mostly they follow it.  dumpDatabase() got it wrong, using  
just the bare database name for those purposes, so that a database  
named "LARGE OBJECT something" would similarly be subject to having  
its comment or security label dropped or included when not wanted.  
Bring that into line too.  (Note that up to now, database ACLs have  
not been processed by pg_dump, so that this issue doesn't affect them.)  
  
_tocEntryRequired() itself is not free of fault: it was overly liberal  
about matching object tags to "LARGE OBJECT " in binary-upgrade mode.  
This looks like it is probably harmless because there would be no data  
component to strip anyway in that mode, but at best it's trouble  
waiting to happen, so tighten that up too.  
  
The possible misclassification of SECURITY LABEL entries for databases is  
in principle a security problem, but the opportunities for actual exploits  
seem too narrow to be interesting.  The other cases seem like just bugs,  
since an object owner can change its ACL or comment for himself, he needn't  
try to trick someone else into doing it by choosing a strange name.  
  
This has been broken since per-large-object TOC entries were introduced  
in 9.0, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/21714.1516553459@sss.pgh.pa.us  

commit   : d66cfe1bf430ba20c52a9e9a9565edcb7cc0ac48    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 21 Jan 2018 13:40:55 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 21 Jan 2018 13:40:55 +0100    

The field is still called "hostaddr", so make sure references use  
"hostaddr values" instead.  
  
Author: Michael Paquier <michael.paquier@gmail.com>  

commit   : e477d148e70302f1f93a42f0ebf0e5770a0fd64f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 Jan 2018 21:47:02 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 Jan 2018 21:47:02 -0500    

Document how to properly create root and intermediate certificates using  
v3_ca extensions and where to place intermediate certificates so they  
are properly transferred to the remote side with the leaf certificate to  
link to the remote root certificate.  This corrects docs that used to  
say that intermediate certificates must be stored with the root  
certificate.  
  
Also add instructions on how to create root, intermediate, and leaf  
certificates.  
  
Discussion: https://postgr.es/m/20180116002238.GC12724@momjian.us  
  
Reviewed-by: Michael Paquier  
  
Backpatch-through: 9.3  

commit   : 61f08c016322ce44b2d35ff5c569d495371a3322    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jan 2018 10:15:08 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jan 2018 10:15:08 -0300    

For no apparent reason, this function was using a 16bit-wide inhseqno  
value, rather than the correct 32 bit width which is what is stored in  
the pg_inherits catalog.  This becomes evident if you try to create a  
table with more than 65535 parents, because this error appears:  
  
ERROR:  duplicate key value violates unique constraint «pg_inherits_relid_seqno_index»  
DETAIL:  Key (inhrelid, inhseqno)=(329371, 0) already exists.  
  
Needless to say, having so many parents is an uncommon situations, which  
explains why this error has never been reported despite being having  
been introduced with the Postgres95 1.01 sources in commit d31084e9d111:  
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/creatinh.c;hb=d31084e9d111#l349  
  
Backpatch all the way back.  
  
David Rowley noticed this while reviewing a patch of mine.  
Discussion: https://postgr.es/m/CAKJS1f8Dn7swSEhOWwzZzssW7747YB=2Hi+T7uGud40dur69-g@mail.gmail.com  

commit   : 5dcbdcbdda488b53768a3093481a2f7d8210cc51    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jan 2018 11:09:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jan 2018 11:09:44 -0500    

On Sparc64, use of __attribute__(aligned(8)) with __int128 causes faulty  
code generation in gcc versions at least through 5.5.0.  We can work around  
that by disabling use of __int128, so teach configure to test for the bug.  
  
This solution doesn't fix things for the case of cross-compiling with a  
buggy compiler; to support that nicely, we'd need to add a manual disable  
switch.  Unless more such cases turn up, it doesn't seem worth the work.  
Affected users could always edit pg_config.h manually.  
  
In passing, fix some typos in the existing configure test for __int128.  
They're harmless because we only compile that code not run it, but  
they're still confusing for anyone looking at it closely.  
  
This is needed in support of commit 751804998, so back-patch to 9.5  
as that was.  
  
Marina Polyakova, Victor Wagner, Tom Lane  
  
Discussion: https://postgr.es/m/0d3a9fa264cebe1cb9966f37b7c06e86@postgrespro.ru  

commit   : 3f05a30b50a7e283d2664719c2fa0832fcd37da0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jan 2018 16:18:39 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 17 Jan 2018 16:18:39 -0500    

When pushing down a join to a foreign server, postgres_fdw constructs  
an alternative plan to be used for any EvalPlanQual rechecks that  
prove to be necessary.  This plan is stored as the outer subplan of  
the Foreign Scan implementing the pushed-down join.  Previously, this  
alternative plan could have a different nominal sort ordering than its  
parent, which seemed OK since there will only be one tuple per base  
table anyway in the case of an EvalPlanQual recheck.  Actually,  
though, it caused a problem if that path was used as a building block  
for the EvalPlanQual recheck plan of a higher-level foreign join,  
because we could end up with a merge join one of whose inputs was not  
labelled with the correct sort order.  Repair by injecting an extra  
Sort node into the EvalPlanQual recheck plan whenever it would  
otherwise fail to be sorted at least as well as its parent Foreign  
Scan.  
  
Report by Jeff Janes.  Patch by me, reviewed by Tom Lane, who also  
provided the test case and comment text.  
  
Discussion: http://postgr.es/m/CAMkU=1y2G8VOVBHv3iXU2TMAj7-RyBFFW1uhkr5sm9LQ2=X35g@mail.gmail.com  

commit   : 8b89b7aaca42d9f1b0798aebb84b088dd0b092fa    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sat, 13 Jan 2018 14:56:49 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sat, 13 Jan 2018 14:56:49 +0100    

Patch by: "Rader, David" <davidr@openscg.com>  

commit   : 67854bc59a8b283f02f2a8f0c0095df639bedf06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jan 2018 16:52:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jan 2018 16:52:49 -0500    

Commit 7012b132d, which added the ability to push down aggregates and  
grouping to the remote server, wasn't careful to ensure that the remote  
server would have the same idea we do about which columns are the grouping  
columns, in cases where there are textually identical GROUP BY expressions.  
Such cases typically led to "targetlist item has multiple sortgroupref  
labels" errors.  
  
To fix this reliably, switch over to using "GROUP BY column-number" syntax  
rather than "GROUP BY expression" in transmitted queries, and adjust  
foreign_grouping_ok() to be more careful about duplicating the sortgroupref  
labeling of the local pathtarget.  
  
Per bug #14890 from Sean Johnston.  Back-patch to v10 where the buggy code  
was introduced.  
  
Jeevan Chalke, reviewed by Ashutosh Bapat  
  
Discussion: https://postgr.es/m/20171107134948.1508.94783@wrigleys.postgresql.org  

commit   : 55e5eb4d97fbe78af9c81d808afbd0d8559fb392    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jan 2018 15:46:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jan 2018 15:46:37 -0500    

If a query against an inheritance tree runs concurrently with an ALTER  
TABLE that's disinheriting one of the tree members, it's possible to get  
a "could not find inherited attribute" error because after obtaining lock  
on the removed member, make_inh_translation_list sees that its columns  
have attinhcount=0 and decides they aren't the columns it's looking for.  
  
An ideal fix, perhaps, would avoid including such a just-removed member  
table in the query at all; but there seems no way to accomplish that  
without adding expensive catalog rechecks or creating a likelihood of  
deadlocks.  Instead, let's just drop the check on attinhcount.  In this  
way, a query that's included a just-disinherited child will still  
succeed, which is not a completely unreasonable behavior.  
  
This problem has existed for a long time, so back-patch to all supported  
branches.  Also add an isolation test verifying related behaviors.  
  
Patch by me; the new isolation test is based on Kyotaro Horiguchi's work.  
  
Discussion: https://postgr.es/m/20170626.174612.23936762.horiguchi.kyotaro@lab.ntt.co.jp  

commit   : d3ca1a6c3721b910fa8c05f41397727a53409fd3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jan 2018 12:24:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jan 2018 12:24:50 -0500    

If we flatten a subquery whose target list contains constants or  
expressions, when those output columns are used in GROUPING SET columns,  
the planner was capable of doing the wrong thing by merging a pulled-up  
expression into the surrounding expression during const-simplification.  
Then the late processing that attempts to match subexpressions to grouping  
sets would fail to match those subexpressions to grouping sets, with the  
effect that they'd not go to null when expected.  
  
To fix, wrap such subquery outputs in PlaceHolderVars, ensuring that  
they preserve their separate identity throughout the planner's expression  
processing.  This is a bit of a band-aid, because the wrapper defeats  
const-simplification even in places where it would be safe to allow.  
But a nicer fix would likely be too invasive to back-patch, and the  
consequences of the missed optimizations probably aren't large in most  
cases.  
  
Back-patch to 9.5 where grouping sets were introduced.  
  
Heikki Linnakangas, with small mods and better test cases by me;  
additional review by Andrew Gierth  
  
Discussion: https://postgr.es/m/7dbdcf5c-b5a6-ef89-4958-da212fe10176@iki.fi  

commit   : b8279a783dafb7c715b3835d4c9244d3451c4c1a    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 11 Jan 2018 14:42:16 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 11 Jan 2018 14:42:16 +0300    

~> (cube, int) operator was especially designed for knn-gist search.  
However, it appears that knn-gist search can't work correctly with current  
behavior of this operator when dataset contains cubes of variable  
dimensionality. In this case, the same value of second operator argument  
can point to different dimension depending on dimensionality of particular cube.  
Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't  
work correctly for it.  
  
This patch changes behavior of ~> (cube, int) operator by introducing dimension  
numbering where value of second argument unambiguously identifies number of  
dimension. With new behavior, this operator can be correctly supported by  
knn-gist. Relevant changes to cube operator class are also included.  
  
Backpatch to v9.6 where operator was introduced.  
  
Since behavior of ~> (cube, int) operator is changed, depending entities  
must be refreshed after upgrade. Such as, expression indexes using this  
operator must be reindexed, materialized views must be rebuilt, stored  
procedures and client code must be revised to correctly use new behavior.  
That should be mentioned in release notes.  
  
Noticed by: Tomas Vondra  
Author: Alexander Korotkov  
Reviewed by: Tomas Vondra, Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com  

commit   : 08adf688f3e9218890929b5d687078974fb8d3de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jan 2018 17:13:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jan 2018 17:13:29 -0500    

These functions are stated to be Oracle-compatible, but they weren't.  
Yugo Nagata noticed that while our code returns zero for a zero or  
negative fourth parameter (occur_index), Oracle throws an error.  
Further testing by me showed that there was also a discrepancy in the  
interpretation of a negative third parameter (beg_index): Oracle thinks  
that a negative beg_index indicates the last place where the target  
substring can *begin*, whereas our code thinks it is the last place  
where the target can *end*.  
  
Adjust the sample code to behave like Oracle in both these respects.  
Also change it to be a CDATA[] section, simplifying copying-and-pasting  
out of the documentation source file.  And fix minor problems in the  
introductory comment, which wasn't very complete or accurate.  
  
Back-patch to all supported branches.  Although this patch only touches  
documentation, we should probably call it out as a bug fix in the next  
minor release notes, since users who have adopted the functions will  
likely want to update their versions.  
  
Yugo Nagata and Tom Lane  
  
Discussion: https://postgr.es/m/20171229191705.c0b43a8c.nagata@sraoss.co.jp  

commit   : 7eb0187a97674210515d167e022429c24d74d47c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jan 2018 15:50:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jan 2018 15:50:54 -0500    

It seems incorrect to assume that the list of CkptSortItems can never  
contain duplicate page numbers: concurrent activity could result in some  
page getting dropped from a low-numbered buffer and later loaded into a  
high-numbered buffer while BufferSync is scanning the buffer pool.  
If that happened, the comparator would give self-inconsistent results,  
potentially confusing qsort().  Saving one comparison step is not worth  
possibly getting the sort wrong.  
  
So far as I can tell, nothing would actually go wrong given our current  
implementation of qsort().  It might get a bit slower than expected  
if there were a large number of duplicates of one value, but that's  
surely a probability-epsilon case.  Still, the comment is wrong,  
and if we ever switched to another sort implementation it might be  
less forgiving.  
  
In passing, avoid casting away const-ness of the argument pointers;  
I've not seen any compiler complaints from that, but it seems likely  
that some compilers would not like it.  
  
Back-patch to 9.6 where this code came in, just in case I've underestimated  
the possible consequences.  
  
Discussion: https://postgr.es/m/18437.1515607610@sss.pgh.pa.us  

commit   : 37dd11281352c2e9cba6c3e2512a23b8ac3adeef    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Jan 2018 15:54:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Jan 2018 15:54:39 -0300    

As src/backend/access/transam/README says, PageGetLSN may only be called  
by processes holding either exclusive lock on buffer, or a shared lock  
on buffer plus buffer header lock.  Therefore any place that only holds  
a shared buffer lock must use BufferGetLSNAtomic instead of PageGetLSN,  
which internally obtains buffer header lock prior to reading the LSN.  
  
A few callsites failed to comply with this rule.  This was detected by  
running all tests under a new (not committed) assertion that verifies  
PageGetLSN locking contract.  All but one of the callsites that failed  
the assertion are fixed by this patch.  Remaining callsites were  
inspected manually and determined not to need any change.  
  
The exception (unfixed callsite) is in TestForOldSnapshot, which only  
has a Page argument, making it impossible to access the corresponding  
Buffer from it.  Fixing that seems a much larger patch that will have to  
be done separately; and that's just as well, since it was only  
introduced in 9.6 and other bugs are much older.  
  
Some of these bugs are ancient; backpatch all the way back to 9.3.  
  
Authors: Jacob Champion, Asim Praveen, Ashwin Agrawal  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/CABAq_6GXgQDVu3u12mK9O5Xt5abBZWQ0V40LZCE+oUf95XyNFg@mail.gmail.com  

commit   : d56a5f994c216847df3338e148b2ae72f20b2e0f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jan 2018 12:34:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jan 2018 12:34:46 -0500    

The general assumption for postmaster child processes is that they  
should just exit(1), reasonably promptly, if the postmaster disappears.  
condition_variable.c neglected this consideration and could be left  
waiting forever, if the counterpart process it is waiting for has  
done the right thing and exited.  
  
We had some discussion of adjusting the WaitEventSet API to make it  
harder to make this type of mistake in future; but for the moment,  
and for v10, let's make this narrow fix.  
  
Discussion: https://postgr.es/m/20412.1515456143@sss.pgh.pa.us  

commit   : 1f5adbd799cf5bf98259003840c69c65c6b021db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jan 2018 12:09:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jan 2018 12:09:30 -0500    

replorigin_drop() misunderstood the API for condition variables: it  
had ConditionVariablePrepareToSleep and ConditionVariableCancelSleep  
inside its test-and-sleep loop, rather than outside the loop as  
intended.  The net effect is a narrow race-condition window wherein,  
if the process using a replication slot releases it immediately after  
replorigin_drop() releases the ReplicationOriginLock, replorigin_drop()  
would get into the condition variable's wait list too late and then  
wait indefinitely for a signal that won't come.  
  
Because there's a different CV for each replication slot, we can't  
just move the ConditionVariablePrepareToSleep call to above the  
test-and-sleep loop.  What we can do, in the wake of commit 13db3b936,  
is drop the ConditionVariablePrepareToSleep call entirely.  This fix  
depends on that commit because (at least in principle) the slot matching  
the target replication origin might move around, so that once in a blue  
moon successive loop iterations might involve different CVs.  We can now  
cope with such a scenario, at the cost of an extra trip through the  
retry loop.  
  
(There are ways we could fix this bug without depending on that commit,  
but they're all a lot more complicated than this way.)  
  
While at it, upgrade the rather skimpy comments in this function.  
  
Back-patch to v10 where this code came in.  
  
Discussion: https://postgr.es/m/19947.1515455433@sss.pgh.pa.us  

commit   : 4af2190eb04b6a9160f2820e00802eabc78b4b1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jan 2018 11:39:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jan 2018 11:39:10 -0500    

The original coding here insisted that callers manually cancel any prepared  
sleep for one condition variable before starting a sleep on another one.  
While that's not a huge burden today, it seems like a gotcha that will bite  
us in future if the use of condition variables increases; anything we can  
do to make the use of this API simpler and more robust is attractive.  
Hence, allow these functions to automatically switch their attention to  
a different CV when required.  This is safe for the same reason it was OK  
for commit aced5a92b to let a broadcast operation cancel any prepared CV  
sleep: whenever we return to the other test-and-sleep loop, we will  
automatically re-prepare that CV, paying at most an extra test of that  
loop's exit condition.  
  
Back-patch to v10 where condition variables were introduced.  Ordinarily  
we would probably not back-patch a change like this, but since it does not  
invalidate any coding pattern that was legal before, it seems safe enough.  
Furthermore, there's an open bug in replorigin_drop() for which the  
simplest fix requires this.  Even if we chose to fix that in some more  
complicated way, the hazard would remain that we might back-patch some  
other bug fix that requires this behavior.  
  
Patch by me, reviewed by Thomas Munro.  
  
Discussion: https://postgr.es/m/2437.1515368316@sss.pgh.pa.us  

commit   : 1776c817c7ef452fb47d915d1b550cd73a318944    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jan 2018 22:43:51 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jan 2018 22:43:51 -0500    

Previously an inaccurate but harmless error was generated when running  
--check on a live server before reporting the servers as compatible.  
The fix is to split error reporting and exit control in the exec_prog()  
API.  
  
Reported-by: Daniel Westermann  
  
Backpatch-through: 10  

commit   : 83fe2708d66889ed9ef6bdb922d27bba4b0d4f81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jan 2018 19:42:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jan 2018 19:42:49 -0500    

In the admittedly-very-unlikely case that AddWaitEventToSet fails,  
ConditionVariablePrepareToSleep would error out after already having  
set cv_sleep_target, which is probably bad, and after having already  
set cv_wait_event_set, which is very bad.  Transaction abort might or  
might not clean up cv_sleep_target properly; but there is nothing  
that would be aware that the WaitEventSet wasn't fully constructed,  
so that all future condition variable sleeps would be broken.  
We can easily guard against these hazards with slight restructuring.  
  
Back-patch to v10 where condition_variable.c was introduced.  
  
Discussion: https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com  

commit   : 1c77e990833a72039a71ca3f813ff6d05a4d09b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jan 2018 19:21:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jan 2018 19:21:30 -0500    

The original implementation of ConditionVariableBroadcast was, per its  
self-description, "the dumbest way possible".  Thomas Munro found out  
it was a bit too dumb.  An awakened process may immediately re-queue  
itself, if the specific condition it's waiting for is not yet satisfied.  
If this happens before ConditionVariableBroadcast is able to see the wait  
queue as empty, then ConditionVariableBroadcast will re-awaken the same  
process, repeating the cycle.  Given unlucky timing this back-and-forth  
can repeat indefinitely; loops lasting thousands of seconds have been  
seen in testing.  
  
To fix, add our own process to the end of the wait queue to serve as a  
sentinel, and exit the broadcast loop once our process is not there  
anymore.  There are various special considerations described in the  
comments, the principal disadvantage being that wakers can no longer  
be sure whether they awakened a real waiter or just a sentinel.  But in  
practice nobody pays attention to the result of ConditionVariableSignal  
or ConditionVariableBroadcast anyway, so that problem seems hypothetical.  
  
Back-patch to v10 where condition_variable.c was introduced.  
  
Tom Lane and Thomas Munro  
  
Discussion: https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com  

commit   : 502b4118e72c6c212ad4304b57eb6ef3280ff428    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jan 2018 14:49:36 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jan 2018 14:49:36 -0500    

Revert another part of 959ee6d267fb24e667fc64e9837a376e236e84a5 .  
  
Backpatch-through: 10  

commit   : 5f45c72e3eea611bf7e06e0dd841c6f610c4d839    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jan 2018 14:46:26 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jan 2018 14:46:26 -0500    

Revert part of 959ee6d267fb24e667fc64e9837a376e236e84a5 .  
  
Backpatch-through: 10  

commit   : b3b058539c27c36a1b28c268e9179660ef0b0293    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jan 2018 14:11:15 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Jan 2018 14:11:15 -0500    

Backpatch-through: 9.4 (9.3 didn't need improving)  

commit   : a19c262f3a013065429462c7a322eebf3f7e3771    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 Jan 2018 12:17:10 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 5 Jan 2018 12:17:10 -0300    

Logical decoding's reorderbuffer.c may spill transaction files to disk  
when transactions are large.  These are supposed to be removed when they  
become "too old" by xid; but file removal requires the boundary LSNs of  
the transaction to be known.  The final_lsn is only set when we see the  
commit or abort record for the transaction, but nothing sets the value  
for transactions that crash, so the removal code misbehaves -- in  
assertion-enabled builds, it crashes by a failed assertion.  
  
To fix, modify the final_lsn of transactions that don't have a value  
set, to the LSN of the very latest change in the transaction.  This  
causes the spilled files to be removed appropriately.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Kyotaro HORIGUCHI, Craig Ringer, Masahiko Sawada  
Discussion: https://postgr.es/m/54e4e488-186b-a056-6628-50628e4e4ebc@lab.ntt.co.jp  

commit   : 0dc5dfcd7a7190739247a88c1c6249c75591effd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jan 2018 15:59:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jan 2018 15:59:30 -0500    

Per buildfarm.  
  
Discussion: https://postgr.es/m/ec295792-a69f-350f-6287-25a20e8f31d5@gmail.com  

commit   : 5ad1b1728767dbf0209b35072db372d19bc032f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jan 2018 14:59:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jan 2018 14:59:00 -0500    

Instead of using our standard macro for this calculation, this code  
did it itself ... and got it wrong, leading to incorrect display of  
the null bitmap in some cases.  Noted and fixed by Maksim Milyutin.  
  
In passing, remove a uselessly duplicative error check.  
  
Errors were introduced in commit d6061f83a; back-patch to 9.6  
where that came in.  
  
Maksim Milyutin, reviewed by Andrey Borodin  
  
Discussion: https://postgr.es/m/ec295792-a69f-350f-6287-25a20e8f31d5@gmail.com  

commit   : a6565da8b9ef2b900d298a19cb817a2c9ca90f7e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Jan 2018 11:16:34 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Jan 2018 11:16:34 -0300    

This reverts commit 2268e6afd596.  It turned out that inconsistency in  
the report is still possible, so go back to the simpler formulation of  
the test and instead add an alternate expected output.  
  
Discussion: https://postgr.es/m/20180103193728.ysqpcp2xjnqpiep7@alvherre.pgsql  

commit   : e3fdb7c00e783ed4b490554ab6bbaccad341c244    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 3 Jan 2018 12:00:11 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 3 Jan 2018 12:00:11 -0800    

Upcoming versions of glibc will contain copy_file_range(2), a wrapper  
around a new linux syscall for in-kernel copying of data ranges. This  
conflicts with pg_rewinds function of the same name.  
  
Therefore rename pg_rewinds version. As our version isn't a generic  
copying facility we decided to choose a rewind specific function name.  
  
Per buildfarm animal caiman and subsequent discussion with Tom Lane.  
  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/20180103033425.w7jkljth3e26sduc@alap3.anarazel.de  
    https://postgr.es/m/31122.1514951044@sss.pgh.pa.us  
Backpatch: 9.5-, where pg_rewind was introduced  

commit   : 0fb69340b2352d8491d15c11156d16988676f71f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 3 Jan 2018 15:26:39 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 3 Jan 2018 15:26:39 -0500    

Commit 614350a3 allowed for an different builds of OpenSSL libraries on  
Windows, but ignored the fact that the alternative builds don't have  
config-specific libraries. This patch fixes the Solution file to ask for  
the correct libraries.  
  
per offline discussions with Leonardo Cecchi and Marco Nenciarini,  
  
Backpatch to all live branches.  

commit   : 43fb4b42230d23e235bed895734a0931fa4c496d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Jan 2018 17:26:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Jan 2018 17:26:20 -0300    

XactLockTableWait assumed that its xid argument has already added itself  
to the lock table.  That assumption led to another assumption that if  
locking the xid has succeeded but the xid is reported as still in  
progress, then the input xid must have been a subtransaction.  
  
These assumptions hold true for the original uses of this code in  
locking related to on-disk tuples, but they break down in logical  
replication slot snapshot building -- in particular, when a standby  
snapshot logged contains an xid that's already in ProcArray but not yet  
in the lock table.  This leads to assertion failures that can be  
reproduced all the way back to 9.4, when logical decoding was  
introduced.  
  
To fix, change SubTransGetParent to SubTransGetTopmostTransaction which  
has a slightly different API: it returns the argument Xid if there is no  
parent, and it goes all the way to the top instead of moving up the  
levels one by one.  Also, to avoid busy-waiting, add a 1ms sleep to give  
the other process time to register itself in the lock table.  
  
For consistency, change ConditionalXactLockTableWait the same way.  
  
Author: Petr Jelínek  
Discussion: https://postgr.es/m/1B3E32D8-FCF4-40B4-AEF9-5C0E3AC57969@postgrespro.ru  
Reported-by: Konstantin Knizhnik  
Diagnosed-by: Stas Kelvich, Petr Jelínek  
Reviewed-by: Andres Freund, Robert Haas  

commit   : 87c44b1aa36e78e67f7529fe523e3aa0fb821730    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Jan 2018 11:16:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Jan 2018 11:16:38 -0300    

I did this by adding another locking process, which makes the other two  
wait.  This way the output should be stable enough.  
  
Per buildfarm and Andres Freund  
Discussion: https://postgr.es/m/20180103034445.t3utrtrnrevfsghm@alap3.anarazel.de  

commit   : 724bceae4fde75faacdb900d0f165eac3b6fce4f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Jan 2018 23:30:12 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Jan 2018 23:30:12 -0500    

Backpatch-through: certain files through 9.3  

commit   : 6d2a9ae0ed172341f78b6d2f4b30fb315d9ce528    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Jan 2018 19:16:16 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Jan 2018 19:16:16 -0300    

Multiple sessions doing CREATE INDEX CONCURRENTLY simultaneously are  
supposed to be able to work in parallel, as evidenced by fixes in commit  
c3d09b3bd23f specifically to support this case.  In reality, one of the  
sessions would be aborted by a misterious "deadlock detected" error.  
  
Jeff Janes diagnosed that this is because of leftover snapshots used for  
system catalog scans -- this was broken by 8aa3e47510b9 keeping track of  
(registering) the catalog snapshot.  To fix the deadlocks, it's enough  
to de-register that snapshot prior to waiting.  
  
Backpatch to 9.4, which introduced MVCC catalog scans.  
  
Include an isolationtester spec that 8 out of 10 times reproduces the  
deadlock with the unpatched code for me (Álvaro).  
  
Author: Jeff Janes  
Diagnosed-by: Jeff Janes  
Reported-by: Jeremy Finzel  
Discussion: https://postgr.es/m/CAMa1XUhHjCv8Qkx0WOr1Mpm_R4qxN26EibwCrj0Oor2YBUFUTg%40mail.gmail.com  

commit   : 5f5d73dd1a813fbd84b5dbeedb665403bc26d98a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 31 Dec 2017 21:58:29 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 31 Dec 2017 21:58:29 -0800    

Otherwise, the test fails with "Timed out while waiting for standby to  
catch up".  This happened rarely, perhaps only when autovacuum wrote WAL  
between our choosing the recovery target and choosing the LSN to await.  
Commit b26f7fa6ae2b4e5d64525b3d5bc66a0ddccd9e24 fixed one case of this.  
Fix two more.  Back-patch to 9.6, which introduced the affected test.  
  
Discussion: https://postgr.es/m/20180101055227.GA2952815@rfd.leadboat.com  

commit   : b38c3d58ed6f43c14e1e0f78f82db0e60cc2fedb    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 29 Dec 2017 16:19:51 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 29 Dec 2017 16:19:51 +0100    

When walsenders were included in pg_stat_activity, only the ones  
actually streaming WAL were listed as active when they were active. In  
particular, the connections sending base backups were listed as being  
idle. Which means that a regular pg_basebackup would show up with one  
active and one idle connection, when both were active.  
  
This patch updates to set all walsenders to active when they are  
(including those doing very fast things like IDENTIFY_SYSTEM), and then  
back to idle. Details about exactly what they are doing is available in  
pg_stat_replication.  
  
Patch by me, review by Michael Paquier and David Steele.  

commit   : bdbf29aaef7d1c698c1c5838a7b8cb027c406f9c    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 27 Dec 2017 18:26:58 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 27 Dec 2017 18:26:58 +0300    

Hash index depends on estimation of numbers of tuples and pages of relations,  
incorrect value could be a reason of significantly growing of index. Vacuum  
full recreates heap and reindex all indexes before renewal stats. The patch  
fixes that, so indexes will see correct values.  
  
Backpatch to v10 only because earlier versions haven't usable hash index and  
growing of hash index is a single user-visible symptom.  
  
Author: Amit Kapila  
Reviewed-by: Ashutosh Sharma, me  
Discussion: https://www.postgresql.org/message-id/flat/20171115232922.5tomkxnw3iq6jsg7@inml.weebeastie.net  

commit   : c252ccda74295ad292c407a361c9d55ca0554e00    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Dec 2017 12:08:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Dec 2017 12:08:18 -0500    

Since 9.4, we've allowed the syntax "select union select" and variants  
of that.  However, the planner wasn't expecting a no-column set operation  
and ended up treating the set operation as if it were UNION ALL.  
  
Turns out it's trivial to fix in v10 and later; we just need to be careful  
about not generating a Sort node with no sort keys.  However, since a weird  
corner case like this is never going to be exercised by developers, we'd  
better have thorough regression tests if we want to consider it supported.  
  
Per report from Victor Yegorov.  
  
Discussion: https://postgr.es/m/CAGnEbojGJrRSOgJwNGM7JSJZpVAf8xXcVPbVrGdhbVEHZ-BUMw@mail.gmail.com  

commit   : f3decdc94ea3dea05715325757db7b0295672bbe    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Dec 2017 09:09:04 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Dec 2017 09:09:04 -0500    

Generally, error recovery paths that need to do things like  
LWLockReleaseAll and pgstat_report_wait_end also need to call  
ConditionVariableCancelSleep, but AbortSubTransaction was missed.  
  
Since subtransaction abort might destroy up the DSM segment that  
contains the ConditionVariable stored in cv_sleep_target, this  
can result in a crash for anything using condition variables.  
  
Reported and diagnosed by Andres Freund.  
  
Discussion: http://postgr.es/m/20171221110048.rxk6464azzl5t2fi@alap3.anarazel.de  

commit   : 7be0d775a2e78d052c00f154741e9d8d76166fa3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Dec 2017 17:21:55 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Dec 2017 17:21:55 -0500    

Otherwise, when the query string is read, we might trailing garbage  
beyond the end, unless there happens to be a \0 there by good luck.  
  
Report and patch by Thomas Munro. Reviewed by Rafia Sabih.  
  
Discussion: http://postgr.es/m/CAEepm=2SJs7X+_vx8QoDu8d1SMEOxtLhxxLNzZun_BvNkuNhrw@mail.gmail.com  

commit   : 72567f6174605c36ba520c80e71697d2601cac0a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 19 Dec 2017 12:21:56 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 19 Dec 2017 12:21:56 -0500    

When a Gather or Gather Merge node is started and stopped multiple  
times, accumulate instrumentation data only once, at the end, instead  
of after each execution, to avoid recording inflated totals.  
  
Commit 778e78ae9fa51e58f41cbdc72b293291d02d8984, the previous attempt  
at a fix, instead reset the state after every execution, which worked  
for the general instrumentation data but had problems for the additional  
instrumentation specific to Sort and Hash nodes.  
  
Report by hubert depesz lubaczewski.  Analysis and fix by Amit Kapila,  
following a design proposal from Thomas Munro, with a comment tweak  
by me.  
  
Discussion: http://postgr.es/m/20171127175631.GA405@depesz.com  

commit   : db2ee079f54c66f57b5cbfa4c506f73dae9dab1b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Dec 2017 16:00:35 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Dec 2017 16:00:35 -0500    

oversight in 244c8b466a743d1ec18a7d841bf42669699b3b56  
  
Reported-by: Blaz Merela <blaz@merela.org>  

commit   : 133d2fab2f83242ec99b15807a5920b48cc3d26c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 19 Dec 2017 03:46:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 19 Dec 2017 03:46:14 +0900    

Previously an assertion failure occurred when pg_stop_backup() for  
non-exclusive backup was aborted while it's waiting for WAL files to  
be archived. This assertion failure happened in do_pg_abort_backup()  
which was called when a non-exclusive backup was canceled.  
do_pg_abort_backup() assumes that there is at least one non-exclusive  
backup running when it's called. But pg_stop_backup() can be canceled  
even after it marks the end of non-exclusive backup (e.g.,  
during waiting for WAL archiving). This broke the assumption that  
do_pg_abort_backup() relies on, and which caused an assertion failure.  
  
This commit changes do_pg_abort_backup() so that it does nothing  
when non-exclusive backup has been already marked as completed.  
That is, the asssumption is also changed, and do_pg_abort_backup()  
now can handle even the case where it's called when there is  
no running backup.  
  
Backpatch to 9.6 where SQL-callable non-exclusive backup was added.  
  
Author: Masahiko Sawada and Michael Paquier  
Reviewed-By: Robert Haas and Fujii Masao  
Discussion: https://www.postgresql.org/message-id/CAD21AoD2L1Fu2c==gnVASMyFAAaq3y-AQ2uEVj-zTCGFFjvmDg@mail.gmail.com  

commit   : b70ea4c75e5f94fd7757ea4a522aee6724885288    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 18 Dec 2017 12:17:37 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 18 Dec 2017 12:17:37 -0500    

es_query_dsa turns out to be broken by design, because it supposes  
that there is only one DSA for the whole query, whereas there is  
actually one per Gather (Merge) node.  For now, work around that  
problem by setting and clearing the pointer around the sections of  
code that might need it.  It's probably a better idea to get rid of  
es_query_dsa altogether in favor of having each node keep track  
individually of which DSA is relevant, but that seems like more than  
we would want to back-patch.  
  
Thomas Munro, reviewed and tested by Andreas Seltenreich, Amit  
Kapila, and by me.  
  
Discussion: http://postgr.es/m/CAEepm=1U6as=brnVvMNixEV2tpi8NuyQoTmO8Qef0-VV+=7MDA@mail.gmail.com  

commit   : ac93acbc05be2ef995208c1ca17f8083f60ccc53    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Dec 2017 10:03:35 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 16 Dec 2017 10:03:35 -0800    

Don't write to stdin of a psql process that could have already exited  
with an authentication failure.  Buildfarm members crake and mandrill  
have failed once by doing so.  Ignore SIGPIPE in all TAP tests.  
Back-patch to v10, where these tests were introduced.  
  
Reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/20171209210203.GC3362632@rfd.leadboat.com  

commit   : d3044f8b0732d369ad255c9268e2feb42acae2a0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Nov 2017 18:45:47 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 13 Nov 2017 18:45:47 -0800    

The previous commit has shown that the sanity checks around freezing  
aren't strong enough. Strengthening them seems especially important  
because the existance of the bug has caused corruption that we don't  
want to make even worse during future vacuum cycles.  
  
The errors are emitted with ereport rather than elog, despite being  
"should never happen" messages, so a proper error code is emitted. To  
avoid superflous translations, mark messages as internal.  
  
Author: Andres Freund and Alvaro Herrera  
Reviewed-By: Alvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/20171102112019.33wb7g5wp4zpjelu@alap3.anarazel.de  
Backpatch: 9.3-  

commit   : 1224383e85eee580a838ff1abf1fdb03ced973dc    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 3 Nov 2017 07:52:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 3 Nov 2017 07:52:29 -0700    

Previously it was possible that a tuple was not pruned during vacuum,  
even though its update xmax (i.e. the updating xid in a multixact with  
both key share lockers and an updater) was below the cutoff horizon.  
  
As the freezing code assumed, rightly so, that that's not supposed to  
happen, xmax would be preserved (as a member of a new multixact or  
xmax directly). That causes two problems: For one the tuple is below  
the xmin horizon, which can cause problems if the clog is truncated or  
once there's an xid wraparound. The bigger problem is that that will  
break HOT chains, which in turn can lead two to breakages: First,  
failing index lookups, which in turn can e.g lead to constraints being  
violated. Second, future hot prunes / vacuums can end up making  
invisible tuples visible again. There's other harmful scenarios.  
  
Fix the problem by recognizing that tuples can be DEAD instead of  
RECENTLY_DEAD, even if the multixactid has alive members, if the  
update_xid is below the xmin horizon. That's safe because newer  
versions of the tuple will contain the locking xids.  
  
A followup commit will harden the code somewhat against future similar  
bugs and already corrupted data.  
  
Author: Andres Freund, with changes by Alvaro Herrera  
Reported-By: Daniel Wood  
Analyzed-By: Andres Freund, Alvaro Herrera, Robert Haas, Peter  
   Geoghegan, Daniel Wood, Yi Wen Wong, Michael Paquier  
Reviewed-By: Alvaro Herrera, Robert Haas, Michael Paquier  
Discussion:  
    https://postgr.es/m/E5711E62-8FDF-4DCA-A888-C200BF6B5742@amazon.com  
    https://postgr.es/m/20171102112019.33wb7g5wp4zpjelu@alap3.anarazel.de  
Backpatch: 9.3-  

commit   : 14c15b1f45c8930fef2a3d69934d3aef69407361    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 14 Dec 2017 11:13:14 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 14 Dec 2017 11:13:14 -0500    

The logical slots have a fast code path for sending data so as not to  
impose too high a per message overhead. The fast path skips checks for  
interrupts and timeouts. However, the existing coding failed to consider  
the fact that a transaction with a large number of changes may take a  
very long time to be processed and sent to the client. This causes the  
walsender to ignore interrupts for potentially a long time and more  
importantly it will result in the walsender being killed due to  
timeout at the end of such a transaction.  
  
This commit changes the fast path to also check for interrupts and only  
allows calling the fast path when the last keepalive check happened less  
than half the walsender timeout ago. Otherwise the slower code path will  
be taken.  
  
Backpatched to 9.4  
  
Petr Jelinek, reviewed by  Kyotaro HORIGUCHI, Yura Sokolov,  Craig  
Ringer and Robert Haas.  
  
Discussion: https://postgr.es/m/e082a56a-fd95-a250-3bae-0fff93832510@2ndquadrant.com  

commit   : 192ffe1cbd4a2beaf6c6975267c97d5affa0f26b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 13 Dec 2017 16:09:00 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 13 Dec 2017 16:09:00 -0500    

The previous coding forgot to release the scan before seizing  
it again, leading to a lockup.  
  
Report by Patrick Hemmer.  Diagnosis by Thomas Munro.  Patch by  
Amit Kapila.  
  
Discussion: http://postgr.es/m/CAEepm=2xZUcOGP9V0O_G0=2P2wwXwPrkF=upWTCJSisUxMnuSg@mail.gmail.com  

commit   : 7b3f85073c8dd470e01583b20269e7c87898b6f7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 13 Dec 2017 15:57:21 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 13 Dec 2017 15:57:21 -0500    

This reverts commit 778e78ae9fa51e58f41cbdc72b293291d02d8984.  Per  
further discussion, that doesn't seem to be the best possible fix.  
  
Discussion: http://postgr.es/m/CAA4eK1LW2aFKzY3=vwvc=t-juzPPVWP2uT1bpx_MeyEqnM+p8g@mail.gmail.com  

commit   : c55253b7d1c3ab1cf1d05e6633779ab9a9cb5284    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Dec 2017 16:37:39 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Dec 2017 16:37:39 -0500    

Reported-by: Noah Misch <noah@leadboat.com>  

commit   : e3d194f74a15417cc6a30b021b87ee836c8544f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Dec 2017 16:33:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Dec 2017 16:33:20 -0500    

I noticed that _SPI_execute_plan initially sets spierrcontext.arg = NULL,  
and only fills it in some time later.  If an error were to happen in  
between, _SPI_error_callback would try to dereference the null pointer.  
This is unlikely --- there's not much between those points except  
push-snapshot calls --- but it's clearly not impossible.  Tweak the  
callback to do nothing if the pointer isn't set yet.  
  
It's been like this for awhile, so back-patch to all supported branches.  

commit   : 22e71b3afb1c3bc994ba71a8c41784ddec53ceda    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 9 Dec 2017 13:45:06 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 9 Dec 2017 13:45:06 +0100    

Reported by Robins Tharakan  

commit   : e2cc65050b0bad0b6b0e291f1d0bf1b44b2b1369    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 9 Dec 2017 00:58:55 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 9 Dec 2017 00:58:55 -0800    

Notably, this permits linking to the 32-bit Perl binaries advertised on  
perl.org, namely Strawberry Perl and ActivePerl.  This has a side effect  
of permitting linking to binaries built with obsolete MSVC versions.  
  
By default, MSVC 2012 and later require a "safe exception handler table"  
in each binary.  MinGW-built, 32-bit DLLs lack the relevant exception  
handler metadata, so linking to them failed with error LNK2026.  Restore  
the semantics of MSVC 2010, which omits the table from a given binary if  
some linker input lacks metadata.  This has no effect on 64-bit builds  
or on MSVC 2010 and earlier.  Back-patch to 9.3 (all supported  
versions).  
  
Reported by Victor Wagner.  
  
Discussion: https://postgr.es/m/20160326154321.7754ab8f@wagner.wagner.home  

commit   : 9b5c99790e83ca539932426f41ae6e14b1748e8d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 8 Dec 2017 18:06:05 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 8 Dec 2017 18:06:05 -0800    

Commits 5a5c2feca3fd858e70ea348822595547e6fa6c15 and  
b5178c5d08ca59e30f9d9428fa6fdb2741794e65 introduced support for modern  
MSVC-built, 32-bit Perl, but they broke use of MinGW-built, 32-bit Perl  
distributions like Strawberry Perl and modern ActivePerl.  Perl has no  
robust means to report whether it expects a -D_USE_32BIT_TIME_T ABI, so  
test this.  Back-patch to 9.3 (all supported versions).  
  
The chief alternative was a heuristic of adding -D_USE_32BIT_TIME_T when  
$Config{gccversion} is nonempty.  That banks on every gcc-built Perl  
using the same ABI.  gcc could change its default ABI the way MSVC once  
did, and one could build Perl with gcc and the non-default ABI.  
  
The GNU make build system could benefit from a similar test, without  
which it does not support MSVC-built Perl.  For now, just add a comment.  
Most users taking the special step of building Perl with MSVC probably  
build PostgreSQL with MSVC.  
  
Discussion: https://postgr.es/m/20171130041441.GA3161526@rfd.leadboat.com  

commit   : a2c6cf36608e10aa223fef49323b5feba344bfcf    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 12:13:04 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 12:13:04 -0500    

Those cases currently crash and supporting them is more work then  
originally thought, so we'll just prohibit these scenarios for now.  
  
Author: Michael Paquier <michael.paquier@gmail.com>  
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Reported-by: Мансур Галиев <gomer94@yandex.ru>  
Bug: #14866  

commit   : 7abb9dd6722876ccf495619711fa6052e2882a73    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 11:16:23 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 11:16:23 -0500    

Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>  

commit   : 218b024a7ec866ec62abb5c2fb4eb9108bb5fc0f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 10:17:46 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 10:17:46 -0500    

Add support to the SCRAM exchange for clients that support channel  
binding, such as PostgreSQL version 11 and beyond.  If such a client  
encounters a PostgreSQL 10 server that does not support channel binding,  
it will send a channel binding flag 'y', meaning the client supports  
channel binding but thinks the server does not.  But PostgreSQL 10  
erroneously did not accept that flag.  This would cause connections to  
fail if a version 11 client connects to a version 10 server with SCRAM  
authentication over SSL.  
  
Author: Michael Paquier <michael.paquier@gmail.com>  

commit   : ee5b595493e1609903d55709853f5276ba85c81d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 09:18:18 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Dec 2017 09:18:18 -0500    

A COPY into a table should apply identity sequence values just like it  
does for ordinary defaults.  This was previously forgotten, leading to  
null values being inserted, which in turn would fail because identity  
columns have not-null constraints.  
  
Author: Michael Paquier <michael.paquier@gmail.com>  
Reported-by: Steven Winfield <steven.winfield@cantabcapital.com>  
Bug: #14952  

commit   : a8ef4e81e6f2b7ab77aa57b986742feba57d9d86    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 6 Dec 2017 08:49:30 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 6 Dec 2017 08:49:30 -0500    

When a worker is flagged as BGW_NEVER_RESTART and we fail to start it,  
or if it is not marked BGW_NEVER_RESTART but is terminated before  
startup succeeds, what BgwHandleStatus should be reported?  The  
previous code really hadn't considered this possibility (as indicated  
by the comments which ignore it completely) and would typically return  
BGWH_NOT_YET_STARTED, but that's not a good answer, because then  
there's no way for code using GetBackgroundWorkerPid() to tell the  
difference between a worker that has not started but will start  
later and a worker that has not started and will never be started.  
So, when this case happens, return BGWH_STOPPED instead.  Update the  
comments to reflect this.  
  
The preceding fix by itself is insufficient to fix the problem,  
because the old code also didn't send a notification to the process  
identified in bgw_notify_pid when startup failed.  That might've  
been technically correct under the theory that the status of the  
worker was BGWH_NOT_YET_STARTED, because the status would indeed not  
change when the worker failed to start, but now that we're more  
usefully reporting BGWH_STOPPED, a notification is needed.  
  
Without these fixes, code which starts background workers and then  
uses the recommended APIs to wait for those background workers to  
start would hang indefinitely if the postmaster failed to fork a  
worker.  
  
Amit Kapila and Robert Haas  
  
Discussion: http://postgr.es/m/CAA4eK1KDfKkvrjxsKJi3WPyceVi3dH1VCkbTJji2fuwKuB=3uw@mail.gmail.com  

commit   : 54b5c8c2f1168108305f1ba3f036af679bbda252    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Dec 2017 15:29:24 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Dec 2017 15:29:24 -0500    

Reported-by: Dave Page <dpage@pgadmin.org>  

commit   : 778e78ae9fa51e58f41cbdc72b293291d02d8984    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 Dec 2017 14:35:42 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 Dec 2017 14:35:42 -0500    

When a Gather or Gather Merge node is started and stopped multiple  
times, the old code wouldn't reset the shared state between executions,  
potentially resulting in dramatically inflated instrumentation data  
for nodes beneath it.  (The per-worker instrumentation ended up OK,  
I think, but the overall totals were inflated.)  
  
Report by hubert depesz lubaczewski.  Analysis and fix by Amit Kapila,  
reviewed and tweaked a bit by me.  
  
Discussion: http://postgr.es/m/20171127175631.GA405@depesz.com  

commit   : ff1473078d2523fa5af7d678dcb4002d9e7f32bd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 Dec 2017 09:24:05 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 Dec 2017 09:24:05 -0500    

This makes life easier for extension authors who wish to support  
Windows.  
  
Brian Cloutier, slightly amended by me.  
  
Discussion: http://postgr.es/m/CAJCy68fscdNhmzFPS4kyO00CADkvXvEa-28H-OtENk-pa2OTWw@mail.gmail.com  

commit   : 9101688502cc25ed8f521e33de5f1d793aeec9e0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 1 Dec 2017 13:30:21 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 1 Dec 2017 13:30:21 -0500    

This ensures that automatically generated HTML anchors don't change in  
every build.  

commit   : 2a11b188e8abc74cb28a9433862daf17c2a92917    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Dec 2017 17:02:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Dec 2017 17:02:52 -0500    

This patch fixes a couple of low-probability bugs that could lead to  
reporting an irrelevant errno value (and hence possibly a wrong SQLSTATE)  
concerning directory-open or file-open failures.  It also fixes places  
where we took shortcuts in reporting such errors, either by using elog  
instead of ereport or by using ereport but forgetting to specify an  
errcode.  And it eliminates a lot of just plain redundant error-handling  
code.  
  
In service of all this, export fd.c's formerly-static function  
ReadDirExtended, so that external callers can make use of the coding  
pattern  
  
	dir = AllocateDir(path);  
	while ((de = ReadDirExtended(dir, path, LOG)) != NULL)  
  
if they'd like to treat directory-open failures as mere LOG conditions  
rather than errors.  Also fix FreeDir to be a no-op if we reach it  
with dir == NULL, as such a coding pattern would cause.  
  
Then, remove code at many call sites that was throwing an error or log  
message for AllocateDir failure, as ReadDir or ReadDirExtended can handle  
that job just fine.  Aside from being a net code savings, this gets rid of  
a lot of not-quite-up-to-snuff reports, as mentioned above.  (In some  
places these changes result in replacing a custom error message such as  
"could not open tablespace directory" with more generic wording "could not  
open directory", but it was agreed that the custom wording buys little as  
long as we report the directory name.)  In some other call sites where we  
can't just remove code, change the error reports to be fully  
project-style-compliant.  
  
Also reorder code in restoreTwoPhaseData that was acquiring a lock  
between AllocateDir and ReadDir; in the unlikely but surely not  
impossible case that LWLockAcquire changes errno, AllocateDir failures  
would be misreported.  There is no great value in opening the directory  
before acquiring TwoPhaseStateLock, so just do it in the other order.  
  
Also fix CheckXLogRemoved to guarantee that it preserves errno,  
as quite a number of call sites are implicitly assuming.  (Again,  
it's unlikely but I think not impossible that errno could change  
during a SpinLockAcquire.  If so, this function was broken for its  
own purposes as well as breaking callers.)  
  
And change a few places that were using not-per-project-style messages,  
such as "could not read directory" when "could not open directory" is  
more correct.  
  
Back-patch the exporting of ReadDirExtended, in case we have occasion  
to back-patch some fix that makes use of it; it's not needed right now  
but surely making it global is pretty harmless.  Also back-patch the  
restoreTwoPhaseData and CheckXLogRemoved fixes.  The rest of this is  
essentially cosmetic and need not get back-patched.  
  
Michael Paquier, with a bit of additional work by me  
  
Discussion: https://postgr.es/m/CAB7nPqRpOCxjiirHmebEFhXVTK7V5Jvw4bz82p7Oimtsm3TyZA@mail.gmail.com  

commit   : bf2b317f14bce456d07363e2050878dcb1078062    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Dec 2017 11:51:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Dec 2017 11:51:43 -0500    

There's no good reason that the multicolumn stats stuff shouldn't work on  
booleans.  But it looked only for "Var = pseudoconstant" clauses, and it  
will seldom find those for boolean Vars, since earlier phases of planning  
will fold "boolvar = true" or "boolvar = false" to just "boolvar" or  
"NOT boolvar" respectively.  Improve dependencies_clauselist_selectivity()  
to recognize such clauses as equivalent to equality restrictions.  
  
This fixes a failure of the extended stats mechanism to apply in a case  
reported by Vitaliy Garnashevich.  It's not a complete solution to his  
problem because the bitmap-scan costing code isn't consulting extended  
stats where it should, but that's surely an independent issue.  
  
In passing, improve some comments, get rid of a NumRelids() test that's  
redundant with the preceding bms_membership() test, and fix  
dependencies_clauselist_selectivity() so that estimatedclauses actually  
is a pure output argument as stated by its API contract.  
  
Back-patch to v10 where this code was introduced.  
  
Discussion: https://postgr.es/m/73a4936d-2814-dc08-ed0c-978f76f435b0@gmail.com  

commit   : f8252b6418262884dc504c93597a54cf2c334802    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 30 Nov 2017 00:57:22 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 30 Nov 2017 00:57:22 -0800    

Invoking the Makefile without an explicit target was building every  
possible target instead of just the "all" target.  Back-patch to 9.3  
(all supported versions).  

commit   : cce3d72a8a42be2db18aaabbf100f8e0f540206c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Nov 2017 00:09:17 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Nov 2017 00:09:17 -0300    

This is simpler and more closely follows overwhelming precedent.  
  
Report and patch by Mark Dilger.  
Discussion: https://postgr.es/m/9A68FB88-5F45-4848-9926-8586E2D777D1@gmail.com  

commit   : d4607590b6d8431906163280704e4023c625670c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Nov 2017 23:25:47 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Nov 2017 23:25:47 -0300    

This is a mistakenly placed conditional in bf2a691e02d7.  
  
Reported by Justin Pryzby  
Discussion: https://postgr.es/m/20171117214352.GE25796@telsasoft.com  

commit   : dba6e75c1113dbfc7b10d93cc6c0babd8b7d852b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Nov 2017 12:05:52 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Nov 2017 12:05:52 -0500    

Commit d4663350646ca0c069a36d906155a0f7e3372eb7 changed things so  
that shm_toc_lookup would fail with an error rather than silently  
returning NULL in the hope that such failures would be reported  
in a useful way rather than via a system crash.  However, it  
overlooked the fact that the lookup of PARALLEL_KEY_ERROR_QUEUE  
in ReinitializeParallelDSM is expected to fail when no DSM segment  
was created in the first place; in that case, we end up with a  
backend-private memory segment that still contains an entry for  
PARALLEL_KEY_FIXED but no others.  Consequently a benign failure  
to initialize parallelism can escalate into an elog(ERROR);  
repair.  
  
Discussion: http://postgr.es/m/CA+Tgmob8LFw55DzH1QEREpBEA9RJ_W_amhBFCVZ6WMwUhVpOqg@mail.gmail.com  

commit   : ec7629dfb98a34cf4e459cf6b27febfd33ae9ad5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Nov 2017 11:39:16 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 28 Nov 2017 11:39:16 -0500    

If we have a plan that uses parallelism but are unable to execute it  
using parallelism, for example due to a lack of available DSM  
segments, then the EState's es_query_dsa will be NULL.  Parallel  
bitmap heap scan needs to fall back to a non-parallel scan in such  
cases.  
  
Patch by me, reviewed by Dilip Kumar  
  
Discussion: http://postgr.es/m/CAEepm=0kADK5inNf_KuemjX=HQ=PuTP0DykM--fO5jS5ePVFEA@mail.gmail.com  

commit   : 7015bb38949a44849b7a2e6c139700d20d82858b    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 28 Nov 2017 09:37:22 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 28 Nov 2017 09:37:22 +0000    

Allows triggers to operate correctly  
  
Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>  
Reported-by: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>  

commit   : 64487044966d6246052ff974f0ce98cac5a0c79b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Nov 2017 19:22:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Nov 2017 19:22:08 -0500    

heap_drop_with_catalog and ATExecDetachPartition neglected to check for  
SearchSysCache failures, as noted in bugs #14927 and #14928 from Pan Bian.  
Such failures are pretty unlikely, since we should already have some sort  
of lock on the rel at these points, but it's neither a good idea nor  
per project style to omit a check for failure.  
  
Also, StorePartitionKey contained a syscache lookup that it never did  
anything with, including never releasing the result.  Presumably the  
reason why we don't see refcount-leak complaints is that the lookup  
always fails; but in any case it's pretty useless, so remove it.  
  
All of these errors were evidently introduced by the relation  
partitioning feature.  Back-patch to v10 where that came in.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/20171127090105.1463.3962@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/20171127091341.1468.72696@wrigleys.postgresql.org  

commit   : a57aa430b613250270cf5cc78a34a3454e61acda    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Nov 2017 17:53:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Nov 2017 17:53:56 -0500    

rewriteTargetListUD's processing is dependent on the relkind of the query's  
target table.  That was fine at the time it was made to act that way, even  
for queries on inheritance trees, because all tables in an inheritance tree  
would necessarily be plain tables.  However, the 9.5 feature addition  
allowing some members of an inheritance tree to be foreign tables broke the  
assumption that rewriteTargetListUD's output tlist could be applied to all  
child tables with nothing more than column-number mapping.  This led to  
visible failures if foreign child tables had row-level triggers, and would  
also break in cases where child tables belonged to FDWs that used methods  
other than CTID for row identification.  
  
To fix, delay running rewriteTargetListUD until after the planner has  
expanded inheritance, so that it is applied separately to the (already  
mapped) tlist for each child table.  We can conveniently call it from  
preprocess_targetlist.  Refactor associated code slightly to avoid the  
need to heap_open the target relation multiple times during  
preprocess_targetlist.  (The APIs remain a bit ugly, particularly around  
the point of which steps scribble on parse->targetList and which don't.  
But avoiding such scribbling would require a change in FDW callback APIs,  
which is more pain than it's worth.)  
  
Also fix ExecModifyTable to ensure that "tupleid" is reset to NULL when  
we transition from rows providing a CTID to rows that don't.  (That's  
really an independent bug, but it manifests in much the same cases.)  
  
Add a regression test checking one manifestation of this problem, which  
was that row-level triggers on a foreign child table did not work right.  
  
Back-patch to 9.5 where the problem was introduced.  
  
Etsuro Fujita, reviewed by Ildus Kurbangaliev and Ashutosh Bapat  
  
Discussion: https://postgr.es/m/20170514150525.0346ba72@postgrespro.ru  

commit   : 4f2d0af1719e608a7d5d1e51620c4b914b3137fa    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 27 Nov 2017 09:24:14 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 27 Nov 2017 09:24:14 +0100    

Andreas Karlsson  

commit   : 94fd57df30b802b6087a92ba1fa88fdfe5618390    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Nov 2017 15:17:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Nov 2017 15:17:25 -0500    

Originally, we palloc'd this buffer just barely big enough to hold the  
largest xlog record seen so far.  It turns out that that can result in  
valgrind complaints, because some compilers will emit code that assumes  
it can safely fetch padding bytes at the end of a struct, and those  
padding bytes were unallocated so far as aset.c was concerned.  We can  
fix that by MAXALIGN'ing the palloc request size, ensuring that it is big  
enough to include any possible padding that might've been omitted from  
the on-disk record.  
  
An additional objection to the original coding is that it could result in  
many repeated palloc cycles, in the worst case where we see a series of  
gradually larger xlog records.  We can ameliorate that cheaply by  
imposing a minimum buffer size that's large enough for most xlog records.  
BLCKSZ/2 was chosen after a bit of discussion.  
  
In passing, remove an obsolete comment in struct xl_heap_new_cid that the  
combocid field is free due to alignment considerations.  Perhaps that was  
true at some point, but it's not now.  
  
Back-patch to 9.5 where this code came in.  
  
Discussion: https://postgr.es/m/E1eHa4J-0006hI-Q8@gemulon.postgresql.org  

commit   : 9e051b6746c248958d4497be43db7cb9023388f7    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 26 Nov 2017 09:50:00 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 26 Nov 2017 09:50:00 -0800    

The various has_*_privilege() functions all support an optional  
WITH GRANT OPTION added to the supported privilege types to test  
whether the privilege is held with grant option. That is, all except  
has_sequence_privilege() variations. Fix that.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/005147f6-8280-42e9-5a03-dd2c1e4397ef@joeconway.com  

commit   : 7b0cb5eccdc9f4eb9a52b1d5c9815a7a5161a9fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 18:15:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 18:15:22 -0500    

Missed this dependency in commits 7cce222c9 et al.  

commit   : 097b24cea68ac167a82bb617eb1844c8be4eaf24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 15:30:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 15:30:11 -0500    

Traditionally IANA has distributed their timezone data in pure source  
form, replete with extensive historical comments.  As of release 2017c,  
they've added a compact single-file format that omits comments and  
abbreviates command keywords.  This form is way shorter than the pure  
source, even before considering its allegedly better compressibility.  
Hence, let's distribute the data in that form rather than pure source.  
  
I'm pushing this now, rather than at the next timezone database update,  
so that it's easy to confirm that this data file produces compiled zic  
output that's identical to what we were getting before.  
  
Discussion: https://postgr.es/m/1915.1511210334@sss.pgh.pa.us  

commit   : ddba320059fcce0126ea43f0c0404d3ed1ce47aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 14:42:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 14:42:10 -0500    

hstoreUniquePairs() often called memcpy with equal source and destination  
pointers.  Although this is almost surely harmless in practice, it's  
undefined according to the letter of the C standard.  Some versions of  
valgrind will complain about it, and some versions of libc as well  
(cf. commit ad520ec4a).  Tweak the code to avoid doing that.  
  
Noted by Tomas Vondra.  Back-patch to all supported versions because  
of the hazard of libc assertions.  
  
Discussion: https://postgr.es/m/bf84d940-90d4-de91-19dd-612e011007f4@fuzzy.cz  

commit   : 5dc7faa91e195a64f58057b7fb90778abfec065c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 14:15:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 14:15:48 -0500    

When nodeValuesscan.c was written, it was impossible to have a SubPlan in  
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby  
would produce an InitPlan instead.  We therefore took a shortcut in the  
logic that throws away a ValuesScan's per-row expression evaluation data  
structures.  This was broken by the introduction of LATERAL however; a  
sub-SELECT containing a lateral reference produces a correlated SubPlan.  
  
The cleanest fix for this would be to give up the optimization of  
discarding the expression eval state.  But that still seems pretty  
unappetizing for long VALUES lists.  It seems to work to just prevent  
the subexpressions from hooking into the ValuesScan node's subPlan  
list, so let's do that and see how well it works.  (If this breaks,  
due to additional connections between the subexpressions and the outer  
query structures, we might consider compromises like throwing away data  
only for VALUES rows not containing SubPlans.)  
  
Per bug #14924 from Christian Duta.  Back-patch to 9.3 where LATERAL  
was introduced.  
  
Discussion: https://postgr.es/m/20171124120836.1463.5310@wrigleys.postgresql.org  

commit   : b9fc2d0b97c122b071e4ce99ba4e274538d81a5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 11:48:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Nov 2017 11:48:09 -0500    

Improve query_is_distinct_for() to accept SRFs in the targetlist when  
we can prove distinctness from a DISTINCT clause.  In that case the  
de-duplication will surely happen after SRF expansion, so the proof  
still works.  Continue to punt in the case where we'd try to prove  
distinctness from GROUP BY (or, in the future, source relations).  
To do that, we'd have to determine whether the SRFs were in the  
grouping columns or elsewhere in the tlist, and it still doesn't  
seem worth the trouble.  But this trivial change allows us to  
recognize that "SELECT DISTINCT unnest(foo) FROM ..." produces  
unique-ified output, which seems worth having.  
  
Also, fix estimate_num_groups() to consider the possibility of SRFs in  
the grouping columns.  Its failure to do so was masked before v10 because  
grouping_planner() scaled up plan rowcount estimates by the estimated SRF  
multiplier after performing grouping.  That doesn't happen anymore, which  
is more correct, but it means we need an adjustment in the estimate for  
the number of groups.  Failure to do this leads to an underestimate for  
the number of output rows of subqueries like "SELECT DISTINCT unnest(foo)"  
compared to what 9.6 and earlier estimated, thus breaking plan choices  
in some cases.  
  
Per report from Dmitry Shalashov.  Back-patch to v10 to avoid degraded  
plan choices compared to previous releases.  
  
Discussion: https://postgr.es/m/CAKPeCUGAeHgoh5O=SvcQxREVkoX7UdeJUMj1F5=aBNvoTa+O8w@mail.gmail.com  

commit   : a1187c4efe024e5a1f5cf9221b13a3f3226d92c5    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 24 Nov 2017 14:12:50 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 24 Nov 2017 14:12:50 +0000    

The comments in get_policies_for_relation() say that CREATE POLICY  
does not support defining restrictive policies. This is no longer  
true, starting from PG10.  

commit   : a5339ac09502158d1c2b9503d077ad9a7114d620    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 24 Nov 2017 12:00:37 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 24 Nov 2017 12:00:37 +0000    

This table summarizes which RLS policy expressions apply to each  
command type, and whether they apply to the old or new tuples (or  
both), which saves reading through a lot of text.  
  
Rod Taylor, hacked on by me. Reviewed by Fabien Coelho.  
  
Discussion: https://postgr.es/m/CAHz80e4HxJShm6m9ZWFrHW=pgd2KP=RZmfFnEccujtPMiAOW5Q@mail.gmail.com  

commit   : 292661e15248ed4df8b27d5a7e92ddb69dd52c1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Nov 2017 00:29:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Nov 2017 00:29:20 -0500    

The query didn't really have a preferred index, leading to platform-  
specific choices of which one to use.  Adjust it to make sure tenk1_hundred  
is always chosen.  
  
Per buildfarm.  

commit   : f16a0958d0ebebf9b4c3fc2272c3e1aa4ae3a1d2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 23 Nov 2017 20:22:04 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 23 Nov 2017 20:22:04 -0800    

This is necessary for ActivePerl 5.18 onwards and for Strawberry Perl.  
It is not sufficient for 32-bit builds with newer Visual Studio; these  
fail with error LINK2026.  Back-patch to 9.3 (all supported versions).  
  
Reported by Victor Wagner.  
  
Discussion: https://postgr.es/m/20160326154321.7754ab8f@wagner.wagner.home  

commit   : c60b898453f9b4d7de94c8e88bf08e930d117958    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 23 Nov 2017 17:13:09 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 23 Nov 2017 17:13:09 -0800    

When strict aggregate combine functions, used in multi-stage/parallel  
aggregation, returned NULL, we didn't check for that, invoking the  
combine function with NULL the next round, despite it being strict.  
  
The equivalent code invoking normal transition functions has a check  
for that situation, which did not get copied in a7de3dc5c346. Fix the  
bug by adding the equivalent check.  
  
Based on a quick look I could not find any strict combine functions in  
core actually returning NULL, and it doesn't seem very likely external  
users have done so. So this isn't likely to have caused issues in  
practice.  
  
Add tests verifying transition / combine functions returning NULL is  
tested.  
  
Reported-By: Andres Freund  
Author: Andres Freund  
Discussion: https://postgr.es/m/20171121033642.7xvmjqrl4jdaaat3@alap3.anarazel.de  
Backpatch: 9.6, where parallel aggregation was introduced  

commit   : 188140500e42a4266f01b683697ac4f787052f3e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Nov 2017 16:46:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Nov 2017 16:46:42 +0900    

wal_receiver_timeout, wal_receiver_status_interval and  
wal_retrieve_retry_interval configuration parameters affect the logical rep  
worker, but previously only wal_receiver_status_interval was not mentioned  
as such parameter in the doc.  
  
Back-patch to v10 where logical rep was added.  
  
Author: Masahiko Sawada  
Discussion: https://www.postgresql.org/message-id/CAD21AoBUnuH_UsnKXyPCsCR7EAMamW0sSb6a7=WgiQRpnMAp5w@mail.gmail.com  

commit   : 5c48d68de575645a668f76f9ec4afc082fd3d73b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 22 Nov 2017 20:18:15 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 22 Nov 2017 20:18:15 -0800    

This hack closes a race condition in "make -j check-world" and "make -j  
installcheck-world".  Back-patch to v10, before which these parallel  
invocations had worse problems.  
  
Discussion: https://postgr.es/m/20171106080752.GA1298146@rfd.leadboat.com  

commit   : 5b2a877070913ee4e7088f3593804595309b3938    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Nov 2017 13:56:24 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Nov 2017 13:56:24 -0500    

Previously, any attempt to request a 3.x protocol version other than  
3.0 would lead to a hard connection failure, which made the minor  
protocol version really no different from the major protocol version  
and precluded gentle protocol version breaks.  Instead, when the  
client requests a 3.x protocol version where x is greater than 0, send  
the new NegotiateProtocolVersion message to convey that we support  
only 3.0.  This makes it possible to introduce new minor protocol  
versions without requiring a connection retry when the server is  
older.  
  
In addition, if the startup packet includes name/value pairs where  
the name starts with "_pq_.", assume that those are protocol options,  
not GUCs.  Include those we don't support (i.e. all of them, at  
present) in the NegotiateProtocolVersion message so that the client  
knows they were not understood.  This makes it possible for the  
client to request previously-unsupported features without bumping  
the protocol version at all; the client can tell from the server's  
response whether the option was understood.  
  
It will take some time before servers that support these new  
facilities become common in the wild; to speed things up and make  
things easier for a future 3.1 protocol version, back-patch to all  
supported releases.  
  
Robert Haas and Badrul Chowdhury  
  
Discussion: http://postgr.es/m/BN6PR21MB0772FFA0CBD298B76017744CD1730@BN6PR21MB0772.namprd21.prod.outlook.com  
Discussion: http://postgr.es/m/30788.1498672033@sss.pgh.pa.us  

commit   : ae772bbf92742b7ca57f7a8872fedcbbc077f526    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Nov 2017 18:05:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Nov 2017 18:05:02 -0500    

David Carlier (from a patch being carried by OpenBSD packagers)  
  
Discussion: https://postgr.es/m/CA+XhMqzwFSGVU7MEnfhCecc8YdP98tigXzzpd0AAdwaGwaVXEA@mail.gmail.com  

commit   : 1ecf7eeb8719e2fab008c37c17590cf3840cfc5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Nov 2017 17:57:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Nov 2017 17:57:46 -0500    

Apparently there are still people out there who care about this old  
architecture.  They probably care about dusty versions of Postgres  
too, so back-patch to all supported branches.  
  
David Carlier (from a patch being carried by OpenBSD packagers)  
  
Discussion: https://postgr.es/m/CA+XhMqzwFSGVU7MEnfhCecc8YdP98tigXzzpd0AAdwaGwaVXEA@mail.gmail.com  

commit   : c4adfc21cbae47f71624a87008073503308c2393    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Nov 2017 16:46:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Nov 2017 16:46:29 -0500    

On gcc 7.2.0, comparing pointer to (Datum) 0 produces a warning.  
Treat it as a simple pointer to avoid that; this is more consistent  
with comparable code elsewhere, anyway.  
  
Tomas Vondra  
  
Discussion: https://postgr.es/m/99410021-61ef-9a9a-9bc8-f733ece637ee@2ndquadrant.com  

commit   : 6313995c27f915333cc3c7aad521afda22a7ce48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Nov 2017 12:46:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Nov 2017 12:46:52 -0500    

The scripts in contrib/start-scripts/osx don't work at all on macOS  
10.10 (Yosemite) or later, because they depend on SystemStarter which  
Apple deprecated long ago and removed in 10.10.  Add a new subdirectory  
contrib/start-scripts/macos with scripts that use the newer launchd  
infrastructure.  
  
Since this problem is independent of which Postgres version you're using,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/31338.1510763554@sss.pgh.pa.us  

commit   : c8df4831ef212b9028824d1b5de558973c110c77    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Nov 2017 14:19:27 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Nov 2017 14:19:27 -0500    

The pending list must (for correctness) always be cleaned up by vacuum, and  
should (for the avoidance of surprising behavior) always be cleaned up  
by an explicit call to gin_clean_pending_list, but cleanup is optional  
when inserting.  The old logic got this backward: cleanup was forced  
if (stats == NULL), but that's going to be *false* when vacuuming and  
*true* for inserts.  
  
Masahiko Sawada, reviewed by me.  
  
Discussion: http://postgr.es/m/CAD21AoBLUSyiYKnTYtSAbC+F=XDjiaBrOUEGK+zUXdQ8owfPKw@mail.gmail.com  

commit   : 4b02e935fee881eab1f4fabdbebccedfa57b4ddd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Nov 2017 11:16:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Nov 2017 11:16:53 -0500    

Commit 9be95ef15 failed to cure all of the redundancy here: we were  
actually calling get_major_server_version() three times for each  
of the old and new data directories.  While that's not enormously  
expensive, it's still sloppy.  
  
A. Akenteva  
  
Discussion: https://postgr.es/m/f9266a85d918a3cf3a386b5148aee666@postgrespro.ru  

commit   : 619a8c47da7279c186bb57cc16b26ad011366b73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Nov 2017 17:49:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Nov 2017 17:49:49 -0500    

Our initial work with int128 neglected alignment considerations, an  
oversight that came back to bite us in bug #14897 from Vincent Lachenal.  
It is unsurprising that int128 might have a 16-byte alignment requirement;  
what's slightly more surprising is that even notoriously lax Intel chips  
sometimes enforce that.  
  
Raising MAXALIGN seems out of the question: the costs in wasted disk and  
memory space would be significant, and there would also be an on-disk  
compatibility break.  Nor does it seem very practical to try to allow some  
data structures to have more-than-MAXALIGN alignment requirement, as we'd  
have to push knowledge of that throughout various code that copies data  
structures around.  
  
The only way out of the box is to make type int128 conform to the system's  
alignment assumptions.  Fortunately, gcc supports that via its  
__attribute__(aligned()) pragma; and since we don't currently support  
int128 on non-gcc-workalike compilers, we shouldn't be losing any platform  
support this way.  
  
Although we could have just done pg_attribute_aligned(MAXIMUM_ALIGNOF) and  
called it a day, I did a little bit of extra work to make the code more  
portable than that: it will also support int128 on compilers without  
__attribute__(aligned()), if the native alignment of their 128-bit-int  
type is no more than that of int64.  
  
Add a regression test case that exercises the one known instance of the  
problem, in parallel aggregation over a bigint column.  
  
Back-patch of commit 751804998.  The code known to be affected only exists  
in 9.6 and later, but we do have some stuff using int128 in 9.5, so patch  
back to 9.5.  
  
Discussion: https://postgr.es/m/20171110185747.31519.28038@wrigleys.postgresql.org  

commit   : a8910506757c58016616b9b0c4c6c78dcb835e3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Nov 2017 17:22:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Nov 2017 17:22:42 -0500    

Generalize section 1 to handle stuff that is principally about the  
compiler (not libraries), such as attributes, and collect stuff there  
that had been dropped into various other parts of c.h.  Also, push  
all the gettext macros into section 8, so that section 0 is really  
just inclusions rather than inclusions and random other stuff.  
  
The primary goal here is to get pg_attribute_aligned() defined before  
section 3, so that we can use it with int128.  But this seems like good  
cleanup anyway.  
  
This patch just moves macro definitions around, and shouldn't result  
in any changes in generated code.  
  
Back-patch of commit 91aec93e6.  
  
Discussion: https://postgr.es/m/20171110185747.31519.28038@wrigleys.postgresql.org  

commit   : 8d8f85d4761a237980657d88394969151c438e52    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Nov 2017 19:26:35 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Nov 2017 19:26:35 +0100    

The new commands are reported by event triggers, but they weren't  
documented as such.  Repair.  
  
Author: David Rowley  
Discussion: https://postgr.es/m/CAKJS1f-t-NE=AThB3zu1mKhdrm8PCb=++3e7x=Lf343xcrFHxQ@mail.gmail.com  

commit   : 64725d7f98a00a292fd2ed9fffb6ae254a5f095d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Nov 2017 18:43:32 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Nov 2017 18:43:32 -0800    

Also, add a warning to catch future instances of naming a nonexistent  
file as a prerequisite.  Back-patch to 9.3 (all supported versions).  

commit   : d6387e27e952a687fd2d89874d928a5d27d1fb55    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Nov 2017 14:31:00 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Nov 2017 14:31:00 -0800    

Apart from calling write_stderr() on failure, the handler depends on no  
PostgreSQL facilities.  We have experienced crashes before reaching the  
former call site.  Given such an early crash, this change cannot hurt  
and may produce a helpful dump.  Absent an early crash, this change has  
no effect.  Back-patch to 9.3 (all supported versions).  
  
Takayuki Tsunakawa  
  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F80CD13@G01JPEXMBYT05  

commit   : dcbec53f4d90af369192695ee53f3b97e492b3bf    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Nov 2017 13:03:15 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Nov 2017 13:03:15 -0800    

PostgreSQL running as a Windows service crashed upon calling  
write_stderr() before MemoryContextInit().  This fix completes work  
started in 5735efee15540765315aa8c1a230575e756037f7.  Messages this  
early contain only ASCII bytes; if we removed the CurrentMemoryContext  
requirement, the ensuing conversions would have no effect.  Back-patch  
to 9.3 (all supported versions).  
  
Takayuki Tsunakawa, reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F80CC73@G01JPEXMBYT05  

commit   : dc10deb2b8ce73a8fc8a97c9aad43edbc1c008a7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 14:35:22 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 14:35:22 -0800    

This suite had been a proper superset of the regular ecpg test suite,  
but the three newest tests didn't reach it.  To make this less likely to  
recur, delete the extra schedule file and pass the TCP-specific test on  
the command line.  Back-patch to 9.3 (all supported versions).  

commit   : 9e61a1a29869992255948c07086c5840b5c0c4f4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 14:33:02 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 14:33:02 -0800    

Since commit 868898739a8da9ab74c105b8349b7b5c711f265a, it has assumed  
"localhost" resolves to both ::1 and 127.0.0.1.  We gain nothing from  
that assumption, and it does not hold in a default installation of Red  
Hat Enterprise Linux 5.  Back-patch to 9.3 (all supported versions).  

commit   : 075ced2a4c09fad1a27ec545ab632cf1504e534f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 13:07:46 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 13:07:46 -0800    

To ensure stable output, catch one more configuration-specific error.  
Back-patch to 9.3, like the commit that added the test.  

commit   : 30a5e940ac9a96c5fee449223528a1b5555502ed    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 11:10:53 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Nov 2017 11:10:53 -0800    

When a value contained an XML declaration naming some other encoding,  
this function interpreted UTF8 bytes as the named encoding, yielding  
mojibake.  xml_parse() already has similar logic.  This would be  
necessary but not sufficient for non-UTF8 databases, so preserve  
behavior there until the xpath facility can support such databases  
comprehensively.  Back-patch to 9.3 (all supported versions).  
  
Pavel Stehule and Noah Misch  
  
Discussion: https://postgr.es/m/CAFj8pRC-dM=tT=QkGi+Achkm+gwPmjyOayGuUfXVumCxkDgYWg@mail.gmail.com  

commit   : f9e2885d51bf585bec2d5ffeda4f9e5e1a723f4d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 10 Nov 2017 14:21:32 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 10 Nov 2017 14:21:32 -0500    

An LDAP URL without a host name such as "ldap://" or without a base DN  
such as "ldap://localhost" would cause a crash when reading pg_hba.conf.  
  
If no binddn is configured, an error message might end up trying to print a  
null pointer, which could crash on some platforms.  
  
Author: Thomas Munro <thomas.munro@enterprisedb.com>  
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>  

commit   : d33fc27e8df65e89497b4b50e82900fc2bfd0b14    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Nov 2017 12:30:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Nov 2017 12:30:01 -0500    

Make bloom WAL test compare psql output text, not just result codes;  
this was evidently the intent all along, but it was mis-coded.  
In passing, make sure we will notice any failure in setup steps.  
  
Alexander Korotkov, reviewed by Michael Paquier and Masahiko Sawada  
  
Discussion: https://postgr.es/m/CAPpHfdtohPdQ9rc5mdWjxq+3VsBNw534KV_5O65dTQrSdVJNgw@mail.gmail.com  

commit   : a11e5a67d9a61bddb4ba7eec77e6671a0437f9fb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 9 Nov 2017 17:06:32 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 9 Nov 2017 17:06:32 -0500    

This causes a warning when accidentally backpatching an XML-style  
empty-element tag like <xref linkend="abc"/>.  

commit   : 4ea3c243b98da6d526960586e9acc6d22283ffa2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 9 Nov 2017 17:00:53 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 9 Nov 2017 17:00:53 -0500    

commit   : 4384f8a51b8b0a2eaac3f2f9d25825cd5f5f4b7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Nov 2017 11:57:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Nov 2017 11:57:20 -0500    

The header comment written into postgresql.auto.conf by ALTER SYSTEM  
should match what initdb put there originally.  
  
Feike Steenbergen  
  
Discussion: https://postgr.es/m/CAK_s-G0KcKdO=0hqZkwb3s+tqZuuHwWqmF5BDsmoO9FtX75r0g@mail.gmail.com  

commit   : 115a7075633899408fc1ab85f3bc2e5deeaa5e45    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Nov 2017 11:30:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Nov 2017 11:30:30 -0500    

Somebody messed up a refactoring here.  As it stood, we'd check pg_ctl's  
--version output twice for each cluster.  Worse, the first check for the  
new cluster's version happened before we'd done any validate_exec checks  
there, breaking the check ordering the code intended.  
  
A. Akenteva  
  
Discussion: https://postgr.es/m/f9266a85d918a3cf3a386b5148aee666@postgrespro.ru  

commit   : 1772c5c6eee7f3eeaa0e485f67e9cd92f165e1cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Nov 2017 11:00:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Nov 2017 11:00:36 -0500    

Upon further review, our Bonjour code doesn't actually work with the  
Avahi not-too-compatible compatibility library.  While you can get it  
to work on non-macOS platforms if you link to Apple's own mDNSResponder  
code, there don't seem to be many people who care about that.  Leaving in  
the AC_SEARCH_LIBS call seems more likely to encourage people to build  
broken configurations than to do anything very useful.  
  
Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead.  
  
Discussion: https://postgr.es/m/2D8331C5-D64F-44C1-8717-63EDC6EAF7EB@brightforge.com  

commit   : 58bc9ea033f7361e4787dc6d29a9ff0b246c8fe4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Nov 2017 17:47:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Nov 2017 17:47:14 -0500    

On macOS the relevant functions require no special library, but elsewhere  
we need to pull in libdns_sd.  
  
Back-patch to supported branches.  No docs change since the docs do not  
suggest that this is a Mac-only feature.  
  
Luke Lonergan  
  
Discussion: https://postgr.es/m/2D8331C5-D64F-44C1-8717-63EDC6EAF7EB@brightforge.com  

commit   : 6c05b8150327ca5f58e47ebe4f2dfa235ef930e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Nov 2017 17:20:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Nov 2017 17:20:53 -0500    

The grammar requires these options to appear the other way 'round.  
  
jotpe@posteo.de  
  
Discussion: https://postgr.es/m/78933bd0-45ce-690e-b832-a328dd1a5567@posteo.de  

commit   : 442bc4160caee01579f5c112c23d9bb5f121f6b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Nov 2017 16:50:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Nov 2017 16:50:13 -0500    

The point of having separate ResourceOwnerEnlargeFoo and  
ResourceOwnerRememberFoo functions is so that resource allocation  
can happen in between.  Doing it in some other order is just wrong.  
  
OpenTemporaryFile() did open(), enlarge, remember, which would leak the  
open file if the enlarge step ran out of memory.  Because fd.c has its own  
layer of resource-remembering, the consequences look like they'd be limited  
to an intratransaction FD leak, but it's still not good.  
  
IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow  
up if the incr-refcount step ever failed.  It was safe enough when written,  
but since the introduction of PrivateRefCountHash, I think the assumption  
that no error could happen there is pretty shaky.  
  
The odds of real problems from either bug are probably small, but still,  
back-patch to supported branches.  
  
Thomas Munro and Tom Lane, per a comment from Andres Freund  

commit   : e836502d64ba7fc936d8c273125e4ac298773e76    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Nov 2017 13:49:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Nov 2017 13:49:36 -0500    

isdigit(), isspace(), etc are likely to give surprising results if passed a  
signed char.  We should always cast the argument to unsigned char to avoid  
that.  Error in commit 63d6b97fd, found by buildfarm member gaur.  
Back-patch to 9.3, like that commit.