PostgreSQL 11.2 commit log

commit   : 6cd404b344f7e27f4d64555bb133f18a758fe851    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Feb 2019 16:17:27 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Feb 2019 16:17:27 -0500    

commit   : 6c9356080c2060bcd4a6cef520aa3d8121940ee7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Feb 2019 12:05:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Feb 2019 12:05:49 -0500    

commit   : 352f9b57cfdf3e8f871474223975ee2c6b725bf7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Feb 2019 14:31:57 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Feb 2019 14:31:57 +0100    

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

commit   : 12055c8f643afa5ed70d17acc7782c21299ffb69    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Feb 2019 10:31:36 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Feb 2019 10:31:36 +0100    

We usually don't use "namespace" in user-facing error messages.  Also,  
in master this was replaced by another error message referring to  
"temporary objects", so we might as well use that here to avoid  
introducing too many variants.  
  
Discussion: https://www.postgresql.org/message-id/[email protected]  

commit   : eb68d71f99e945c89bbb1190086237be65ad784c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2019 22:51:33 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2019 22:51:33 -0500    

indxpath.c needs a good deal more attention for covering indexes than  
it's gotten.  But so far as I can tell, the only really awful breakage  
is in expand_indexqual_rowcompare (nee adjust_rowcompare_for_index),  
which was only half fixed in c266ed31a.  The other problems aren't  
bad enough to take the risk of a just-before-wrap fix.  
  
The problem here is that if the leading column of a row comparison  
matches an index (allowing this code to be reached), and some later  
column doesn't match the index, it'll nonetheless believe that that  
column matches the first included index column.  Typically that'll  
lead to an error like "operator M is not a member of opfamily N" as  
a result of fetching a garbage opfamily OID.  But with enough bad  
luck, maybe a broken plan would be generated.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2eebda274fa97e5fee6a6001a07eed079e5be69f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2019 15:44:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2019 15:44:04 -0500    

commit   : 1f67ff8ce55a3397733f3b18371865f145873143    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2019 14:02:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Feb 2019 14:02:26 -0500    

Add items for the weekend's commits.  Add corrections from  
Peter Geoghegan, Amit Kapila, and Alexander Kuzmenkov.  
Some copy-editing of my own too.  

commit   : cc126b45ea5c5e408b01ff4fb09a974450e11025    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sun, 10 Feb 2019 10:00:11 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sun, 10 Feb 2019 10:00:11 -0300    

After commit 123cc697a8eb, we remove redundant FK action triggers during  
partition ATTACH by merely deleting the catalog tuple, but that's wrong:  
it should use performDeletion() instead.  Repair, and make the comments  
more explicit.  
  
Per code review from Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ee6370978fd921c22ec8bf2239ad4d30ae126fed    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 9 Feb 2019 21:02:06 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 9 Feb 2019 21:02:06 -0500    

Renaming varchar_transform to varchar_support had a side effect  
I hadn't foreseen: the core regression tests leave around a  
transform object that relies on that function, so the name  
change breaks cross-version upgrade tests, because the name  
used in the older branches doesn't match.  
  
Since the dependency on varchar_transform was chosen with the  
aid of a dartboard anyway (it would surely not work as a  
language transform support function), fix by just choosing  
a different random builtin function with the right signature.  
Also add some comments explaining why this isn't horribly unsafe.  
  
I chose to make the same substitution in a couple of other  
copied-and-pasted test cases, for consistency, though those  
aren't directly contributing to the testing problem.  
  
Per buildfarm.  Back-patch, else it doesn't fix the problem.  

commit   : ef9bf359369b4dfaceb859941c3898b5ce1decf6    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 9 Feb 2019 19:45:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 9 Feb 2019 19:45:38 -0500    

warn_or_exit_horribly() was blithely passing a potentially-NULL  
string pointer to a %s format specifier.  That works (at least  
to the extent of not crashing) on some platforms, but not all,  
and since we switched to our own snprintf.c it doesn't work  
for us anywhere.  
  
Of the three string fields being handled this way here, I think  
that only "owner" is supposed to be nullable ... but considering  
that this is error-reporting code, it has very little business  
assuming anything, so put in defenses for all three.  
  
Per a crash observed on buildfarm member crake and then  
reproduced here.  Because of the portability aspect,  
back-patch to all supported versions.  

commit   : 027b5a300a9e9b407f465f0264cb88305eb0539d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 9 Feb 2019 11:41:09 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 9 Feb 2019 11:41:09 -0500    

The previous ordering of these steps satisfied the nominal requirement  
that set_rel_pathlist_hook could editorialize on the whole set of Paths  
constructed for a base relation.  In practice, though, trying to change  
the set of partial paths was impossible.  Adding one didn't work because  
(a) it was too late to be included in Gather paths made by the core code,  
and (b) calling add_partial_path after generate_gather_paths is unsafe,  
because it might try to delete a path it thinks is dominated, but that  
is already embedded in some Gather path(s).  Nor could the hook safely  
remove partial paths, for the same reason that they might already be  
embedded in Gathers.  
  
Better to call extensions first, let them add partial paths as desired,  
and then gather.  In v11 and up, we already doubled down on that ordering  
by postponing gathering even further for single-relation queries; so even  
if the hook wished to editorialize on Gather path construction, it could  
not.  
  
Report and patch by KaiGai Kohei.  Back-patch to 9.6 where Gather paths  
were added.  
  
Discussion: https://postgr.es/m/CAOP8fzahwpKJRTVVTqo2AE=mDTz_efVzV6Get_0=U3SO+-ha1A@mail.gmail.com  

commit   : 920311ab18aac799aee6ad2303b2ed2b6b44c1b8    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 02:44:10 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 02:44:10 -0800    

This is not necessary anymore after 297d627e, but extensions that have  
not been recompiled after the fix will not use the new definition of  
heap_getattr(). While recompiling those extensions is obviously the  
suggested course, it's cheap enough to retain the expansion in  
GetTupleForTrigger().  
  
Per suggestion from Andrew Gierth.  
  
Discussion: [email protected]  

commit   : 35afccaba6d0e0aa14e3d1f859e6d84e69aee2cc    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    

This uses the facility added in the preceding commit to fix  
performance issues caused by rebuilding the hashtable (with its  
comparator expression being the most expensive bit), after every  
reset. That's especially important when the comparator is JIT  
compiled.  
  
Bug: #15592 #15486  
Reported-By: Jakub Janeček, Dmitry Marakasov  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/[email protected]  
    https://postgr.es/m/[email protected]  
Backpatch: 11, where I broke this in bf6c614a2f2c5  

commit   : 6455c65882474a48b6bde298bd04c18aa4e4b27f    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    

This has the advantage that the comparator expression, the table's  
slot, etc do not have to be rebuilt. Additionally the simplehash.h  
hashtable within the tuple hashtable now keeps its previous size and  
doesn't need to be reallocated. That both reduces allocator overhead,  
and improves performance in cases where the input estimation was off  
by a significant factor.  
  
To avoid an API/ABI break, the new parameter is exposed via the new  
BuildTupleHashTableExt(), and BuildTupleHashTable() now is a wrapper  
around the former, that continues to allocate the table itself in the  
tablecxt.  
  
Using this fixes performance issues discovered in the two bugs  
referenced. This commit however has not converted the callers, that's  
done in a separate commit.  
  
Bug: #15592 #15486  
Reported-By: Jakub Janeček, Dmitry Marakasov  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/[email protected]  
    https://postgr.es/m/[email protected]  
Backpatch: 11, this is a prerequisite for other fixes  

commit   : 350b0a40375e5fa171da15bd3062de83c54cd099    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    

A hashtable reset just reset the hashtable entries, but does not free  
memory.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Bug: #15592 #15486  
Backpatch: 11, this is a prerequisite for other fixes  

commit   : 9cf37a527cf83e94f8f166d380baf53287a0337b    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 9 Feb 2019 00:35:57 -0800    

In bf6c614a2f2c5 I added a expr context to evaluate the grouping  
expression. Unfortunately the code I added initialized them while in  
the calling context, rather the table context.  Additionally, I used  
CreateExprContext() rather than CreateStandaloneExprContext(), which  
creates the econtext in the estate's query context.  
  
Fix that by using CreateStandaloneExprContext when in the table's  
tablecxt. As we rely on the memory being freed by a memory context  
reset that means that the econtext's shutdown callbacks aren't being  
called, but that seems ok as the expressions are tightly controlled  
due to ExecBuildGroupingEqual().  
  
Bug: #15592  
Reported-By: Dmitry Marakasov  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11, where I broke this in bf6c614a2f2c5  

commit   : 5996cfc4665735a7e6e8d473bd66e8b11e320bbb    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2019 20:17:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2019 20:17:14 -0500    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : 8e2956734b98933f833c7845da724c7a6d98341d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2019 13:30:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2019 13:30:42 -0500    

While this isn't really supposed to happen, it can occur in OOM  
situations and perhaps others.  Instead of crashing, substitute  
"(no message provided)".  
  
I didn't worry about localizing this text, since we aren't  
localizing anything else here; besides, if we're on the edge of  
OOM, it's unlikely gettext() would work.  
  
Report and fix by Sergio Conde Gómez in bug #15624.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8cf3fada2f87f2cbd0102389bf59434b45e911fe    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2019 12:49:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Feb 2019 12:49:36 -0500    

Also clean up some discussion that had been left in a very confused  
state thanks to half-hearted adjustments for the change to  
standard_conforming_strings being the default.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9d6d2b21343db76a769fbcae72fbcbc18aa388cb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2019 13:10:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Feb 2019 13:10:46 -0500    

As reported in bug #15613 from Srinivasan S A, file_fdw and postgres_fdw  
neglected to mark plain baserel foreign paths as parameterized when the  
relation has lateral_relids.  Other FDWs have surely copied this mistake,  
so rather than just patching those two modules, install a band-aid fix  
in create_foreignscan_path to rectify the mistake centrally.  
  
Although the band-aid is enough to fix the visible symptom, correct  
the calls in file_fdw and postgres_fdw anyway, so that they are valid  
examples for external FDWs.  
  
Also, since the band-aid isn't enough to make this work for parameterized  
foreign joins, throw an elog(ERROR) if such a case is passed to  
create_foreignscan_path.  This shouldn't pose much of a problem for  
existing external FDWs, since it's likely they aren't trying to make such  
paths anyway (though some of them may need a defense against joins with  
lateral_relids, similar to the one this patch installs into postgres_fdw).  
  
Add some assertions in relnode.c to catch future occurrences of the same  
error --- in particular, as backstop against core-code mistakes like the  
one fixed by commit bdd9a99aa.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 8722d2cbc0500b8ae1ebaf0a388115617615c1eb    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 7 Feb 2019 10:22:49 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 7 Feb 2019 10:22:49 -0500    

The modules RewindTest.pm and ServerSetup.pm are really only useful for  
TAP tests, so they really belong in the TAP test directories. In  
addition, ServerSetup.pm is renamed to SSLServer.pm.  
  
The test scripts have their own directories added to the search path so  
that the relocated modules will be found, regardless of where the tests  
are run from, even on modern perl where "." is no longer in the  
searchpath.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch as appropriate to 9.5  

commit   : 004f494b513c3398030983b2644eeea8776c0a5d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 5 Feb 2019 15:08:53 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 5 Feb 2019 15:08:53 +0100    

Otherwise functions that require collation information will not have  
it if they are called in arguments to a CALL statement.  
  
Reported-by: Jean-Marc Voillequin <[email protected]>  
Reviewed-by: Tom Lane <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/1EC8157EB499BF459A516ADCF135ADCE39FFAC54%40LON-WGMSX712.ad.moodys.net  

commit   : d850af428deb21d074330f6fe801c52e52965fde    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 7 Feb 2019 09:02:45 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 7 Feb 2019 09:02:45 +0530    

In commit f16241bef7c, we have changed the behavior for concurrent updates  
that move row to a different partition, but forgot to update the docs.  
Previously when an UPDATE command causes a row to move from one partition  
to another, there is a chance that another concurrent UPDATE or DELETE  
misses this row.  However, now we raise a serialization failure error in  
such a case.  
  
Reported-by: David Rowley  
Author: David Rowley and Amit Kapila  
Backpatch-through: 11 where it was introduced  
Discussion: https://postgr.es/m/CAKJS1f-iVhGD4-givQWpSROaYvO3c730W8yoRMTF9Gc3craY3w@mail.gmail.com  

