PostgreSQL 11.0 commit log

commit   : 19f20081df059fef87e14c8e953669bd173dd7f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 17:12:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 17:12:02 -0400    

commit   : db9034bf7653fa527e2531e1a713dbbd37066a6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 14:01:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Oct 2018 14:01:38 -0400    

ProcessUtility can recurse, and indeed can be driven to infinite  
recursion, so it ought to have a check_stack_depth() call.  This  
covers the reported bug (portal trying to execute itself) and a bunch  
of other cases that could perhaps arise somewhere.  
  
Per bug #15428 from Malthe Borch.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/15428-b3c2915ec470b033@postgresql.org  

commit   : 6c6deadb044bd0353641aff8203fd92eb0e6606f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 11:33:11 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 11:33:11 +0200    

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

commit   : d315639c82e8a2cfd1d1b98b7acf0f6c033ab955    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 09:48:49 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Oct 2018 09:48:49 +0200    

With the PostgreSQL 11 release notes acknowledgments list, FOP reported  
  
WARNING: Glyph "?" (0x144, nacute) not available in font "Times-Roman".  
WARNING: Glyph "?" (0x15e, Scedilla) not available in font "Times-Roman".  
WARNING: Glyph "?" (0x15f, scedilla) not available in font "Times-Roman".  
WARNING: Glyph "?" (0x131, dotlessi) not available in font "Times-Roman".  
  
This is because we have some new contributors whose names use letters  
that we haven't used before, and apparently FOP can't handle them out  
of the box.  
  
For now, just fix this by "unaccenting" those names.  In the future,  
maybe this can be fixed better with a different font configuration.  
  
There is also another warning  
  
WARNING: Glyph "?" (0x3c0, pi) not available in font "Times-Roman".  
  
but that existed in previous releases and is not touched here.  

commit   : 1846bac46da142e0a9fdef3f9004c306370d7213    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 15 Oct 2018 00:40:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 15 Oct 2018 00:40:17 +0300    

This commit documents rounding of "length" parameter and absence of support  
for unique indexes and NULLs searching.  Backpatch to 9.6 where contrib/bloom  
was introduced.  
  
Discussion: https://postgr.es/m/CAF4Au4wPQQ7EHVSnzcLjsbY3oLSzVk6UemZLD1Sbmwysy3R61g%40mail.gmail.com  
Author: Oleg Bartunov with minor editorialization by me  
Backpatch-through: 9.6  

commit   : 18781cd2af97002234f2db08f68cc4b392b2e463    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 14 Oct 2018 22:23:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 14 Oct 2018 22:23:29 +0900    

On a primary, sets of XLOG_RUNNING_XACTS records are generated on a  
periodic basis to allow recovery to build the initial state of  
transactions for a hot standby.  The set of transaction IDs is created  
by scanning all the entries in ProcArray.  However it happens that its  
logic never counted on the fact that two-phase transactions finishing to  
prepare can put ProcArray in a state where there are two entries with  
the same transaction ID, one for the initial transaction which gets  
cleared when prepare finishes, and a second, dummy, entry to track that  
the transaction is still running after prepare finishes.  This way  
ensures a continuous presence of the transaction so as callers of for  
example TransactionIdIsInProgress() are always able to see it as alive.  
  
So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase  
transaction finishes to prepare, the record can finish with duplicated  
XIDs, which is a state expected by design.  If this record gets applied  
on a standby to initial its recovery state, then it would simply fail,  
so the odds of facing this failure are very low in practice.  It would  
be tempting to change the generation of XLOG_RUNNING_XACTS so as  
duplicates are removed on the source, but this requires to hold on  
ProcArrayLock for longer and this would impact all workloads,  
particularly those using heavily two-phase transactions.  
  
XLOG_RUNNING_XACTS is also actually used only to initialize the standby  
state at recovery, so instead the solution is taken to discard  
duplicates when applying the initial snapshot.  
  
Diagnosed-by: Konstantin Knizhnik  
Author: Michael Paquier  
Discussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru  
Backpatch-through: 9.3  

commit   : 52f76a02f6609ab84a4b929d8b0f1ccc0f7f3c9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 21:39:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 21:39:20 -0400    

Justin Pryzby and myself.  
  
Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com  

commit   : e2002b4014d4650ebb42c93111b8a7a9b34ec8d9    
  
author   : Greg Stark <stark@mit.edu>    
date     : Sat, 6 Oct 2018 13:03:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Oct 2018 13:03:43 -0400    

6e7baa3227 and b06d8e58b5 added "B" as a valid suffix for  
GUC_UNIT_BYTES but neglected to add it to the docs.  

commit   : d1fd7576e1d3d17d1d63c8796a02de1649fd63fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 17:29:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 17:29:12 -0400    

Justin Pryzby, Jonathan S. Katz, and myself.  
  
Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com  

commit   : 4d00ee4b4ac2c17e32633d3c305041f5e6570bea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:42:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:42:58 -0400    

Justin Pryzby, Jonathan S. Katz, and myself.  
  
Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com  

commit   : a31af2551fed8cb7d2d52f3dbe6c6e0d21a1c57c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:31:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Oct 2018 16:31:09 -0400    

Set the release date.  Do a bunch of copy-editing and markup improvement,  
rearrange some stuff into what seemed a more sensible order, move some  
things that did not seem to be in the right section.  

commit   : 184951a48a107c7e1f128f7fa3887fbd216d6d60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 19:33:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 19:33:56 -0400    

In the back branches, drop these tables after the regression tests are  
done with them.  This fixes failures of cross-branch pg_upgrade testing  
caused by these types having been removed in v12.  We do lose the ability  
to test dump/restore behavior with these types in the back branches, but  
the actual loss of code coverage seems to be nil given that there's nothing  
very special about these types.  
  
Discussion: https://postgr.es/m/20181009192237.34wjp3nmw7oynmmr@alap3.anarazel.de  

commit   : 3d059655be7dfcb7124c6b3ce0925448de89f669    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 14:26:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Oct 2018 14:26:56 -0400    

We can allow this macro to accept either abbreviated or non-abbreviated  
allocation parameters by making use of __VA_ARGS__.  As noted by Andres  
Freund, it's unlikely that any compiler would have __builtin_constant_p  
but not __VA_ARGS__, so this gives up little or no error checking, and  
it avoids a minor but annoying API break for extensions.  
  
With this change, there is no reason for anybody to call  
AllocSetContextCreateExtended directly, so in HEAD I renamed it to  
AllocSetContextCreateInternal.  It's probably too late for an ABI  
break like that in 11, though.  
  
Discussion: https://postgr.es/m/20181012170355.bhxi273skjt6sag4@alap3.anarazel.de  

commit   : 355684ee3fa3001adf0de3873fddadd119773819    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 Oct 2018 12:36:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 12 Oct 2018 12:36:26 -0300    

There was no code to handle foreign key constraints on partitioned  
tables in the case of ALTER TABLE DETACH; and if you happened to ATTACH  
a partition that already had an equivalent constraint, that one was  
ignored and a new constraint was created.  Adding this to the fact that  
foreign key cloning reuses the constraint name on the partition instead  
of generating a new name (as it probably should, to cater to SQL  
standard rules about constraint naming within schemas), the result was a  
pretty poor user experience -- the most visible failure was that just  
detaching a partition and re-attaching it failed with an error such as  
  
  ERROR:  duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"  
  DETAIL:  Key (conrelid, contypid, conname)=(26702, 0, test_result_asset_id_fkey) already exists.  
  
because it would try to create an identically-named constraint in the  
partition.  To make matters worse, if you tried to drop the constraint  
in the now-independent partition, that would fail because the constraint  
was still seen as dependent on the constraint in its former parent  
partitioned table:  
  ERROR:  cannot drop inherited constraint "test_result_asset_id_fkey" of relation "test_result_cbsystem_0001_0050_monthly_2018_09"  
  
This fix attacks the problem from two angles: first, when the partition  
is detached, the constraint is also marked as independent, so the drop  
now works.  Second, when the partition is re-attached, we scan existing  
constraints searching for one matching the FK in the parent, and if one  
exists, we link that one to the parent constraint.  So we don't end up  
with a duplicate -- and better yet, we don't need to scan the referenced  
table to verify that the constraint holds.  
  
To implement this I made a small change to previously planner-only  
struct ForeignKeyCacheInfo to contain the constraint OID; also relcache  
now maintains the list of FKs for partitioned tables too.  
  
Backpatch to 11.  
  
