PostgreSQL 9.5.5 commit log

commit   : 811b6c4a1df5d8323b532460ef2157e771dfb358    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 24 Oct 2016 16:10:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 24 Oct 2016 16:10:50 -0400    

commit   : ffaa8bcf0e65f7f8095d04aeaba6953e52af8c12    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 24 Oct 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 24 Oct 2016 12:00:00 -0400    

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

commit   : a5c76651e94b8b8598f99380ad84071aa11f9222    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 24 Oct 2016 09:37:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 24 Oct 2016 09:37:23 -0400    

commit   : 7a2fa5774a52bf7469f622e3ed4d6317c1d5a64e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 24 Oct 2016 09:27:24 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 24 Oct 2016 09:27:24 -0300    

An oversight in setting the boundaries of known commit timestamps during  
startup caused old commit timestamps to become inaccessible after a  
server restart.  
  
Author and reporter: Julien Rouhaud  
Review, test code: Craig Ringer  

commit   : ce9bae2261de6ad10a14dd02c63bdd31a5b23307    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 22:13:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 22:13:28 -0400    

commit   : beac79369411f62615d465953b9e6da1296758dc    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 19:14:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 19:14:32 -0400    

INSERT ... ON CONFLICT (specifically ExecCheckHeapTupleVisible) contains  
another example of this unsafe coding practice.  It is much harder to get  
a failure out of it than the case fixed in commit 6292c2339, because in  
most scenarios any hint bits that could be set would have already been set  
earlier in the command.  However, Konstantin Knizhnik reported a failure  
with a custom transaction manager, and it's clearly possible to get a  
failure via a race condition in async-commit mode.  
  
For lack of a reproducible example, no regression test case in this  
commit.  
  
I did some testing with Asserts added to tqual.c's functions, and can say  
that running "make check-world" exposed these two bugs and no others.  
The Asserts are messy enough that I've not added them to the code for now.  
  
Report: <[email protected]>  
Related-Discussion: <CAO3NbwOycQjt2Oqy2VW-eLTq2M5uGMyHnGm=RNga4mjqcYD7gQ@mail.gmail.com>  

commit   : 65d85b8f9dc3768b3b5bf59187620e9c7cafcb47    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 18:36:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 18:36:13 -0400    

A transaction that conflicts against itself, for example  
	INSERT INTO t(pk) VALUES (1),(1) ON CONFLICT DO NOTHING;  
should behave the same regardless of isolation level.  It certainly  
shouldn't throw a serialization error, as retrying will not help.  
We got this wrong due to the ON CONFLICT logic not considering the case,  
as reported by Jason Dusek.  
  
Core of this patch is by Peter Geoghegan (based on an earlier patch by  
Thomas Munro), though I didn't take his proposed code refactoring for fear  
that it might have unexpected side-effects.  Test cases by Thomas Munro  
and myself.  
  
Report: <CAO3NbwOycQjt2Oqy2VW-eLTq2M5uGMyHnGm=RNga4mjqcYD7gQ@mail.gmail.com>  
Related-Discussion: <[email protected]>  

commit   : 913e7e5983ff4b544879845af5305f70a4fa6277    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 15:01:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 23 Oct 2016 15:01:24 -0400    

Despite the argumentation I wrote in commit 7a2fe85b0, it's unsafe to do  
this, because in corner cases it's possible for HeapTupleSatisfiesSelf  
to try to set hint bits on the target tuple; and at least since 8.2 we  
have required the buffer content lock to be held while setting hint bits.  
  
The added regression test exercises one such corner case.  Unpatched, it  
causes an assertion failure in assert-enabled builds, or otherwise would  
cause a hint bit change in a buffer we don't hold lock on, which given  
the right race condition could result in checksum failures or other data  
consistency problems.  The odds of a problem in the field are probably  
pretty small, but nonetheless back-patch to all supported branches.  
  
Report: <[email protected]>  

commit   : 13d5dd50956163cbd3268b1ab118aad801c78274    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 22 Oct 2016 14:04:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 22 Oct 2016 14:04:51 -0400    

Show how to get the system's huge page size, rather than misleadingly  
referring to PAGE_SIZE (which is usually understood to be the regular  
page size).  Show how to confirm whether huge pages have been allocated.  
Minor wordsmithing.  Back-patch to 9.4 where this section appeared.  

commit   : 8acc15eaa1f10e4c171b88d4a29ced617e8d54c5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 21 Oct 2016 11:01:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 21 Oct 2016 11:01:35 -0400    

Replace "Full path to ..." with "Full path name of ...".  At least one  
user has misinterpreted the existing wording as meaning "Directory  
containing ...".  

commit   : cc0e4c5670083feecdfd1dff0abfb9a685462c15    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Oct 2016 17:17:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Oct 2016 17:17:50 -0400    

With track_io_timing = on, EXPLAIN (ANALYZE, BUFFERS) will emit fields  
named like "I/O Read Time".  The slash makes that invalid as an XML  
element name, so that adding FORMAT XML would produce invalid XML.  
  
We already have code in there to translate spaces to dashes, so let's  
generalize that to convert anything that isn't a valid XML name character,  
viz letters, digits, hyphens, underscores, and periods.  We could just  
reject slashes, which would run a bit faster.  But the fact that this went  
unnoticed for so long doesn't give me a warm feeling that we'd notice the  
next creative violation, so let's make it a permanent fix.  
  
Reported by Markus Winand, though this isn't his initial patch proposal.  
  
Back-patch to 9.2 where track_io_timing was added.  The problem is only  
latent in 9.1, so I don't feel a need to fix it there.  
  
Discussion: <[email protected]>  

commit   : aac898ac557ebf6a963c9d2a6d88c82e746b3f0c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Oct 2016 15:40:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Oct 2016 15:40:07 -0400    

This absorbs a fix for a symlink-manipulation bug in zic that was  
introduced in 2016g.  It probably isn't interesting for our use-case,  
but I'm not quite sure, so let's update while we're at it.  

commit   : 8cddedc17c6fa8a908c70153cacd8096bf126821    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 20 Oct 2016 15:20:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 20 Oct 2016 15:20:11 -0400    