commit   : 2f541666683be0608594fad79acbe5619b49734c    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 6 Feb 2019 15:54:17 -0800    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 6 Feb 2019 15:54:17 -0800    

The previous tacit assumption that index_form_tuple() hides differences  
in the TOAST state of its input datums was wrong.  Normalize input  
varlena datums by decompressing compressed values, and forming a new  
index tuple for fingerprinting using uncompressed inputs.  The final  
normalized representation may actually be compressed once again within  
index_form_tuple(), though that shouldn't matter.  When the original  
tuple is found to have no datums that are compressed inline, fingerprint  
the original tuple directly.  
  
Normalization avoids false positive reports of corruption in certain  
cases.  For example, the executor can apply toasting with some inline  
compression to an entire heap tuple because its input has a single  
external TOAST pointer.  Varlena datums for other attributes that are  
not particularly good candidates for inline compression can be  
compressed in the heap tuple in passing, without the representation of  
the same values in index tuples ever receiving concomitant inline  
compression.  
  
Add a test case to recreate the issue in a simpler though less realistic  
way: by exploiting differences in pg_attribute.attstorage between heap  
and index relations.  
  
This bug was discovered by me during testing of an upcoming set of nbtree  
enhancements.  It was also independently reported by Andreas Kunert, as  
bug #15597.  His test case was rather more realistic than the one I  
ended up using.  
  
Bug: #15597  
Discussion: https://postgr.es/m/CAH2-WznrVd9ie+TTJ45nDT+v2nUt6YJwQrT9SebCdQKtAvfPZw@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, where heapallindexed verification was introduced.  

commit   : 45ae2031ec1514ea403a85961f155296bc4be350    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 6 Feb 2019 12:44:58 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 6 Feb 2019 12:44:58 -0500    

create_lateral_join_info() computes a bunch of information about lateral  
references between base relations, and then attempts to propagate those  
markings to appendrel children of the original base relations.  But the  
original coding neglected the possibility of indirect descendants  
(grandchildren etc).  During v11 development we noticed that this was  
wrong for partitioned-table cases, but failed to realize that it was just  
as wrong for any appendrel.  While the case can't arise for appendrels  
derived from traditional table inheritance (because we make a flat  
appendrel for that), nested appendrels can arise from nested UNION ALL  
subqueries.  Failure to mark the lower-level relations as having lateral  
references leads to confusion in add_paths_to_append_rel about whether  
unparameterized paths can be built.  It's not very clear whether that  
leads to any user-visible misbehavior; the lack of field reports suggests  
that it may cause nothing worse than minor cost misestimation.  Still,  
it's a bug, and it leads to failures of Asserts that I intend to add  
later.  
  
To fix, we need to propagate information from all appendrel parents,  
not just those that are RELOPT_BASERELs.  We can still do it in one  
pass, if we rely on the append_rel_list to be ordered with ancestor  
relationships before descendant ones; add assertions checking that.  
While fixing this, we can make a small performance improvement by  
traversing the append_rel_list just once instead of separately for  
each appendrel parent relation.  
  