Reported-by: Michael Vitale (bug #15425)  
Discussion: https://postgr.es/m/15425-2dbc9d2aa999f816@postgresql.org  

commit   : 88670a4366110c946ef47048d1cebd641209fb0d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 10 Oct 2018 13:53:02 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 10 Oct 2018 13:53:02 -0700    

Repeatedly rewriting a mapped catalog table with VACUUM FULL or  
CLUSTER could cause logical decoding to fail with:  
ERROR, "could not map filenode \"%s\" to relation OID"  
  
To trigger the problem the rewritten catalog had to have live tuples  
with toasted columns.  
  
The problem was triggered as during catalog table rewrites the  
heap_insert() check that prevents logical decoding information to be  
emitted for system catalogs, failed to treat the new heap's toast table  
as a system catalog (because the new heap is not recognized as a  
catalog table via RelationIsLogicallyLogged()). The relmapper, in  
contrast to the normal catalog contents, does not contain historical  
information. After a single rewrite of a mapped table the new relation  
is known to the relmapper, but if the table is rewritten twice before  
logical decoding occurs, the relfilenode cannot be mapped to a  
relation anymore.  Which then leads us to error out.   This only  
happens for toast tables, because the main table contents aren't  
re-inserted with heap_insert().  
  
The fix is simple, add a new heap_insert() flag that prevents logical  
decoding information from being emitted, and accept during decoding  
that there might not be tuple data for toast tables.  
  
Unfortunately that does not fix pre-existing logical decoding  
errors. Doing so would require not throwing an error when a filenode  
cannot be mapped to a relation during decoding, and that seems too  
likely to hide bugs.  If it's crucial to fix decoding for an existing  
slot, temporarily changing the ERROR in ReorderBufferCommit() to a  
WARNING appears to be the best fix.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20180914021046.oi7dm4ra3ot2g2kt@alap3.anarazel.de  
Backpatch: 9.4-, where logical decoding was introduced  

commit   : 4c676181cdb6c16c414d5e9cd2304f5c73881601    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 17:24:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 17:24:40 -0400    

commit   : 1145c26b749a73419d32e4c997237e84fbbffa04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 16:16:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Oct 2018 16:16:36 -0400    

Per discussion, this behavior seems less astonishing than not doing so.  
  
Peter Eisentraut and Tom Lane  
  
Discussion: https://postgr.es/m/20180920234040.GC29981@momjian.us  

commit   : 8569ef63f4d30d25f950270f62ca7263b56157a3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Oct 2018 10:36:33 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Oct 2018 10:36:33 -0300    

gcc 6.3 does not whine about this mistake I made in 39808e8868c8 but  
evidently lots of other compilers do, according to Michael Paquier,  
Peter Eisentraut, Arthur Zakirov, Tomas Vondra.  
  
Discussion: too many to list  

commit   : 69ff26b96f6f1ea947bd52d18f21e99fd61c25ec    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Oct 2018 12:03:54 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Oct 2018 12:03:54 +0200    

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

commit   : c2055a4a171b11a7d0df7fabeaaeec9b8cdf85af    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 14:14:03 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 14:14:03 +0200    

This was forgotten when procedures were implemented.  
  
Reported-by: Lukas Fittl <lukas@fittl.com>  

commit   : c8ed820c68bcad00d07d60e436cdddb7c0edf44d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Oct 2018 17:56:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Oct 2018 17:56:13 +0900    

Error messages for creating a foreign key on a partitioned table using  
ONLY or NOT VALID were wrong in mentioning the objects they worked on.  
This commit adds on the way some regression tests missing for those  
cases.  
  
Author: Laurenz Albe  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/c11c05810a9ed65e9b2c817a9ef442275a32fe80.camel@cybertec.at  

commit   : 4d7c74039f091e04e520d5688c964f653f8c55a8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 8 Oct 2018 08:57:24 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 8 Oct 2018 08:57:24 +0200    

Reported by Alexander Lakhin in bug #15423  

commit   : 1c7f585b5c1a317bdbdf7d41c7ffab9968738149    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 22:13:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 22:13:19 -0300    

Commit 2fbdf1b38bc changed the order in which we inserted catalog rows  
when creating partitions, so that we could remove an unsightly hack  
required for untimely relcache invalidations.  However, that commit only  
changed the ordering for CREATE TABLE PARTITION OF, and left ALTER TABLE  
ATTACH PARTITION unchanged, so the latter can be affected when catalog  
invalidations occur, for instance when the partition key involves an SQL  
function.  
  
Reported-by: Rajkumar Raghuwanshi  
Author: Amit Langote  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/CAKcux6=nTz9KSfTr_6Z2mpzLJ_09JN-rK6=dWic6gGyTSWueyQ@mail.gmail.com  

commit   : 1a852f7c1e27eef563cf0577c2604baec1be5512    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 19:17:46 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 6 Oct 2018 19:17:46 -0300    

Index DDL cascading on partitioned tables introduced a way for ALTER  
TABLE to be called reentrantly.  This caused an an important deficiency  
in event trigger support to be exposed: on exiting the reentrant call,  
the alter table state object was clobbered, causing a crash when the  
outer alter table tries to finalize its processing.  Fix the crash by  
creating a stack of event trigger state objects.  There are still ways  
to cause things to misbehave (and probably other crashers) with more  
elaborate tricks, but at least it now doesn't crash in the obvious  
scenario.  
  
Backpatch to 9.5, where DDL deparsing of event triggers was introduced.  
  
Reported-by: Marco Slot  
Authors: Michaël Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/CANNhMLCpi+HQ7M36uPfGbJZEQLyTy7XvX=5EFkpR-b1bo0uJew@mail.gmail.com  

commit   : 6bf278df891d7601eda2824a8b0df15dc52b7def    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Oct 2018 12:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Oct 2018 12:00:09 -0400    

Previously, a worker process would establish values for these based on  
its own start time.  In v10 and up, this can trivially be shown to cause  
misbehavior of transaction_timestamp(), timestamp_in(), and related  
functions which are (perhaps unwisely?) marked parallel-safe.  It seems  
likely that other behaviors might diverge from what happens in the parent  
as well.  
  
It's not as trivial to demonstrate problems in 9.6 or 9.5, but I'm sure  
it's still possible, so back-patch to all branches containing parallel  
worker infrastructure.  
  
In HEAD only, mark now() and statement_timestamp() as parallel-safe  
(other affected functions already were).  While in theory we could  
still squeeze that change into v11, it doesn't seem important enough  
to force a last-minute catversion bump.  
  
Konstantin Knizhnik, whacked around a bit by me  
  
Discussion: https://postgr.es/m/6406dbd2-5d37-4cb6-6eb2-9c44172c7e7c@postgrespro.ru  

commit   : c905b67b79b72b88ba80d2486443c824232c6d85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Oct 2018 14:59:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 6 Oct 2018 14:59:52 +0900    

This is for example used when attaching a partition to a partitioned  
table which includes foreign keys, and in this case the constraint name  
has been missing in the data cloned.  This could lead to hard crashes,  
as when validating the foreign key constraint, the constraint name is  
always expected.  Particularly, when using log_min_messages >= DEBUG1, a  
log message would be generated with this unassigned constraint name,  
leading to an assertion failure on HEAD.  
  
While on it, rename a variable in ATExecAttachPartition which was  
declared twice with the same name.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20181005042236.GG1629@paquier.xyz  
Backpatch-through: 11  

commit   : 076cfffb39af281f4e3b7d9852715bb09e214171    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Oct 2018 17:20:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Oct 2018 17:20:24 -0400    

Discussion: https://postgr.es/m/1f5b2e66-7ba8-98ec-c06a-aee9ff33f050@postgresql.org  
  
Author: Jonathan S. Katz  
  
Backpatch-through: 11  

commit   : 67e7d4da72dca6525fd2b9a2f2522994040897ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 16:01:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 16:01:29 -0400    

Historically we forbade datatype-specific comparison functions from  
returning INT_MIN, so that it would be safe to invert the sort order  
just by negating the comparison result.  However, this was never  
really safe for comparison functions that directly return the result  
of memcmp(), strcmp(), etc, as POSIX doesn't place any such restriction  
on those library functions.  Buildfarm results show that at least on  
recent Linux on s390x, memcmp() actually does return INT_MIN sometimes,  
causing sort failures.  
  
The agreed-on answer is to remove this restriction and fix relevant  
call sites to not make such an assumption; code such as "res = -res"  
should be replaced by "INVERT_COMPARE_RESULT(res)".  The same is needed  
in a few places that just directly negated the result of memcmp or  
strcmp.  
  
To help find places having this problem, I've also added a compile option  
to nbtcompare.c that causes some of the commonly used comparators to  
return INT_MIN/INT_MAX instead of their usual -1/+1.  It'd likely be  
a good idea to have at least one buildfarm member running with  
"-DSTRESS_SORT_INT_MIN".  That's far from a complete test of course,  
but it should help to prevent fresh introductions of such bugs.  
  
This is a longstanding portability hazard, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/20180928185215.ffoq2xrq5d3pafna@alap3.anarazel.de  

commit   : 6e526b78706a99dc52182387d0e6f84d05bd597a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 12:45:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Oct 2018 12:45:37 -0400    

Without this, the syntax-tree-dumping functions in pl_funcs.c crash,  
and there are other places that might be at risk too.  Per report  
from Pavel Stehule.  
  
Looks like I broke this in commit f9263006d, so back-patch to v11.  
  
Discussion: https://postgr.es/m/CAFj8pRA+3f5n4642q2g8BXCKjbTd7yU9JMYAgDyHgozk6cQ-VA@mail.gmail.com  

commit   : 40159d91cc546b2585efd3eb0b3db05cd6f2be93    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 17:10:19 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Oct 2018 17:10:19 +0200    

Author: Nikita Glukhov <n.gluhov@postgrespro.ru>  

commit   : ff347f8aff04865680c19ffc818460bb2afaad5b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 Oct 2018 11:37:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 4 Oct 2018 11:37:20 -0300    

When using the CREATE TABLE .. PARTITION OF syntax, it's possible to  
cause a partition to get two primary keys if the parent already has one.  
Tighten the check to disallow that.  
  
Reported-by: Rajkumar Raghuwanshi  
Author: Amul Sul  
Discussion: https://postgr.es/m/CAKcux6=OnSV3-qd8Gb6W=KPPwcCz6Fe_O_MQYjTa24__Xn8XxA@mail.gmail.com  

commit   : e97c4d967ba500c7ec427a56467440f036127158    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 3 Oct 2018 12:48:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 3 Oct 2018 12:48:37 -0700    

I (Andres) was more than a bit hasty in committing 33001fd7a7072d48327  
after last minute changes, leading to a number of problems (jit output  
was only shown for JIT in parallel workers, and just EXPLAIN without  
ANALYZE didn't work).  Lukas luckily found these issues quickly.  
  
Instead of combining instrumentation in in standard_ExecutorEnd(), do  
so on demand in the new ExplainPrintJITSummary().  
  
Also update a documentation example of the JIT output, changed in  
52050ad8ebec8d831.  
  
Author: Lukas Fittl, with minor changes by me  
Discussion: https://postgr.es/m/CAP53PkxmgJht69pabxBXJBM+0oc6kf3KHMborLP7H2ouJ0CCtQ@mail.gmail.com  
Backpatch: 11, where JIT compilation was introduced  

commit   : ca5ca25d08710d7f5aaf0e390aae284bc594a6da    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Oct 2018 09:14:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 3 Oct 2018 09:14:09 +0530    

The API (EOH_flatten_into) that flattens the expanded value representation  
expects the target address to be maxaligned.  All it's usage adhere to that  
principle except when serializing datums for parallel query.  Fix that  
usage.  
  
Diagnosed-by: Tom Lane  
Author: Tom Lane and Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/11629.1536550032@sss.pgh.pa.us  

commit   : a051c19c3cf4415b36e6333a83a113de4d90a973    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 12:41:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 12:41:28 -0400    

Previously, we used the platform's NL_ARGMAX if any, otherwise 16.  
The trouble with this is that the platform value is hugely variable,  
ranging from the POSIX-minimum 9 to as much as 64K on recent FreeBSD.  
Values of more than a dozen or two have no practical use and slow down  
the initialization of the argtypes array.  Worse, they cause snprintf.c  
to consume far more stack space than was the design intention, possibly  
resulting in stack-overflow crashes.  
  
Standardize on 31, which is comfortably more than we need (it looks like  
no existing translatable message has more than about 10 parameters).  
I chose that, not 32, to make the array sizes powers of 2, for some  
possible small gain in speed of the memset.  
  
The lack of reported crashes suggests that the set of platforms we  
use snprintf.c on (in released branches) may have no overlap with  
the set where NL_ARGMAX has unreasonably large values.  But that's  
not entirely clear, so back-patch to all supported branches.  
  
Per report from Mateusz Guzik (via Thomas Munro).  
  
Discussion: https://postgr.es/m/CAEepm=3VF=PUp2f8gU8fgZB22yPE_KBS0+e1AHAtQ=09schTHg@mail.gmail.com  

commit   : 419cc8add5fb81331efbc7ea8862e08b981b7762    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 11:54:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Oct 2018 11:54:12 -0400    

The variants of these functions that take numeric inputs (OIDs or  
column numbers) are supposed to return NULL rather than failing  
on bad input; this rule reduces problems with snapshot skew when  
queries apply the functions to all rows of a catalog.  
  
has_column_privilege() had careless handling of the case where the  
table OID didn't exist.  You might get something like this:  
	select has_column_privilege(9999,'nosuchcol','select');  
	ERROR:  column "nosuchcol" of relation "(null)" does not exist  
or you might get a crash, depending on the platform's printf's response  
to a null string pointer.  
  
In addition, while applying the column-number variant to a dropped  
column returned NULL as desired, applying the column-name variant  
did not:  
	select has_column_privilege('mytable','........pg.dropped.2........','select');  
	ERROR:  column "........pg.dropped.2........" of relation "mytable" does not exist  
It seems better to make this case return NULL as well.  
  
Also, the OID-accepting variants of has_foreign_data_wrapper_privilege,  
has_server_privilege, and has_tablespace_privilege didn't follow the  
principle of returning NULL for nonexistent OIDs.  Superusers got TRUE,  
everybody else got an error.  
  
Per investigation of Jaime Casanova's report of a new crash in HEAD.  
These behaviors have been like this for a long time, so back-patch to  
all supported branches.  
  
Patch by me; thanks to Stephen Frost for discussion and review  
  
Discussion: https://postgr.es/m/CAJGNTeP=-6Gyqq5TN9OvYEydi7Fv1oGyYj650LGTnW44oAzYCg@mail.gmail.com  

commit   : e9cff306168743e6ff2abdc03e4857ecb9fb4001    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Oct 2018 16:34:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Oct 2018 16:34:59 +0900    

The example used in the documentation is outdated as well.  This is an  
oversight from 0ac5ad5, which bumped up pgrowlocks but forgot some bits  
of the documentation.  
  
Reported-by: Chris Wilson  
Discussion: https://postgr.es/m/153838692816.2950.12001142346234155699@wrigleys.postgresql.org  
Backpatch-through: 9.3  

commit   : 3b983c3354df78f273594dc711c207d09cd214dd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 Oct 2018 23:02:55 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 1 Oct 2018 23:02:55 +0200    

This was claimed to have been done in  
0a63f996e018ac508c858e87fa39cc254a5db49f, but that actually only  
changed the documentation and not the grammar.  (That commit did fully  
change it for CREATE TRIGGER.)  

commit   : 1f25c7a8fc99bb33a9b978ab92b9ba9840366753    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:51:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:51:07 -0400    

contrib/pageinspect's tuple_data_split() function thought it could get  
away with opening the referenced relation with NoLock.  In practice  
there's no guarantee that the current session holds any lock on that  
rel (even if we just read a page from it), so that this is unsafe.  
  
Switch to using AccessShareLock.  Also, postpone closing the relation,  
so that we needn't copy its tupdesc.  Also, fix unsafe use of  
att_isnull() for attributes past the end of the tuple.  
  
Per testing with a patch that complains if we open a relation without  
holding any lock on it.  I don't plan to back-patch that patch, but we  
should close the holes it identifies in all supported branches.  
  
Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us  

commit   : 4c985549fe82c2a283f5f113747ae2ffd1a95926    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:39:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Oct 2018 11:39:13 -0400    

If the column being modified is referenced by a foreign key constraint  
of another table, ALTER TABLE would open the other table (to re-parse  
the constraint's definition) without having first obtained a lock on it.  
This was evidently intentional, but that doesn't mean it's really safe.  
It's especially not safe in 9.3, which pre-dates use of MVCC scans for  
catalog reads, but even in current releases it doesn't seem like a good  
idea.  
  
We know we'll need AccessExclusiveLock shortly to drop the obsoleted  
constraint, so just get that a little sooner to close the hole.  
  
Per testing with a patch that complains if we open a relation without  
holding any lock on it.  I don't plan to back-patch that patch, but we  
should close the holes it identifies in all supported branches.  
  
Discussion: https://postgr.es/m/2038.1538335244@sss.pgh.pa.us  

commit   : 7871a36255e2675075990714bfe0d051f3807efc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Sep 2018 16:24:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Sep 2018 16:24:56 -0400    

The method we've traditionally used, of redeclaring strerror_r() to  
see if the compiler complains of inconsistent declarations, turns out  
not to work reliably because some compilers only report a warning,  
not an error.  Amazingly, this has gone undetected for years, even  
though it certainly breaks our detection of whether strerror_r  
succeeded.  
  
Let's instead test whether the compiler will take the result of  
strerror_r() as a switch() argument.  It's possible this won't  
work universally either, but it's the best idea I could come up with  
on the spur of the moment.  
  
Back-patch of commit 751f532b9.  Buildfarm results indicate that only  
icc-on-Linux actually has an issue here; perhaps the lack of field  
reports indicates that people don't build PG for production that way.  
  
Discussion: https://postgr.es/m/10877.1537993279@sss.pgh.pa.us  

commit   : a8fb03fceadb5fe9698ff0182ca76b0640348e70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Sep 2018 16:12:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 28 Sep 2018 16:12:13 -0400    

Give a specific error complaining about lack of posix_fadvise() when  
someone tries to set effective_io_concurrency > 0 on platforms  
without that.  
  
This probably isn't worth extensive back-patching, but I (tgl) felt  
cramming it into v11 was reasonable.  
  
James Robinson  
  
Discussion: https://postgr.es/m/153771876450.14994.560017943128223619@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/A3942987-5BC7-4F05-B54D-2A0EC2914B33@jlr-photo.com  

commit   : 6c8671bc395c9be44571e424c458b94ec20975d3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 28 Sep 2018 12:24:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 28 Sep 2018 12:24:09 +0530    

When the checkpointer receives a SIGHUP signal to update its configuration,  
it may need to update the shared memory for full_page_writes and need to  
write a WAL record for it.  Now, it is quite possible that the XLOG  
machinery has not been initialized by that time and it will lead to  
assertion failure while doing that.  Fix is to allow the initialization of  
the XLOG machinery outside critical section.  
  
This bug has been introduced by the commit 2c03216d83 which added the XLOG  
machinery initialization in RecoveryInProgress code path.  
  
Reported-by: Dilip Kumar  
Author: Dilip Kumar  
Reviewed-by: Michael Paquier and Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com  

commit   : 88926fd481b7d1c928947230e154235d9d9720f4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Sep 2018 11:55:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 28 Sep 2018 11:55:43 +0900    

A restart point or a checkpoint recycling WAL segments treats segments  
marked with neither ".done" (archiving is done) or ".ready" (segment is  
ready to be archived) in archive_status the same way for archive_mode  
being "on" or "always".  While for a primary this is fine, a standby  
running a restart point with archive_mode = on would try to mark such a  
segment as ready for archiving, which is something that will never  
happen except after the standby is promoted.  
  
Note that this problem applies only to WAL segments coming from the  
local pg_wal the first time archive recovery is run.  Segments part of a  
self-contained base backup are the most common case where this could  
happen, however even in this case normally the .done markers would be  
most likely part of the backup.  Segments recovered from an archive are  
marked as .ready or .done by the startup process, and segments finished  
streaming are marked as such by the WAL receiver, so they are handled  
already.  
  
Reported-by: Haruka Takatsuka  
Author: Michael Paquier  
Discussion: https://postgr.es/m/15402-a453c90ed4cf88b2@postgresql.org  
Backpatch-through: 9.5, where archive_mode = always has been added.  

commit   : 49507dec46010cc781a4b4575b6c2ff5088b13d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Sep 2018 18:15:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Sep 2018 18:15:06 -0400    

It failed if passed a nonexistent relation OID, or one that was a non-heap  
relation, because of blindly applying heap_open to a user-supplied OID.  
This is not OK behavior for a SQL-exposed function; we have a project  
policy that we should return NULL in such cases.  Moreover, since  
pg_get_partition_constraintdef ought now to work on indexes, restricting  
it to heaps is flat wrong anyway.  
  
The underlying function generate_partition_qual() wasn't on board with  
indexes having partition quals either, nor for that matter with rels  
having relispartition set but yet null relpartbound.  (One wonders  
whether the person who wrote the function comment blocks claiming that  
these functions allow a missing relpartbound had ever tested it.)  
  
Fix by testing relispartition before opening the rel, and by using  
relation_open not heap_open.  (If any other relkinds ever grow the  
ability to have relispartition set, the code will work with them  
automatically.)  Also, don't reject null relpartbound in  
generate_partition_qual.  
  
Back-patch to v11, and all but the null-relpartbound change to v10.  
(It's not really necessary to change generate_partition_qual at all  
in v10, but I thought s/heap_open/relation_open/ would be a good  
idea anyway just to keep the code in sync with later branches.)  
  
Per report from Justin Pryzby.  
  
Discussion: https://postgr.es/m/20180927200020.GJ776@telsasoft.com  

commit   : 6485469606c15ae219977b1c228a266087eb30ca    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jun 2018 23:22:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jun 2018 23:22:14 -0400    

When a table ownership is changed, we must apply that also to any owned  
sequences.  (Otherwise, it would result in a situation that cannot be  
restored, because linked sequences must have the same owner as the  
table.)  But this was previously only applied to regular tables and  
materialized views.  But it should also apply to at least foreign  
tables.  This patch removes the relkind check altogether, because it  
doesn't save very much and just introduces the possibility of similar  
omissions.  
  
Bug: #15238  
Reported-by: Christoph Berg <christoph.berg@credativ.de>  

commit   : 180feb8c7ef5d4968170d49136faf492b6a03c67    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Sep 2018 10:29:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Sep 2018 10:29:20 +0900    

The activation and deactivation of commit timestamp tracking has not  
been handled consistently for a primary or standbys at recovery.  The  
facility can be activated at three different moments of recovery:  
- The beginning, where a primary would use the GUC value for the  
decision-making, and where a standby relies on the contents of the  
control file.  
- When replaying a XLOG_PARAMETER_CHANGE record at redo.  
- The end, where both primary and standby rely on the GUC value.  
  
Using the GUC value for a primary at the beginning of recovery causes  
problems with commit timestamp access when doing crash recovery.  
Particularly, when replaying transaction commits, it could be possible  
that an attempt to read commit timestamps is done for a transaction  
which committed at a moment when track_commit_timestamp was disabled.  
  
A test case is added to reproduce the failure.  The test works down to  
v11 as it takes advantage of transaction commits within procedures.  
  
Reported-by: Hailong Li  
Author: Masahiko Sawasa, Michael Paquier  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/11224478-a782-203b-1f17-e4797b39bdf0@qunar.com  
Backpatch-through: 9.5, where commit timestamps have been introduced.  

commit   : 2886a8f7045411c8a1607cf3b01f3856cb475f9e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Sep 2018 17:55:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 25 Sep 2018 17:55:22 -0300    

The documented shortcoming was actually fixed in 4c728f3829  
so the comment is not true anymore.  

commit   : e63441c3f5ca4a3cdb47f9c7fed9e61dde17b60d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 25 Sep 2018 12:54:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 25 Sep 2018 12:54:29 -0700    

Previously, when using parallel query, EXPLAIN (ANALYZE)'s JIT  
compilation timings did not include the overhead from doing so on the  
workers.  Fix that.  
  
We do so by simply aggregating the cost of doing JIT compilation on  
workers and the leader together. Arguably that's not quite accurate,  
because the total time spend doing so is spent in parallel - but it's  
hard to do much better.  For additional detail, when VERBOSE is  
specified, the stats for workers are displayed separately.  
  
Author: Amit Khandekar and Andres Freund  
Discussion: https://postgr.es/m/CAJ3gD9eLrz51RK_gTkod+71iDcjpB_N8eC6vU2AW-VicsAERpQ@mail.gmail.com  
Backpatch: 11-  

commit   : 9590f7d6c66321214926e13558c42f0099737ce4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Sep 2018 13:23:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Sep 2018 13:23:29 -0400    

Apple's latest rearrangements of the system-supplied headers have broken  
building of PL/Perl and PL/Tcl.  The only practical way to fix PL/Tcl is to  
start using the "-isysroot" compiler flag to point to SDK-supplied headers,  
as Apple expects.  We must also start distinguishing where to find Perl's  
headers from where to find its shared library; but that seems like good  
cleanup anyway.  
  
Extensions that formerly did something like -I$(perl_archlibexp)/CORE  
should now do -I$(perl_includedir)/CORE instead.  perl_archlibexp  
is still the place to look for libperl.so, though.  
  
If for some reason you don't like the default -isysroot setting, you can  
override that by setting PG_SYSROOT in configure's arguments.  I don't  
currently think people would need to do so, unless maybe for cross-version  
build purposes.  
  
In addition, teach configure where to find tclConfig.sh.  Our traditional  
method of searching $auto_path hasn't worked for the last couple of macOS  
releases, and it now seems clear that Apple's not going to change that.  
The workaround of manually specifying --with-tclconfig was annoying  
already, but Mojave's made it a lot more so because the sysroot path now  
has to be included as well.  Let's just wire the knowledge into configure  
instead.  To avoid breaking builds against non-default Tcl installations  
(e.g. MacPorts) wherein the $auto_path method probably still works,  
arrange to try the additional case only after all else has failed.  
  
Back-patch to all supported versions, since at least the buildfarm  
cares about that.  The changes are set up to not do anything on macOS  
releases that are old enough to not have functional sysroot trees.  

commit   : 1f50394119642f1a0e4a207ca57c27a97bfbc8c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 11:05:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 11:05:13 +0900    

96e1cb4 has added support for --no-publications in pg_dump, pg_dumpall  
and pg_restore, but forgot the fact that publication tables also need to  
be ignored when this option is used.  
  
Author: Gilles Darold  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/3f48e812-b0fa-388e-2043-9a176bdee27e@dalibo.com  
Backpatch-through: 10, where publications have been added.  

commit   : a3bb831efebf846ea1745b5cbe7ba2597bf33029    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 09:56:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Sep 2018 09:56:41 +0900    

Commit 25fff40 has granted execute permission of the function  
pg_stat_statements_reset() to default role "pg_read_all_stats", but this  
role is meant to read statistics, and not to reset them.  The  
permissions on this function are revoked from "pg_read_all_stats".  The  
version of pg_stat_statements is bumped up in consequence.  
  
Author: Haribabu Kommi  
Reviewed-by: Michael Paquier, Amit Kapila  
Discussion: https://postgr.es/m/CAJrrPGf5fCnKqXObpwGN9nMyD--tzOf-7LFCJiz59Z1wJ5qj9A@mail.gmail.com  

commit   : e5b2bd091aa4884f8f68e2d55c851e9ebd2d8c11    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:40:57 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:40:57 -0700    

Due to my (Andres') omission auto_explain did not include information  
about JIT compilation. Fix that.  
  
Author: Lukas Fittl  
Discussion:  
https://postgr.es/m/CAP53PkzgSyoTCau0-5FNaM484B=uO8nLzma7L1ncWLb1=oVJQA@mail.gmail.com  
Backpatch: 11-, where JIT compilation was introduced  

commit   : 6859bd2632d80e21d25830ac60bbb48bf12f6d46    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:27:08 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 24 Sep 2018 13:27:08 -0700    

A discussion about also reporting JIT compilation overhead on workers  
brought unhappiness with the verbosity of the current explain format  
to light.  Make the text format more dense, and restructure the  
structured output to mirror that more closely.  
  
As we're re-jiggering the output format anyway: The denser format  
allows us to report all flags for JIT compilation (now also reporting  
PGJIT_EXPR and PGJIT_DEFORM), and report the total time in addition to  
the individual times.  
  
Per complaint from Tom Lane.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/27812.1537221015@sss.pgh.pa.us  
Backpatch: 11-, where JIT compilation was introduced  

commit   : 9625ab79245b5b91162ede9d1b4d8b4be823c21c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 24 Sep 2018 16:11:24 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 24 Sep 2018 16:11:24 -0400    

Ensure that triggers get properly filled in tuples for the OLD value.  
Also fix the logic of detecting missing null values. The previous logic  
failed to detect a missing null column before the first missing column  
with a default. Fixing this has simplified the logic a bit.  
  
Regression tests are added to test changes. This should ensure better  
coverage of expand_tuple().  
  
Original bug reports, and some code and test scripts from Tomas Vondra  
  
Backpatch to release 11.  

commit   : bfdd02f88b9678dea0e0ba5866ee772f3aa55cba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Sep 2018 11:30:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Sep 2018 11:30:51 -0400    

array_out overestimated the space needed for its output, possibly by  
a very substantial amount if the array is multi-dimensional, because  
of wrong order of operations in the loop that counts the number of  
curly-brace pairs needed.  While the output string is normally  
short-lived, this could still cause problems in extreme cases.  
  
An additional minor error was that it counted one more delimiter than  
is actually needed.  
  
Repair those errors, add an Assert that the space is now correctly  
calculated, and make some minor improvements in the comments.  
  
I also failed to resist the temptation to get rid of an integer  
modulus operation per array element; a simple comparison is sufficient.  
  
This bug dates clear back to Berkeley days, so back-patch to all  
supported versions.  
  
Keiichi Hirobe, minor additional work by me  
  
Discussion: https://postgr.es/m/CAH=EFxE9W0tRvQkixR2XJRRCToUYUEDkJZk6tnADXugPBRdcdg@mail.gmail.com  

commit   : 89f2b64da370e7b0737760e3282f096591d6518f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Sep 2018 22:56:39 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Sep 2018 22:56:39 -0700    

This removes a difference between the standard IsUnderPostmaster  
execution environment and that of --boot and --single.  In a stand-alone  
backend, "SELECT random()" always started at the same seed.  
  
On a system capable of using posix shared memory, initdb could still  
conclude "selecting dynamic shared memory implementation ... sysv".  
Crashed --boot or --single postgres processes orphaned shared memory  
objects having names that collided with the not-actually-random names  
that initdb probed.  The sysv fallback appeared after ten crashes of  
--boot or --single postgres.  Since --boot and --single are rare in  
production use, systems used for PostgreSQL development are the  
principal candidate to notice this symptom.  
  
Back-patch to 9.3 (all supported versions).  PostgreSQL 9.4 introduced  
dynamic shared memory, but 9.3 does share the "SELECT random()" problem.  
  
Reviewed by Tom Lane and Kyotaro HORIGUCHI.  
  
Discussion: https://postgr.es/m/20180915221546.GA3159382@rfd.leadboat.com  

commit   : b1356f18b70e566da5acd9544632db7b196b3220    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 18:34:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 18:34:18 -0400    

This isn't terribly safe, and making it so doesn't seem like a small  
project, so for the moment just warn against it.  
  
Discussion: https://postgr.es/m/13624.1535486019@sss.pgh.pa.us  

commit   : fe30cd25ec82bdc9bb9e12d3b52adadc08bedc8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 16:05:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Sep 2018 16:05:45 -0400    

In a case where we have multiple relation-scan nodes in a cursor plan,  
such as a scan of an inheritance tree, it's possible to fetch from a  
given scan node, then rewind the cursor and fetch some row from an  
earlier scan node.  In such a case, execCurrent.c mistakenly thought  
that the later scan node was still active, because ExecReScan hadn't  
done anything to make it look not-active.  We'd get some sort of  
failure in the case of a SeqScan node, because the node's scan tuple  
slot would be pointing at a HeapTuple whose t_self gets reset to  
invalid by heapam.c.  But it seems possible that for other relation  
scan node types we'd actually return a valid tuple TID to the caller,  
resulting in updating or deleting a tuple that shouldn't have been  
considered current.  To fix, forcibly clear the ScanTupleSlot in  
ExecScanReScan.  
  
Another issue here, which seems only latent at the moment but could  
easily become a live bug in future, is that rewinding a cursor does  
not necessarily lead to *immediately* applying ExecReScan to every  
scan-level node in the plan tree.  Upper-level nodes will think that  
they can postpone that call if their child node is already marked  
with chgParam flags.  I don't see a way for that to happen today in  
a plan tree that's simple enough for execCurrent.c's search_plan_tree  
to understand, but that's one heck of a fragile assumption.  So, add  
some logic in search_plan_tree to detect chgParam flags being set on  
nodes that it descended to/through, and assume that that means we  
should consider lower scan nodes to be logically reset even if their  
ReScan call hasn't actually happened yet.  
  
Per bug #15395 from Matvey Arye.  This has been broken for a long time,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/153764171023.14986.280404050547008575@wrigleys.postgresql.org  

commit   : 7f203d60f413007a654a0f9b7763ef986150ce95    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Sep 2018 19:55:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Sep 2018 19:55:07 -0400    

standard_conforming_strings defaulted to 'on' in PG 9.1.  
bytea_output defaulted to 'hex' in PG 9.0.  
  
Reported-by: André Hänsel  
  
Discussion: https://postgr.es/m/12e601d447ac$345994a0$9d0cbde0$@webkr.de  
  
Backpatch-through: 9.3  

commit   : 45a2d45f4ff2e2f1524e7eb3aca9243895eefa8a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Sep 2018 15:58:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Sep 2018 15:58:37 -0400    

You can't use "FOR TABLE" as a single Matches argument, because readline  
will consider that input to be two words not one.  It's necessary to make  
the pattern contain two arguments.  
  
The case accidentally worked anyway because the words_after_create  
test fired ... but only for the first such table name.  
  
Noted by Edmund Horner, though this isn't exactly his proposed fix.  
Backpatch to v10 where the faulty code came in.  
  
Discussion: https://postgr.es/m/CAMyN-kDe=gBmHgxWwUUaXuwK+p+7g1vChR7foPHRDLE592nJPQ@mail.gmail.com  

commit   : ec7b27675dcc39e81555260a5e33c5aa0fb2bcd2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 22 Sep 2018 00:40:13 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 22 Sep 2018 00:40:13 +1200    

Takeshi Ideriha complained that there is a mixture of Size and size_t  
in dsa.c and corresponding header.  Let's use size_t.  Back-patch to 10  
where dsa.c landed, to make future back-patching easy.  
  
Discussion: https://postgr.es/m/4E72940DA2BF16479384A86D54D0988A6F19ABD9%40G01JPEXMBKW04  

commit   : 3d4b143dc7fd9d060e9f11ac6c17620f58cfc33d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Sep 2018 15:09:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 21 Sep 2018 15:09:40 +0900    

This can happen for CREATE TABLE and ALTER TABLE, so a mention is added  
to both of them in the concerned subsections.  
  
Author: Adrien Nayrat  
Discussion: https://postgr.es/m/c4e8af11-1dfc-766a-c953-76979b9fcdaa@anayrat.info  

commit   : 84f14fb788523d5175fc9b5a11c36853a3697d32    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 14:18:43 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 14:18:43 -0700    

As clang currently doesn't support -fexcess-precision=standard,  
compiling x86-32 code with SSE2 disabled, can lead to problems with  
floating point overflow checks and the like.  
  
This issue was noticed because clang, on at least some BSDs, defaults  
to i386 compatibility, whereas it defaults to pentium4 on Linux.  Our  
forced usage of __builtin_isinf() lead to some overflow checks not  
triggering when compiling for i386, e.g. when the result of the  
calculation didn't overflow in 80bit registers, but did so in 64bit.  
  
While we could just fall back to a non-builtin isinf, it seems likely  
that the use of 80bit registers leads to other problems (which is why  
we force the flag for GCC already).  Therefore error out when  
detecting clang in that situation.  
  
Reported-By: Victor Wagner  
Analyzed-By: Andrew Gierth and Andres Freund  
Author: Andres Freund  
Discussion: https://postgr.es/m/20180905005130.ewk4xcs5dgyzcy45@alap3.anarazel.de  
Backpatch: 9.3-, all supported versions are affected  

commit   : 8ffc3be10f86af74d1341ba886237a330e47485f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 15:52:39 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 15:52:39 +1200    

If a segment has been freed by dsa.c because it is entirely empty, other  
backends must make sure to unmap it before following links to new  
segments that might happen to have the same index number, or they could  
finish up looking at a defunct segment and then corrupt the segment_bins  
lists.  The correct protocol requires checking freed_segment_counter  
after acquiring the area lock and before resolving any index number to a  
segment.  Add the missing checks and an assertion.  
  
Back-patch to 10, where dsa.c first arrived.  
  
Author: Thomas Munro  
Reported-by: Tomas Vondra  
Discussion: https://postgr.es/m/CAEepm%3D0thg%2Bja5zGVa7jBy-uqyHrTqTm8HGhEOtMmigGrAqTbw%40mail.gmail.com  

commit   : 9d178fb928040f1a5ab5b566f1ec76d7ac554587    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 14:02:56 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 20 Sep 2018 14:02:56 +1200    

Several users of extensions complained of crashes in parallel workers  
that turned out to be due to syscache access from their _PG_init()  
functions.  Reorder the initialization of parallel workers so that  
libraries are restored after the caches are initialized, and inside a  
transaction.  
  
This was reported in bug #15350 and elsewhere.  We don't consider it  
to be a bug: extensions shouldn't do that, because then they can't be  
used in shared_preload_libraries.  However, it's a fairly obscure  
hazard and these extensions worked in practice before parallel query  
came along.  So let's make it work.  Later commits might add a warning  
message and eventually an error.  
  
Back-patch to 9.6, where parallel query landed.  
  
Author: Thomas Munro  
Reviewed-by: Amit Kapila  
Reported-by: Kieran McCusker, Jimmy  
Discussion: https://postgr.es/m/153512195228.1489.8545997741965926448%40wrigleys.postgresql.org  

commit   : 6449616419c59c3223b3c4f731cefa3d77fac567    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 17:06:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 17:06:40 -0400    

No periods at the ends of primary error messages, please.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/43E004C0-18C6-42B4-A313-003B43EB0571@yesql.se  

commit   : c84f83975eb48d19f712b2b4d3c788c018906ed2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 12:43:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2018 12:43:51 -0400    

Commit 37c54863c removed the code in StandbyAcquireAccessExclusiveLock  
that checked the return value of LockAcquireExtended.  That created a  
bug, because it's still passing reportMemoryError = false to  
LockAcquireExtended, meaning that LOCKACQUIRE_NOT_AVAIL will be returned  
if we're out of shared memory for the lock table.  
  
In such a situation, the startup process would believe it had acquired an  
exclusive lock even though it hadn't, with potentially dire consequences.  
  
To fix, just drop the use of reportMemoryError = false, which allows us  
to simplify the call into a plain LockAcquire().  It's unclear that the  
locktable-full situation arises often enough that it's worth having a  
better recovery method than crash-and-restart.  (I strongly suspect that  
the only reason the code path existed at all was that it was relatively  
simple to do in the pre-37c54863c implementation.  But now it's not.)  
  
LockAcquireExtended's reportMemoryError parameter is now dead code and  
could be removed.  I refrained from doing so, however, because there  
was some interest in resurrecting the behavior if we do get reports of  
locktable-full failures in the field.  Also, it seems unwise to remove  
the parameter concurrently with shipping commit f868a8143, which added a  
parameter; if there are any third-party callers of LockAcquireExtended,  
we want them to get a wrong-number-of-parameters compile error rather  
than a possibly-silent misinterpretation of its last parameter.  
  
Back-patch to 9.6 where the bug was introduced.  
  
Discussion: https://postgr.es/m/6202.1536359835@sss.pgh.pa.us  

commit   : df8b5f3eb8a7c477156d0ad9d83e7297912cfe79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 17:28:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 17:28:27 -0400    

This reverts commit f02259fe93e75d5443a2fabe2f2f38b81924ab36, in the  
v11 branch only.  
  
The hack this required in initdb.c should probably have clued us that it  
wasn't really ready, but we didn't get the hint.  Subsequent developments  
have made clear that it affected text-vs-binary behavior in a lot of  
places, and there's no reason to think that any of those behavioral changes  
are desirable.  There's no time to fix this before 11beta4, so just revert  
for the moment.  We can keep working on this in HEAD, and maybe reconsider  
a back-patch once we're satisfied things are stable.  
  
(I take the blame for this fiasco, having encouraged Michael to back-patch  
a change at the last possible moment before beta wrap.)  

commit   : 5c07d6497d8e694e5de5a78c1e3f74e2b9790c48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 13:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2018 13:02:27 -0400    

The system expects TABLEFUNC RTEs to have coltypes, coltypmods, and  
colcollations lists, but outfuncs doesn't dump them and readfuncs doesn't  
restore them.  This doesn't cause obvious failures, because the only things  
that look at those fields are expandRTE() and get_rte_attribute_type(),  
which are mostly used during parse analysis, before anything would've  
passed the parsetree through outfuncs/readfuncs.  But expandRTE() is used  
in build_physical_tlist(), which means that that function will return a  
wrong answer for a TABLEFUNC RTE that came from a view.  Very accidentally,  
this doesn't cause serious problems, because what it will return is NIL  
which callers will interpret as "couldn't build a physical tlist because  
of dropped columns".  So you still get a plan that works, though it's  
marginally less efficient than it could be.  There are also some other  
expandRTE() calls associated with transformation of whole-row Vars in  
the planner.  I have been unable to exhibit misbehavior from that, and  
it may be unreachable in any case that anyone would care about ... but  
I'm not entirely convinced, so this seems like something we should back-  
patch a fix for.  Fortunately, we can fix it without forcing a change  
of stored rules and a catversion bump, because we can just copy these  
lists from the subsidiary TableFunc object.  
  
readfuncs.c was also missing support for NamedTuplestoreScan plan nodes.  
This accidentally fails to break parallel query because a query using  
a named tuplestore would never be considered parallel-safe anyway.  
However, project policy since parallel query came in is that all plan  
node types should have outfuncs/readfuncs support, so this is clearly  
an oversight that should be repaired.  
  
Noted while fooling around with a patch to test outfuncs/readfuncs more  
thoroughly.  That exposed some other issues too, but these are the only  
ones that seem worth back-patching.  
  
Back-patch to v10 where both of these features came in.  
  
Discussion: https://postgr.es/m/17114.1537138992@sss.pgh.pa.us  

commit   : 63efab4ca139ab18095b8e095d5708d5566fc9e2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Sep 2018 22:56:36 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Sep 2018 22:56:36 +1200    

Chris Travers reported that the startup process can repeatedly try to  
cancel a backend that is in a posix_fallocate()/EINTR loop and cause it  
to loop forever.  Teach the retry loop to give up if an interrupt is  
pending.  Don't actually check for interrupts in that loop though,  
because a non-local exit would skip some clean-up code in the caller.  
  
Back-patch to 9.4 where DSM was added (and posix_fallocate() was later  
back-patched).  
  
Author: Chris Travers  
Reviewed-by: Ildar Musin, Murat Kabilov, Oleksii Kliukin  
Tested-by: Oleksii Kliukin  
Discussion: https://postgr.es/m/CAN-RpxB-oeZve_J3SM_6%3DHXPmvEG%3DHX%2B9V9pi8g2YR7YW0rBBg%40mail.gmail.com  

commit   : 3d65e406d1ea82060ad13a7bc41178ed22c599d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 18:43:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 18:43:41 -0400    

commit   : 486cfb3b8ce6e94eaad48038acff51064c070ccb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 13:16:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 13:16:32 -0400    

The original coding for XMLTABLE thought it could represent a default  
namespace by a T_String Value node with a null string pointer.  That's  
not okay, though; in particular outfuncs.c/readfuncs.c are not on board  
with such a representation, meaning you'll get a null pointer crash  
if you try to store a view or rule containing this construct.  
  
To fix, change the parsetree representation so that we have a NULL  
list element, instead of a bogus Value node.  
  
This isn't really a functional limitation since default XML namespaces  
aren't yet implemented in the executor; you'd just get "DEFAULT  
namespace is not supported" anyway.  But crashes are not nice, so  
back-patch to v10 where this syntax was added.  Ordinarily we'd consider  
a parsetree representation change to be un-backpatchable; but since  
existing releases would crash on the way to storing such constructs,  
there can't be any existing views/rules to be incompatible with.  
  
Per report from Andrey Lepikhov.  
  
Discussion: https://postgr.es/m/3690074f-abd2-56a9-144a-aa5545d7a291@postgrespro.ru  

commit   : d45f157e8b07aee455df0bcc76fdf4e9963c0200    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 12:11:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2018 12:11:43 -0400    

Our general practice in frontend code is to accept input with either  
Unix-style newlines (\n) or DOS-style (\r\n).  pgbench was mostly down  
with that, but its rule for line continuations (backslash-newline) was  
not.  This had been masked on Windows buildfarm machines before commit  
0ba06e0bf by use of Windows text mode to read files.  We could have fixed  
it by forcing text mode again, but it's better to fix the parsing code  
so that Windows-style text files on Unix systems don't cause problems.  
  
Back-patch to v10 where pgbench grew line continuations.  
  
Discussion: https://postgr.es/m/17194.1537191697@sss.pgh.pa.us  

commit   : f02259fe93e75d5443a2fabe2f2f38b81924ab36    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Sep 2018 20:38:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Sep 2018 20:38:42 +0900    

PostgreSQL uses a custom wrapper for open() and fopen() which is  
concurrent-safe, allowing multiple processes to open and work on the  
same file.  This has a couple of advantages:  
- pg_test_fsync does not handle O_DSYNC correctly otherwise, leading to  
false claims that disks are unsafe.  
- TAP tests can run into race conditions when a postmaster and pg_ctl  
open postmaster.pid, fixing some random failures in the buildfam.  
  
pg_upgrade is one frontend tool using workarounds to bypass file locking  
issues with the log files it generates, however the interactions with  
pg_ctl are proving to be tedious to get rid of, so this is left for  
later.  
  
Author: Laurenz Albe  
Reviewed-by: Michael Paquier, Kuntal Ghosh  
Discussion: https://postgr.es/m/1527846213.2475.31.camel@cybertec.at  
Discussion: https://postgr.es/m/16922.1520722108@sss.pgh.pa.us  

commit   : bcbd1590279c1dfc3e6756a09166943437071bd2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 17 Sep 2018 08:40:36 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 17 Sep 2018 08:40:36 +0200    

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

commit   : 05ae1bafa540e7eeba6faa7fd217a2997021c214    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Sep 2018 22:06:42 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Sep 2018 22:06:42 +0200    

This contains all individuals mentioned in the commit messages during  
PostgreSQL 11 development.  
  
current through 7a2f70f0e5e83871d091ee479abea4b8f850dd29  

commit   : f1ca5a654d5db32c2af8b28b7fbca38bbb793f56    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 16 Sep 2018 18:46:45 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 16 Sep 2018 18:46:45 +0100    

Neither plperl nor plpython installed sufficient header files to  
permit transform modules to be built out-of-tree using PGXS. Fix that  
by installing all plperl and plpython header files (other than those  
with special purposes such as generated data tables), and also install  
plpython's special .mk file for mangling regression tests.  
  
(This commit does not fix the windows install, which does not  
currently install _any_ plperl or plpython headers.)  
  
Also fix the existing transform modules for hstore and ltree so that  
their cross-module #include directives work as anticipated by commit  
df163230b9 et seq. This allows them to serve as working examples of  
how to reference other modules when doing separate out-of-tree builds.  
  
Discussion: https://postgr.es/m/87o9ej8bgl.fsf%40news-spur.riddles.org.uk  

commit   : 0ca27ea66a18cbf9b9bc69443df15a637f26b9b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Sep 2018 13:02:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Sep 2018 13:02:47 -0400    

I noticed while poking at a report from Andrey Lepikhov that the  
recent addition of RawStmt nodes at the top of raw parse trees  
makes it impossible to print any raw parse trees whatsoever,  
because outfuncs.c doesn't know RawStmt and hence fails to descend  
into it.  
  
While we generally lack outfuncs.c support for utility statements,  
there is reasonably complete support for what you can find in a  
raw SELECT statement.  It was not my intention to make that all  
dead code ... so let's add support for RawStmt.  
  
Back-patch to v10 where RawStmt appeared.  

commit   : 7a2f70f0e5e83871d091ee479abea4b8f850dd29    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 16 Sep 2018 11:35:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 16 Sep 2018 11:35:34 -0400    

The previous text was overly complex.  
  
Backpatch-through: 11  

commit   : 0fdadfb0192935e0f8bec7fa5ec9dbb470d6d587    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 17:24:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 17:24:35 -0400    

Per discussion, JIT isn't quite mature enough to ship enabled-by-default.  
  
I failed to resist the temptation to do a bunch of copy-editing on the  
related documentation.  Also, clean up some inconsistencies in which  
section of config.sgml the JIT GUCs are documented in vs. what guc.c  
and postgresql.config.sample had.  
  
Discussion: https://postgr.es/m/20180914222657.mw25esrzbcnu6qlu@alap3.anarazel.de  

commit   : f13e2d1cec9b786405d649c72a4aa29fadcea617    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 13:42:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Sep 2018 13:42:34 -0400    

The EvalPlanQual machinery assumes that any initplans (that is,  
uncorrelated sub-selects) used during an EPQ recheck would have already  
been evaluated during the main query; this is implicit in the fact that  
execPlan pointers are not copied into the EPQ estate's es_param_exec_vals.  
But it's possible for that assumption to fail, if the initplan is only  
reached conditionally.  For example, a sub-select inside a CASE expression  
could be reached during a recheck when it had not been previously, if the  
CASE test depends on a column that was just updated.  
  
This bug is old, appearing to date back to my rewrite of EvalPlanQual in  
commit 9f2ee8f28, but was not detected until Kyle Samson reported a case.  
  
To fix, force all not-yet-evaluated initplans used within the EPQ plan  
subtree to be evaluated at the start of the recheck, before entering the  
EPQ environment.  This could be inefficient, if such an initplan is  
expensive and goes unused again during the recheck --- but that's piling  
one layer of improbability atop another.  It doesn't seem worth adding  
more complexity to prevent that, at least not in the back branches.  
  
It was convenient to use the new-in-v11 ExecEvalParamExecParams function  
to implement this, but I didn't like either its name or the specifics of  
its API, so revise that.  
  
Back-patch all the way.  Rather than rewrite the patch to avoid depending  
on bms_next_member() in the oldest branches, I chose to back-patch that  
function into 9.4 and 9.3.  (This isn't the first time back-patches have  
needed that, and it exhausted my patience.)  I also chose to back-patch  
some test cases added by commits 71404af2a and 342a1ffa2 into 9.4 and 9.3,  
so that the 9.x versions of eval-plan-qual.spec are all the same.  
  
Andrew Gierth diagnosed the problem and contributed the added test cases,  
though the actual code changes are by me.  
  
Discussion: https://postgr.es/m/A033A40A-B234-4324-BE37-272279F7B627@tripadvisor.com  

commit   : 444455c2d9094c70f42706184064a9729906253e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 19:06:57 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 19:06:57 -0300    

There's no reason to expose the struct definition, so don't.  
  
Author: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Discussion: https://postgr.es/m/d3fa24c1-bc65-7133-81df-6474387ccc4f@lab.ntt.co.jp  

commit   : 6009bad9134782babfc45c6bae6cfbca7f4899d0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 13:57:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Sep 2018 13:57:30 -0300    

When ALTER TABLE ... SET DATA TYPE affects a column referenced by  
constraints and indexes, it drop those constraints and indexes and  
recreates them afterwards, so that the definitions match the new data  
type.  The original code did this by dropping one object at a time  
(commit 077db40fa1f3 of May 2004), which worked fine because the  
dependencies between the objects were pretty straightforward, and  
ordering the objects in a specific way was enough to make this work.  
However, when there are foreign key constraints in partitioned tables,  
the dependencies are no longer so straightforward, and we were getting  
errors when attempted:  
  ERROR:  cache lookup failed for constraint 16398  
  
This can be fixed by doing all the drops in one pass instead, using  
performMultipleDeletions (introduced by df18c51f2955 of Aug 2006).  With  
this change we can also remove the code to carefully order the list of  
objects to be deleted.  
  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/CAKcux6nWS_m+s=1Udk_U9B+QY7pA-Ac58qR5BdUfOyrwnWHDew@mail.gmail.com  

commit   : 830d7565902f8d1da5f07259982a6a54dc65e40d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 14 Sep 2018 09:51:47 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 14 Sep 2018 09:51:47 +0530    

Allowing sub-select containing LIMIT/OFFSET in workers can lead to  
inconsistent results at the top-level as there is no guarantee that the  
row order will be fully deterministic.  The fix is to prohibit pushing  
LIMIT/OFFSET within sub-selects to workers.  
  
Reported-by: Andrew Fletcher  
Bug: 15324  
Author: Amit Kapila  
Reviewed-by: Dilip Kumar  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/153417684333.10284.11356259990921828616@wrigleys.postgresql.org  

commit   : a2afcdab8a1a90245cab3ed4b2d4bd0812d4955a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Sep 2018 23:35:43 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Sep 2018 23:35:43 +0200    

Fix one untranslatable string concatenation in pg_rewind.  
  
Fix one message in pg_verify_checksums to use a style use elsewhere  
and avoid plural issues.  
  
Fix one gratuitous abbreviation in psql.  

commit   : 99ba795d982efe2305d94573f2f4594bedaf6eab    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 10:41:39 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Sep 2018 10:41:39 -0700    

Before this commit LLVM 7 was supported, but only if one explicitly  
provided LLVM_CONFIG= and CLANG= paths.  As LLVM 7 is the first  
version that includes our upstreamed debugging and profiling features,  
and as debian is planning to default to 7 due to wider architecture  
support, it seems good to support auto-detecting that version.  
  
Author: Christoph Berg  
Discussion: https://postgr.es/m/20180912124517.GD24584@msg.df7cb.de  
Backpatch: 11, where LLVM was introduced  

commit   : ff4220ead2c833fb36e9709ab2568c6ac43e9d3b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 13 Sep 2018 15:38:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 13 Sep 2018 15:38:15 +0530    

XLogInsert fails to attach a required FPI to the first record after  
full_page_writes is turned on by the last checkpoint.  This bug got  
introduced in 9.5 due to code rearrangement in commits 2c03216d83 and  
2076db2aea.  Fix it by ensuring that XLogInsertRecord performs a  
recomputation when the given record is generated with FPW as off but  
found that the flag has been turned on while actually inserting the  
record.  
  
Reported-by: Kyotaro Horiguchi  
Author: Kyotaro Horiguchi  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.5 where this problem was introduced  
Discussion: https://postgr.es/m/20180420.151043.74298611.horiguchi.kyotaro@lab.ntt.co.jp  

commit   : 12368f5e83e70e015a7352f52115579c135e82e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Sep 2018 15:24:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Sep 2018 15:24:56 -0400    

* Include partitioned tables in what's offered after ANALYZE.  
  
* Include toast_tuple_target in what's offered after ALTER TABLE ... SET|RESET.  
  
* Include HASH in what's offered after PARTITION BY.  
  
This is extracted from a larger patch; these bits seem like  
uncontroversial bug fixes for v11 features, so back-patch them into v11.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20180529000623.GA21896@telsasoft.com  

commit   : f7d0343ead29cd3e44eccd1c8b7cc291b79209fe    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 12 Sep 2018 19:31:06 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 12 Sep 2018 19:31:06 +0100    

Commit c8ea87e4b introduced a temporary conversion buffer for  
substrings extracted during regexp splits. Unfortunately the code that  
sized it was failing to ignore the effects of ignored degenerate  
regexp matches, so for regexp_split_* calls it could under-size the  
buffer in such cases.  
  
Fix, and add some regression test cases (though those will only catch  
the bug if run in a multibyte encoding).  
  
Backpatch to 9.3 as the faulty code was.  
  
Thanks to the PostGIS project, Regina Obe and Paul Ramsey for the  
report (via IRC) and assistance in analysis. Patch by me.  

commit   : b91ae36029df3db31a951ebda102ace8be5741ba    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 12 Sep 2018 14:33:15 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 12 Sep 2018 14:33:15 +0200    

When we removed the ecpg-specific versions, we also removed the  
"(PostgreSQL)" from the --version output, which we show in other  
programs.  
  
Reported-by: Ioseph Kim <pgsql-kr@postgresql.kr>  

commit   : 293010a68afd5b3a1f1e7621d5c89ba422c21d09    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 Sep 2018 17:01:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 11 Sep 2018 17:01:51 -0400    

Fixes for channel binding, SQL procedures, and pg_trgm.  
  
Backpatch-through: 11  

commit   : 224256f890c71b809c1a6b62b426fc8ceec7b0da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2018 16:32:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2018 16:32:12 -0400    

Up to now, get_const_expr() insisted on prefixing BIT and VARBIT  
literals with 'B'.  That's not really necessary, because we always  
append explicit-cast syntax to identify the constant's type.  
Moreover, it's subtly wrong for VARBIT, because the parser will  
interpret B'...' as '...'::"bit"; see make_const() which explicitly  
assigns type BITOID for a T_BitString literal.  So what had been  
a simple VARBIT literal is reconstructed as ('...'::"bit")::varbit,  
which is not the same thing, at least not before constant folding.  
This results in odd differences after dump/restore, as complained  
of by the patch submitter, and it could result in actual failures in  
partitioning or inheritance DDL operations (see commit 542320c2b,  
which repaired similar misbehaviors for some other data types).  
  
Fixing it is pretty easy: just remove the special case and let the  
default code path handle these types.  We could have kept the special  
case for BIT only, but there seems little point in that.  
  
Like the previous patch, I judge that back-patching this into stable  
branches wouldn't be a good idea.  However, it seems not quite too  
late for v11, so let's fix it there.  
  
Paul Guo, reviewed by Davy Machado and John Naylor, minor adjustments  
by me  
  
Discussion: https://postgr.es/m/CABQrizdTra=2JEqA6+Ms1D1k1Kqw+aiBBhC9TreuZRX2JzxLAA@mail.gmail.com  

commit   : e331d6712f0224160d2699591704ddcc3ef2d67b    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 11 Sep 2018 18:14:19 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 11 Sep 2018 18:14:19 +0100    

spgrescan would first reset traversalCxt, and then traverse a  
potentially non-empty stack containing pointers to traversalValues  
which had been allocated in those contexts, freeing them a second  
time. This bug originates in commit ccd6eb49a where traversalValue was  
introduced.  
  
Repair by traversing the stack before the context reset; this isn't  
ideal, since it means doing retail pfree in a context that's about to  
be reset, but the freeing of a stack entry is also done in other  
places in the code during the scan so it's not worth trying to  
refactor it further. Regression test added.  
  
Backpatch to 9.6 where the problem was introduced.  
  
Per bug #15378; analysis and patch by me, originally from a report on  
IRC by user velix; see also PostGIS ticket #4174; review by Alexander  
Korotkov.  
  
Discussion: https://postgr.es/m/153663176628.23136.11901365223750051490@wrigleys.postgresql.org  

commit   : e3aafe200125975022653eb3197bcf03f7744391    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Sep 2018 22:22:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Sep 2018 22:22:12 -0400    

These platforms are also subject to the mis-linking problem addressed  
in commit e3d77ea6b.  It's not clear whether we could solve it with  
a solution equivalent to GNU ld's version scripts, but -Bsymbolic  
appears to fix it, so let's use that.  
  
Like the previous commit, back-patch as far as v10.  
  
Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org  

commit   : 6395ac14d99e4a5d9ee1b83dcc382a368e50240c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2018 15:16:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2018 15:16:51 -0400    

On ELF-based platforms (and maybe others?) it's possible for a shared  
library, when dynamically loaded into the backend, to call the backend  
versions of src/port and src/common functions rather than the frontend  
versions that are actually linked into the shlib.  This is the cause  
of bug #15367 from Jeremy Evans, and is likely to lead to more problems  
in future; it's accidental that we've failed to notice any bad effects  
up to now.  
  
The recommended way to fix this on ELF-based platforms is to use a  
linker "version script" that makes the shlib's versions of the functions  
local.  (Apparently, -Bsymbolic would fix it as well, but with other  
side effects that we don't want.)  Doing so has the additional benefit  
that we can make sure the shlib only exposes the symbols that are meant  
to be part of its API, and not ones that are just for cross-file  
references within the shlib.  So we'd already been using a version  
script for libpq on popular platforms, but it's now apparent that it's  
necessary for correctness on every ELF-based platform.  
  
Hence, add appropriate logic to the openbsd, freebsd, and netbsd stanzas  
of Makefile.shlib; this is just a copy-and-paste from the linux stanza.  
There may be additional work to do if commit ed0cdf0e0 reveals that the  
problem exists elsewhere, but this is all that is known to be needed  
right now.  
  
Back-patch to v10 where SCRAM support came in.  The problem is ancient,  
but analysis suggests that there were no really severe consequences  
in older branches.  Hence, I won't take the risk of such a large change  
in the build process for older branches.  
  
In passing, remove a rather opaque comment about -Bsymbolic; I don't  
think it's very on-point about why we don't use that, if indeed that's  
what it's talking about at all.  
  
Patch by me; thanks to Andrew Gierth for helping to diagnose the problem,  
and for additional testing.  
  
Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org  

commit   : cc909ddbfb480928a781c21b1c142ccf1adb2fe5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 9 Sep 2018 21:19:29 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 9 Sep 2018 21:19:29 +0300    

ginRedoRecompress() replays actions over compressed segments of posting list  
in-place.  However, it might lead to write past pg_upper, because intermediate  
state during playing the changes can take more space than both original state  
and final state.  This commit fixes that by refuse from in-place modification.  
Instead page tail is copied once modification is started, and then it's used  
as the source of original segments.  Backpatch to 9.4 where posting list  
compression was introduced.  
  
Reported-by: Sivasubramanian Ramasubramanian  
Discussion: https://postgr.es/m/1536091151804.6588%40amazon.com  
Author: Alexander Korotkov based on patch from and ideas by Sivasubramanian Ramasubramanian  
Review: Sivasubramanian Ramasubramanian  
Backpatch-through: 9.4  

commit   : f7d745318b180634e8bb1734867caaf71b00b305    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 18:26:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 18:26:10 -0700    

Buildfarm member tern failed src/bin/pg_ctl/t/001_start_stop.pl when a  
check_mode_recursive() call overlapped a server's startup-time deletion  
of pg_stat/global.stat.  Just warn.  Also, include errno in the message.  
Back-patch to v11, where check_mode_recursive() first appeared.  

commit   : 475c1fb5a765da70a77f9f24454977a873d96dc4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 16:20:50 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Sep 2018 16:20:50 -0700    

Buildfarm members sungazer and tern revealed this deficit.  Back-patch  
to v10, like commit 4f10e7ea7b2231f453bb18b6e710ac333eaf121b, which  
introduced the test.  

commit   : 86d226ae5a3607b8bbde2487f821b8f8807da1c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Sep 2018 18:20:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Sep 2018 18:20:36 -0400    

Ensure that pg_saslprep() initializes its output argument to NULL in  
all failure paths, and then remove the redundant initialization that  
some (not all) of its callers did.  This does not fix any live bug,  
but it reduces the odds of future bugs of omission.  
  
Also add a comment about why the existing failure-path coding is  
adequate.  
  
Back-patch so as to keep the function's API consistent across branches,  
again to forestall future bug introduction.  
  
Patch by me, reviewed by Michael Paquier  
  
Discussion: https://postgr.es/m/16558.1536407783@sss.pgh.pa.us  

commit   : 825f10fbda7a5d8a48d187b8193160e5e44e4011    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 20:09:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 20:09:57 -0400    

This patch removes two sources of interference between nominally  
independent functions when one SPI-using function calls another,  
perhaps without knowing that it does so.  
  
Chapman Flack pointed out that xml.c's query_to_xml_internal() expects  
SPI_tuptable and SPI_processed to stay valid across datatype output  
function calls; but it's possible that such a call could involve  
re-entrant use of SPI.  It seems likely that there are similar hazards  
elsewhere, if not in the core code then in third-party SPI users.  
Previously SPI_finish() reset SPI's API globals to zeroes/nulls, which  
would typically make for a crash in such a situation.  Restoring them  
to the values they had at SPI_connect() seems like a considerably more  
useful behavior, and it still meets the design goal of not leaving any  
dangling pointers to tuple tables of the function being exited.  
  
Also, cause SPI_connect() to reset these variables to zeroes/nulls after  
saving them.  This prevents interference in the opposite direction: it's  
possible that a SPI-using function that's only ever been tested standalone  
contains assumptions that these variables start out as zeroes.  That was  
the case as long as you were the outermost SPI user, but not so much for  
an inner user.  Now it's consistent.  
  
Report and fix suggestion by Chapman Flack, actual patch by me.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/9fa25bef-2e4f-1c32-22a4-3ad0723c4a17@anastigmatix.net  

commit   : 90fd3bfd17070d3c2467a45204ede17b70a15387    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:13:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:13:29 -0400    

It's somewhat surprising that we got away with this before.  (Actually,  
since nobody tests this routinely AFAIK, it might've been broken for  
awhile.  But it's definitely broken in the wake of commit f868a8143.)  
It seems sufficient to limit the forced recursion to a small number  
of levels.  
  
Back-patch to all supported branches, like the preceding patch.  
  
Discussion: https://postgr.es/m/12259.1532117714@sss.pgh.pa.us  

commit   : 2569ca0dc8a28f0aa475c32ff122c439700f020a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:04:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2018 18:04:38 -0400    

LockRelationOid and sibling routines supposed that, if our session already  
holds the lock they were asked to acquire, they could skip calling  
AcceptInvalidationMessages on the grounds that we must have already read  
any remote sinval messages issued against the relation being locked.  
This is normally true, but there's a critical special case where it's not:  
processing inside AcceptInvalidationMessages might attempt to access system  
relations, resulting in a recursive call to acquire a relation lock.  
  
Hence, if the outer call had acquired that same system catalog lock, we'd  
fall through, despite the possibility that there's an as-yet-unread sinval  
message for that system catalog.  This could, for example, result in  
failure to access a system catalog or index that had just been processed  
by VACUUM FULL.  This is the explanation for buildfarm failures we've been  
seeing intermittently for the past three months.  The bug is far older  
than that, but commits a54e1f158 et al added a new recursion case within  
AcceptInvalidationMessages that is apparently easier to hit than any  
previous case.  
  
To fix this, we must not skip calling AcceptInvalidationMessages until  
we have *finished* a call to it since acquiring a relation lock, not  
merely acquired the lock.  (There's already adequate logic inside  
AcceptInvalidationMessages to deal with being called recursively.)  
Fortunately, we can implement that at trivial cost, by adding a flag  
to LOCALLOCK hashtable entries that tracks whether we know we have  
completed such a call.  
  
There is an API hazard added by this patch for external callers of  
LockAcquire: if anything is testing for LOCKACQUIRE_ALREADY_HELD,  
it might be fooled by the new return code LOCKACQUIRE_ALREADY_CLEAR  
into thinking the lock wasn't already held.  This should be a fail-soft  
condition, though, unless something very bizarre is being done in  
response to the test.  
  
Also, I added an additional output argument to LockAcquireExtended,  
assuming that that probably isn't called by any outside code given  
the very limited usefulness of its additional functionality.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/12259.1532117714@sss.pgh.pa.us  

commit   : 094ffd68460a8ba905df7b4eae4e9c690dc6e06f    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 7 Sep 2018 13:51:30 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Fri, 7 Sep 2018 13:51:30 +0100    

Commit be54b3777 failed on gmake 3.80 due to a chained conditional,  
which on closer examination could be removed entirely with some  
refactoring elsewhere for a net simplification and more robustness  
against empty expansions. Along the way, add some more comments.  
  
Also make explicit in the documentation and comments that built  
headers are not removed by 'make clean', since we don't typically want  
that for headers generated by a separate ./configure step, and it's  
much easier to add your own 'distclean' rule or use EXTRA_CLEAN than  
to try and override a deletion rule in pgxs.mk.  
  
Per buildfarm member prariedog and comments by Michael Paquier, though  
all the actual changes are my fault.  

commit   : 23aad181f44741c2061ce5caceb307774ac14fb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Sep 2018 10:49:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Sep 2018 10:49:45 -0400    

Since the fixes for CVE-2018-1058, we've advised people to schema-qualify  
function references in order to fix failures in code that executes under  
a minimal search_path setting.  However, that's insufficient to make the  
single-argument form of unaccent() work, because it looks up the "unaccent"  
text search dictionary using the search path.  
  
The most expedient answer seems to be to remove the search_path dependency  
by making it look in the same schema that the unaccent() function itself  
is declared in.  This will definitely work for the normal usage of this  
function with the unaccent dictionary provided by the extension.  
It's barely possible that there are people who were relying on the  
search-path-dependent behavior to select other dictionaries with the same  
name; but if there are any such people at all, they can still get that  
behavior by writing unaccent('unaccent', ...), or possibly  
unaccent('unaccent'::text::regdictionary, ...) if the lookup has to be  
postponed to runtime.  
  
Per complaint from Gunnlaugur Thor Briem.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CAPs+M8LCex6d=DeneofdsoJVijaG59m9V0ggbb3pOH7hZO4+cQ@mail.gmail.com  

commit   : 834bce0a5293424d127ab72440b9eacc8841051f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Sep 2018 10:07:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 6 Sep 2018 10:07:18 +0530    

The commit 620b49a1 changed the value of HASH_MAX_BITMAPS with the intent  
to allow many non-unique values in hash indexes without worrying to reach  
the limit of the number of overflow pages.  At that time, this didn't  
occur to us that it can overrun the block for smaller block sizes.  
  
Choose the value of HASH_MAX_BITMAPS based on BLCKSZ such that it gives  
the same answer as now for the cases where the overrun doesn't occur, and  
some other sufficiently-value for the cases where an overrun currently  
does occur.  This allows us not to change the behavior in any case that  
currently works, so there's really no reason for a HASH_VERSION bump.  
  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAA4eK1LtF4VmU4mx_+i72ff1MdNZ8XaJMGkt2HV8+uSWcn8t4A@mail.gmail.com  

commit   : 235526a20a2efb199c4138c5d793260ce37d7231    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 5 Sep 2018 22:01:21 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 5 Sep 2018 22:01:21 +0100    

Commit df163230b overlooked the case that an out-of-tree extension  
might need to build its header files (e.g. via ./configure). If it is  
also doing a VPATH build, the HEADERS_* rules in the original commit  
would then fail to find the files, since they would be looking only  
under $(srcdir) and not in the build directory.  
  
Fix by adding HEADERS_built and HEADERS_built_$(MODULE) which behave  
like DATA_built in that they look in the build dir rather than the  
source dir (and also make the files dependencies of the "all" target).  
  
No Windows support appears to be needed for this, since it is only  
relevant to out-of-tree builds (no support exists in Mkvcbuild.pm to  
build extension header files in any case).  

commit   : c1ea31147248842743c3ba931f71b5a4a218cb58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 14:29:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 14:29:58 -0400    

Oversight in 2fbdf1b38.  Per buildfarm.  

commit   : 337bf254ae81a3c8426504f3bee04cd6c5eb8a59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 13:47:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2018 13:47:16 -0400    

pg_get_object_address and pg_identify_object_as_address are supposed  
to be inverses, but they disagreed as to the names of the arguments  
representing the textual form of an object address.  Moreover, the  
documented argument names didn't agree with reality at all, either  
for these functions or pg_identify_object.  
  
In HEAD and v11, I think we can get away with renaming the input  
arguments of pg_get_object_address to match the outputs of  
pg_identify_object_as_address.  In theory that might break queries  
using named-argument notation to call pg_get_object_address, but  
it seems really unlikely that anybody is doing that, or that they'd  
have much trouble adjusting if they were.  In older branches, we'll  
just live with the lack of consistency.  
  
Aside from fixing the documentation of these functions to match reality,  
I couldn't resist the temptation to do some copy-editing.  
  
Per complaint from Jean-Pierre Pelletier.  Back-patch to 9.5 where these  
functions were introduced.  (Before v11, this is a documentation change  
only.)  
  
Discussion: https://postgr.es/m/CANGqjDnWH8wsTY_GzDUxbt4i=y-85SJreZin4Hm8uOqv1vzRQA@mail.gmail.com  

commit   : 52ab02d593e9d83c7bff8b6853aba59242ce967a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Sep 2018 14:36:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Sep 2018 14:36:13 -0300    

In the original code, we were storing the pg_inherits row for a  
partitioned table too early: enough that we had a hack for relcache to  
avoid falling flat on its face while reading such a partial entry.  If  
we finish the pg_class creation first and *then* store the pg_inherits  
entry, we don't need that hack.  
  
Also recognize that pg_class.relpartbound is not marked NOT NULL and  
therefore it's entirely possible to read null values, so having only  
Assert() protection isn't enough.  Change those to if/elog tests  
instead.  This qualifies as a robustness fix, so backpatch to pg11.  
  
In passing, remove one access that wasn't actually needed, and reword  
one message to be like all the others that check for the same thing.  
  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/20180903213916.hh6wasnrdg6xv2ud@alvherre.pgsql  

commit   : 838fd62cab520a5ae15fdab30d0f962070571bdb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Sep 2018 22:34:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Sep 2018 22:34:07 -0400    

The previous description was unclear.  Also add a third example, change  
use of time zone acronyms to more verbose descriptions, and add a  
mention that using 'time' with AT TIME ZONE uses the current time zone  
rules.  
  
Backpatch-through: 9.3  

commit   : fb466d7b5dbe73f318324cada80203522f46401f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Sep 2018 13:45:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Sep 2018 13:45:35 -0400    

It's been true for a long time that we expect names of table and domain  
constraints to be unique among the constraints of that table or domain.  
However, the enforcement of that has been pretty haphazard, and it missed  
some corner cases such as creating a CHECK constraint and then an index  
constraint of the same name (as per recent report from André Hänsel).  
Also, due to the lack of an actual unique index enforcing this, duplicates  
could be created through race conditions.  
  
Moreover, the code that searches pg_constraint has been quite inconsistent  
about how to handle duplicate names if one did occur: some places checked  
and threw errors if there was more than one match, while others just  
processed the first match they came to.  
  
To fix, create a unique index on (conrelid, contypid, conname).  Since  
either conrelid or contypid is zero, this will separately enforce  
uniqueness of constraint names among constraints of any one table and any  
one domain.  (If we ever implement SQL assertions, and put them into this  
catalog, more thought might be needed.  But it'd be at least as reasonable  
to put them into a new catalog; having overloaded this one catalog with  
two kinds of constraints was a mistake already IMO.)  This index can replace  
the existing non-unique index on conrelid, though we need to keep the one  
on contypid for query performance reasons.  
  
Having done that, we can simplify the logic in various places that either  
coped with duplicates or neglected to, as well as potentially improve  
lookup performance when searching for a constraint by name.  
  
Also, as per our usual practice, install a preliminary check so that you  
get something more friendly than a unique-index violation report in the  
case complained of by André.  And teach ChooseIndexName to avoid choosing  
autogenerated names that would draw such a failure.  
  
While it's not possible to make such a change in the back branches,  
it doesn't seem quite too late to put this into v11, so do so.  
  
Discussion: https://postgr.es/m/0c1001d4428f$0942b430$1bc81c90$@webkr.de  

commit   : 2ce253cf57b1c3f8100a31f30647449d0b88fe24    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 10:26:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 10:26:06 +0530    

Allowing window function calculation in workers leads to inconsistent  
results because if the input row ordering is not fully deterministic, the  
output of window functions might vary across workers.  The fix is to treat  
them as parallel-restricted.  
  
In the passing, improve the coding pattern in max_parallel_hazard_walker  
so that it has a chain of mutually-exclusive if ... else if ... else if  
... else if ... IsA tests.  
  
Reported-by: Marko Tiikkaja  
Bug: 15324  
Author: Amit Kapila  
Reviewed-by: Tom Lane  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CAL9smLAnfPJCDUUG4ckX2iznj53V7VSMsYefzZieN93YxTNOcw@mail.gmail.com  

commit   : 16e7bcfac57fc21dd2124b39132c58971e41448a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 08:33:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 4 Sep 2018 08:33:33 +0530    

On a split, we allocate a new splitpoint's worth of bucket pages wherein  
we initialize the last page with zeros which is fine, but we forgot to set  
the checksum for that last page.  
  
We decided to back-patch this fix till 10 because we don't have an easy  
way to test it in prior versions.  Another reason is that the hash-index  
code is changed heavily in 10, so it is not advisable to push the fix  
without testing it in prior versions.  
  
Author: Amit Kapila  
Reviewed-by: Yugo Nagata  
Backpatch-through: 10  
Discussion: https://postgr.es/m/5d03686d-727c-dbf8-0064-bf8b97ffe850@2ndquadrant.com  

commit   : bd47c4a9d4ec55e26e841754ce62c23ca9008e87    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 3 Sep 2018 12:58:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 3 Sep 2018 12:58:42 -0300    

This column was added in commit 8224de4f42cc ("Indexes with INCLUDE  
columns and their support in B-tree") to ease writing the ruleutils.c  
supporting code for that feature, but it turns out to be unnecessary --  
we can do the same thing with just one more syscache lookup.  
  
Even the documentation for the new column being removed in this commit  
is awkward.  
  
Discussion: https://postgr.es/m/20180902165018.33otxftp3olgtu4t@alvherre.pgsql  

commit   : 081cf78d12f17c97efc6199039bc83f059fffcf6    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 3 Sep 2018 02:10:24 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 3 Sep 2018 02:10:24 +0200    

When decoding a TRUNCATE record, the relids array was being allocated in  
the main ReorderBuffer memory context, but not released with the change  
resulting in a memory leak.  
  
The array was also ignored when serializing/deserializing the change,  
assuming all the information is stored in the change itself.  So when  
spilling the change to disk, we've only we have serialized only the  
pointer to the relids array.  Thanks to never releasing the array,  
the pointer however remained valid even after loading the change back  
to memory, preventing an actual crash.  
  
This fixes both the memory leak and (de)serialization.  The relids array  
is still allocated in the main ReorderBuffer memory context (none of the  
existing ones seems like a good match, and adding an extra context seems  
like an overkill).  The allocation is wrapped in a new ReorderBuffer API  
functions, to keep the details within reorderbuffer.c, just like the  
other ReorderBufferGet methods do.  
  
Author: Tomas Vondra  
Discussion: https://www.postgresql.org/message-id/flat/66175a41-9342-2845-652f-1bd4c3ee50aa%402ndquadrant.com  
Backpatch: 11, where decoding of TRUNCATE was introduced  

commit   : 680f89e5613cc859356152ae65597c78f0cea4dd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Sep 2018 12:40:38 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 2 Sep 2018 12:40:38 -0700    

At the beginning of recovery, information from replication slots is  
recovered from disk to memory.  In order to ensure the durability of the  
information, the status file as well as its parent directory are  
synced.  It happens that the sync on the parent directory was done  
directly using the status file path, which is logically incorrect, and  
the current code has been doing a sync on the same object twice in a  
row.  
  
Reported-by: Konstantin Knizhnik  
Diagnosed-by: Konstantin Knizhnik  
Author: Michael Paquier  
Discussion: https://postgr.es/m/9eb1a6d5-b66f-2640-598d-c5ea46b8f68a@postgrespro.ru  
Backpatch-through: 9.4-  

commit   : 3099eec7468f081d638be25475f2c5b43b7d1f88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 16:02:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 16:02:47 -0400    

This table claimed that JOHAB could be used as a server encoding, which  
was true originally but hasn't been true since 8.3.  It also lacked  
entries for EUC_JIS_2004 and SHIFT_JIS_2004.  
  
JOHAB problem noted by Lars Kanis, the others by me.  
  
Discussion: https://postgr.es/m/c0f514a1-b7a9-b9ea-1c02-c34aead56c06@greiz-reinsdorf.de  

commit   : f5c93cf92223534df862ab7d8c698f05d5b38485    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 15:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Sep 2018 15:27:13 -0400    

There's a project policy against using plain "char buf[BLCKSZ]" local  
or static variables as page buffers; preferred style is to palloc or  
malloc each buffer to ensure it is MAXALIGN'd.  However, that policy's  
been ignored in an increasing number of places.  We've apparently got  
away with it so far, probably because (a) relatively few people use  
platforms on which misalignment causes core dumps and/or (b) the  
variables chance to be sufficiently aligned anyway.  But this is not  
something to rely on.  Moreover, even if we don't get a core dump,  
we might be paying a lot of cycles for misaligned accesses.  
  
To fix, invent new union types PGAlignedBlock and PGAlignedXLogBlock  
that the compiler must allocate with sufficient alignment, and use  
those in place of plain char arrays.  
  
I used these types even for variables where there's no risk of a  
misaligned access, since ensuring proper alignment should make  
kernel data transfers faster.  I also changed some places where  
we had been palloc'ing short-lived buffers, for coding style  
uniformity and to save palloc/pfree overhead.  
  
Since this seems to be a live portability hazard (despite the lack  
of field reports), back-patch to all supported versions.  
  
Patch by me; thanks to Michael Paquier for review.  
  
Discussion: https://postgr.es/m/1535618100.1286.3.camel@credativ.de  

commit   : ee0ab275408f8fc10eedd7fb8c767cdbad0cb57b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 31 Aug 2018 22:59:58 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 31 Aug 2018 22:59:58 -0700    

Healthy clients of servers having poor I/O performance, such as  
buildfarm members hamster and tern, saw unexpected timeouts.  That  
disagreed with documentation.  This fix adds one gettimeofday() call  
whenever ProcessRepliesIfAny() finds no client reply messages.  
Back-patch to 9.4; the bug's symptom is rare and mild, and the code all  
moved between 9.3 and 9.4.  
  
Discussion: https://postgr.es/m/20180826034600.GA1105084@rfd.leadboat.com  

commit   : 1f349aa7d9a6633e87db071390c73a39ac279ba4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Aug 2018 16:56:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Aug 2018 16:56:11 -0700    

The previous definition was used in C++ mode, which causes problems  
when using clang with libc++ (rather than libstdc++), due to bugs  
therein.  So just avoid in C++ mode.  
  
A second problem is that depending on include order and implicit  
includes the previous definition did not guarantee that the current  
hack was effective by the time isinf was used, fix that by forcing  
math.h to be included.  This can cause clang using builds, or gcc  
using ones with JIT enabled, to slow down noticably.  
  
It's likely that we at some point want a better solution for the  
performance problem, but while it's there it should better work.  
  
Reported-By: Steven Winfield  
Bug: #15270  
Discussion: https://postgr.es/m/153116283147.1401.360416241833049560@wrigleys.postgresql.org  
Author: Andres Freund  
Backpatch: 11, like the previous commit.  

commit   : ed9c336b0f6bcf08e7b6bbe7080fdb63640a680e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 16:45:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 16:45:33 -0400    

A cast declared WITH INOUT was described as '(binary coercible)',  
which seems pretty inaccurate; let's print '(with inout)' instead.  
Per complaint from Jean-Pierre Pelletier.  
  
This definitely seems like a bug fix, but given that it's been wrong  
since 8.4 and nobody complained before, I'm hesitant to back-patch a  
behavior change into stable branches.  It doesn't seem too late for  
v11 though.  
  
Discussion: https://postgr.es/m/5b887023.1c69fb81.ff96e.6a1d@mx.google.com  

commit   : c34f8078aa354a9c352b6db488ca1d5aac39560c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Aug 2018 11:03:55 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 31 Aug 2018 11:03:55 -0700    

Startup process has improved its calculation of incorrect minimum  
consistent point in 8d68ee6, which ensures that all WAL available gets  
replayed when doing crash recovery, and has introduced an incorrect  
calculation of the minimum recovery point for non-startup processes,  
which can cause incorrect page references on a standby when for example  
the background writer flushed a couple of pages on-disk but was not  
updating the control file to let a subsequent crash recovery replay to  
where it should have.  
  
The only case where this has been reported to be a problem is when a  
standby needs to calculate the latest removed xid when replaying a btree  
deletion record, so one would need connections on a standby that happen  
just after recovery has thought it reached a consistent point.  Using a  
background worker which is started after the consistent point is reached  
would be the easiest way to get into problems if it connects to a  
database.  Having clients which attempt to connect periodically could  
also be a problem, but the odds of seeing this problem are much lower.  
  
The fix used is pretty simple, as the idea is to give access to the  
minimum recovery point written in the control file to non-startup  
processes so as they use a reference, while the startup process still  
initializes its own references of the minimum consistent point so as the  
original problem with incorrect page references happening post-promotion  
with a crash do not show up.  
  
Reported-by: Alexander Kukushkin  
Diagnosed-by: Alexander Kukushkin  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi, Alexander Kukushkin  
Discussion: https://postgr.es/m/153492341830.1368.3936905691758473953@wrigleys.postgresql.org  
Backpatch-through: 9.3  

commit   : d787af7badfe8c4c9afb7f0af9958a69b723a212    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 13:42:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 13:42:18 -0400    

Use postgres_fe.h, since this is frontend code.  Pretend that we've heard  
of project style guidelines for, eg, #include order.  Use BlockNumber not  
int arithmetic for block numbers, to avoid misbehavior with relations  
exceeding 2^31 blocks.  Avoid an unnecessary strict-aliasing warning  
(per report from Michael Banck).  Const-ify assorted stuff.  Avoid  
scribbling on the output of readdir() -- perhaps that's safe in practice,  
but POSIX forbids it, and this code has so far earned exactly zero  
credibility portability-wise.  Editorialize on an ambiguously-worded  
message.  
  
I did not touch the problem of the "buf" local variable being possibly  
insufficiently aligned; that's not specific to this code, and seems like  
it should be fixed as part of a different, larger patch.  
  
Discussion: https://postgr.es/m/1535618100.1286.3.camel@credativ.de  

commit   : 36343e59b51165da542943d2043878737fbe910b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:18:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:18:53 +0300    

contrib/cube has a limit to 100 dimensions for cube datatype.  However, it's  
not enforced everywhere, and one can actually construct cube with more than  
100 dimensions having then trouble with dump/restore.  This commit add checks  
for dimensions limit in all functions responsible for cube construction.  
Backpatch to all supported versions.  
  
Reported-by: Andrew Gierth  
Discussion: https://postgr.es/m/87va7uybt4.fsf%40news-spur.riddles.org.uk  
Author: Andrey Borodin with small additions by me  
Review: Tom Lane  
Backpatch-through: 9.3  

commit   : 1668186eb37851df41c9ff4b9ba9b4f71ce4f348    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:09:25 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 30 Aug 2018 14:09:25 +0300    

We're currently maintaining two outputs for cube regression test.  But that  
appears to be unsuitable, because these outputs are different in out few checks  
involving scientific notation.  So, split checks involving scientific notation  
into separate test, making contrib/cube easier to maintain.  Backpatch to all  
supported versions in order to make further backpatching easier.  
  
Discussion: https://postgr.es/m/CAPpHfdvJgWjxHsJTtT%2Bo1tz3OR8EFHcLQjhp-d3%2BUcmJLh-fQA%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 9.3  

commit   : 9daff2fe69dcfaf29c7901b9e6bad285778a45c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 12:26:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Aug 2018 12:26:20 -0400    

In general, Postgres requires -fno-strict-aliasing with compilers that  
implement C99 strict aliasing rules.  There's little hope of getting  
rid of that overall.  But it seems like it would be a good idea if  
storage/checksum_impl.h in particular didn't depend on it, because  
that header is explicitly intended to be included by external programs.  
We don't have a lot of control over the compiler switches that an  
external program might use, as shown by Michael Banck's report of  
failure in a privately-modified version of pg_verify_checksums.  
  
Hence, switch to using a union in place of willy-nilly pointer casting  
inside this file.  I think this makes the code a bit more readable  
anyway.  
  
checksum_impl.h hasn't changed since it was introduced in 9.3,  
so back-patch all the way.  
  
Discussion: https://postgr.es/m/1535618100.1286.3.camel@credativ.de  

commit   : 940487956ede2a6d0fb98b0b92cbf1f4656baaf0    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 20:47:17 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 20:47:17 +0900    

Commit f49842d, which added support for partitionwise joins, built the  
child's tlist by applying adjust_appendrel_attrs() to the parent's.  So in  
the case where the parent's included a whole-row Var for the parent, the  
child's contained a ConvertRowtypeExpr.  To cope with that, that commit  
added code to the planner, such as setrefs.c, but some code paths still  
assumed that the tlist for a scan (or join) rel would only include Vars  
and PlaceHolderVars, which was true before that commit, causing errors:  
  
* When creating an explicit sort node for an input path for a mergejoin  
  path for a child join, prepare_sort_from_pathkeys() threw the 'could not  
  find pathkey item to sort' error.  
* When deparsing a relation participating in a pushed down child join as a  
  subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw  
  the 'unexpected expression in subquery output' error.  
* When performing set_plan_references() on a local join plan generated by  
  contrib/postgres_fdw for EvalPlanQual support for a pushed down child  
  join, fix_join_expr() threw the 'variable not found in subplan target  
  lists' error.  
  
To fix these, two approaches have been proposed: one by Ashutosh Bapat and  
one by me.  While the former keeps building the child's tlist with a  
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the  
child not to violate the planner assumption, and tries to fix it up later,  
But both approaches need more work, so refuse to generate partitionwise  
join paths when whole-row Vars are involved, instead.  We don't need to  
handle ConvertRowtypeExprs in the child's tlists for now, so this commit  
also removes the changes to the planner.  
  
Previously, partitionwise join computed attr_needed data for each child  
separately, and built the child join's tlist using that data, which also  
required an extra step for adding PlaceHolderVars to that tlist, but it  
would be more efficient to build it from the parent join's tlist through  
the adjust_appendrel_attrs() transformation.  So this commit builds that  
list that way, and simplifies build_joinrel_tlist() and placeholder.c as  
well as part of set_append_rel_size() to basically what they were before  
partitionwise join went in.  
  
Back-patch to PG11 where partitionwise join was introduced.  
  
Report by Rajkumar Raghuwanshi.  Analysis by Ashutosh Bapat, who also  
provided some of regression tests.  Patch by me, reviewed by Robert Haas.  
  
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com  

commit   : 762a16572bb5d9be6c9c53c9ecd29288da213d02    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 31 Aug 2018 15:45:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 31 Aug 2018 15:45:09 +0530    

To verify the checksums, we open the file in text mode which doesn't work  
on Windows as WIN32 treats Control-Z as EOF in files opened in text mode.  
This leads to "short read of block .." error in some cases.  
  
Fix it by opening the files in the binary mode.  
  
Author: Amit Kapila  
Reviewed-by: Magnus Hagander  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAA4eK1+LOnzod+h85FGmyjWzXKy-XV1FYwEyP-Tky2WpD5cxwA@mail.gmail.com  

commit   : 40e981391395ae93aadfaf08cd343af65cc6252b    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 16:42:30 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 31 Aug 2018 16:42:30 +0900    

commit   : a840a8ac7b8ab5f8cb86627779d7b1250cdaca8d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 06:31:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 06:31:05 -0300    

Using -d is odd, because we normally reserve that for a database  
argument, so rename it to -v and add long version --verbose.  
  
Also, reduce it to emit one line per file checked rather than one line  
per block.  
  
Per a complaint from Michael Banck.  
  
Author: Yugo Nagata <nagata@sraoss.co.jp>  
Reviewed-by: Michael Banck <michael.banck@credativ.de>  
Discussion: https://postgr.es/m/20180827113411.GA22768@nighthawk.caipicrew.dd-dns.de  

commit   : c731ec455a234bb0b6fd736898d9dddf3e8d517f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 05:39:56 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Aug 2018 05:39:56 -0300    

This changed during pg10 development, but had not been documented.  
  
Co-authored-by: Jonathan S. Katz <jkatz@postgresql.org>  
Discussion: https://postgr.es/m/20180828163408.vl44nwetdybwffyk@alvherre.pgsql  

commit   : c1c1bfc500a09eacf90f7d006e645714f0383f98    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 30 Aug 2018 09:08:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 30 Aug 2018 09:08:33 +0300    

Recently, ii_KeyAttrNumbers was renamed to ii_IndexAttrNumbers, and ii_Am  
field was added, but the comments were not updated.  
  
Author: Yugo Nagata  
Discussion: https://www.postgresql.org/message-id/20180830134831.e35a91b8b978b248c16c8f7b@sraoss.co.jp  

commit   : 35622f7d3210f251c507e77730a3f18246629a95    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Aug 2018 17:10:13 -0700    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 Aug 2018 17:10:13 -0700    

When a postmaster gets into its phase PM_STARTUP, it would start  
background workers using BgWorkerStart_PostmasterStart mode immediately,  
which would cause problems for a fast shutdown as the postmaster forgets  
to send SIGTERM to already-started background workers.  With smart and  
immediate shutdowns, this correctly happened, and fast shutdown is the  
only mode missing the shot.  
  
Author: Alexander Kukushkin  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vU9GYn8UvHkA@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 49841edcc6440ccfe8cab2a2f478edadc9a0b266    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:46:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:46:59 -0400    

This function had a blacklist of dump object types that it believed  
needed exclusive lock ... but we hadn't maintained that, so that it  
was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of  
which need (or should be treated as needing) exclusive lock.  
  
Since the same oversight seems likely in future, let's reverse the  
sense of the test so that the code has a whitelist of safe object  
types; better to wrongly assume a command can't be run in parallel  
than the opposite.  Currently the only POST_DATA object type that's  
safe is CREATE INDEX ... and that list hasn't changed in a long time.  
  
Back-patch to 9.5 where RLS came in.  
  
Discussion: https://postgr.es/m/11450.1535483506@sss.pgh.pa.us  

commit   : 18f6258e5ee8ea8d9c06bd58655cf8c6e4f1016f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:33:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 19:33:04 -0400    

Ensure the TOC entry is marked with the correct schema, so that its  
name is as unique as the index's is.  
  
Fix the dependencies: we want dependencies from this TOC entry to the  
two indexes it depends on, and we don't care (at least not for this  
purpose) what order the indexes are created in.  Also, add dependencies  
on the indexes' underlying tables.  Those might seem pointless given  
the index dependencies, but they are helpful to cue parallel restore  
to avoid running the ATTACH PARTITION in parallel with other DDL on  
the same tables.  
  
Discussion: https://postgr.es/m/10817.1535494963@sss.pgh.pa.us  

commit   : 8ede2691d65e4c0aa1ae23453b5bed63f9a36254    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 17:26:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Aug 2018 17:26:09 -0400    

Now that we have TAP tests, a contrib module may have something useful  
to do in "make check" even if it has no pg_regress-style regression  
scripts, and hence no REGRESS setting.  But the TAP tests will fail,  
or else test the wrong installed files, unless we install the contrib  
module into the temp installation.  So move the bit about adding to  
EXTRA_INSTALL so that it applies regardless.  
  
We might want this in back branches in future, but for the moment  
I only risked adding it to v11.  
  
Discussion: https://postgr.es/m/12438.1535488750@sss.pgh.pa.us  

commit   : 8bc6a301b21cc189f5141c45be93938215e21fb7    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 14:43:51 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 14:43:51 +0100    

Commit aa09cd242 changed a condition in find_em_expr_for_rel from  
being a bms_equal comparison of relids to bms_is_subset, in order to  
support order by clauses on foreign joins. But this also allows  
through the degenerate case of expressions with no Vars at all (and  
hence empty relids), including integer constants which will be parsed  
unexpectedly on the remote (viz. "ERROR: ORDER BY position 0 is not in  
select list" as in the bug report).  
  
Repair by adding an additional !bms_is_empty test.  
  
Backpatch through to 9.6 where the aforementioned change was made.  
  
Per bug #15352 from Maksym Boguk; analysis and patch by me.  
  
Discussion: https://postgr.es/m/153518420278.1478.14875560810251994661@wrigleys.postgresql.org  

commit   : bc552b322fd954f8d87aef850b64e0d9ed376cfa    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 09:52:25 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Tue, 28 Aug 2018 09:52:25 +0100    

regexp_matches, regexp_split_to_table and regexp_split_to_array all  
work by compiling a list of match positions as character offsets (NOT  
byte positions) in the source string.  
  
Formerly, they then used text_substr to extract the matched text; but  
in a multi-byte encoding, that counts the characters in the string,  
and the characters needed to reach the starting byte position, on  
every call. Accordingly, the performance degraded as the product of  
the input string length and the number of match positions, such that  
splitting a string of a few hundred kbytes could take many minutes.  
  
Repair by keeping the wide-character copy of the input string  
available (only in the case where encoding_max_length is not 1) after  
performing the match operation, and extracting substrings from that  
instead. This reduces the complexity to being linear in the number of  
result bytes, discounting the actual regexp match itself (which is not  
affected by this patch).  
  
In passing, remove cleanup using retail pfree() which was obsoleted by  
commit ff428cded (Feb 2008) which made cleanup of SRF multi-call  
contexts automatic. Also increase (to ~134 million) the maximum number  
of matches and provide an error message when it is reached.  
  
Backpatch all the way because this has been wrong forever.  
  
Analysis and patch by me; review by Kaiting Chen.  
  
Discussion: https://postgr.es/m/87pnyn55qh.fsf@news-spur.riddles.org.uk  
  
see also https://postgr.es/m/87lg996g4r.fsf@news-spur.riddles.org.uk  

commit   : da793baca29fa83e3fb1eb09d2ef9aa863a02f7a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 28 Aug 2018 11:49:11 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 28 Aug 2018 11:49:11 +0200    

The source code was already set up for NLS support, so just a nls.mk  
file needed to be added.  Also, fix the old problem of putting the int64  
format specifier right into the string, which breaks NLS.  

commit   : 2657d4ea66c775c3334181722115be2d6128c5cd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 15:13:48 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 23 Aug 2018 15:13:48 +0200    

The problem arises with the combination of CALL with output parameters  
and doing a COMMIT inside the procedure.  When a CALL has output  
parameters, the portal uses the strategy PORTAL_UTIL_SELECT instead of  
PORTAL_MULTI_QUERY.  Using PORTAL_UTIL_SELECT causes the portal's  
snapshot to be registered with the current resource  
owner (portal->holdSnapshot); see  
9ee1cf04ab6bcefe03a11837b53f29ca9dc24c7a for the reason.  
  
Normally, PortalDrop() unregisters the snapshot.  If not, then  
ResourceOwnerRelease() will print a warning about a snapshot leak on  
transaction commit.  A transaction commit normally drops all  
portals (PreCommit_Portals()), except the active portal.  So in case of  
the active portal, we need to manually release the snapshot to avoid the  
warning.  
  
Reported-by: Prabhat Sahu <prabhat.sahu@enterprisedb.com>  
Reviewed-by: Jonathan S. Katz <jkatz@postgresql.org>  

commit   : c5e235ff8ad0f4907a736a6440dc4be6f939e65c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2018 15:11:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Aug 2018 15:11:12 -0400    

The archive should show a dependency on the item's table, but it failed  
to include one.  This could cause failures in parallel restore due to  
emitting ALTER TABLE ... ENABLE ROW LEVEL SECURITY before restoring  
the table's data.  In practice the odds of a problem seem low, since  
you would typically need to have set FORCE ROW LEVEL SECURITY as well,  
and you'd also need a very high --jobs count to have any chance of this  
happening.  That probably explains the lack of field reports.  
  
Still, it's a bug, so back-patch to 9.5 where RLS was introduced.  
  
Discussion: https://postgr.es/m/19784.1535390902@sss.pgh.pa.us  

commit   : 9ca2207990002a2fd594fd7f9776d9d91acba189    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Aug 2018 09:32:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 27 Aug 2018 09:32:59 +1200    

Author: David Rowley  
Discussion: https://postgr.es/m/CAKJS1f8du35u5DprpykWvgNEScxapbWYJdHq%2Bz06Wj3Y2KFPbw%40mail.gmail.com  

commit   : f8fc5f5f50dbabec866dee79cd739bb3f68052a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Aug 2018 14:21:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Aug 2018 14:21:55 -0400    

The previous coding figured it'd be good enough to postpone opening  
the first CSV log file until we got a message we needed to write there.  
This is unsafe, though, because if the open fails we end up in infinite  
recursion trying to report the failure.  Instead make the CSV log file  
management code look as nearly as possible like the longstanding logic  
for the stderr log file.  In particular, open it immediately at postmaster  
startup (if enabled), or when we get a SIGHUP in which we find that  
log_destination has been changed to enable CSV logging.  
  
It seems OK to fail if a postmaster-start-time open attempt fails, as  
we've long done for the stderr log file.  But we can't die if we fail  
to open a CSV log file during SIGHUP, so we're still left with a problem.  
In that case, write any output meant for the CSV log file to the stderr  
log file.  (This will also cover race-condition cases in which backends  
send CSV log data before or after we have the CSV log file open.)  
  
This patch also fixes an ancient oversight that, if CSV logging was  
turned off during a SIGHUP, we never actually closed the last CSV  
log file.  
  
In passing, remember to reset whereToSendOutput = DestNone during syslogger  
start, since (unlike all other postmaster children) it's forked before the  
postmaster has done that.  This made for a platform-dependent difference  
in error reporting behavior between the syslogger and other children:  
except on Windows, it'd report problems to the original postmaster stderr  
as well as the normal error log file(s).  It's barely possible that that  
was intentional at some point; but it doesn't seem likely to be desirable  
in production, and the platform dependency definitely isn't desirable.  
  
Per report from Alexander Kukushkin.  It's been like this for a long time,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAFh8B==iLUD_gqC-dAENS0V+kVrCeGiKujtKqSQ7++S-caaChw@mail.gmail.com  

commit   : 231cf30e984b1501cbe640f567c08919a195d9d1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:35:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:35:14 -0400    

Mention that "Latest checkpoint location" will not match in pg_upgrade  
if the standby server is still running during the upgrade, which is  
possible.  "Match" text first appeared in PG 9.5.  
  
Reported-by: Paul Bonaud  
  
Discussion: https://postgr.es/m/c7268794-edb4-1772-3bfd-04c54585c24e@trainline.com  
  
Backpatch-through: 9.5  

commit   : 3c712c580e63a983081758059607ca1ee4bc4b6b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:01:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 13:01:24 -0400    

Reported-by: Ashutosh Sharma  
  
Discussion: https://postgr.es/m/CAE9k0PnhnL6MNDLuvkk8USzOa_DpzDzFQPAM_uaGuXbh9HMKYw@mail.gmail.com  
  
Author: Ashutosh Sharma  
  
Backpatch-through: 9.3  

commit   : 04d36cf44bcc14c649037470e72fb990e794e212    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 12:01:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 12:01:53 -0400    

The options string appeared in PG 10.  
  
Reported-by: pgsql-kr@postgresql.kr  
  
Discussion: https://postgr.es/m/153500377658.1378.6587007319641704057@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : 2c852e3e53c8e64b84f518ee2ab04509c3f29b95    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 11:52:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 25 Aug 2018 11:52:29 -0400    

Reported-by: Adam Bielański  
  
Discussion: https://postgr.es/m/153484305538.1370.7605856225879294548@wrigleys.postgresql.org  
  
Backpatch-through: 9.3