(Didn't I just do this?  Oh well.)  
  
DST law changes in Palestine.  Historical corrections for Turkey.  
Switch to numeric abbreviations for Asia/Colombo.  

commit   : f5d177632e6622676ff7fe49962a75d71820eb97    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 23:32:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 23:32:08 -0400    

clang points out that SIZE_MAX wouldn't fit into an int, which means  
this comparison is pretty useless.  Per report from Thomas Munro.  

commit   : ab1c96e19e074264c57c7536d3beabce16fe5198    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 19:28:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 19:28:11 -0400    

Per buildfarm.  

commit   : bc59c1236fb6db77b5c4426be3bb5b1a934ae2a7    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 18:55:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 18:55:52 -0400    

This is mostly to absorb some corner-case fixes in zic for year-2037  
timestamps.  The other changes that have been made are unlikely to affect  
our usage, but nonetheless we may as well take 'em.  

commit   : 9cfe353c51a8c077802c9d3ef5b4e2eb493bf46c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 18:11:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 18:11:49 -0400    

IANA got rid of the really silly "abbreviation" and replaced it with one  
that's only moderately silly.  But it's still pointless, so keep on not  
showing it.  

commit   : 5508d0c0b21d4ecb27dcf54ccfe6e35b697f1e8c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 17:56:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 19 Oct 2016 17:56:38 -0400    

DST law changes in Turkey.  Historical corrections for America/Los_Angeles,  
Europe/Kirov, Europe/Moscow, Europe/Samara, and Europe/Ulyanovsk.  
Rename Asia/Rangoon to Asia/Yangon, with a backward compatibility link.  
  
The IANA crew continue their campaign to replace invented time zone  
abbrevations with numeric GMT offsets.  This update changes numerous zones  
in Antarctica and the former Soviet Union, for instance Antarctica/Casey  
now reports "+08" not "AWST" in the pg_timezone_names view.  I kept these  
abbreviations in the tznames/ data files, however, so that we will still  
accept them for input.  (We may want to start trimming those files someday,  
but today is not that day.)  
  
An exception is that since IANA no longer claims that "AMT" is in use  
in Armenia for GMT+4, I replaced it in the Default file with GMT-4,  
corresponding to Amazon Time which is in use in South America.  It may be  
that that meaning is also invented and IANA will drop it in a future  
update; but for now, it seems silly to give pride of place to a meaning  
not traceable to IANA over one that is.  

commit   : b82573d6e4e946ed8e9e3a3c6650245c16e223c1    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 19 Oct 2016 14:43:34 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 19 Oct 2016 14:43:34 +0300    

When a relation is truncated, it is important that the FSM is truncated as  
well. Otherwise, after recovery, the FSM can return a page that has been  
truncated away, leading to errors like:  
  
ERROR:  could not read block 28991 in file "base/16390/572026": read only 0  
of 8192 bytes  
  
We were using MarkBufferDirtyHint() to dirty the buffer holding the last  
remaining page of the FSM, but during recovery, that might in fact not  
dirty the page, and the FSM update might be lost.  
  
To fix, use the stronger MarkBufferDirty() function. MarkBufferDirty()  
requires us to do WAL-logging ourselves, to protect from a torn page, if  
checksumming is enabled.  
  
Also fix an oversight in visibilitymap_truncate: it also needs to WAL-log  
when checksumming is enabled.  
  
Analysis by Pavan Deolasee.  
  
Discussion: <CABOikdNr5vKucqyZH9s1Mh0XebLs_jRhKv6eJfNnD2wxTn=_9A@mail.gmail.com>  
  
Backpatch to 9.3, where we got data checksums.  

commit   : 219d476d8a8b720a034c6b21c5782c6fc20f5bf8    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 18 Oct 2016 12:24:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 18 Oct 2016 12:24:46 -0400    

CommandId is declared as uint32, and values up to 4G are indeed legal.  
cidout() handles them properly by treating the value as unsigned int.  
But cidin() was just using atoi(), which has platform-dependent behavior  
for values outside the range of signed int, as reported by Bart Lengkeek  
in bug #14379.  Use strtoul() instead, as xidin() does.  
  
In passing, make some purely cosmetic changes to make xidin/xidout  
look more like cidin/cidout; the former didn't have a monopoly on  
best practice IMO.  
  
Neither xidin nor cidin make any attempt to throw error for invalid input.  
I didn't change that here, and am not sure it's worth worrying about  
since neither is really a user-facing type.  The point is just to ensure  
that indubitably-valid inputs work as expected.  
  
It's been like this for a long time, so back-patch to all supported  
branches.  
  
Report: <[email protected]>  

commit   : 75c9d9a674a1feec3c02aa83e3f24275e6d4cba5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Oct 2016 16:28:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Oct 2016 16:28:34 -0400    

bitshiftright() and bitshiftleft() would recursively call each other  
infinitely if the user passed INT_MIN for the shift amount, due to integer  
overflow in negating the shift amount.  To fix, clamp to -VARBITMAXLEN.  
That doesn't change the results since any shift distance larger than the  
input bit string's length produces an all-zeroes result.  
  
Also fix some places that seemed inadequately paranoid about input typmods  
exceeding VARBITMAXLEN.  While a typmod accepted by anybit_typmodin() will  
certainly be much less than that, at least some of these spots are  
reachable with user-chosen integer values.  
  
Andreas Seltenreich and Tom Lane  
  
Discussion: <[email protected]>  

commit   : 3cd504254f604a37adefc2bd9d43a0a6041463fd    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 19:45:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 19:45:58 -0400    

pgstat_twophase_postcommit is supposed to duplicate the math in  
AtEOXact_PgStat, but it had missed out the bit about clearing  
t_delta_live_tuples/t_delta_dead_tuples for a TRUNCATE.  
  
It's harder than you might think to replicate the issue here, because  
those counters would only be nonzero when a previous transaction in  
the same backend had added/deleted tuples in the truncated table,  
and those counts hadn't been sent to the stats collector yet.  
  
Evident oversight in commit d42358efb.  I've not added a regression  
test for this; we tried to add one in d42358efb, and had to revert it  
because it was too timing-sensitive for the buildfarm.  
  
Back-patch to 9.5 where d42358efb came in.  
  
Stas Kelvich  
  
Discussion: <[email protected]>  

commit   : 3217ac3a98673b1520d774f2a61fffc237874e47    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 17:05:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 17:05:15 -0400    

It's not good for an inherited child constraint to be marked connoinherit;  
that would result in the constraint not propagating to grandchild tables,  
if any are created later.  The code mostly prevented this from happening  
but there was one case that was missed.  
  
This is somewhat related to commit e55a946a8, which also tightened checks  
on constraint merging.  Hence, back-patch to 9.2 like that one.  This isn't  
so much because there's a concrete feature-related reason to stop there,  
as to avoid having more distinct behaviors than we have to in this area.  
  
Amit Langote  
  
Discussion: <[email protected]>  

commit   : 43d17489d112e19bb51ae418bd3d63cb062afd62    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 15:06:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 15:06:46 -0400    

Even if Linux's mmap() is okay with a partial-hugepage request, munmap()  
is not, as reported by Chris Richards.  Therefore it behooves us to try  
a bit harder to find out the actual hugepage size, instead of assuming  
that we can skate by with a guess.  
  
For the moment, just look into /proc/meminfo to find out the default  
hugepage size, and use that.  Later, on kernels that support requests  
for nondefault sizes, we might try to consider other alternatives.  
But that smells more like a new feature than a bug fix, especially if  
we want to provide any way for the DBA to control it, so leave it for  
another day.  
  
I set this up to allow easy addition of platform-specific code for  
non-Linux platforms, if needed; but right now there are no reports  
suggesting that we need to work harder on other platforms.  
  
Back-patch to 9.4 where hugepage support was introduced.  
  
Discussion: <[email protected]>  

commit   : b1b56b653c036cfb64e162d498b4d0ae79e6b10d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 13:59:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Oct 2016 13:59:56 -0400    

Fix detaching of the mmap'd segment to have its own on_shmem_exit callback,  
rather than piggybacking on the one for detaching from the SysV segment.  
That was confusing, and given the distance between the two attach calls,  
it was trouble waiting to happen.  
  
Make the detaching calls idempotent by clearing AnonymousShmem to show  
we've already unmapped.  I spent quite a bit of time yesterday trying  
to find a path that would allow the munmap()'s to be done twice, and  
while I did not succeed, it seems silly that there's even a question.  
  
Make the #ifdef logic less confusing by separating "do we want to use  
anonymous shmem" from EXEC_BACKEND.  Even though there's no current  
scenario where those conditions are different, it is not helpful for  
different places in the same file to be testing EXEC_BACKEND for what  
are fundamentally different reasons.  
  
Don't do on_exit_reset() in StartBackgroundWorker().  At best that's  
useless (InitPostmasterChild would have done it already) and at worst  
it could zap some callback that's unrelated to shared memory.  
  
Improve comments, and simplify the huge_pages enablement logic slightly.  
  
Back-patch to 9.4 where hugepage support was introduced.  
Arguably this should go into 9.3 as well, but the code looks  
significantly different there, and I doubt it's worth the  
trouble of adapting the patch given I can't show a live bug.  

commit   : 16d41c84f26674ad2fe3cd3f75c83163c91b5619    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Oct 2016 18:01:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Oct 2016 18:01:43 -0400    

This turns out not to be as harmless as I thought: MSVC will complain  
if it sees an "extern" declaration without PGDLLEXPORT and then one with.  
(Seems fairly silly, given that this can be changed after the fact by the  
linker, but there you have it.)  Therefore, contrib modules that have  
extern's for V1 functions in header files are falling over in the  
buildfarm, since none of those externs are marked PGDLLEXPORT.  
  
We might or might not conclude that we're willing to plaster those  
declarations with PGDLLEXPORT in HEAD, but in any case there's no way we're  
going to ship this change in the back branches.  Third-party authors would  
not thank us for breaking their code in a minor release.  Hence, revert  
the addition of PGDLLEXPORT (but let's keep the extra info in the comment).  
If we do the other changes we can revert this commit in HEAD.  
  
Per buildfarm.  

commit   : 6298eaec86d86228dc59cb38fa7e69930598776d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Oct 2016 12:45:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Oct 2016 12:45:50 -0400    

This isn't really necessary for our own code, because we use a .DEF file  
in MSVC builds (see gendef.pl), or --export-all-symbols in MinGW and  
Cygwin builds, to ensure that all global symbols in loadable modules  
will be exported on Windows.  However, third-party authors might use  
different build processes that need this marker, and it's harmless  
enough for our own builds.  
  
To some extent, this is an oversight in commit e7128e8db, so back-patch  
to 9.4 where that was added.  
  
Laurenz Albe  
  
Discussion: <A737B7A37273E048B164557ADEF4A58B539300BD@ntex2010a.host.magwien.gv.at>  

commit   : e611b11634aa48852a6c9f8ff2da5f80ffa61eb9    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 12 Oct 2016 12:07:54 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 12 Oct 2016 12:07:54 +0300    

Amit Langote  

commit   : b987294fa917e5c0a5e1debb85ae5179910e8230    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Oct 2016 10:08:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Oct 2016 10:08:45 -0400    

It was perhaps not entirely clear that internal self-references shouldn't  
be schema-qualified even if the view name is written with a schema.  
Spell it out.  
  
Discussion: <[email protected]>  

commit   : 4f87f7640981bae3a37e14bae744452e80e9545d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 10 Oct 2016 10:35:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 10 Oct 2016 10:35:58 -0400    

Ordinarily there would not be an async result sitting around at this  
point, but it appears that in corner cases there can be.  Considering  
all the work we're about to launch, it's hardly going to cost anything  
noticeable to check.  
  
It's been like this forever, so back-patch to all supported branches.  
  
Report: <CAD-Qf1eLUtBOTPXyFQGW-4eEsop31tVVdZPu4kL9pbQ6tJPO8g@mail.gmail.com>  

commit   : d1a9f128defa6cb86c3c1274befe46c2e0d381f4    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 8 Oct 2016 19:29:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 8 Oct 2016 19:29:27 -0400    

Historically, we've allowed users to add a CHECK constraint to a child  
table and then add an identical CHECK constraint to the parent.  This  
results in "merging" the two constraints so that the pre-existing  
child constraint ends up with both conislocal = true and coninhcount > 0.  
However, if you tried to do it in the other order, you got a duplicate  
constraint error.  This is problematic for pg_dump, which needs to issue  
separated ADD CONSTRAINT commands in some cases, but has no good way to  
ensure that the constraints will be added in the required order.  
And it's more than a bit arbitrary, too.  The goal of complaining about  
duplicated ADD CONSTRAINT commands can be served if we reject the case of  
adding a constraint when the existing one already has conislocal = true;  
but if it has conislocal = false, let's just make the ADD CONSTRAINT set  
conislocal = true.  In this way, either order of adding the constraints  
has the same end result.  
  
Another problem was that the code allowed creation of a parent constraint  
marked convalidated that is merged with a child constraint that is  
!convalidated.  In this case, an inheritance scan of the parent table could  
emit some rows violating the constraint condition, which would be an  
unexpected result given the marking of the parent constraint as validated.  
Hence, forbid merging of constraints in this case.  (Note: valid child and  
not-valid parent seems fine, so continue to allow that.)  
  
Per report from Benedikt Grundmann.  Back-patch to 9.2 where we introduced  
possibly-not-valid check constraints.  The second bug obviously doesn't  
apply before that, and I think the first doesn't either, because pg_dump  
only gets into this situation when dealing with not-valid constraints.  
  
Report: <CADbMkNPT-Jz5PRSQ4RbUASYAjocV_KHUWapR%2Bg8fNvhUAyRpxA%40mail.gmail.com>  
Discussion: <[email protected]>  

commit   : d1595525bdaffa1bc2812fcda8a151cfbdc81a47    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 8 Oct 2016 18:43:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 8 Oct 2016 18:43:01 -0400    

Back-patch commit 0dba54f1666ead71c54ce100b39efda67596d297 into the older  
branches.  This test is almost as much of a patching hazard there as it is  
in HEAD, and it has no more reason to be needed than it does in HEAD.  
  
I went back as far as 9.2; I judged 9.1 not worth the trouble since  
it's on the verge of being EOL'd.  

commit   : 008a7dc327ba3165e7fab17d4cbb58c0f2ded3a5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Oct 2016 21:12:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 7 Oct 2016 21:12:25 -0400    

The need for this was previously obscured even on picky platforms  
by the hack we used to support direct cross-module references in  
the transforms contrib modules.  Now that that hack is gone, the  
undefined symbol is exposed, as reported by Robert Haas.  
  
Back-patch to 9.5 where we started to use -Wl,-undefined,dynamic_lookup.  
I'm a bit surprised that the older branches don't seem to contain  
any gettext references in this module, but since they don't fail  
at build time, they must not.  (We might be able to get away with  
leaving this alone in 9.5/9.6, but I think it's cleaner if the  
reference gets resolved at link time.)  
  
Report: <CA+TgmoaHJKU5kcWZcYduATYVT7Mnx+8jUnycaYYL7OtCwCigug@mail.gmail.com>  

commit   : 93fd6de14156d8d9c8d47e6cbfd067ab2b02e399    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 7 Oct 2016 16:55:15 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 7 Oct 2016 16:55:15 -0700    

I somehow had assumed that in the spinlock (in turn possibly using  
semaphores) based fallback atomics implementation 32 bit writes could be  
done without a lock. As far as the write goes that's correct, since  
postgres supports only platforms with single-copy atomicity for aligned  
32bit writes.  But writing without holding the spinlock breaks  
read-modify-write operations like pg_atomic_compare_exchange_u32(),  
since they'll potentially "miss" a concurrent write, which can't happen  
in actual hardware implementations.  
  
In 9.6+ when using the fallback atomics implementation this could lead  
to buffer header locks not being properly marked as released, and  
potentially some related state corruption.  I don't see a related danger  
in 9.5 (earliest release with the API), because pg_atomic_write_u32()  
wasn't used in a concurrent manner there.  
  
The state variable of local buffers, before this change, were  
manipulated using pg_atomic_write_u32(), to avoid unnecessary  
synchronization overhead. As that'd not be the case anymore, introduce  
and use pg_atomic_unlocked_write_u32(), which does not correctly  
interact with RMW operations.  
  
This bug only caused issues when postgres is compiled on platforms  
without atomics support (i.e. no common new platform), or when compiled  
with --disable-atomics, which explains why this wasn't noticed in  
testing.  
  
Reported-By: Tom Lane  
Discussion: <[email protected]>  
Backpatch: 9.5-, where the atomic operations API was introduced.  

commit   : 00d7e2f8c8b0def5cb3dcb0cae4cfca10dc4876f    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 21:48:21 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 21:48:21 +0300    

Recent Perl and/or new Linux distributions are starting to remove "." from  
the @INC list by default. That breaks pg_rewind and ssl test suites, which  
use helper perl modules that reside in the same directory. To fix, add the  
current source directory explicitly to prove's include dir.  
  
The vcregress.pl script probably also needs something like this, but I  
wasn't able to remove '.' from @INC on Windows to test this, and don't want  
to try doing that blindly.  
  
Discussion: <[email protected]>  

commit   : 010a1b5614cc6a26b35ea04ba85271baa0e929ac    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 14:35:17 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 14:35:17 +0300    

They are supposed to be mutually exclusive, but there was no check for  
that.  
  
Michael Banck  
  
Discussion: <[email protected]>  

commit   : f0ca540374ee89b45bce83b499327ffd934344a8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 12:53:42 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 12:53:42 +0300    

Leaving the error in the error queue used to be harmless, because the  
X509_STORE_load_locations() call used to be the last step in  
initialize_SSL(), and we would clear the queue before the next  
SSL_connect() call. But previous commit moved things around. The symptom  
was that if a CRL file was not found, and one of the subsequent  
initialization steps, like loading the client certificate or private key,  
failed, we would incorrectly print the "no such file" error message from  
the earlier X509_STORE_load_locations() call as the reason.  
  
Backpatch to all supported versions, like the previous patch.  

commit   : cb38c056fda53234dcc7f7d10bd08dd5a277c92e    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 12:20:39 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 7 Oct 2016 12:20:39 +0300    

There were several issues with the old coding:  
  
1. There was a race condition, if two threads opened a connection at the  
   same time. We used a mutex around SSL_CTX_* calls, but that was not  
   enough, e.g. if one thread SSL_CTX_load_verify_locations() with one  
   path, and another thread set it with a different path, before the first  
   thread got to establish the connection.  
  
2. Opening two different connections, with different sslrootcert settings,  
   seemed to fail outright with "SSL error: block type is not 01". Not sure  
   why.  
  
3. We created the SSL object, before calling SSL_CTX_load_verify_locations  
   and SSL_CTX_use_certificate_chain_file on the SSL context. That was  
   wrong, because the options set on the SSL context are propagated to the  
   SSL object, when the SSL object is created. If they are set after the  
   SSL object has already been created, they won't take effect until the  
   next connection. (This is bug #14329)  
  
At least some of these could've been fixed while still using a shared  
context, but it would've been more complicated and error-prone. To keep  
things simple, let's just use a separate SSL context for each connection,  
and accept the overhead.  
  
Backpatch to all supported versions.  
  
Report, analysis and test case by Kacper Zuk.  
  
Discussion: <[email protected]>  

commit   : 69da71254b4293b6f817486eaed2df17f8725743    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Oct 2016 13:24:46 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Oct 2016 13:24:46 +0300    

If you point pg_rewind to a server that is using synchronous replication,  
with "pg_rewind --source-server=...", and the replication is not working  
for some reason, pg_rewind will get stuck because it creates a temporary  
table, which needs to be replicated. You could call broken replication a  
pilot error, but pg_rewind is often used in special circumstances, when  
there are changes to the replication setup.  
  
We don't do any "real" updates, and we don't care about fsyncing or  
replicating the operations on the temporary tables, so fix that by  
setting synchronous_commit off.  
  
Michael Banck, Michael Paquier. Backpatch to 9.5, where pg_rewind was  
introduced.  
  
Discussion: <[email protected]>  

commit   : ce603a34a4568e876c0d9c826325d9b12c9e5497    
  
author   : Andres Freund <[email protected]>    
date     : Mon, 3 Oct 2016 22:11:36 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Mon, 3 Oct 2016 22:11:36 -0700    

Before initializing iteration over a subtransaction's changes, the last  
few changes were not spilled to disk. That's correct if the transaction  
didn't spill to disk, but otherwise... This bug can lead to missed or  
misorderd subtransaction contents when they were spilled to disk.  
  
Move spilling of the remaining in-memory changes to  
ReorderBufferIterTXNInit(), where it can easily be applied to the top  
transaction and, if present, subtransactions.  
  
Since this code had too many bugs already, noticeably increase test  
coverage.  
  
Fixes: #14319  
Reported-By: Huan Ruan  
Discussion: <[email protected]>  
Backport: 9,4-, where logical decoding was added  

commit   : f50fa46cca9a1e5bfd517f7f1d979ef4db55ce03    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Oct 2016 16:40:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Oct 2016 16:40:06 -0400    

Commit 88e982302 invented GUC_UNIT_XSEGS for min_wal_size and max_wal_size,  
but neglected to make it display sensibly in pg_settings.unit (by adding a  
case to the switch in GetConfigOptionByNum).  Fix that, and adjust said  
switch to throw a run-time error the next time somebody forgets.  
  
In passing, avoid using a static buffer for the output string --- the rest  
of this function pstrdup's from a local buffer, and I see no very good  
reason why the units code should do it differently and less safely.  
  
Per report from Otar Shavadze.  Back-patch to 9.5 where the new unit type  
was added.  
  
Report: <CAG-jOyA=iNFhN+yB4vfvqh688B7Tr5SArbYcFUAjZi=0Exp-Lg@mail.gmail.com>  

commit   : 647a86e374d2eb01d8cdda2fc759a770b38cc232    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 3 Oct 2016 16:23:12 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Mon, 3 Oct 2016 16:23:12 -0400    

Attempting to COPY a subset of columns from a table with RLS enabled  
would fail due to an invalid query being constructed (using a single  
ColumnRef with the list of fields to exact in 'fields', but that's for  
the different levels of an indirection for a single column, not for  
specifying multiple columns).  
  
Correct by building a ColumnRef and then RestTarget for each column  
being requested and then adding those to the targetList for the select  
query.  Include regression tests to hopefully catch if this is broken  
again in the future.  
  
Patch-By: Adam Brightwell  
Reviewed-By: Michael Paquier  

commit   : 0f259bd178f64b8e351a62d5479e3565e84b956e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Oct 2016 10:07:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Oct 2016 10:07:39 -0400    

pg_upgrade checks whether all the shared libraries used in the old cluster  
are also available in the new one by issuing LOAD for each library name.  
Previously, it cared not what order it did the LOADs in.  Ideally it  
should not have to care, but currently the transform modules in contrib  
fail unless both the language and datatype modules they depend on are  
loaded first.  A backend-side solution for that looks possible but  
probably not back-patchable, so as a stopgap measure, let's do the LOAD  
tests in order by library name length.  That should fix the problem for  
reasonably-named transform modules, eg "hstore_plpython" will be loaded  
after both "hstore" and "plpython".  (Yeah, it's a hack.)  
  
In a larger sense, having a predictable order of these probes is a good  
thing, since it will make upgrades predictably work or not work in the  
face of inter-library dependencies.  Also, this patch replaces O(N^2)  
de-duplication logic with O(N log N) logic, which could matter in  
installations with very many databases.  So I don't foresee reverting this  
even after we have a proper fix for the library-dependency problem.  
  
In passing, improve a couple of SQL queries used here.  
  
Per complaint from Andrew Dunstan that pg_upgrade'ing the transform contrib  
modules failed.  Back-patch to 9.5 where transform modules were introduced.  
  
Discussion: <[email protected]>  

commit   : e12b83abb5fed85f4bbb9625ebd221b880a4c692    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 1 Oct 2016 17:15:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 1 Oct 2016 17:15:10 -0400    

In standard Unix builds, postmaster child processes do ClosePostmasterPorts  
immediately after InitPostmasterChild, that is almost immediately after  
being spawned.  This is important because we don't want children holding  
open the postmaster's end of the postmaster death watch pipe.  
  
However, in EXEC_BACKEND builds, SubPostmasterMain was postponing this  
responsibility significantly, in order to make it slightly more convenient  
to pass the right flag value to ClosePostmasterPorts.  This is bad,  
particularly seeing that process_shared_preload_libraries() might invoke  
nearly-arbitrary code.  Rearrange so that we do it as soon as we've  
fetched the socket FDs via read_backend_variables().  
  
Also move the comment explaining about randomize_va_space to before the  
call of PGSharedMemoryReAttach, which is where it's relevant.  The old  
placement was appropriate when the reattach happened inside  
CreateSharedMemoryAndSemaphores, but that was a long time ago.  
  
Back-patch to 9.3; the patch doesn't apply cleanly before that, and  
it doesn't seem worth a lot of effort given that we've had no actual  
field complaints traceable to this.  
  
Discussion: <[email protected]>  

commit   : d8b4c3490c8ada0e39727475328a67c2e510f2f2    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 30 Sep 2016 11:19:30 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 30 Sep 2016 11:19:30 +0200    

There is a small window between when the server closes out the existing  
segment and the new one is created. Put a loop around the open call in  
this case to make sure we wait for the new file to actually appear.  

commit   : 2937ffa5d5790e6bcefae0492388adb192db936b    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 28 Sep 2016 19:31:58 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 28 Sep 2016 19:31:58 -0300    

Reported by Peter Eisentraut.  Coding suggested by Tom Lane.  

commit   : fdaa5777062856e125961501dadfbc27409e9369    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 28 Sep 2016 12:38:33 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 28 Sep 2016 12:38:33 -0400    

Without this, statistics changes accumulated by the worker never get  
reported to the stats collector, which is bad.  
  
Julien Rouhaud  

commit   : 8d11c303d01087186605d7ea53bfc4b7f53725f4    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 27 Sep 2016 01:05:21 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 27 Sep 2016 01:05:21 -0300    

<sys/select.h> is required by POSIX.1-2001 to get the prototype of  
select(2), but nearly no systems enforce that because older standards  
let you get away with including some other headers.  Recent OpenBSD  
hacking has removed that frail touch of friendliness, however, which  
broke some compiles; fix all the way back to 9.1 by adding the required  
standard.  Only vacuumdb.c was reported to fail, but it seems easier to  
fix the whole lot in a fell swoop.  
  
Per bug #14334 by Sean Farrell.  

commit   : 1e903c2f00f8b94ae34a8503f63e37b2963eb2cf    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 26 Sep 2016 11:50:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 26 Sep 2016 11:50:35 -0400    

Evidently an oversight in commit 729205571.  Back-patch to 9.2 where  
privileges for types were introduced.  
  
Report: <[email protected]>  

commit   : 025c9a7226f603823f51a6fde78fc97624269a46    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 15:50:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 15:50:00 -0400    

When configured with --enable-tap-tests, "make install" will now install  
the Perl support files for TAP testing where PGXS will find them.  
This allows extensions to rely on $(prove_check) even when being built  
out-of-tree.  Back-patch to 9.4 where we first started to support TAP  
testing, to reduce the number of cases extension makefiles need to  
consider.  
  
Craig Ringer  
  
Discussion: <CAMsr+YFXv+2qne6xJW7z_25mYBtktRX5rpkrgrb+DRgQ_FxgHQ@mail.gmail.com>  

commit   : 0a2b2ea5654a782e572f70dd81f2de80c0ca6bc6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 14:22:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 14:22:07 -0400    

These worked as-is until around 7.0, but fail in newer versions because  
there are more operators named "#".  Besides it's a bit inconsistent that  
only two of the examples on this page lack type names on their constants.  
  
Report: <[email protected]>  

commit   : 96e16d73918f57ba8dd45d7708092d6220263bfc    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 13:49:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 13:49:26 -0400    

Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to  
dumping range constructor functions if they are part of an extension  
and we're in binary-upgrade mode.  Actually, we don't want to dump them  
separately even then, since CREATE TYPE AS RANGE will create the range's  
constructor functions regardless.  Per report from Andrew Dunstan.  
  
It looks like this mistake was introduced by me, in commit b985d4877, in  
perhaps-overzealous refactoring to reduce code duplication.  I'm suitably  
embarrassed.  
  
Report: <[email protected]>  

commit   : eda5e908291e80df9ea2ff5b6a9fd026719de2a6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 10:09:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 10:09:52 -0400    

We must test GetLastError() even when CreateFileMapping() returns a  
non-null handle.  If that value were left over from some previous system  
call, we might be fooled into thinking the segment already existed.  
Experimentation on Windows 7 suggests that CreateFileMapping() clears  
the error code on success, but it is not documented to do so, so let's  
not rely on that happening in all Windows releases.  
  
Amit Kapila  
  
Discussion: <[email protected]>  

commit   : 93528f7b41419d4c690ab83f45912e01281a590c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 09:54:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Sep 2016 09:54:11 -0400    

Commits 470d886c3 et al intended to fix the problem that the postmaster  
selected the same "random" DSM control segment ID on every start.  But  
using PostmasterRandom() for that destroys the intended property that the  
delay between random_start_time and random_stop_time will be unpredictable.  
(Said delay is probably already more predictable than we could wish, but  
that doesn't mean that reducing it by a couple orders of magnitude is OK.)  
Revert the previous patch and add a comment warning against misuse of  
PostmasterRandom.  Fix the original problem by calling srandom() early in  
PostmasterMain, using a low-security seed that will later be overwritten  
by PostmasterRandom.  
  
Discussion: <[email protected]>  

commit   : c359178350ac7790437feb817c1fb523838abbd9    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 22 Sep 2016 11:34:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 22 Sep 2016 11:34:44 -0400    

ExecInitCteScan supposed that it didn't have to do anything to the extra  
tuplestore read pointer it gets from tuplestore_alloc_read_pointer.  
However, it needs this read pointer to be positioned at the start of the  
tuplestore, while tuplestore_alloc_read_pointer is actually defined as  
cloning the current position of read pointer 0.  In normal situations  
that accidentally works because we initialize the whole plan tree at once,  
before anything gets read.  But it fails in an EvalPlanQual recheck, as  
illustrated in bug #14328 from Dima Pavlov.  To fix, just forcibly rewind  
the pointer after tuplestore_alloc_read_pointer.  The cost of doing so is  
negligible unless the tuplestore is already in TSS_READFILE state, which  
wouldn't happen in normal cases.  We could consider altering tuplestore's  
API to make that case cheaper, but that would make for a more invasive  
back-patch and it doesn't seem worth it.  
  
This has been broken probably for as long as we've had CTEs, so back-patch  
to all supported branches.  
  
Discussion: <[email protected]>  

commit   : b93d37474fdf31d2cd71c13f014b481863abb7c2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 21 Sep 2016 13:14:48 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 21 Sep 2016 13:14:48 +0300    

If the test duration was given in # of transactions (-t or no option),  
rather as a duration (-T), the latency average was always printed as 0.  
It has been broken ever since the display of latency average was added,  
in 9.4.  
  
Fabien Coelho  
  
Discussion: <alpine.DEB.2.20.1607131015370.7486@sto>  

commit   : 923ad1a16ae2b399e78447581b9de65a0e2a439a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

based on patch from Takeshi Ideriha <[email protected]>  

commit   : 722d0045f3b08e882c6b016410650ba9e314468a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

The existing example threw an error.  
  
From: gabrielle <[email protected]>  

commit   : b1aed95f52f5fea1366f4c4b3a46b5604c6ca1e3    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 20 Sep 2016 12:24:44 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 20 Sep 2016 12:24:44 -0400    

Otherwise, every startup gets the same "random" value, which is  
definitely not what was intended.  

commit   : c124e3649b0423cd7abc3f81208d9c7e8a7e8a8a    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 20 Sep 2016 12:04:41 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 20 Sep 2016 12:04:41 -0400    

Otherwise, attempts to run multiple postmasters running on the same  
machine may fail, because Windows sometimes returns ERROR_ACCESS_DENIED  
rather than ERROR_ALREADY_EXISTS when there is an existing segment.  
  
Hitting this bug is much more likely because of another defect not  
fixed by this patch, namely that dsm_postmaster_startup() uses  
random() which returns the same value every time.  But that's not  
a reason not to fix this.  
  
Kyotaro Horiguchi and Amit Kapila, reviewed by Michael Paquier  
  
Discussion: <CAA4eK1JyNdMeF-dgrpHozDecpDfsRZUtpCi+1AbtuEkfG3YooQ@mail.gmail.com>  

commit   : f0a86dfdb465d4d18b8010000205224733d9848e    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 20 Sep 2016 11:38:25 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 20 Sep 2016 11:38:25 +0300    

The GiST search queue is implemented as a pairing heap rather than as  
Red-Black Tree, since 9.5 (commit e7032610). I neglected these comments  
in that commit.  

commit   : edb5c4097604c90e12649cdf24accc6052140b78    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Sep 2016 22:55:43 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Sep 2016 22:55:43 +0300    

We can't use txn_scheduled to hold the sleep-until time for \sleep, because  
that interferes with calculation of the latency of the transaction as whole.  
  
Backpatch to 9.4, where this bug was introduced.  
  
Fabien COELHO  
  
Discussion: <alpine.DEB.2.20.1608231622170.7102@lancre>  

commit   : 52acf020a11945ae22a910e3ea784bb23ccdd3a7    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 19 Sep 2016 14:21:48 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 19 Sep 2016 14:21:48 -0400    

MauMau, reviewed by Michael Paquier  

commit   : 7c177ddc291692e5c7c41279b0488936283626f7    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 18 Sep 2016 13:46:32 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Sun, 18 Sep 2016 13:46:32 +0300    

This makes the -? and -V options work consistently with other binaries.  
--help and --version are now only recognized as the first option, i.e.  
"ecpg --foobar --help" no longer prints the help, but that's consistent  
with most of our other binaries, too.  
  
Backpatch to all supported versions.  
  
Haribabu Kommi  
  
Discussion: <CAJrrPGfnRXvmCzxq6Dy=stAWebfNHxiL+Y_z7uqksZUCkW_waQ@mail.gmail.com>  

commit   : 48e5ba61e6ad1773820794835132823a54d6aa8e    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 15 Sep 2016 22:29:39 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 15 Sep 2016 22:29:39 +0300    

LibreSSL defines OPENSSL_VERSION_NUMBER to claim that it is version 2.0.0,  
but it doesn't have the functions added in OpenSSL 1.1.0. Add autoconf  
checks for the individual functions we need, and stop relying on  
OPENSSL_VERSION_NUMBER.  
  
Backport to 9.5 and 9.6, like the patch that broke this. In the  
back-branches, there are still a few OPENSSL_VERSION_NUMBER checks left,  
to check for OpenSSL 0.9.8 or 0.9.7. I left them as they were - LibreSSL  
has all those functions, so they work as intended.  
  
Per buildfarm member curculio.  
  
Discussion: <[email protected]>  

commit   : 60b6d99dac05b888b7f121720cafea88ba0c9307    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 15 Sep 2016 09:22:52 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 15 Sep 2016 09:22:52 -0400    

Otherwise, users who have configured shared_buffers >= 256GB won't  
be able to use this module.  There probably aren't many of those, but  
it doesn't hurt anything to fix it so that it works.  
  
Backpatch to 9.4, where MemoryContextAllocHuge was introduced.  The  
same problem exists in older branches, but there's no easy way to  
fix it there.  
  
KaiGai Kohei  

commit   : e2838c58047a98e91cb6f329b17bb86f343c03d2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 15 Sep 2016 12:55:38 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 15 Sep 2016 12:55:38 +0300    

Changes needed to build at all:  
  
- Check for SSL_new in configure, now that SSL_library_init is a macro.  
- Do not access struct members directly. This includes some new code in  
  pgcrypto, to use the resource owner mechanism to ensure that we don't  
  leak OpenSSL handles, now that we can't embed them in other structs  
  anymore.  
- RAND_SSLeay() -> RAND_OpenSSL()  
  
Changes that were needed to silence deprecation warnings, but were not  
strictly necessary:  
  
- RAND_pseudo_bytes() -> RAND_bytes().  
- SSL_library_init() and OpenSSL_config() -> OPENSSL_init_ssl()  
- ASN1_STRING_data() -> ASN1_STRING_get0_data()  
- DH_generate_parameters() -> DH_generate_parameters()  
- Locking callbacks are not needed with OpenSSL 1.1.0 anymore. (Good  
  riddance!)  
  
Also change references to SSLEAY_VERSION_NUMBER with OPENSSL_VERSION_NUMBER,  
for the sake of consistency. OPENSSL_VERSION_NUMBER has existed since time  
immemorial.  
  
Fix SSL test suite to work with OpenSSL 1.1.0. CA certificates must have  
the "CA:true" basic constraint extension now, or OpenSSL will refuse them.  
Regenerate the test certificates with that. The "openssl" binary, used to  
generate the certificates, is also now more picky, and throws an error  
if an X509 extension is specified in "req_extensions", but that section  
is empty.  
  
Backpatch to 9.5 and 9.6, per popular demand. The file structure was  
somewhat different in earlier branches, so I didn't bother to go further  
than that. In back-branches, we still support OpenSSL 0.9.7 and above.  
OpenSSL 0.9.6 should still work too, but I didn't test it. In master, we  
only support 0.9.8 and above.  
  
Patch by Andreas Karlsson, with additional changes by me.  
  
Discussion: <[email protected]>  

commit   : caad70c76085664c70c6e9fe3565b6cd172e403d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Sep 2016 19:19:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Sep 2016 19:19:24 -0400    

Standardize on "user_name" for a field name in related examples in  
ddl.sgml; before we had variously "user_name", "username", and "user".  
The last is flat wrong because it conflicts with a reserved word.  
  
Be consistent about entry capitalization in a table in func.sgml.  
  
Fix a typo in pgtrgm.sgml.  
  
Back-patch to 9.6 and 9.5 as relevant.  
  
Alexander Law  

commit   : 75684fc1f5bbcb097f8230cb9d897b689d44eb10    
  
author   : Simon Riggs <[email protected]>    
date     : Mon, 12 Sep 2016 09:02:32 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Mon, 12 Sep 2016 09:02:32 +0100    

Daniel Gustafsson  

commit   : 43ef6abcbb6010593a000a0d42303f138b9f5b4c    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 10 Sep 2016 17:54:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 10 Sep 2016 17:54:23 -0400    

Some experimentation with an older version of gcc showed that it is able  
to determine whether "if (elevel_ >= ERROR)" is compile-time constant  
if elevel_ is declared "const", but otherwise not so much.  We had  
accounted for that in ereport() but were too miserly with braces to  
make it so in elog().  I don't know how many currently-interesting  
compilers have the same quirk, but in case it will save some code  
space, let's make sure that elog() is on the same footing as ereport()  
for this purpose.  
  
Back-patch to 9.3 where we introduced pg_unreachable() calls into  
elog/ereport.  

commit   : bca6eeb82e856bc378fb31781d519caed5123b63    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 10 Sep 2016 13:49:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 10 Sep 2016 13:49:04 -0400    

Commit dd1a3bccc replaced a test on whether a subroutine returned a  
null pointer with a test on whether &pointer->backendStatus was null.  
This accidentally failed to fail, at least on common compilers, because  
backendStatus is the first field in the struct; but it was surely trouble  
waiting to happen.  Commit f91feba87 then messed things up further,  
changing the logic to  
  
	local_beentry = pgstat_fetch_stat_local_beentry(curr_backend);  
	if (!local_beentry)  
		continue;  
	beentry = &local_beentry->backendStatus;  
	if (!beentry)  
	{  
  
where the second "if" is now dead code, so that the intended behavior of  
printing a row with "<backend information not available>" cannot occur.  
  
I suspect this is all moot because pgstat_fetch_stat_local_beentry  
will never actually return null in this function's usage, but it's still  
very poor coding.  Repair back to 9.4 where the original problem was  
introduced.  

commit   : f337658850801706334fcfec07928a804fb4e24f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 9 Sep 2016 15:54:29 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 9 Sep 2016 15:54:29 -0300    

When heap_lock_tuple decides to follow the update chain, it tried to  
also lock any version of the tuple that was created by an update that  
was subsequently rolled back.  This is pointless, since for all intents  
and purposes that tuple exists no more; and moreover it causes  
misbehavior, as reported independently by Marko Tiikkaja and Marti  
Raudsepp: some SELECT FOR UPDATE/SHARE queries may fail to return  
the tuples, and assertion-enabled builds crash.  
  
Fix by having heap_lock_updated_tuple test the xmin and return success  
immediately if the tuple was created by an aborted transaction.  
  
The condition where tuples become invisible occurs when an updated tuple  
chain is followed by heap_lock_updated_tuple, which reports the problem  
as HeapTupleSelfUpdated to its caller heap_lock_tuple, which in turn  
propagates that code outwards possibly leading the calling code  
(ExecLockRows) to believe that the tuple exists no longer.  
  
Backpatch to 9.3.  Only on 9.5 and newer this leads to a visible  
failure, because of commit 27846f02c176; before that, heap_lock_tuple  
skips the whole dance when the tuple is already locked by the same  
transaction, because of the ancient HeapTupleSatisfiesUpdate behavior.  
Still, the buggy condition may also exist in more convoluted scenarios  
involving concurrent transactions, so it seems safer to fix the bug in  
the old branches too.  
  
Discussion:  
	https://www.postgresql.org/message-id/CABRT9RC81YUf1=jsmWopcKJEro=VoeG2ou6sPwyOUTx_qteRsg@mail.gmail.com  
	https://www.postgresql.org/message-id/[email protected]  

commit   : f3b3e871ee694ec050073c9732764c93fb891a31    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 9 Sep 2016 11:43:46 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 9 Sep 2016 11:43:46 +0100    

lazy_truncate_heap() was waiting for  
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds  
not milliseconds as originally intended.  
  
Found by code inspection.  
  
Simon Riggs  

commit   : 26ce63ce76f91eac7570fcb893321ed0233d62ff    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 8 Sep 2016 16:51:09 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 8 Sep 2016 16:51:09 -0700    

mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting  
it. That lead to a fd.c handle to a truncated file being kept open until  
backend exit.  
  
The issue appears to have been introduced way back in 1a5c450f3024ac5,  
before that the handle was closed inside FileUnlink().  
  
The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE  
for temporary tables, truncate files in place (i.e. TRUNCATE itself is  
not affected), and the relation has to be bigger than 1GB. The  
consequences of a leaked fd.c handle aren't severe either.  
  
Discussion: <[email protected]>  
Backpatch: all supported releases  

commit   : 142a110b312fa2d6bbc4eba4df196c35e0caf7bb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 8 Sep 2016 10:48:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 8 Sep 2016 10:48:03 -0400    

If the database has a non-default tablespace, we emitted a TABLESPACE  
clause in the CREATE DATABASE command emitted by -C, even if  
--no-tablespaces was also specified.  This seems wrong, and it's  
inconsistent with what pg_dumpall does, so change it.  Per bug #14315  
from Danylo Hlynskyi.  
  
Back-patch to 9.5.  The bug is much older, but it'd be a more invasive  
change before 9.5 because dumpDatabase() hasn't got an easy way to get  
to the outputNoTablespaces flag.  Doesn't seem worth the work given  
the lack of previous complaints.  
  
Report: <[email protected]>  

commit   : 6cdc26e482182a872d10a899cc4bbdb11364720b    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Sep 2016 17:50:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Sep 2016 17:50:53 -0400    

Mostly, explain how row xmin's used to be replaced by FrozenTransactionId  
and no longer are.  Do a little copy-editing on the side.  
  
Per discussion with Egor Rogov.  Back-patch to 9.4 where the behavioral  
change occurred.  
  
Discussion: <[email protected]>  

commit   : 0ce080147a52dec71774c6eacbf855721926c448    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Sep 2016 20:02:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Sep 2016 20:02:16 -0400    

After further reflection about the mess cleaned up in commit 39b691f25,  
I decided the main bit of test coverage that was still missing was to  
check that the non-default abbreviation-set files we supply are usable.  
Add that.  
  
Back-patch to supported branches, just because it seems like a good  
idea to keep this all in sync.  

commit   : c26a3aba7d58724377030a2ab6d44681f0d0ec23    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Sep 2016 19:42:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Sep 2016 19:42:08 -0400    

Commit b2cbced9e instituted a policy of referring to the timezone database  
as the "IANA timezone database" in our user-facing documentation.  
Propagate that wording into a couple of places that were still using "zic"  
to refer to the database, which is definitely not right (zic is the  
compilation tool, not the data).  
  
Back-patch, not because this is very important in itself, but because  
we routinely cherry-pick updates to the tznames files and I don't want  
to risk future merge failures.  

commit   : 08a72872f516573c31f51868dbb82abd2b32f67a    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 3 Sep 2016 13:28:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 3 Sep 2016 13:28:53 -0400    

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by  
memcpy'ing the first two bytes of an int-sized variable.  That accidentally  
works on little-endian hardware, but not at all on big-endian.  Replay then  
thinks it's looking at an ADDITEMS action with zero entries, and reads the  
first two bytes of the first TID therein as the next segno/action,  
typically leading to "unexpected GIN leaf action" errors during replay.  
Even if replay failed to crash, the resulting GIN index page would surely  
be incorrect.  To fix, just declare the variable as uint16 instead.  
  
Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning  
his problem into a self-contained test case).  This likely also explains  
a previous report of the same symptom from Bernd Helmle.  
  
Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).  
  
Discussion: <[email protected]>  
Possible-Report: <[email protected]>  

commit   : 73a802a4111f60b0333ee4033c7c6a480c174182    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Sep 2016 17:29:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Sep 2016 17:29:31 -0400    

Previously, we threw an error if a dynamic timezone abbreviation did not  
match any abbreviation recorded in the referenced IANA time zone entry.  
That seemed like a good consistency check at the time, but it turns out  
that a number of the abbreviations in the IANA database are things that  
Olson and crew made up out of whole cloth.  Their current policy is to  
remove such names in favor of using simple numeric offsets.  Perhaps  
unsurprisingly, a lot of these made-up abbreviations have varied in meaning  
over time, which meant that our commit b2cbced9e and later changes made  
them into dynamic abbreviations.  So with newer IANA database versions  
that don't mention these abbreviations at all, we fail, as reported in bug  
#14307 from Neil Anderson.  It's worse than just a few unused-in-the-wild  
abbreviations not working, because the pg_timezone_abbrevs view stops  
working altogether (since its underlying function tries to compute the  
whole view result in one call).  
  
We considered deleting these abbreviations from our abbreviations list, but  
the problem with that is that we can't stay ahead of possible future IANA  
changes.  Instead, let's leave the abbreviations list alone, and treat any  
"orphaned" dynamic abbreviation as just meaning the referenced time zone.  
It will behave a bit differently than it used to, in that you can't any  
longer override the zone's standard vs. daylight rule by using the "wrong"  
abbreviation of a pair, but that's better than failing entirely.  (Also,  
this solution can be interpreted as adding a small new feature, which is  
that any abbreviation a user wants can be defined as referencing a time  
zone name.)  
  
Back-patch to all supported branches, since this problem affects all  
of them when using tzdata 2016f or newer.  
  
Report: <[email protected]>  
Discussion: <[email protected]>  

commit   : 86ddc12a8dd18676146ed6ef085a9a3c4029d169    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 1 Sep 2016 12:48:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 1 Sep 2016 12:48:06 -0400    

Back-patch commit a2fd62dd53fb606dee69e0f4eb12289c87f5c8b1  
into older branches.  Per complaint from Pavel Stehule.  

commit   : c40bb11559c516c24ff1460e2fac5da20abfeb39    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Aug 2016 08:52:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Aug 2016 08:52:13 -0400    

This can't really work because standby_mode expects there to be more  
WAL arriving, which there will not ever be because there's no WAL  
receiver process to fetch it.  Moreover, if standby_mode is on then  
hot standby might also be turned on, causing even more strangeness  
because that expects read-only sessions to be executing in parallel.  
Bernd Helmle reported a case where btree_xlog_delete_get_latestRemovedXid  
got confused, but rather than band-aiding individual problems it seems  
best to prevent getting anywhere near this state in the first place.  
Back-patch to all supported branches.  
  
In passing, also fix some omissions of errcodes in other ereport's in  
readRecoveryCommandFile().  
  
Michael Paquier (errcode hacking by me)  
  
Discussion: <[email protected]>  

commit   : 3aa233f82fad7ba46c93045408d2052ab1450e15    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 29 Aug 2016 18:11:36 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 29 Aug 2016 18:11:36 -0300    

Fix compile problem in 9050e5c89dc08, which was botched because of  
refactoring that had taken place in 38c83c9b75693.  
  
Per buildfarm  

commit   : 9050e5c89dc08fc217895c67b9f99b3b4f4bd539    
  
author   : Simon Riggs <[email protected]>    
date     : Mon, 29 Aug 2016 12:18:57 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Mon, 29 Aug 2016 12:18:57 +0100    

Make pg_receivexlog work correctly with —-synchronous without slots  
  
Backpatch to 9.5  
  
Gabriele Bartolini, reviewed by Michael Paquier and Simon Riggs  

commit   : 7dfb9b4796e05743398fc578ac7b25eab086721a    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 29 Aug 2016 14:34:58 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 29 Aug 2016 14:34:58 +0900    

Previously pg_xlogdump failed to dump the contents of the WAL file  
if the file starts with the continuation WAL record which spans  
more than one pages. Since pg_xlogdump assumed that the continuation  
record always fits on a page, it could not find the valid WAL record to  
start reading from in that case.  
  
This patch changes pg_xlogdump so that it can handle a continuation  
WAL record which crosses a page boundary and find the valid record  
to start reading from.  
  
Back-patch to 9.3 where pg_xlogdump was introduced.  
  
Author: Pavan Deolasee  
Reviewed-By: Michael Paquier and Craig Ringer  
Discussion: CABOikdPsPByMiG6J01DKq6om2+BNkxHTPkOyqHM2a4oYwGKsqQ@mail.gmail.com  

commit   : b09caece0df11266dd685187f4c86f452b378996    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Aug 2016 15:04:05 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Aug 2016 15:04:05 -0400    

HandleParallelMessages leaked memory into the caller's context.  Since it's  
called from ProcessInterrupts, there is basically zero certainty as to what  
CurrentMemoryContext is, which means we could be leaking into long-lived  
contexts.  Over the processing of many worker messages that would grow to  
be a problem.  Things could be even worse than just a leak, if we happened  
to service the interrupt while ErrorContext is current: elog.c thinks it  
can reset that on its own whim, possibly yanking storage out from under  
HandleParallelMessages.  
  
Give HandleParallelMessages its own dedicated context instead, which we can  
reset during each call to ensure there's no accumulation of wasted memory.  
  
Discussion: <[email protected]>  

commit   : 51b5008c7fdbdc762ce2103c1d907278c0882909    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Aug 2016 14:15:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Aug 2016 14:15:47 -0400    

Copy the palloc'd strings into the correct context, ie ErrorContext  
not wherever the source ErrorData is.  This would be a large bug,  
except that it appears that all catchers of thrown errors do either  
EmitErrorReport or CopyErrorData before doing anything that would  
cause transient memory contexts to be cleaned up.  Still, it's wrong  
and it will bite somebody someday.  
  
Fix failure to copy cursorpos and internalpos.  
  
Utter the appropriate incantations involving recursion_depth, so that  
we'll behave sanely if we get an error inside pstrdup.  (In general,  
the body of this function ought to act like, eg, errdetail().)  
  
Per code reading induced by Jakob Egger's report.  

commit   : 8c907045f63257859f84b073c0648d2012f7919c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Aug 2016 09:57:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Aug 2016 09:57:09 -0400    

Commit f0c7b789a added a test case in case.sql that creates and then drops  
both an '=' operator and the type it's for.  Given the right timing, that  
can cause a "cache lookup failed for type" failure in concurrent sessions,  
which see the '=' operator as a potential match for '=' in a query, but  
then the type is gone by the time they inquire into its properties.  
It might be nice to make that behavior more robust someday, but as a  
back-patchable solution, adjust the new test case so that the operator  
is never visible to other sessions.  Like the previous commit, back-patch  
to all supported branches.  
  
Discussion: <[email protected]>  

commit   : 46bd14a108ffde3e0db68ccae0fd88a4128c8e84    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Aug 2016 22:20:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Aug 2016 22:20:01 -0400    

When there is an identifiable REPLICA IDENTITY index on the target table,  
heap_update leaks the id_attrs bitmapset.  That's not many bytes, but it  
adds up over enough rows, since the code typically runs in a query-lifespan  
context.  Bug introduced in commit e55704d8b, which did a rather poor job  
of cloning the existing use-pattern for RelationGetIndexAttrBitmap().  
  
Per bug #14293 from Zhou Digoal.  Back-patch to 9.4 where the bug was  
introduced.  
  
Report: <[email protected]>  

commit   : 25fe5f758c10c52b96497b04658382c2bb577e8f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Aug 2016 14:37:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Aug 2016 14:37:50 -0400    

ExecReScanAgg's check for whether it could re-use a previously calculated  
hashtable neglected the possibility that the Agg node might reference  
PARAM_EXEC Params that are not referenced by its input plan node.  That's  
okay if the Params are in upper tlist or qual expressions; but if one  
appears in aggregate input expressions, then the hashtable contents need  
to be recomputed when the Param's value changes.  
  
To avoid unnecessary performance degradation in the case of a Param that  
isn't within an aggregate input, add logic to the planner to determine  
which Params are within aggregate inputs.  This requires a new field in  
struct Agg, but fortunately we never write plans to disk, so this isn't  
an initdb-forcing change.  
  
Per report from Jeevan Chalke.  This has been broken since forever,  
so back-patch to all supported branches.  
  
Andrew Gierth, with minor adjustments by me  
  
Report: <CAM2+6=VY8ykfLT5Q8vb9B6EbeBk-NGuLbT6seaQ+Fq4zXvrDcA@mail.gmail.com>  

commit   : da9659f87c868ae638ea34654737f9ef0409211f    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 22 Aug 2016 15:22:11 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 22 Aug 2016 15:22:11 -0400    

Due to an error in the abbreviated key abort logic, the most recently  
processed SortTuple could be incorrectly marked NULL, resulting in an  
incorrect final sort order.  
  
In the worst case, this could result in a corrupt btree index, which  
would need to be rebuild using REINDEX.  However, abbrevation doesn't  
abort very often, not all data types use it, and only one tuple would  
end up in the wrong place, so the practical impact of this mistake may  
be somewhat limited.  
  
Report and patch by Peter Geoghegan.  

commit   : ac3aac3292d6e958bb8235120ba6a12159a29afe    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 19 Aug 2016 14:38:55 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 19 Aug 2016 14:38:55 -0300    

Clobbering errno during cleanup after an error is an oft-repeated, easy  
to make mistake.  Deal with it here as everywhere else, by saving it  
aside and restoring after cleanup, before ereport'ing.  
  
In passing, add a missing errcode declaration in another ereport() call  
in the same file, which I noticed while skimming the file looking for  
similar problems.  
  
Backpatch to 9.4, where this code was introduced.  

commit   : c4f1540d3a296d0328e21b32cdc612f611353b7c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Aug 2016 16:04:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Aug 2016 16:04:35 -0400    

As usual, we've been pretty awful about maintaining these counts.  
They're not all that critical, perhaps, but let's get them right  
at release time.  Also fix 9.5, which I notice is just as bad.  
It's probably wrong further back, but the lack of --help=foo  
options before 9.5 makes it too painful to count.  

commit   : a8fc1950520985f321d4d07da9b1c633c0addd97    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Aug 2016 14:48:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Aug 2016 14:48:51 -0400    

These types are storage-compatible with real arrays, but they don't support  
toasting, so of course they can't support expansion either.  
  
Per bug #14289 from Michael Overmeyer.  Back-patch to 9.5 where expanded  
arrays were introduced.  
  
Report: <[email protected]>  

commit   : a0833b972bd1e1198486bcea1651fcbd160a02c3    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 18 Aug 2016 12:32:42 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 18 Aug 2016 12:32:42 +0200    

This adds a couple of new timezones that are present in the newer  
versions of Windows. It also updates comments to reference UTC rather  
than GMT, as this change has been made in Windows.  
  
Michael Paquier  

commit   : 94bc30725aed39498652e1394422d553ea305634    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 17 Aug 2016 17:03:36 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 17 Aug 2016 17:03:36 -0700    

INSERT ..  ON CONFLICT runs a pre-check of the possible conflicting  
constraints before performing the actual speculative insertion.  In case  
the inserted tuple included TOASTed columns the ON CONFLICT condition  
would be handled correctly in case the conflict was caught by the  
pre-check, but if two transactions entered the speculative insertion  
phase at the same time, one would have to re-try, and the code for  
aborting a speculative insertion did not handle deleting the  
speculatively inserted TOAST datums correctly.  
  
TOAST deletion would fail with "ERROR: attempted to delete invisible  
tuple" as we attempted to remove the TOAST tuples using  
simple_heap_delete which reasoned that the given tuples should not be  
visible to the command that wrote them.  
  
This commit updates the heap_abort_speculative() function which aborts  
the conflicting tuple to use itself, via toast_delete, for deleting  
associated TOAST datums.  Like before, the inserted toast rows are not  
marked as being speculative.  
  
This commit also adds a isolationtester spec test, exercising the  
relevant code path. Unfortunately 9.5 cannot handle two waiting  
sessions, and thus cannot execute this test.  
  
Reported-By: Viren Negi, Oskari Saarenmaa  
Author: Oskari Saarenmaa, edited a bit by me  
Bug: #14150  
Discussion: <[email protected]>  
Backpatch: 9.5, where ON CONFLICT was introduced  

commit   : de396a1cb34626619ddc6fb9dec6d12abee8b589    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 17 Aug 2016 13:15:03 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 17 Aug 2016 13:15:03 -0700    

Slot creation did not clear all fields upon creation. After start the  
memory is zeroed, but when a physical replication slot was created in  
the shared memory of a previously existing logical slot, catalog_xmin  
would not be cleared. That in turn would prevent vacuum from doing its  
duties.  
  
To fix initialize all the fields. To make similar future bugs less  
likely, zero all of ReplicationSlotPersistentData, and re-order the  
rest of the initialization to be in struct member order.  
  
Analysis: Andrew Gierth  
Reported-By: [email protected]  
Author: Michael Paquier  
Discussion: <[email protected]>  
Backpatch: 9.4, where replication slots were introduced  

commit   : 509815ed782cd34b4b38e79431f6d7d0c8b25223    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Aug 2016 15:51:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Aug 2016 15:51:10 -0400    

As implemented, -e ran an EXPLAIN but then discarded the output, which  
certainly seems pointless.  Make it print to stdout instead.  It's been  
like that forever, so back-patch to all supported branches.  
  
Daniel Gustafsson, reviewed by Andreas Scherbaum  
  
Patch: <[email protected]>  

commit   : 7f35949aaf6feadb79450808af07d9aabd338b14    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Aug 2016 15:58:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Aug 2016 15:58:30 -0400    

This is somewhat cosmetic, since as long as you know what you are looking  
at, "10.0" is a serviceable substitute for "10".  But there is a potential  
for confusion between version numbers with minor numbers and those without  
--- we don't want people asking "why is psql saying 10.0 when my server is  
10.2".  Therefore, back-patch as far as practical, which turns out to be  
9.3.  I could have redone the patch to use fprintf(stderr) in place of  
psql_error(), but it seems more work than is warranted for branches that  
will be EOL or nearly so by the time v10 comes out.  
  
Although only psql seems to contain any code that needs this, I chose  
to put the support function into fe_utils, since it seems likely we'll  
need it in other client programs in future.  (In 9.3-9.5, use dumputils.c,  
the predecessor of fe_utils/string_utils.c.)  
  
In HEAD, also fix the backend code that whines about loadable-library  
version mismatch.  I don't see much need to back-patch that.  

commit   : 6356512140ced6be8eff469862ad7f2ab27126c2    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Aug 2016 15:06:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Aug 2016 15:06:01 -0400    

NUMERIC_MAX_PRECISION is a purely arbitrary constraint on the precision  
and scale you can write in a numeric typmod.  It might once have had  
something to do with the allowed range of a typmod-less numeric value,  
but at least since 9.1 we've allowed, and documented that we allowed,  
any value that would physically fit in the numeric storage format;  
which is something over 100000 decimal digits, not 1000.  
  
Hence, get rid of numeric_in()'s use of NUMERIC_MAX_PRECISION as a limit  
on the allowed range of the exponent in scientific-format input.  That was  
especially silly in view of the fact that you can enter larger numbers as  
long as you don't use 'e' to do it.  Just constrain the value enough to  
avoid localized overflow, and let make_result be the final arbiter of what  
is too large.  Likewise adjust ecpg's equivalent of this code.  
  
Also get rid of numeric_recv()'s use of NUMERIC_MAX_PRECISION to limit the  
number of base-NBASE digits it would accept.  That created a dump/restore  
hazard for binary COPY without doing anything useful; the wire-format  
limit on number of digits (65535) is about as tight as we would want.  
  
In HEAD, also get rid of pg_size_bytes()'s unnecessary intimacy with what  
the numeric range limit is.  That code doesn't exist in the back branches.  
  
Per gripe from Aravind Kumar.  Back-patch to all supported branches,  
since they all contain the documentation claim about allowed range of  
NUMERIC (cf commit cabf5d84b).  
  
Discussion: <[email protected]>  

commit   : ed2d7b8c8ce53648a0ef1c3fc5e99bd69b17dfca    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Aug 2016 12:13:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 12 Aug 2016 12:13:04 -0400    

EXPLAIN (ANALYZE, TIMING OFF) would print an elapsed time of zero for  
a trigger function, because no measurement has been taken but it printed  
the field anyway.  This isn't what EXPLAIN does elsewhere, so suppress it.  
  
In the same vein, EXPLAIN (ANALYZE, BUFFERS) with non-text output format  
would print buffer I/O timing numbers even when no measurement has been  
taken because track_io_timing is off.  That seems not per policy, either,  
so change it.  
  
Back-patch to 9.2 where these features were introduced.  
  
Maksim Milyutin  
  
Discussion: <[email protected]>  

commit   : 4fc8e2315da3ee67538f55ce0c6aee3eee07e026    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 12 Aug 2016 12:49:38 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 12 Aug 2016 12:49:38 +0100    

Commit 14e8803f1 removed LWLocks when accessing MyProc->syncRepState  
but didn't clean up the surrounding code and comments.  
  
Cleanup and backpatch to 9.5, to keep code similar.  
  
Julien Rouhaud, improved by suggestion from Michael Paquier,  
implemented trivially by myself.  

commit   : 270c29f125f5b5d2a199fb98fdf9c289640093a3    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 12 Aug 2016 10:36:20 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 12 Aug 2016 10:36:20 +0100    

Original wording was correct but not the intended meaning.  
  
Reported by Patrik Wenger  

commit   : c4bf83017f90eb5a1959e4394381442f75509740    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 11 Aug 2016 15:09:24 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 11 Aug 2016 15:09:24 -0400    

commit   : 894993ffee387383b371ebc515b5e8ea156f9574    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 11 Aug 2016 11:22:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 11 Aug 2016 11:22:25 -0400    

Commit 874fe3aea changed the command tag returned for CREATE MATVIEW/CREATE  
TABLE AS ... WITH NO DATA, but missed that there was code in spi.c that  
expected the command tag to always be "SELECT".  Fortunately, the  
consequence was only an Assert failure, so this oversight should have no  
impact in production builds.  
  
Since this code path was evidently un-exercised, add a regression test.  
  
Per report from Shivam Saxena. Back-patch to 9.3, like the previous commit.  
  
Michael Paquier  
  
Report: <[email protected]>  

commit   : a470858078e129641de24f5d090632f76b055cd8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Aug 2016 21:39:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Aug 2016 21:39:50 -0400    

Previous contents of adminpack.sgml were rather far short of project norms.  
Not to mention being outright wrong about the signature of pg_file_read().  

commit   : 57f2abd176075fcb6a5d94d2c33adbf489765b10    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 9 Aug 2016 19:07:24 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 9 Aug 2016 19:07:24 -0400    

commit   : 930675867b932efe02a4aba8b639402a2f3d5b9d    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 9 Aug 2016 13:39:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 9 Aug 2016 13:39:24 -0400    

Per discussion with David Johnston.