Noted while investigating bug #15613, though this patch does not fix  
that (which is why I'm not committing the related Asserts yet).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 11f11e1e0103e56649e86dbaaf800a1b4a6d5ebe    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 6 Feb 2019 07:32:35 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 6 Feb 2019 07:32:35 -0500    

Commit f83419b739 failed to notice that mkvcbuild.pl and build.pl use  
different searchpath and do-file logic, breaking the latter, so it is  
adjusted to use the same logic as mkvcbuild.pl.  

commit   : 297d627e074ad4aa2a9936b029a4b9231f9a150e    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 6 Feb 2019 01:09:32 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 6 Feb 2019 01:09:32 -0800    

Previously heap_getattr() returned NULL for attributes with a fast  
default value (c.f. 16828d5c0273), as it had no handling whatsoever  
for that case.  
  
A previous fix, 7636e5c60f, attempted to fix issues caused by this  
oversight, but just expanding OLD tuples for triggers doesn't actually  
solve the underlying issue.  
  
One known consequence of this bug is that the check for HOT updates  
can return the wrong result, when a previously fast-default'ed column  
is set to NULL. Which in turn means that an index over a column with  
fast default'ed columns might be corrupt if the underlying column(s)  
allow NULLs.  
  
Fix by handling fast default columns in heap_getattr(), remove now  
superfluous expansion in GetTupleForTrigger().  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11, where fast defaults were introduced  

commit   : 77173d0cca4df1df1f423a467e2af4a4db9a0d10    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 18:57:12 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 18:57:12 -0500    

Contrary to the comment on 772d4b76, only paths starting with "./" or  
"../" are considered relative to the current working directory by perl's  
"do" function. So this patch converts all the relevant cases to use "./"  
paths. This only affects MSVC.  
  
Backpatch to all live branches.  

commit   : 99eb3bba649b5a48fa9b679b6d94334ca110e1db    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 15:16:55 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 15:16:55 -0500    

It doesn't like code before "use strict;".  

commit   : 46b454096973fee0fb55c092496fdf8005eea885    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Feb 2019 10:58:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Feb 2019 10:58:53 -0500    

DST law changes in Kazakhstan, Metlakatla, and São Tomé and Príncipe.  
Kazakhstan's Qyzylorda zone is split in two, creating a new zone  
Asia/Qostanay, as some areas did not change UTC offset.  
Historical corrections for Hong Kong and numerous Pacific islands.  

commit   : 4e7a5130271fcc579f89d3f7ae6b69e73d37c32a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 09:59:46 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 5 Feb 2019 09:59:46 -0500    

This was fixed for MSVC tools by commit 1df92eeafefac4, but per  
buildfarm member bowerbird genbki.pl needs the same treatment.  
  
Backpatch to all live branches.  

commit   : 0d13dd371b64c52221ba220d214d8fbce3e474f5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2019 19:18:50 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2019 19:18:50 -0500    

Historically we've had each release branch include all prior branches'  
notes, including minor-release changes, back to the beginning of the  
project.  That's basically an O(N^2) proposition, and it was starting to  
catch up with us: as of HEAD the back-branch release notes alone accounted  
for nearly 30% of the documentation.  While there's certainly some value  
in easy access to back-branch notes, this is getting out of hand.  
  
Hence, switch over to the rule that each branch contains only its own  
release notes.  So as to not make older notes too hard to find, each  
branch will provide URLs for the immediately preceding branches'  
release notes on the project website.  
  
There might be value in providing aggregated notes across all branches  
somewhere on the website, but that's a task for another day.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b8de846a511a8328faaac792641253054cc6c6e9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2019 17:20:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Feb 2019 17:20:02 -0500    

Commit 62215de29 turns out to have been not quite on-the-mark.  
When we are forced to postpone dumping of a materialized view into  
the dump's post-data section (because it depends on a unique index  
that isn't created till that section), we may also have to postpone  
dumping other matviews that depend on said matview.  The previous fix  
didn't reliably work for such cases: it'd break the dependency loops  
properly, producing a workable object ordering, but it didn't  
necessarily mark all the matviews as "postponed_def".  This led to  
harmless bleating about "archive items not in correct section order",  
as reported by Tom Cassidy in bug #15602.  Less harmlessly,  
selective-restore options such as --section might misbehave due to  
the matview dump objects not being properly labeled.  
  
The right way to fix it is to consider that each pre-data dependency  
we break amounts to moving the no-longer-dependent object into  
post-data, and hence we should mark that object if it's a matview.  
  
Back-patch to all supported versions, since the issue's been there  
since matviews were introduced.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ed1bb25075c5f12993af66bb0aba114f843b2764    
  
author   : Andrew Gierth <[email protected]>    
date     : Mon, 4 Feb 2019 18:47:33 +0000    
  
committer: Andrew Gierth <[email protected]>    
date     : Mon, 4 Feb 2019 18:47:33 +0000    

Rather than define ld_library_path_ver with a big nested $(if), just  
put the overriding values in the makefiles for the relevant ports.  
  
Also add a variable for port makefiles to append their own stuff to  
with_temp_install, and use it to set LD_LIBRARY_PATH_RPATH=1 on  
FreeBSD which is needed to make LD_LIBRARY_PATH override DT_RPATH  
if DT_RUNPATH is not set (which seems to depend in unpredictable ways  
on the choice of compiler, at least on my system).  
  
Backpatch for the benefit of anyone doing regression tests on FreeBSD.  
(For other platforms there should be no functional change.)  

commit   : 40e821b01870a1de5e3fdcf5c76d46116c0a56b7    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 4 Feb 2019 09:57:36 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 4 Feb 2019 09:57:36 +0900    

The option is ignored on Windows, and GUC data_directory_mode already  
mentioned that within its description in the documentation.  
  
Author: Michael Paquier  
Reported-by: Haribabu Kommi, David Steele  
Discussion: https://postgr.es/m/CAJrrPGefxTG43yk6BrOC7ZcMnCTccG9+inCSncvyys_t8Ev9cQ@mail.gmail.com  
Backpatch-through: 11  

commit   : 946430da6a0b91cac5607758264f506d25b3321f    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 3 Feb 2019 17:48:35 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 3 Feb 2019 17:48:35 +0900    

Add PG_CFLAGS, PG_CXXFLAGS, and PG_LDFLAGS variables to pgxs.mk which  
will be appended or prepended to the corresponding make variables.  
Notably, there was previously no way to pass custom CXXFLAGS to third  
party extension module builds, COPT and PROFILE supporting only CFLAGS  
and LDFLAGS.  
  
Backpatch all the way down to ease integration with existing  
extensions.  
  
Author: Christoph Berg  
Reviewed-by: Andres Freund, Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 904413637f8b04aab02cbe03173a1a0bdadc2b6b    
  
author   : Amit Kapila <[email protected]>    
date     : Sat, 2 Feb 2019 08:38:26 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Sat, 2 Feb 2019 08:38:26 +0530    

To avoid deadlock, backend acquires a lock on heap pages in block  
number order.  In certain cases, lock on heap pages is dropped and  
reacquired.  In this case, the locks are dropped for reading in  
corresponding VM page/s. The issue is we re-acquire locks in bufferId  
order whereas the intention was to acquire in blockid order.  
  
This commit ensures that we will always acquire locks on heap pages in  
blockid order.  
  
Reported-by: Nishant Fnu  
Author: Nishant Fnu  
Reviewed-by: Amit Kapila and Robert Haas  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/[email protected]  

commit   : 47412e075266a5f23c66aaaf3abbb76b075c2c15    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 1 Feb 2019 10:35:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 1 Feb 2019 10:35:40 +0900    

When logging the replica identity of a deleted tuple, XLOG_HEAP_DELETE  
records include references of the old tuple.  Its data is stored in an  
intermediate variable used to register this information for the WAL  
record, but this variable gets away from the stack when the record gets  
actually inserted.  
  
Spotted by clang's AddressSanitizer.  
  
Author: Stas Kelvish  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : cf25498f718a35addf0fc783691538d91d60dcf8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 28 Jan 2019 22:09:33 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 28 Jan 2019 22:09:33 +0100    

The bug was that determining which columns are part of the replica  
identity index using RelationGetIndexAttrBitmap() would run  
eval_const_expressions() on index expressions and predicates across  
all indexes of the table, which in turn might require a snapshot, but  
there wasn't one set, so it crashes.  There were actually two separate  
bugs, one on the publisher and one on the subscriber.  
  
To trigger the bug, a table that is part of a publication or  
subscription needs to have an index with a predicate or expression  
that lends itself to constant expressions simplification.  
  
The fix is to avoid the constant expressions simplification in  
RelationGetIndexAttrBitmap(), so that it becomes safe to call in these  
contexts.  The constant expressions simplification comes from the  
calls to RelationGetIndexExpressions()/RelationGetIndexPredicate() via  
BuildIndexInfo().  But RelationGetIndexAttrBitmap() calling  
BuildIndexInfo() is overkill.  The latter just takes pg_index catalog  
information, packs it into the IndexInfo structure, which former then  
just unpacks again and throws away.  We can just do this directly with  
less overhead and skip the troublesome calls to  
eval_const_expressions().  This also removes the awkward  
cross-dependency between relcache.c and index.c.  
  
Bug: #15114  
Reported-by: Петър Славов <[email protected]>  
Reviewed-by: Noah Misch <[email protected]>  
Reviewed-by: Michael Paquier <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/[email protected]/  

commit   : ff9e63c7d33a92503895b3c8acc8d96cb8116220    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 29 Jan 2019 10:42:41 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 29 Jan 2019 10:42:41 +0100    

Author: Alex Kliukin  
Reviewed-By: Michael Paquier, Magnus Hagander  

commit   : 6a5c0bb6abbfa987ac065789b50240e485b75725    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 28 Jan 2019 18:05:52 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 28 Jan 2019 18:05:52 -0800    

Previously llvmjit.h #error'ed when USE_LLVM was not defined, to  
prevent it from being included from code not having #ifdef USE_LLVM  
guards - but that's not actually that useful after, during the  
development of JIT support, LLVM related code was moved into a  
separately compiled .so.  Having that #error means cpluspluscheck  
doesn't work when llvm support isn't enabled, which isn't great.  
  
Similarly add USE_LLVM guards to llvmjit_emit.h, and additionally make  
sure it compiles standalone.  
  
Per complaint from Tom Lane.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11, where JIT support was added  

commit   : 453be7d4dd03a4589bca753dabcff786c277de4f    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 28 Jan 2019 13:51:12 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 28 Jan 2019 13:51:12 -0800    

There's no reason not to install these, and jit.h can be useful for  
users of e.g. planner hooks.  
  
Author: Donald Dong  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, where JIT compilation was introduced  

commit   : 04bbefcc30f0f41066607da319dea58e3a319433    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Jan 2019 22:12:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Jan 2019 22:12:49 -0500    

Given the right timing, psql could emit "connection to server was lost"  
rather than one of the other messages that this test script checked for.  
It looks like commit 4247db625 may have made this more likely, but  
I don't really believe it was impossible before then.  Rather than  
stress about it, just add that spelling as one of the crash-successfully-  
detected cases.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2c50c9f23d1dbb36b4fed50409ec590a0e9adaa2    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Jan 2019 14:15:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Jan 2019 14:15:42 -0500    

Previously, \g would successfully execute the COPY command, but  
the target specification if any was ignored, so that the data was  
always dumped to the regular query output target.  This seems like  
a clear bug, so let's not just fix it but back-patch it.  
  
While at it, adjust the documentation for \copy to recommend  
"COPY ... TO STDOUT \g foo" as a plausible alternative.  
  
Back-patch to 9.5.  The problem exists much further back, but the  
code associated with \g was refactored enough in 9.5 that we'd  
need a significantly different patch for 9.4, and it doesn't  
seem worth the trouble.  
  
Daniel Vérité, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c0aed6959541f1ce3930977c8cf8dd874308a1b5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 Jan 2019 21:14:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 Jan 2019 21:14:31 -0500    

Since LISTEN is (still) disallowed, UNLISTEN must be a no-op in a  
hot-standby session, and so there's no harm in allowing it.  This  
change allows client code to not worry about whether it's connected  
to a primary or standby server when performing session-state-reset  
type activities.  (Note that DISCARD ALL, which includes UNLISTEN,  
was already allowed, making it inconsistent to reject UNLISTEN.)  
  
Per discussion, back-patch to all supported versions.  
  
Shay Rojansky, reviewed by Mi Tar  
  
Discussion: https://postgr.es/m/CADT4RqCf2gA_TJtPAjnGzkC3ZiexfBZiLmA-mV66e4UyuVv8bA@mail.gmail.com  

commit   : 28868f77b6cb531fca376767c29c9767ac39f54b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Jan 2019 16:46:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Jan 2019 16:46:55 -0500    

A report from Andrew Dunstan showed that an ecpglib breakage that  
causes repeated query failures could lead to infinite loops in some  
ecpg test scripts, because they contain "while(1)" loops with no  
exit condition other than successful test completion.  That might  
be all right for manual testing, but it seems entirely unacceptable  
for automated test environments such as our buildfarm.  We don't  
want buildfarm owners to have to intervene manually when a test  
goes wrong.  
  
To fix, just change all those while(1) loops to exit after at most  
100 iterations (which is more than any of them expect to iterate).  
This seems sufficient since we'd see discrepancies in the test output  
if any loop executed the wrong number of times.  
  
I tested this by dint of intentionally breaking ecpg_do_prologue  
to always fail, and verifying that the tests still got to completion.  
  
Back-patch to all supported branches, since the whole point of this  
exercise is to protect the buildfarm against future mistakes.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1ad5210998e33cccb4ea97b33837f19193d1011d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 24 Jan 2019 14:09:56 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 24 Jan 2019 14:09:56 -0300    

We were failing to set conislocal correctly for constraints in  
partitions after partition detach, leading to those constraints becoming  
undroppable.  Fix by setting the flag correctly.  Existing databases  
might contain constraints with the conislocal wrongly set to false, for  
partitions that were detached; this situation should be fixable by  
applying an UPDATE on pg_constraint to set conislocal true.  This  
problem should otherwise be innocuous and should disappear across a  
dump/restore or pg_upgrade.  
  
Secondarily, when constraint drop was attempted in a partitioned table,  
ATExecDropConstraint would try to recurse to partitions after doing  
performDeletion() of the constraint in the partitioned table itself; but  
since the constraint in the partitions are dropped by the initial call  
of performDeletion() (because of following dependencies), the recursion  
step would fail since it would not find the constraint, causing the  
whole operation to fail.  Fix by preventing recursion.  
  
Reported-by: Amit Langote  
Diagnosed-by: Amit Langote  
Author: Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  

commit   : 27d6bc68f98e062a4af625fd5044ba7e23a2003f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 24 Jan 2019 11:31:54 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 24 Jan 2019 11:31:54 -0500    

The pgbench regression test supposed that srandom() with a specific value  
would result in deterministic output from random(), as required by POSIX.  
It emerges however that OpenBSD is too smart to be constrained by mere  
standards, so their random() emits nondeterministic output anyway.  
While a workaround does exist, what seems like a better fix is to stop  
relying on the platform's srandom()/random() altogether, so that what  
you get from --random-seed=N is not merely deterministic but platform  
independent.  Hence, use a separate pg_jrand48() random sequence in  
place of random().  
  
Also adjust the regression test case that's supposed to detect  
nondeterminism so that it's more likely to detect it; the original  
choice of random_zipfian parameter tended to produce the same output  
all the time even if the underlying behavior wasn't deterministic.  
  
In passing, improve pgbench's docs about random_zipfian().  
  
Back-patch to v11 where this code was introduced.  
  
Fabien Coelho and Tom Lane  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 71eba83999f3702ee9b909ad2df5cae7ebb58882    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 24 Jan 2019 11:18:35 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 24 Jan 2019 11:18:35 -0300    

The original coding was too baroque and led to an use-after-release  
mistake, noticed by buildfarm member prion.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b620cf2d47625280e631127ae7202e798257647d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 23 Jan 2019 22:46:45 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 23 Jan 2019 22:46:45 -0500    

Apparently, some builds of MinGW contain a version of  
_configthreadlocale() that always returns -1, indicating failure.  
Rather than treating that as a curl-up-and-die condition, soldier on  
as though the function didn't exist.  This leaves us without thread  
safety on such MinGW versions, but we didn't have it anyway.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 00376eaa2ec28db92efe349a895164b0e31b314c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 23 Jan 2019 23:57:46 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 23 Jan 2019 23:57:46 -0300    

I (Álvaro) forgot to do this in eb7ed3f30634, leading to undroppable  
constraints after partitions are detached.  Repair.  
  
Reported-by: Amit Langote  
Author: Amit Langote  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0359d832128485840bd7dcf0b09646ad752f6a72    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Jan 2019 13:39:00 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 23 Jan 2019 13:39:00 +0200    

Spotted mostly by Fabien Coelho.  
  
Discussion: https://www.postgresql.org/message-id/alpine.DEB.2.21.1901230947050.16643@lancre  

commit   : 77002ad375a8ca6b7587560208303cf2555d62bb    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Wed, 23 Jan 2019 13:14:52 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Wed, 23 Jan 2019 13:14:52 +0900    

In other places that has been changed from http://www.oasis-open.org/  
https://www.oasis-open.org/ but there's a place where the change was  
missed.  
Discussion: https://postgr.es/m/20190121.222844.399814306477973879.t-ishii%40sraoss.co.jp  

commit   : f6192660ab861a9308bc5d1d4613b71f896aeac6    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 22 Jan 2019 11:46:59 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 22 Jan 2019 11:46:59 -0800    

Author: Amit Langote  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, where llvm was introduced.  

commit   : f305e8457d1e19eb4e6f4e16f42061ebaf7cb509    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jan 2019 23:18:58 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jan 2019 23:18:58 -0500    

ecpglib attempts to force the LC_NUMERIC locale to "C" while reading  
server output, to avoid problems with strtod() and related functions.  
Historically it's just issued setlocale() calls to do that, but that  
has major problems if we're in a threaded application.  setlocale()  
itself is not required by POSIX to be thread-safe (and indeed is not,  
on recent OpenBSD).  Moreover, its effects are process-wide, so that  
we could cause unexpected results in other threads, or another thread  
could change our setting.  
  
On platforms having uselocale(), which is required by POSIX:2008,  
we can avoid these problems by using uselocale() instead.  Windows  
goes its own way as usual, but we can make it safe by using  
_configthreadlocale().  Platforms having neither continue to use the  
old code, but that should be pretty much nobody among current systems.  
  
(Subsequent buildfarm results show that recent NetBSD versions still  
lack uselocale(), but it's not a big problem because they also do not  
support non-"C" settings for LC_NUMERIC.)  
  
Back-patch of commits 8eb4a9312 and ee27584c4.  
  
Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7fbdefd30e7c644bd7c6ec0799abb49584e01477    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jan 2019 18:33:32 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jan 2019 18:33:32 -0500    

Seems to be from a bad case of copy-and-paste-itis in commit 665d1fad9.  
It wouldn't be quite so annoying if it didn't contradict the comment  
half a dozen lines above.  
  
David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f95Dyf8Qkdz4W+PbCmT-HTb54tkqUCC8isa2RVgSJ_pXQ@mail.gmail.com  

commit   : 123cc697a8eb0827e82ceea3f6da55b2f05eb422    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 21 Jan 2019 19:59:07 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 21 Jan 2019 19:59:07 -0300    

Detaching a partition from a partitioned table that's constrained by  
foreign keys requires additional action triggers on the referenced side;  
otherwise, DELETE/UPDATE actions there fail to notice rows in the table  
that was partition, and so are incorrectly allowed through.  With this  
commit, those triggers are now created.  Conversely, when a table that  
has a foreign key is attached as a partition to a table that also has  
the same foreign key, those action triggers are no longer needed, so we  
remove them.  
  
Add a minimal test case verifying (part of) this.  
  
Authors: Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  

commit   : a7474308ceafb6d73730507165f45ffdbd5429c8    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 21 Jan 2019 19:34:11 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 21 Jan 2019 19:34:11 -0300    

Back in commit 100340e2dcd0, we made relcache entries keep lists of the  
foreign keys applying to the relation -- but we forgot to update  
CacheInvalidateHeapTuple to flush those entries when new FKs got created  
or existing ones updated/deleted.  No bugs appear to have been reported  
that would be explained by this ommission, but I noticed the problem  
while working on an unrelated bugfix which clearly showed it.  Fix by  
adding relcache flush on relevant foreign key changes.  
  
Backpatch to 9.6, like the aforementioned commit.  
  
Discussion: https://postgr.es/m/[email protected]  
Reviewed-by: Tom Lane  

commit   : aa47fa8532effa95cb9ca6dbd2baba8a620bf67e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 21 Jan 2019 14:41:44 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 21 Jan 2019 14:41:44 -0300    

Per note from Erik Rijkers  
Discussion: https://postgr.es/m/[email protected]  

commit   : 93f80cc2d75866cb6c53ce8e1addac47f6b61d67    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Jan 2019 11:28:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Jan 2019 11:28:03 -0500    

This reverts commit 458a1244f1fcf407874482a93b7631ecf5303d6e.  
It has portability problems on Windows, which will require  
a little bit of research to fix.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : b10e3bba86731b53467b33533ca52a1d432163b2    
  
author   : Etsuro Fujita <[email protected]>    
date     : Mon, 21 Jan 2019 17:46:15 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Mon, 21 Jan 2019 17:46:15 +0900    

Previously, in set_append_rel_size(), we generated tlists and EC members  
for dummy children for possible use by partition-wise join, even if  
partition-wise join was disabled or the top parent was not a partitioned  
table, but adding such EC members causes noticeable planning speed  
degradation for queries with certain kinds of join quals like  
"(foo.x + bar.y) = constant" where foo and bar are partitioned tables in  
cases where there are lots of dummy children, as the EC members lists  
grow huge, especially for the ECs derived from such join quals, which  
makes the search for the parent EC members in add_child_rel_equivalences()  
very time-consuming.  Postpone the work until such children are actually  
involved in a partition-wise join.  
  
Reported-by: Sanyo Capobiango  
Analyzed-by: Justin Pryzby and Alvaro Herrera  
Author: Amit Langote, with a few additional changes by me  
Reviewed-by: Ashutosh Bapat  
Backpatch-through: v11 where partition-wise join was added  
Discussion: https://postgr.es/m/CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR%2BpqjF%3DrmKBTgpw%40mail.gmail.com  

commit   : 0ec29785c52cfd400d3106d6606f150ed2356b11    
  
author   : Tomas Vondra <[email protected]>    
date     : Sat, 19 Jan 2019 20:48:02 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Sat, 19 Jan 2019 20:48:02 +0100    

This reverts commit bf070ce09e05943d6484de0ec17c7b02f2690a6d.  
  
Per discussion, it's not desirable to add valgrind suppressions for  
outside our own code base (e.g. glibc in this case), especially when  
the suppressions may be platform-specific. There are better ways to  
deal with that, e.g. by providing local suppressions.  
  
Discussion: https://www.postgresql.org/message-id/flat/90ac0452-e907-e7a4-b3c8-15bd33780e62%402ndquadrant.com  

commit   : 5279c8d097a1346e3dddbed7c0002c735aa23f73    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 19 Jan 2019 09:34:24 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 19 Jan 2019 09:34:24 +0100    

The issue the comment is referring to was fixed by  
08859bb5c2cebc132629ca838113d27bb31b990c.  

commit   : e14536f79ea7ab70f0566b2e85c164af6a333829    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Jan 2019 15:23:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Jan 2019 15:23:44 -0500    

Avoids issues if build directory's pathname contains regex  
metacharacters.  
  
Raúl Marín Rodríguez  
  
Discussion: https://postgr.es/m/CAM6_UM6dGdU39PKAC24T+HD9ouy0jLN9vH6163K8QEEzr__iZw@mail.gmail.com  

commit   : e4ffa0dcb797d625d590ff25d232d1bbc991aa28    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 18 Jan 2019 15:06:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 18 Jan 2019 15:06:26 -0500    

Recent OpenBSD (at least 5.9 and up) has a version of getopt(3)  
that will not cope with the "-:" spec we use to accept double-dash  
options in postgres.c and postmaster.c.  Admittedly, that's a hack  
because POSIX only requires getopt() to allow alphanumeric option  
characters.  I have no desire to find another way, however, so  
let's just do what we were already doing on Solaris: force use  
of our own src/port/getopt.c implementation.  
  
In passing, improve some of the comments around said implementation.  
  
Per buildfarm and local testing.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4dff8935fbab64aef38470424cc57dbda9efa1cf    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 18 Jan 2019 14:49:40 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 18 Jan 2019 14:49:40 -0300    

When creating a foreign key in a partitioned table, if some partitions  
already have equivalent constraints, we wastefully create duplicates of  
the constraints instead of attaching to the existing ones.  That's  
inconsistent with the de-duplication that is applied when a table is  
attached as a partition.  To fix, reuse the FK-cloning code instead of  
having a separate code path.  
  
Backpatch to Postgres 11.  This is a subtle behavior change, but surely  
a welcome one since there's no use in having duplicate foreign keys.  
  
Discovered by Álvaro Herrera while thinking about a different problem  
reported by Jesper Pedersen (bug #15587).  
  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/[email protected]  

commit   : fca6cabed17c4960224408d44e3d384b560b78f5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 18 Jan 2019 14:49:27 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 18 Jan 2019 14:49:27 -0300    

My commit 3de241dba86f introduced some code to create a clone of a  
foreign key to a partition, but I put it in pg_constraint.c because it  
was too close to the contents of the pg_constraint row.  With the  
previous commit that split out the constraint tuple deconstruction into  
its own routine, it makes more sense to have the FK-cloning function in  
tablecmds.c, mostly because its static subroutine can then be used by a  
future bugfix.  
  
My initial posting of this patch had this routine as static in  
tablecmds.c, but sadly this function is already part of the Postgres 11  
ABI as exported from pg_constraint.c, so keep it as exported also just  
to avoid breaking any possible users of it.  

commit   : e974f223abb473ba62577261378ca740c641814f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 18 Jan 2019 14:40:13 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 18 Jan 2019 14:40:13 -0300    

My commit 3de241dba86f introduced some code (in tablecmds.c) to obtain  
data from a pg_constraint row for a foreign key, that already existed in  
ri_triggers.c.  Split it out into its own routine in pg_constraint.c,  
where it naturally belongs.  
  
No functional code changes, only code movement.  
  
Backpatch to pg11, because a future bugfix is simpler after this.  

commit   : 3daac78d983f7be1c824ce625c8e92f42ebf41fe    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 18 Jan 2019 10:51:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 18 Jan 2019 10:51:47 +0900    

current_schema() gets called in the recently-added regression test from  
c5660e0, and can be used in a parallel context, causing its call to fail  
when creating a temporary schema.  
  
Per buildfarm members crake and lapwing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 43404015955804dd6ff10563f4f78f5f352dbe25    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 17 Jan 2019 19:31:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 17 Jan 2019 19:31:03 -0500    

I've had enough of "fixing" this test case.  Whatever value it has  
is limited to verifying that pgbench fails for an unrecognized switch,  
and we don't need to assume anything about what getopt_long prints in  
order to do that.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3e4fdb3bc0dc3314a0396bc7067afb40e0df186e    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 18 Jan 2019 09:21:52 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 18 Jan 2019 09:21:52 +0900    

Attempting to use a temporary table within a two-phase transaction is  
forbidden for ages.  However, there have been uncovered grounds for  
a couple of other object types and commands which work on temporary  
objects with two-phase commit.  In short, trying to create, lock or drop  
an object on a temporary schema should not be authorized within a  
two-phase transaction, as it would cause its state to create  
dependencies with other sessions, causing all sorts of side effects with  
the existing session or other sessions spawned later on trying to use  
the same temporary schema name.  
  
Regression tests are added to cover all the grounds found, the original  
report mentioned function creation, but monitoring closer there are many  
other patterns with LOCK, DROP or CREATE EXTENSION which are involved.  
One of the symptoms resulting in combining both is that the session  
which used the temporary schema is not able to shut down completely,  
waiting for being able to drop the temporary schema, something that it  
cannot complete because of the two-phase transaction involved with  
temporary objects.  In this case the client is able to disconnect but  
the session remains alive on the backend-side, potentially blocking  
connection backend slots from being used.  Other problems reported could  
also involve server crashes.  
  
This is back-patched down to v10, which is where 9b013dc has introduced  
MyXactFlags, something that this patch relies on.  
  
Reported-by: Alexey Bashtanov  
Author: Michael Paquier  
Reviewed-by: Masahiko Sawada  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : ef2cd88fb0f3a62312bdd33c8f5f36b9b18fc1ac    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 17 Jan 2019 13:42:40 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 17 Jan 2019 13:42:40 +0100    

The namespace for all lists have changed a while ago, so all references  
should use the correct address.  

commit   : bbccf9a83c22b38f5d8ae061560639e2c06bcded    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 17 Jan 2019 13:35:34 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 17 Jan 2019 13:35:34 +0100    

Lists are not handled by Majordomo anymore and haven't been for a while,  
so remove the reference and instead direct people to the list server.  

commit   : e74d8c5085aaf132be55670e8db5b019c7c3f4d3    
  
author   : Andrew Gierth <[email protected]>    
date     : Thu, 17 Jan 2019 05:33:01 +0000    
  
committer: Andrew Gierth <[email protected]>    
date     : Thu, 17 Jan 2019 05:33:01 +0000    

Previously, parseCheckAggregates was run before  
assign_query_collations, but this causes problems if any expression  
has already had a collation assigned by some transform function (e.g.  
transformCaseExpr) before parseCheckAggregates runs. The differing  
collations would cause expressions not to be recognized as equal to  
the ones in the GROUP BY clause, leading to spurious errors about  
unaggregated column references.  
  
The result was that CASE expr WHEN val ... would fail when "expr"  
contained a GROUPING() expression or matched one of the group by  
expressions, and where collatable types were involved; whereas the  
supposedly identical CASE WHEN expr = val ... would succeed.  
  
Backpatch all the way; this appears to have been wrong ever since  
collations were introduced.  
  
Per report from Guillaume Lelarge, analysis and patch by me.  
  
Discussion: https://postgr.es/m/CAECtzeVSO_US8C2Khgfv54ZMUOBR4sWq+6_bLrETnWExHT=rFg@mail.gmail.com  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6afea53c30d9ec841d593651ab7ae252801f64c5    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 15 Jan 2019 08:47:08 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 15 Jan 2019 08:47:08 +0900    

These have been found while cross-checking for the use of unique words  
in the documentation, and a wait event was not getting generated in a way  
consistent to what the documentation provided.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

commit   : 74aa7e046e4a3927d506bc651261724539f67139    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 14 Jan 2019 19:25:19 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 14 Jan 2019 19:25:19 -0300    

We were considering the INCLUDE columns as part of the key, allowing  
unicity-violating rows to be inserted in different partitions.  
  
Concurrent development conflict in eb7ed3f30634 and 8224de4f42cc.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/[email protected]  

commit   : 20b4ed8d03047501cc28b600973564850bd1dd80    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 13 Jan 2019 16:43:14 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 13 Jan 2019 16:43:14 -0500    

commit   : f0566cec3a9fd67d30612afbe6dc4cf602641efa    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 13 Jan 2019 15:59:35 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 13 Jan 2019 15:59:35 -0500    

This will enable things like the buildfarm client to discover more  
reliably if certain libraries have been installed.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches.  

commit   : 0f514dd78f673080511f9fa7749e6e312a1ddd9b    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 13 Jan 2019 11:32:31 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Sun, 13 Jan 2019 11:32:31 -0800    

This especially helps braces that surround code blocks.  Back-patch to  
v11, where commit 56fb890ace8ac0ca955ae0803c580c2074f876f6 first  
appeared; before that, settings were even more distant from perltidy.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3d498c65ac6ed69aa6ede68186420b3c0dadf3c7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 11 Jan 2019 15:45:15 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 11 Jan 2019 15:45:15 +0100    

Some systems don't ship with "python" by default anymore, only  
"python3" or "python2" or some combination, so include those in the  
configure search.  
  
Discussion: https://www.postgresql.org/message-id/flat/1457.1543184081%40sss.pgh.pa.us#c9cc1199338fd6a257589c6dcea6cf8d  

commit   : f285f23970dee5ab9ac67a415a41a3a19010be87    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 11 Jan 2019 17:39:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 11 Jan 2019 17:39:30 -0500    

Some makefiles were trying to do this:  
  
temp-install: EXTRA_INSTALL=contrib/test_decoding  
  
but that no longer works as of commit aa019da52: the macro is now  
consulted by the checkprep target, one level down, and apparently  
gmake doesn't propagate such macro settings recursively.  
  
The problem is masked since 42e61c774 because pgxs.mk also sets up  
EXTRA_INSTALL, and correctly applies it to the checkprep target.  
  
Unfortunately I'd not risked back-patching that to before v11.  
Since aa019da52 was pushed back to v10, it broke test_decoding  
there (the only module for which this actually makes a difference  
at present).  
  
Hence, back-patch 42e61c774 to v10.  Also, remove some demonstrably  
useless settings of EXTRA_INSTALL in v10 and v11 (they'd already  
been cleaned up in HEAD).  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/CAEepm=1pEJdwv6DSGmOfpX0EaX7L7sT28c1nXpqvQvmLfEWb1g@mail.gmail.com  

commit   : 89d52b9a3e3fab3d6876c997370684a8b1c77f3b    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 11 Jan 2019 17:12:54 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 11 Jan 2019 17:12:54 -0500    

This was an oversight in commit 3b174b1a3.  
  
Per offline gripe from Alvaro Herrera  
  
Backpatch to release 11.  

commit   : 05eb923eae46c1698088d555ae590a73d4fc7070    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 11 Jan 2019 15:53:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 11 Jan 2019 15:53:34 -0500    

Up to now, createplan.c attempted to share PARAM_EXEC slots for  
NestLoopParams across different plan levels, if the same underlying Var  
was being fed down to different righthand-side subplan trees by different  
NestLoops.  This was, I think, more of an artifact of using subselect.c's  
PlannerParamItem infrastructure than an explicit design goal, but anyway  
that was the end result.  
  
This works well enough as long as the plan tree is executing synchronously,  
but the feature whereby Gather can execute the parallelized subplan locally  
breaks it.  An upper NestLoop node might execute for a row retrieved from  
a parallel worker, and assign a value for a PARAM_EXEC slot from that row,  
while the leader's copy of the parallelized subplan is suspended with a  
different active value of the row the Var comes from.  When control  
eventually returns to the leader's subplan, it gets the wrong answers if  
the same PARAM_EXEC slot is being used within the subplan, as reported  
in bug #15577 from Bartosz Polnik.  
  
This is pretty reminiscent of the problem fixed in commit 46c508fbc, and  
the proper fix seems to be the same: don't try to share PARAM_EXEC slots  
across different levels of controlling NestLoop nodes.  
  
This requires decoupling NestLoopParam handling from PlannerParamItem  
handling, although the logic remains somewhat similar.  To avoid bizarre  
division of labor between subselect.c and createplan.c, I decided to move  
all the param-slot-assignment logic for both cases out of those files  
and put it into a new file paramassign.c.  Hopefully it's a bit better  
documented now, too.  
  
A regression test case for this might be nice, but we don't know a  
test case that triggers the problem with a suitably small amount  
of data.  
  
Back-patch to 9.6 where we added Gather nodes.  It's conceivable that  
related problems exist in older branches; but without some evidence  
for that, I'll leave the older branches alone.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : c559d8dbf9e7871c64ecc976199cc89765a6cee8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 11 Jan 2019 17:21:45 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 11 Jan 2019 17:21:45 +0100    

Since approximately PostgreSQL 10, it is no longer required that  
environment variables at installation time such as PERL, PYTHON, TCLSH  
be "full path names", so change that phrasing in the installation  
instructions.  (The exact time of change appears to differ for PERL  
and the others, but it works consistently in PostgreSQL 10.)  
  
Also while we're here document the defaults for PERL and PYTHON, but  
since the search list for TCLSH is so long, let's leave that out so we  
don't need to maintain a copy of that list in the installation  
instructions.  

commit   : 076ffbcb5f45eeffb20940842e0f45bdcb4a32fc    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 10 Jan 2019 15:53:45 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 10 Jan 2019 15:53:45 -0500    

This was an oversight in commit 16828d5c. If the table is going to be  
rewritten, we simply clear all the missing values from all the table's  
attributes, since there will no longer be any rows with the attributes  
missing. Otherwise, we repackage the missing value in an array  
constructed with the new type specifications.  
  
Backpatch to release 11.  
  
This fixes bug #15446, reported by Dmitry Molotkov  
  
Reviewed by Dean Rasheed  

commit   : 312d21d8635065c14d392b4e5469e7abc03f2bde    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Jan 2019 11:35:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Jan 2019 11:35:14 -0500    

For a long time, plpgsql has allowed trigger functions to parse  
references to OLD and NEW even if the current trigger event type didn't  
assign a value to one or the other variable; but actually executing such  
a reference would fail.  The v11 changes to use "expanded records" for  
DTYPE_REC variables changed the behavior so that the unassigned variable  
now reads as a null composite value.  While this behavioral change was  
more or less unintentional, it seems that leaving it like this is better  
than adding code and complexity to be bug-compatible with the old way.  
The change doesn't break any code that worked before, and it eliminates  
a gotcha that often required extra code to work around.  
  
Hence, update the docs to say that these variables are "null" not  
"unassigned" when not relevant to the event type.  And add a regression  
test covering the behavior, so that we'll notice if we ever break it  
again.  
  
Per report from Kristjan Tammekivi.  
  
Discussion: https://postgr.es/m/CAABK7uL-uC9ZxKBXzo_68pKt7cECfNRv+c35CXZpjq6jCAzYYA@mail.gmail.com  

commit   : f2e14c2a69147927b7ba090a7ba5a13b2b2b7d5f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 8 Jan 2019 12:03:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 8 Jan 2019 12:03:53 -0500    

runtime.sgml said that you couldn't change SysV IPC parameters on OpenBSD  
except by rebuilding the kernel.  That's definitely wrong in OpenBSD 6.x,  
and excavation in their man pages says it changed in OpenBSD 3.3.  
  
Update NetBSD and OpenBSD sections to recommend adjustment of the SEMMNI  
and SEMMNS settings, which are painfully small by default on those  
platforms.  (The discussion thread contemplated recommending that  
people select POSIX semaphores instead, but the performance consequences  
of that aren't really clear, so I'll refrain.)  
  
Remove pointless discussion of SEMMNU and SEMMAP from the FreeBSD  
section.  Minor other wordsmithing.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6ce6d983224a8cf00ff34bb3dd6c9d734d9bae86    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 8 Jan 2019 09:55:18 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 8 Jan 2019 09:55:18 +0900    

Acronym "btree" better means "multi-way balanced tree" rather than  
"multi-way binary tree".  
  
Discussion: https://postgr.es/m/20190105.183532.1686260542006440682.t-ishii%40sraoss.co.jp  

commit   : 7de8c719d3becdb4dcbefbae53c03c588a0ea699    
  
author   : Andrew Gierth <[email protected]>    
date     : Mon, 7 Jan 2019 18:19:46 +0000    
  
committer: Andrew Gierth <[email protected]>    
date     : Mon, 7 Jan 2019 18:19:46 +0000    

In passing add a couple of links to the message severity table.  
  
Backpatch because it's always been this way.  
  
Author: Karl O. Pinc <[email protected]>  

commit   : fc8adddd9af24737e46006dcdf12b98c3e195fd7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Jan 2019 17:00:08 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Jan 2019 17:00:08 -0500    

This patch changes the rule for whether or not a tuple seen by ANALYZE  
should be included in its sample.  
  
When we last touched this logic, in commit 51e1445f1, we weren't  
thinking very hard about tuples being UPDATEd by a long-running  
concurrent transaction.  In such a case, we might see the pre-image as  
either LIVE or DELETE_IN_PROGRESS depending on timing; and we might see  
the post-image not at all, or as INSERT_IN_PROGRESS.  Since the existing  
code will not sample either DELETE_IN_PROGRESS or INSERT_IN_PROGRESS  
tuples, this leads to concurrently-updated rows being omitted from the  
sample entirely.  That's not very helpful, and it's especially the wrong  
thing if the concurrent transaction ends up rolling back.  
  
The right thing seems to be to sample DELETE_IN_PROGRESS rows just as if  
they were live.  This makes the "sample it" and "count it" decisions the  
same, which seems good for consistency.  It's clearly the right thing  
if the concurrent transaction ends up rolling back; in effect, we are  
sampling as though IN_PROGRESS transactions haven't happened yet.  
Also, this combination of choices ensures maximum robustness against  
the different combinations of whether and in which state we might see the  
pre- and post-images of an update.  
  
It's slightly annoying that we end up recording immediately-out-of-date  
stats in the case where the transaction does commit, but on the other  
hand the stats are fine for columns that didn't change in the update.  
And the alternative of sampling INSERT_IN_PROGRESS rows instead seems  
like a bad idea, because then the sampling would be inconsistent with  
the way rows are counted for the stats report.  
  
Per report from Mark Chambers; thanks to Jeff Janes for diagnosing  
what was happening.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/CAFh58O_Myr6G3tcH3gcGrF-=OExB08PJdWZcSBcEcovaiPsrHA@mail.gmail.com  

commit   : 1b0294d9a02cf77392fe71387813a0614a808782    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 3 Jan 2019 15:06:53 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 3 Jan 2019 15:06:53 +0100    

Debian testing and newer now require that RSA and DHE keys are at  
least 2048 bit long and no longer allow SHA-1 for signatures in  
certificates.  This is currently causing the ssl tests to fail there  
because the test certificates and keys have been created in violation  
of those conditions.  
  
Update the parameters to create the test files and create a new set of  
test files.  
  
Author: Kyotaro HORIGUCHI <[email protected]>  
Reported-by: Michael Paquier <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/20180917131340.GE31460%40paquier.xyz  

commit   : 099063340bb1f82cc3e156e5558f6c456b41bfa5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 2 Jan 2019 16:33:48 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 2 Jan 2019 16:33:48 -0500    

MinMaxExpr invokes the btree comparison function for its input datatype,  
so it's only leakproof if that function is.  Many such functions are  
indeed leakproof, but others are not, and we should not just assume that  
they are.  Hence, adjust contain_leaked_vars to verify the leakproofness  
of the referenced function explicitly.  
  
I didn't add a regression test because it would need to depend on  
some particular comparison function being leaky, and that's a moving  
target, per discussion.  
  
This has been wrong all along, so back-patch to supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 7cf8879fe61e330aa55154b16b750bb19d6c6e97    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 2 Jan 2019 12:44:25 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 2 Jan 2019 12:44:25 -0500    

Backpatch-through: certain files through 9.4  

commit   : 2882bab920a41186ed9ec719947b1e730fd335a8    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 1 Jan 2019 10:39:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 1 Jan 2019 10:39:29 +0900    

fe0a0b5, which has added a stronger random source in Postgres, has  
introduced a thinko when creating a padding message which gets encrypted  
for Elgamal.  The padding message cannot have zeros, which are replaced  
by random bytes.  However if pg_strong_random() failed, the message  
would finish by being considered in correct shape for encryption with  
zeros.  
  
Author: Tom Lane  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : 6dd690be366148ad0cd9a7f99ca094d89aa76f02    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 31 Dec 2018 13:54:38 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 31 Dec 2018 13:54:38 -0800    

This closes a race condition in "make -j check-world"; the symptom was  
EEXIST errors.  Back-patch to v10, before which parallel check-world had  
worse problems.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 95fae739af68b27c5c555ffe10c4c98f2a6a3cdd    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 31 Dec 2018 13:53:05 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 31 Dec 2018 13:53:05 -0800    

We already redirected other temp-install stderr and all temp-install  
stdout in this way.  Back-patch to v10, like the next commit.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : ca01a6748d0bfb594128833fec6a64e6d092d37f    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 31 Dec 2018 13:50:32 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 31 Dec 2018 13:50:32 -0800    

Detect it the way pg_ctl's wait_for_postmaster() does.  When pg_regress  
spawned a postmaster that failed startup, we were detecting that only  
with "pg_regress: postmaster did not respond within 60 seconds".  
Back-patch to 9.4 (all supported versions).  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 025cc86b77052ee130519ce2dcfa52abeedc5bef    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 29 Dec 2018 13:02:51 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 29 Dec 2018 13:02:51 +0100    

commit   : 6a19384e74a8d8510d06e85b3956136bd30d4733    
  
author   : Michael Paquier <[email protected]>    
date     : Sat, 29 Dec 2018 08:24:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sat, 29 Dec 2018 08:24:47 +0900    

This was incorrectly referring to --walsegsize, and its description is  
rewritten in a clearer way.  
  
Author: Ian Barwick, Tom Lane  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : d58e01f8abe2de106516073b39391c466aaab5f6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 28 Dec 2018 14:08:24 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 28 Dec 2018 14:08:24 -0500    

POSIX specifies that jrand48() returns a signed 32-bit value (in the  
range [-2^31, 2^31)), but our code was returning an unsigned 32-bit  
value (in the range [0, 2^32)).  This doesn't actually matter to any  
existing call site, because they all cast the "long" result to int32  
or uint32; but it will doubtless bite somebody in the future.  
To fix, cast the arithmetic result to int32 explicitly before the  
compiler widens it to long (if widening is needed).  
  
While at it, upgrade this file's far-short-of-project-style comments.  
Had there been some peer pressure to document pg_jrand48() properly,  
maybe this thinko wouldn't have gotten committed to begin with.  
  
Backpatch to v10 where pg_jrand48() was added, just in case somebody  
back-patches a fix that uses it and depends on the standard behavior.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : fcdda202bcf8fa71e1b919f62d3bb96f610ff25f    
  
author   : Alexander Korotkov <[email protected]>    
date     : Fri, 28 Dec 2018 03:33:10 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Fri, 28 Dec 2018 03:33:10 +0300    

Isolation test suite of GIN predicate locking was criticized for being too slow,  
especially under Valgrind.  This commit is intended to accelerate it.  Tests are  
simplified in the following ways.  
  
  1) Amount of data is reduced.  We're now close to the minimal amount of data,  
     which produces at least one posting tree and at least two pages of entry  
     tree.  
  2) Three isolation tests are merged into one.  
  3) Only one tuple is queried from posting tree.  So, locking of index is the  
     same, but tuple locks are not propagated to relation lock.  Also, it is  
     faster.  
  4) Test cases itself are simplified.  Now each test case run just one INSERT  
     and one SELECT involving GIN, which either conflict or not.  
  
