PostgreSQL 11.5 (upcoming) commit log

Fix thinko in construction of old_conpfeqop list.

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

Click here for diff

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

M src/backend/commands/tablecmds.c

doc: mention pg_reload_conf() for reloading the config file

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

Click here for diff

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

M doc/src/sgml/client-auth.sgml

Fix documentation for pgbench tpcb-like.

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

Click here for diff

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

M doc/src/sgml/ref/pgbench.sgml

Fix get_actual_variable_range() to cope with broken HOT chains.

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

Click here for diff

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

M src/backend/utils/adt/selfuncs.c

Fix RANGE partition pruning with multiple boolean partition keys

commit   : 757f1baa8c13ffe7abd7b0f49f787a1c007cdf89    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 12 Jul 2019 19:10:12 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 12 Jul 2019 19:10:12 +1200    

Click here for diff

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

M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql

Mention limitation of unique in partitioned tables

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

Click here for diff

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

M doc/src/sgml/ddl.sgml

Fix compile failure

commit   : 2ede93de9e80f0f39276c0afabf1621d21180370    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 Jul 2019 09:01:28 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 Jul 2019 09:01:28 -0400    

Click here for diff

REL_11_STABLE's configure does not select C99 mode by default, so using  
C99 block initializer broke the build for some compilers.  Revert to C89  
in that branch.  
  
Author: Michaël Paquier  
Discussion: https://postgr.es/m/20190710070122.GE1031@paquier.xyz  

M src/backend/commands/tablecmds.c

Fix variable initialization when using buffering build with GiST

commit   : 1cde7fe84a479113127596e46e070f07ac6f09d0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jul 2019 15:15:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jul 2019 15:15:07 +0900    

Click here for diff

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

M src/backend/access/gist/gistbuildbuffers.c

Pass QueryEnvironment down to EvalPlanQual's EState.

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

Click here for diff

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

M src/backend/executor/execMain.c

Propagate trigger arguments to partitions

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

Click here for diff

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

M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

Force hash joins to be enabled in the hash join regression tests.

commit   : 3955c50f3762be6f0a63573c5b4efef72b30dc2b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 9 Jul 2019 18:24:33 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 9 Jul 2019 18:24:33 +1200    

Click here for diff

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

M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

doc: Clarify logical replication documentation

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

Click here for diff

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

M doc/src/sgml/logical-replication.sgml

Ensure plpgsql result tuples have the right composite type marking.

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

Click here for diff

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

M src/pl/plpgsql/src/expected/plpgsql_record.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_record.sql

Don't remove surplus columns from GROUP BY for inheritance parents

commit   : 133f5ae214de4a9aed7bfb138ea72ad7926262e2    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 3 Jul 2019 23:45:42 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 3 Jul 2019 23:45:42 +1200    

Click here for diff

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

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql

Add support for Visual Studio 2019 in build scripts

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

Click here for diff

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

M doc/src/sgml/install-windows.sgml
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/README
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm

Fix tab completion of "SET variable TO|=" to not offer bogus completions.

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

Click here for diff

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

M src/bin/psql/tab-complete.c

Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType.

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

Click here for diff

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

M src/backend/utils/adt/arrayfuncs.c
M src/include/utils/array.h
M src/include/utils/arrayaccess.h
M src/include/utils/expandeddatum.h

Repair logic for reordering grouping sets optimization.

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

Click here for diff

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

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql

Fix for dropped columns in a partitioned table's default partition

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

Click here for diff

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

M src/backend/commands/tablecmds.c
M src/backend/partitioning/partbounds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Fix misleading comment in nodeIndexonlyscan.c.

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

Click here for diff

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

M src/backend/executor/nodeIndexonlyscan.c

Update reference to sampling algorithm in analyze.c

commit   : 803cdf22a2d395653496702af789ccae7c17e18c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 27 Jun 2019 18:14:25 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 27 Jun 2019 18:14:25 +0200    

Click here for diff

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

M src/backend/commands/analyze.c

Fix use-after-free introduced in 55ed3defc966

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

Click here for diff

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

M src/backend/commands/indexcmds.c

Fix partitioned index creation with foreign partitions

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

Click here for diff

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

M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_foreign_table.sgml
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/tcop/utility.c
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql

Add support for OpenSSL 1.1.0 and newer versions in MSVC scripts

commit   : 0e08a3a1f541228e312111eda5122f6004fe7dbf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Jun 2019 23:04:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Jun 2019 23:04:32 +0900    

Click here for diff

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

M src/tools/msvc/Solution.pm

Follow the rule that regression-test-created roles are named "regress_xxx".

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

Click here for diff

contrib/amcheck didn't get the memo either.  

M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql

Fix thinkos in LookupFuncName() for function name lookups

commit   : 52cdbdc42c23e4f9ae1e62e95bd85d11c030d3f6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Jun 2019 11:15:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Jun 2019 11:15:38 +0900    

Click here for diff

This could trigger valgrind failures when doing ambiguous function name  
lookups when no arguments are provided by the caller.  The problem has  
been introduced in aefeb68, so backpatch to v10.  HEAD is fine thanks to  
the refactoring done in bfb456c1.  
  
Reported-by: Alexander Lakhin  
Author: Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/3d068be5-f617-a5ee-99f6-458a407bfd65@gmail.com  
Backpatch-through: 10  

M src/backend/parser/parse_func.c

Don't unset MAKEFLAGS in non-GNU Makefile.

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

Click here for diff

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

M Makefile

Remove misleading comment from pathnodes.h.

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

Click here for diff

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

M src/include/nodes/relation.h

Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.

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

Click here for diff

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

M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Fix spinlock assembly code for MIPS so it works on MIPS r6.

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

Click here for diff

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

M src/include/storage/s_lock.h

Consolidate methods for translating a Perl path to a Windows path.

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

Click here for diff

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

M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/014_unlogged_reinit.pl
M src/test/recovery/t/017_shm.pl

Remove obsolete comments about sempahores from proc.c.

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

Click here for diff

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

M src/backend/storage/lmgr/proc.c

Fix description of WAL record XLOG_BTREE_META_CLEANUP

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

Click here for diff

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

M src/backend/access/rmgrdesc/nbtdesc.c

Avoid spurious deadlocks when upgrading a tuple lock

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

Click here for diff

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

M src/backend/access/heap/README.tuplock
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec

Prevent Parallel Hash Join for JOIN_UNIQUE_INNER.

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

Click here for diff

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

M src/backend/optimizer/path/joinpath.c