Discussion: https://postgr.es/m/20181204000740.ok2q53nvkftwu43a%40alap3.anarazel.de  
Reported-by: Andres Freund  
Tested-by: Andrew Dunstan  
Author: Alexander Korotkov  
Backpatch-through: 11  

commit   : fd7c081955929df343318d6c5d32ea24a574aacf    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 27 Dec 2018 04:10:51 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 27 Dec 2018 04:10:51 +0300    

According to README we acquire predicate locks on entry tree leafs and posting  
tree roots.  However, when ginFindLeafPage() is going to lock leaf in exclusive  
mode, then it checks root for conflicts regardless whether it's a entry or  
posting tree.  Assuming that we never place predicate lock on entry tree root  
(excluding corner case when root is leaf), this check is redundant.  This  
commit removes this check.  Now, root conflict checking is controlled by  
separate argument of ginFindLeafPage().  
  
Discussion: https://postgr.es/m/CAPpHfdv7rrDyy%3DMgsaK-L9kk0AH7az0B-mdC3w3p0FSb9uoyEg%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 11  

commit   : b30b9dce1f40499949fd3749265acf1b379102dc    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 27 Dec 2018 10:17:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 27 Dec 2018 10:17:09 +0900    

Inheritance trees can include temporary tables if the parent is  
permanent, which makes possible the presence of multiple temporary  
children from different sessions.  Trying to issue a TRUNCATE on the  
parent in this scenario causes a failure, so similarly to any other  
queries just ignore such cases, which makes TRUNCATE work  
transparently.  
  
This makes truncation behave similarly to any other DML query working on  
the parent table with queries which need to be issues on children.  A  
set of isolation tests is added to cover basic cases.  
  
Reported-by: Zhou Digoal  
Author: Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 47c93ace9fd1e3ed90defb3a478ad2287342b22d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 26 Dec 2018 15:30:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 26 Dec 2018 15:30:10 -0500    

I made a frontend fprintf() format use %m, forgetting that that's only  
safe in HEAD not the back branches; prior to 96bf88d52 and d6c55de1f,  
it would work on glibc platforms but not elsewhere.  Revert to using  
%s ... strerror(errno) as the code did before.  
  
We could have left HEAD as-is, but for code consistency across branches,  
I chose to apply this patch there too.  
  
Per Coverity and a few buildfarm members.  

commit   : a016f59d5901ce37f28e58b622169b579258c2e0    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 24 Dec 2018 20:25:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 24 Dec 2018 20:25:49 +0900    

At the end of recovery for the post-promotion process, a new history  
file is created followed by the last partial segment of the previous  
timeline.  Based on the timing, the archiver would first try to archive  
the last partial segment and then the history file.  This can delay the  
detection of a new timeline taken, particularly depending on the time it  
takes to transfer the last partial segment as it delays the moment the  
history file of the new timeline gets archived.  This can cause promoted  
standbys to use the same timeline as one already taken depending on the  
circumstances if multiple instances look at archives at the same  
location.  
  
This commit changes the order of archiving so as history files are  
archived in priority over other file types, which reduces the likelihood  
of the same timeline being taken (still not reducing the window to  
zero), and it makes the archiver behave more consistently with the  
startup process doing its post-promotion business.  
  
Author: David Steele  
Reviewed-by: Michael Paquier, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.5  

commit   : ff9c222669063d7a17b179bc19617caf9c1f67ea    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 23 Dec 2018 16:43:47 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 23 Dec 2018 16:43:47 +0900    

COPY can skip writing WAL when loading data on a table which has been  
created in the same transaction as the one loading the data, however  
this cannot work on views or foreign table as this would result in  
trying to flush relation files which do not exist.  So disable the  
optimization so as commands are able to work the same way with any  
configuration of wal_level.  
  
Tests are added to cover the different cases, which need to have  
wal_level set to minimal to allow the problem to show up, and that is  
not the default configuration.  
  
Reported-by: Luis M. Carril, Etsuro Fujita  
Author: Amit Langote, Michael Paquier  
Reviewed-by: Etsuro Fujita  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10, where support for COPY on views has been added,  
while v11 has added support for COPY on foreign tables.  

commit   : 018923ccc1a68eeac852edeac2ba3bc91dcbd494    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 22 Dec 2018 07:21:40 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 22 Dec 2018 07:21:40 +0100    

This has never been correct since this code was introduced.  

commit   : 8193d64072c46e75fe94065111099ee3b2658769    
  
author   : Alexander Korotkov <[email protected]>    
date     : Fri, 21 Dec 2018 02:37:31 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Fri, 21 Dec 2018 02:37:31 +0300    

013ebc0a7b implements so-called GiST microvacuum.  That is gistgettuple() marks  
index tuples as dead when kill_prior_tuple is set.  Later, when new tuple  
insertion claims page space, those dead index tuples are physically deleted  
from page.  When this deletion is replayed on standby, it might conflict with  
read-only queries.  But 013ebc0a7b doesn't handle this.  That may lead to  
disappearance of some tuples from read-only snapshots on standby.  
  
This commit implements resolving of conflicts between replay of GiST microvacuum  
and standby queries.  On the master we implement new WAL record type  
XLOG_GIST_DELETE, which comprises necessary information.  On stable releases  
we've to be tricky to keep WAL compatibility.  Information required for conflict  
processing is just appended to data of XLOG_GIST_PAGE_UPDATE record.  So,  
PostgreSQL version, which doesn't know about conflict processing, will just  
ignore that.  
  
Reported-by: Andres Freund  
Diagnosed-by: Andres Freund  
Discussion: https://postgr.es/m/20181212224524.scafnlyjindmrbe6%40alap3.anarazel.de  
Author: Alexander Korotkov  
Backpatch-through: 9.6  

commit   : 053ad56d275d343b407bc5fd389bad6f3e340562    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 20 Dec 2018 16:42:13 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 20 Dec 2018 16:42:13 -0300    

For probably bogus reasons, we acquire only AccessShareLock on the  
partition when we try to detach it from its parent partitioned table.  
This can cause ugly things to happen if another transaction is doing  
any sort of DDL to the partition concurrently.  
  
Upgrade that lock to ShareUpdateExclusiveLock, which per discussion  
seems to be the minimum needed.  
  
Reported by Robert Haas.  
  
Discussion: https://postgr.es/m/CA+TgmoYruJQ+2qnFLtF1xQtr71pdwgfxy3Ziy-TxV28M6pEmyA@mail.gmail.com  

commit   : 4e4c0d66866c0d54ec33ef987204cdec729a741b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Dec 2018 13:55:11 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Dec 2018 13:55:11 -0500    

"$user" in a search_path string is replaced by CURRENT_USER not  
SESSION_USER.  (It actually was SESSION_USER in the initial implementation,  
but we changed it shortly later, and evidently forgot to fix the docs to  
match.)  
  
Noted by [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 9bb2ce5ec765e2c886af369fa3ba57f98db014e3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 20 Dec 2018 10:58:22 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 20 Dec 2018 10:58:22 -0300    

When a partition is detached from its parent, we acquire locks on all  
attached indexes to also detach them ... but we release those locks  
immediately.  This is a violation of the policy of keeping locks on user  
objects to the end of the transaction.  Bug introduced in 8b08f7d4820f.  
  
It's unclear that there are any ill effects possible, but it's clearly  
wrong nonetheless.  It's likely that bad behavior *is* possible, but  
mostly because the relation that the index is for is only locked with  
AccessShareLock, which is an older bug that shall be fixed separately.  
  
While touching that line of code, close the index opened with  
index_open() using index_close() instead of relation_close().  
No difference in practice, but let's be consistent.  
  
Unearthed by Robert Haas.  
  
Discussion: https://postgr.es/m/CA+TgmoYruJQ+2qnFLtF1xQtr71pdwgfxy3Ziy-TxV28M6pEmyA@mail.gmail.com  

commit   : 128ce8e1a18ed7a83dd0f8dbe7bfb00eb73f200b    
  
author   : Greg Stark <[email protected]>    
date     : Wed, 19 Dec 2018 18:28:35 -0500    
  
committer: Greg Stark <[email protected]>    
date     : Wed, 19 Dec 2018 18:28:35 -0500    

The flag for IF NOT EXISTS was only being passed down in the normal  
recursing case. It's been this way since originally added in 9.6 in  
commit 2cd40adb85 so backpatch back to 9.6.  

commit   : c9a1c55a8b342cd00ffa810dfa63620ce6d497da    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Dec 2018 11:02:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Dec 2018 11:02:07 -0500    

Thinko in commit f66912b0a.  Back-patch to v10, as that was.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 741c4c41429b72b8140a269f578f5a87e03d6ab6    
  
author   : Peter Geoghegan <[email protected]>    
date     : Tue, 18 Dec 2018 16:59:49 -0800    
  
committer: Peter Geoghegan <[email protected]>    
date     : Tue, 18 Dec 2018 16:59:49 -0800    

Commit 40dae7ec537, which made the handling of interrupted nbtree page  
splits more robust, removed an nbtree-specific end-of-recovery cleanup  
step.  This meant that it was no longer possible to complete an  
interrupted page split during recovery.  However, a reference to  
recovery as a reason for using a NULL stack while inserting into a  
parent page was missed.  Remove the reference.  
  
Remove a similar obsolete reference to recovery that was introduced much  
more recently, as part of the btree fastpath optimization enhancement  
that made it into Postgres 11 (commit 2b272734, and follow-up commits).  
  
Backpatch: 11-, where the fastpath optimization was introduced.  

commit   : 84fcc2ce56962a82e4da633b5ba2bd68c4960cd8    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Wed, 19 Dec 2018 09:45:10 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Wed, 19 Dec 2018 09:45:10 +0900    

Issue reported by me and fix by Tom Lane.  
Discussion: https://postgr.es/m/20181219.080458.1434575730369741406.t-ishii%40sraoss.co.jp  

commit   : ad425aaf06c1059a6666180a69f3a76f8343b278    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Dec 2018 11:19:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Dec 2018 11:19:38 -0500    

"rescanratio" was computed as 1 + rescanned-tuples / total-inner-tuples,  
which is sensible if it's to be multiplied by total-inner-tuples or a cost  
value corresponding to scanning all the inner tuples.  But in reality it  
was (mostly) multiplied by inner_rows or a related cost, numbers that take  
into account the possibility of stopping short of scanning the whole inner  
relation thanks to a limited key range in the outer relation.  This'd  
still make sense if we could expect that stopping short would result in a  
proportional decrease in the number of tuples that have to be rescanned.  
It does not, however.  The argument that establishes the validity of our  
estimate for that number is independent of whether we scan all of the inner  
relation or stop short, and experimentation also shows that stopping short  
doesn't reduce the number of rescanned tuples.  So the correct calculation  
is 1 + rescanned-tuples / inner_rows, and we should be sure to multiply  
that by inner_rows or a corresponding cost value.  
  
Most of the time this doesn't make much difference, but if we have  
both a high rescan rate (due to lots of duplicate values) and an outer  
key range much smaller than the inner key range, then the error can  
be significant, leading to a large underestimate of the cost associated  
with rescanning.  
  
Per report from Vijaykumar Jain.  This thinko appears to go all the way  
back to the introduction of the rescan estimation logic in commit  
70fba7043, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAE7uO5hMb_TZYJcZmLAgO6iD68AkEK6qCe7i=vZUkCpoKns+EQ@mail.gmail.com  

commit   : da1a20a68e2e4d3f8c3d841f5ba994ab13f9cb23    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Dec 2018 10:02:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Dec 2018 10:02:39 +0900    

The project has moved to a new place.  
  
Reported-by: Peter Neave  
Discussion: https://postgr.es/m/[email protected]  

commit   : d0960eb8ab78f098beb1de2628229ac992da055c    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 18 Dec 2018 09:28:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 18 Dec 2018 09:28:56 +0900    

The new grammar pattern of ALTER INDEX SET STATISTICS able to use column  
numbers on top of the existing column names introduced by commit 5b6d13e  
forgot to add support for the feature in pg_dump, so defining statistics  
on index columns was missing from the dumps, potentially causing silent  
planning problems with a subsequent restore.  
  
pg_dump ought to not use column names in what it generates as these are  
automatically generated by the server and could conflict with real  
relation attributes with matching patterns.  "expr" and "exprN", N  
incremented automatically after the creation of the first one, are used  
as default attribute names for index expressions, and that could easily  
match what is defined in other relations, causing the dumps to fail if  
some of those attributes are renamed at some point.  So to avoid any  
problems, the new grammar with column numbers gets used.  
  
Reported-by: Ronan Dunklau  
Author: Michael Paquier  
Reviewed-by: Tom Lane, Adrien Nayrat, Amul Sul  
Discussion: https://postgr.es/m/CAARsnT3UQ4V=yDNW468w8RqHfYiY9mpn2r_c5UkBJ97NAApUEw@mail.gmail.com  
Backpatch-through: 11, where the new syntax has been introduced.  

commit   : f760a8b5cc1fa8c9d341faaf2cbda3b94d5a20d9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 17 Dec 2018 11:44:19 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 17 Dec 2018 11:44:19 -0300    

Author: Amit Langote  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/[email protected]  

commit   : f88dd4fa43b4edf4fb906e95c55a706d9508021b    
  
author   : Amit Kapila <[email protected]>    
date     : Mon, 17 Dec 2018 14:19:11 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Mon, 17 Dec 2018 14:19:11 +0530    

Reported-by: David Rowley  
Author: David Rowley  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAKJS1f8EneeYyzzvdjahVZ6gbAHFkHbSFB5m_C0Y6TUJs9Dgdg@mail.gmail.com  

commit   : e83e0988dc62026dbabad76b206bddea3d4f830e    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Dec 2018 12:43:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Dec 2018 12:43:39 +0900    

This is an oversight from recent commit b13fd344.  While on it, tweak  
the previous test with a better name for the renamed primary key.  
  
Detected by buildfarm member prion which forces relation cache release  
with -DRELCACHE_FORCE_RELEASE.  Back-patch down to 9.4 as the previous  
commit.  

commit   : 25b8094d33ac66773ba1418457cb74eb22b5d50a    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 17 Dec 2018 10:36:03 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 17 Dec 2018 10:36:03 +0900    

When a constraint gets renamed, it may have associated with it a target  
relation (for example domain constraints don't have one).  Not  
invalidating the target relation cache when issuing the renaming can  
result in issues with subsequent commands that refer to the old  
constraint name using the relation cache, causing various failures.  One  
pattern spotted was using CREATE TABLE LIKE after a constraint  
renaming.  
  
Reported-by: Stuart <[email protected]>  
Author: Amit Langote  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : b054498c74c3630348b9a35f7f4c6dc90e204643    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Dec 2018 14:51:47 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Dec 2018 14:51:47 -0500    

reap_child() basically ignored the possibility of either an error in  
waitpid() itself or a child process failure on signal.  We don't really  
need to do more than report and crash hard, but proceeding as though  
nothing is wrong is definitely Not Acceptable.  The error report for  
nonzero child exit status was pretty off-point, as well.  
  
Noted while fooling around with child-process failure detection  
logic elsewhere.  It's been like this a long time, so back-patch to  
all supported branches.  

commit   : b1894a6076f36a20338e0c3b0eb73a250ea2e47e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 16 Dec 2018 14:32:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 16 Dec 2018 14:32:14 -0500    

Commit ffa4cbd62 added logic to detect SIGPIPE failure of a COPY child  
process, but it only worked correctly if the SIGPIPE occurred in the  
immediate child process.  Depending on the shell in use and the  
complexity of the shell command string, we might instead get back  
an exit code of 128 + SIGPIPE, representing a shell error exit  
reporting SIGPIPE in the child process.  
  
We could just hack up ClosePipeToProgram() to add the extra case,  
but it seems like this is a fairly general issue deserving a more  
general and better-documented solution.  I chose to add a couple  
of functions in src/common/wait_error.c, which is a natural place  
to know about wait-result encodings, that will test for either a  
specific child-process signal type or any child-process signal failure.  
Then, adjust other places that were doing ad-hoc tests of this type  
to use the common functions.  
  
In RestoreArchivedFile, this fixes a race condition affecting whether  
the process will report an error or just silently proc_exit(1): before,  
that depended on whether the intermediate shell got SIGTERM'd itself  
or reported a child process failing on SIGTERM.  
  
Like the previous patch, back-patch to v10; we could go further  
but there seems no real need to.  
  
Per report from Erik Rijkers.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 171cae1579124a400e234f89c1fc80f3caed5f68    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Dec 2018 15:11:09 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Dec 2018 15:11:09 -0500    

The idea here is to not call recordDependencyOn for the default collation,  
since we know that's pinned.  But what the code actually did was to record  
the partition key's dependency on the opclass twice, instead.  
  
Evidently introduced by sloppy coding in commit 2186b608b.  Back-patch  
to v10 where that came in.  

commit   : dd951dc34a2ecde28cd8d686cd06de1d21f474a0    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 13 Dec 2018 06:12:31 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 13 Dec 2018 06:12:31 +0300    

When GIN vacuum deletes a posting tree page, it assumes that no concurrent  
searchers can access it, thanks to ginStepRight() locking two pages at once.  
However, since 9.4 searches can skip parts of posting trees descending from the  
root.  That leads to the risk that page is deleted and reclaimed before  
concurrent search can access it.  
  
This commit prevents the risk of above by waiting for every transaction, which  
might wait to reference this page, to finish.  Due to binary compatibility  
we can't change GinPageOpaqueData to store corresponding transaction id.  
Instead we reuse page header pd_prune_xid field, which is unused in index pages.  
  
Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com  
Author: Andrey Borodin, Alexander Korotkov  
Reviewed-by: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : 225b5c9c480fa90d4734ce4a8d1a4b46ac5e826e    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 13 Dec 2018 06:12:25 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 13 Dec 2018 06:12:25 +0300    

On standby ginRedoDeletePage() can work concurrently with read-only queries.  
Those queries can traverse posting tree in two ways.  
1) Using rightlinks by ginStepRight(), which locks the next page before  
   unlocking its left sibling.  
2) Using downlinks by ginFindLeafPage(), which locks at most one page at time.  
  
Original lock order was: page, parent, left sibling.  That lock order can  
deadlock with ginStepRight().  In order to prevent deadlock this commit changes  
lock order to: left sibling, page, parent.  Note, that position of parent in  
locking order seems insignificant, because we only lock one page at time while  
traversing downlinks.  
  
Reported-by: Chen Huajun  
Diagnosed-by: Chen Huajun, Peter Geoghegan, Andrey Borodin  
Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com  
Author: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : 9aa94d8536f81168b6de3744c1fb4a173af1cefe    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 13 Dec 2018 06:12:11 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 13 Dec 2018 06:12:11 +0300    

Before 218f51584d5 if posting tree page is about to be deleted, then the whole  
posting tree is locked by LockBufferForCleanup() on root preventing all the  
concurrent inserts.  218f51584d5 reduced locking to the subtree containing  
page to be deleted.  However, due to concurrent parent split, inserter doesn't  
always holds pins on all the pages constituting path from root to the target  
leaf page.  That could cause a deadlock between GIN vacuum process and GIN  
inserter.  And we didn't find non-invasive way to fix this.  
  
This commit reverts VACUUM behavior to lock the whole posting tree before  
delete any page.  However, we keep another useful change by 218f51584d5: the  
tree is locked only if there are pages to be deleted.  
  
Reported-by: Chen Huajun  
Diagnosed-by: Chen Huajun, Andrey Borodin, Peter Geoghegan  
Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com  
Author: Alexander Korotkov, based on ideas from Andrey Borodin and Peter Geoghegan  
Reviewed-by: Andrey Borodin  
Backpatch-through: 10  

commit   : 7465871879abdc43dad7b5f6dcf1dd4880d53f9e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Dec 2018 16:08:30 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Dec 2018 16:08:30 -0500    

postgres_fdw's postgresGetForeignPlan() assumes without checking that the  
outer_plan it's given for a join relation must have a NestLoop, MergeJoin,  
or HashJoin node at the top.  That's been wrong at least since commit  
4bbf6edfb (which could cause insertion of a Sort node on top) and it seems  
like a pretty unsafe thing to Just Assume even without that.  
  
Through blind good fortune, this doesn't seem to have any worse  
consequences today than strange EXPLAIN output, but it's clearly trouble  
waiting to happen.  
  
To fix, test the node type explicitly before touching Join-specific  
fields, and avoid jamming the new tlist into a node type that can't  
do projection.  Export a new support function from createplan.c  
to avoid building low-level knowledge about the latter into FDWs.  
  
Back-patch to 9.6 where the faulty coding was added.  Note that the  
associated regression test cases don't show any changes before v11,  
apparently because the tests back-patched with 4bbf6edfb don't actually  
exercise the problem case before then (there's no top-level Sort  
in those plans).  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 302d4eee933ec76ef91575d6129558caa64307ca    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Dec 2018 13:49:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Dec 2018 13:49:41 -0500    

Our support for multiple-set-clauses in UPDATE assumes that the Params  
referencing a MULTIEXPR_SUBLINK SubPlan will appear before that SubPlan  
in the targetlist of the plan node that calculates the updated row.  
(Yeah, it's a hack...)  In some PG branches it's possible that a Result  
node gets inserted between the primary calculation of the update tlist  
and the ModifyTable node.  setrefs.c did the wrong thing in this case  
and left the upper-level Params as Params, causing a crash at runtime.  
What it should do is replace them with "outer" Vars referencing the child  
plan node's output.  That's a result of careless ordering of operations  
in fix_upper_expr_mutator, so we can fix it just by reordering the code.  
  
Fix fix_join_expr_mutator similarly for consistency, even though join  
nodes could never appear in such a context.  (In general, it seems  
likely to be a bit cheaper to use Vars than Params in such situations  
anyway, so this patch might offer a tiny performance improvement.)  
  
The hazard extends back to 9.5 where the MULTIEXPR_SUBLINK stuff  
was introduced, so back-patch that far.  However, this may be a live  
bug only in 9.6.x and 10.x, as the other branches don't seem to want  
to calculate the final tlist below the Result node.  (That plan shape  
change between branches might be a mini-bug in itself, but I'm not  
really interested in digging into the reasons for that right now.  
Still, add a regression test memorializing what we expect there,  
so we'll notice if it changes again.)  
  
Per bug report from Eduards Bezverhijs.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4e33da5f0af340da40bd51354b87332c551a4bbc    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Dec 2018 11:48:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Dec 2018 11:48:00 -0500    

This module overlooked this necessary fixup step on the results of  
transformWhereClause().  It accidentally worked anyway, because the  
constructed expression involved type "name" which is not collatable,  
but it fell over while I was experimenting with changing "name" to  
be collatable.  
  
Back-patch, not because there's any live bug here in back branches,  
but because somebody might use this code as a model for some real  
application and then not understand why it doesn't work.  

commit   : 9fbe7d974026925dc6f671e72c47fae3b3e49688    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Dec 2018 11:21:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Dec 2018 11:21:36 -0500    

Unlike other ALTER ref pages, this one neglected to mention that  
ALTER OWNER requires being a member of the new owning role.  
Per bug #15546 from Stefan Kadow.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 73822b8c9750c3d1da5232916c573319a80c24e3    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 10 Dec 2018 20:15:42 -0800    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 10 Dec 2018 20:15:42 -0800    

Slow runs of buildfarm members chipmunk, hornet and mandrill saw the  
shorter timeouts expire.  The 180s timeout in poll_query_until has been  
trouble-free since 2a0f89cd717ce6d49cdc47850577823682167e87 introduced  
it two years ago, so use 180s more widely.  Back-patch to 9.6, where the  
first of these timeouts was introduced.  
  
Reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 62999b93251eefbfcf900a0bb202721b0a422ffd    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Dec 2018 11:12:43 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Dec 2018 11:12:43 -0500    

Although copyfuncs.c has a check_stack_depth call in its recursion,  
equalfuncs.c, outfuncs.c, and readfuncs.c lacked one.  This seems  
unwise.  
  
Likewise fix planstate_tree_walker(), in branches where that exists.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a628e0c5b484eed450093258440cf858bcdb0555    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Dec 2018 10:38:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Dec 2018 10:38:49 -0500    

Previously, it would just pass back a partially-uninitialized tupdesc,  
which doesn't seem like a safe or useful behavior.  
  
Backpatch to v10 where this code came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : aedd3d4dbd6ecf73a4045e302b68cc498d0e6b58    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Dec 2018 12:12:00 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Dec 2018 12:12:00 -0500    

The stanza of ExecuteTruncate[Guts] that truncates a target table's toast  
relation re-used the loop local variable "rel" to reference the toast rel.  
This was safe enough when written, but commit d42358efb added code below  
that that supposed "rel" still pointed to the parent table.  Therefore,  
the stats counter update was applied to the wrong relcache entry (the  
toast rel not the user rel); and if we were unlucky and that relcache  
entry had been flushed during reindex_relation, very bad things could  
ensue.  
  
(I'm surprised that CLOBBER_CACHE_ALWAYS testing hasn't found this.  
I'm even more surprised that the problem wasn't detected during the  
development of d42358efb; it must not have been tested in any case  
with a toast table, as the incorrect stats counts are very obvious.)  
  
To fix, replace use of "rel" in that code branch with a more local  
variable.  Adjust test cases added by d42358efb so that some of them  
use tables with toast tables.  
  
Per bug #15540 from Pan Bian.  Back-patch to 9.5 where d42358efb came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6bc8193193201652b75a682fa6257ac24b22ed23    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Dec 2018 11:02:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Dec 2018 11:02:39 -0500    

Remove dead code (which would be incorrect if it weren't dead),  
per report from Pan Bian.  Add a CHECK_FOR_INTERRUPTS in the  
inner loop over child relations, because there's little point  
in having one in the outer loop if there's not one here too.  
Minor stylistic adjustments and comment improvements.  
  
Seems to be aboriginal to this code (cf commit 665d1fad9).  
Back-patch to v10 where that came in, not because any of this  
is significant, but just to keep the branches looking similar.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 4c6d6acec5f228604d99162dfbc3b3c028dcfdfe    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Dec 2018 10:41:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Dec 2018 10:41:26 -0500    

Jeff Janes  
  
Discussion: https://postgr.es/m/CAMkU=1w7Tn2M9BhK+rt8Shtz1AkU+ty7By8gj5C==z65=U4vyQ@mail.gmail.com  

commit   : d8e1de899c8ec480af6696350957b13a2cc3ff0b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 6 Dec 2018 15:08:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 6 Dec 2018 15:08:44 -0500    

Places that are testing for *printf failure ought to include the format  
string in their error reports, since bad-format-string is one of the  
more likely causes of such failure.  This both makes it easier to find  
and repair the mistake, and provides at least some useful info to the  
user who stumbles across such a problem.  
  
Also, tighten snprintf.c to report EINVAL for an invalid flag or  
final character in a format %-spec (including the case where the  
%-spec is missing a final character altogether).  This seems like  
better project policy, and it also allows removing an instruction  
or two from the hot code path.  
  
Back-patch the error reporting change in pvsnprintf, since it should be  
harmless and may be helpful; but not the snprintf.c change.  
  
Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an  
invalid translated format string.  These changes don't fix that error,  
but they should improve matters next time we make such a mistake.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : aa175f61e0fcef16af57f82968a59ed5324146ca    
  
author   : Stephen Frost <[email protected]>    
date     : Thu, 6 Dec 2018 11:39:03 -0500    
  
committer: Stephen Frost <[email protected]>    
date     : Thu, 6 Dec 2018 11:39:03 -0500    

It was pointed out that in the planner stats documentation under  
Extended Statistics, one of the sentences was a bit awkward.  Improve  
that by rewording it slightly.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 37798a8e83db978c7d92f2491935c6ba96b95fbc    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 5 Dec 2018 13:31:55 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 5 Dec 2018 13:31:55 -0300    

When an indexes is created on a partitioned table using ONLY (don't  
recurse to partitions), it gets marked invalid until index partitions  
are attached for each table partition.  But there's no reason to do this  
if there are no partitions ... and moreover, there's no way to get the  
index to become valid afterwards, because all partitions that get  
created/attached get their own index partition already attached to the  
parent index, so there's no chance to do ALTER INDEX ... ATTACH PARTITION  
that would make the parent index valid.  
  
Fix by not marking the index as invalid to begin with.  
  
This is very similar to 9139aa19423b, but the pg_dump aspect does not  
appear to be relevant until we add FKs that can point to PKs on  
partitioned tables.  (I tried to cause the pg_upgrade test to break by  
leaving some of these bogus tables around, but wasn't able to.)  
  
Making this change means that an index that was supposed to be invalid  
in the insert_conflict regression test is no longer invalid; reorder the  
DDL so that the test continues to verify the behavior we want it to.  
  
Author: Álvaro Herrera  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/[email protected]  

commit   : 367f362b2d902de1c8f265639980ae001a4307e8    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 5 Dec 2018 10:02:55 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 5 Dec 2018 10:02:55 +0900    

"remote_flush" has never been a valid user-facing value, but "on" is.  
  
Author: Maksim Milyutin  
Discussion: https://postgr.es/m/[email protected]  

commit   : 19516afdf167aeaf9e95edf7c5a105bb16f8914c    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 30 Nov 2018 10:34:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 30 Nov 2018 10:34:56 +0900    

Three issues are fixed in this patch:  
- Base backups forgot to ignore files specific to EXEC_BACKEND, leading  
to spurious warnings when checksums are enabled, per analysis from me.  
- pg_verify_checksums forgot about files specific to EXEC_BACKEND,  
leading to failures of the tool on any such build, particularly Windows.  
This error was originally found by newly-introduced TAP tests in various  
buildfarm members using EXEC_BACKEND.  
- pg_verify_checksums forgot to count for temporary files and temporary  
paths, which could be valid relation files, without checksums, per  
report from Andres Freund.  More tests are added to cover this case.  
  
A new test case which emulates corruption for a file in a different  
tablespace is added, coming from from Michael Banck, while I have coded  
the main code and refactored the test code.  
  
Author: Michael Banck, Michael Paquier  
Reviewed-by: Stephen Frost, David Steele  
Discussion: https://postgr.es/m/[email protected]  

commit   : 85036308dc5871b1d41e4292fa089d3809963252    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 30 Nov 2018 10:15:06 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 30 Nov 2018 10:15:06 +0900    

This basically reverts commit d55241af705667d4503638e3f77d3689fd6be31,  
leaving around a portion of the regression tests still adapted with  
empty relation files, and corrupted cases.  This is also proving to be  
failing to check properly relation files located in a non-default  
tablespace path.  
  
Per discussion with various folks, including Stephen Frost, David  
Steele, Andres Freund, Michael Banck and myself.  
  
Reported-by: Michael Banck  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 11  

commit   : 53a5ceb2b68bc90a2ebd40e489d79f6e02441378    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2018 18:28:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2018 18:28:10 -0500    

The source code comments documented this, but the user-facing docs, not  
so much.  Add a section to Appendix B that discusses it.  
  
In passing, improve a couple other things in Appendix B --- notably,  
a long-obsolete claim that time zone abbreviations are looked up in  
a fixed table.  
  
Per bug #15527 from Michael Davidson.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 0ff56de46eb0a045417c5c22a5a07c4d6ea9ff78    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2018 15:53:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Nov 2018 15:53:44 -0500    

In at least Apple's version of ranlib, the output file is updated to have  
a mod time equal to the max of the timestamps of its components, and that  
data only has seconds precision.  On a filesystem with sub-second file  
timestamp precision --- say, APFS --- this can result in the finished  
static library appearing older than its input files, which causes useless  
rebuilds and possible outright failures in parallel makes.  
  
We've only seen this reported in the field from people using Apple's  
ranlib with a non-Apple make, because Apple's make doesn't know about  
sub-second timestamps either so it doesn't decide rebuilds are needed.  
But Apple's ranlib presumably shares code with at least some BSDen,  
so it's not that unlikely that the same problem could arise elsewhere.  
  
To fix, just "touch" the output file after ranlib finishes.  
  
We seem to need this in only one place.  There are other calls of  
ranlib in our makefiles, but they are working on intermediate files  
whose timestamps are not actually important, or else on an installed  
static library for which sub-second timestamp precision is unlikely  
to matter either.  (Also, so far as I can tell, Apple's ranlib doesn't  
mess up the file timestamp in the latter usage anyhow.)  
  
In passing, change "ranlib" to "$(RANLIB)" in one place that was  
bypassing the make macro for no good reason.  
  
Per bug #15525 from Jack Kelly (via Alyssa Ross).  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : f7001b00a08f37bac306a6ae2028afb3dd2c5084    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 29 Nov 2018 14:14:26 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 29 Nov 2018 14:14:26 +1300    

Author: Takeshi Ideriha  
Discussion: https://postgr.es/m/4E72940DA2BF16479384A86D54D0988A6F3BF22D%40G01JPEXMBKW04  

commit   : bad41764a443605bef9bb3d1c3614e1b3770005d    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 29 Nov 2018 09:12:40 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 29 Nov 2018 09:12:40 +0900    

This fixes an oversight from c6c3334 which forgot that if a subset of  
WAL senders are stopping and in a sync state, other WAL senders could  
still be waiting for a WAL position to be synced while committing a  
transaction.  However the subset of stopping senders would not release  
waiters, potentially breaking synchronous replication guarantees.  This  
commit makes sure that even WAL senders stopping are able to release  
waiters and are tracked properly.  
  
On 9.4, this can also trigger an assertion failure when setting for  
example max_wal_senders to 1 where a WAL sender is not able to find  
itself as in synchronous state when the instance stops.  
  
Reported-by: Paul Guo  
Author: Paul Guo, Michael Paquier  
Discussion: https://postgr.es/m/CAEET0ZEv8VFqT3C-cQm6byOB4r4VYWcef1J21dOX-gcVhCSpmA@mail.gmail.com  
Backpatch-through: 9.4  

commit   : 95c45718126fe081e9236335a85d15ad24adc107    
  
author   : Peter Geoghegan <[email protected]>    
date     : Wed, 28 Nov 2018 14:42:52 -0800    
  
committer: Peter Geoghegan <[email protected]>    
date     : Wed, 28 Nov 2018 14:42:52 -0800    

Move the responsibility for checking for and reporting a failure from  
the only current BufFileSize() caller, logtape.c, to BufFileSize()  
itself.  Code within buffile.c is generally responsible for interfacing  
with fd.c to report irrecoverable failures.  This seems like a  
convention that's worth sticking to.  
  
Reorganizing things this way makes it easy to make the error message  
raised in the event of BufFileSize() failure descriptive of the  
underlying problem.  We're now clear on the distinction between  
temporary file name and BufFile name, and can show errno, confident that  
its value actually relates to the error being reported.  In passing, an  
existing, similar buffile.c ereport() + errcode_for_file_access() site  
is changed to follow the same conventions.  
  
The API of the function BufFileSize() is changed by this commit, despite  
already being in a stable release (Postgres 11).  This seems acceptable,  
since the BufFileSize() ABI was changed by commit aa551830421, which  
hasn't made it into a point release yet.  Besides, it's difficult to  
imagine a third party BufFileSize() caller not just raising an error  
anyway, since BufFile state should be considered corrupt when  
BufFileSize() fails.  
  
Per complaint from Tom Lane.  
  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 11-, where shared BufFiles were introduced.  

commit   : 48cf9184ce9574363b310eaf65c7c939a5d40e76    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 28 Nov 2018 07:34:10 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 28 Nov 2018 07:34:10 -0500    

Reported-by: Etsuro Fujita  
  
Discussion: https://postgr.es/m/[email protected]  
  
Author: Etsuro Fujita  
  
Backpatch-through: 10  

commit   : 0640d9517e7e6804851a5f0d2520d51fc6faf014    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 28 Nov 2018 14:00:57 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 28 Nov 2018 14:00:57 +1300    

Since commit 2f1d2b7a we have set PAM_RHOST to "[local]" for Unix  
sockets.  This caused Linux PAM's libaudit integration to make DNS  
requests for that name.  It's not exactly clear what value PAM_RHOST  
should have in that case, but it seems clear that we shouldn't set it  
to an unresolvable name, so don't do that.  
  
Back-patch to 9.6.  Bug #15520.  
  
Author: Thomas Munro  
Reviewed-by: Peter Eisentraut  
Reported-by: Albert Schabhuetl  
Discussion: https://postgr.es/m/15520-4c266f986998e1c5%40postgresql.org  

commit   : f8397c955e54d7093a81b2a84ba44898c6566203    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 28 Nov 2018 01:11:15 +0100    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 28 Nov 2018 01:11:15 +0100