PostgreSQL 9.5.2 commit log

commit   : 730811c7d1600b92d4bcb91ac66d2206cf3a06ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Mar 2016 16:07:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Mar 2016 16:07:39 -0400    

commit   : b56f7b1f0c5e41e85828774debf8b911a203e012    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Mar 2016 11:32:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Mar 2016 11:32:17 -0400    

Security: CVE-2016-2193, CVE-2016-3065  

commit   : bf78a6f107949fdfb513d1b45e30cefe04e09e4f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Mar 2016 10:57:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Mar 2016 10:57:42 -0300    

brin_page_type() and brin_metapage_info() did not enforce being called  
by superuser, like other pageinspect functions that take bytea do.  
Since they don't verify the passed page thoroughly, it is possible to  
use them to read the server memory with a carefully crafted bytea value,  
up to a file kilobytes from where the input bytea is located.  
  
Have them throw errors if called by a non-superuser.  
  
Report and initial patch: Andreas Seltenreich  
  
Security: CVE-2016-3065  

commit   : db69e58a0642ef7fa46d62f6c4cf2460c3a1b41b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 28 Mar 2016 09:03:41 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 28 Mar 2016 09:03:41 -0400    

In the plancache, we check if the environment we planned the query under  
has changed in a way which requires us to re-plan, such as when the user  
for whom the plan was prepared changes and RLS is being used (and,  
therefore, there may be different policies to apply).  
  
Unfortunately, while those values were set and checked, they were not  
being reset when the query was re-planned and therefore, in cases where  
we change role, re-plan, and then change role again, we weren't  
re-planning again.  This leads to potentially incorrect policies being  
applied in cases where role-specific policies are used and a given query  
is planned under one role and then executed under other roles, which  
could happen under security definer functions or when a common user and  
query is planned initially and then re-used across multiple SET ROLEs.  
  
Further, extensions which made use of CopyCachedPlan() may suffer from  
similar issues as the RLS-related fields were not properly copied as  
part of the plan and therefore RevalidateCachedQuery() would copy in the  
current settings without invalidating the query.  
  
Fix by using the same approach used for 'search_path', where we set the  
correct values in CompleteCachedPlan(), check them early on in  
RevalidateCachedQuery() and then properly reset them if re-planning.  
Also, copy through the values during CopyCachedPlan().  
  
Pointed out by Ashutosh Bapat.  Reviewed by Michael Paquier.  
  
Back-patch to 9.5 where RLS was introduced.  
  
Security: CVE-2016-2193  

commit   : d6e740129a1be7ef751d976c21b48904e151e3be    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 28 Mar 2016 08:44:53 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 28 Mar 2016 08:44:53 +0200    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 0ffb9ae13cb7e2a9480ed8ee34071074bd80a7aa  

commit   : 4a1d57d4dafe543fa5be2f6546df97c5ce5d8f63    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Mar 2016 19:26:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 27 Mar 2016 19:26:26 -0400    

commit   : c5b5168cfc5c7aa74ce95ef64b79c6633230f424    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 27 Mar 2016 23:46:25 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 27 Mar 2016 23:46:25 +0200    

Previously pg_rewind did not fsync any files. That's problematic, given  
that the target directory is modified. If the database was started  
afterwards, 2ce439f33 luckily already caused the data directory to be  
synced to disk at postmaster startup; reducing the scope of the problem.  
  
To fix, use initdb -S, at the end of the pg_rewind run. It doesn't seem  
worthwhile to duplicate the code into pg_rewind, and initdb -S is  
already used that way by pg_upgrade.  
  
Reported-By: Andres Freund  
Author: Michael Paquier, somewhat edited by me  
Discussion: 20160310034352.iuqgvpmg5qmnxtkz@alap3.anarazel.de  
    CAB7nPqSytVG1o4S3S2pA1O=692ekurJ+fckW2PywEG3sNw54Ow@mail.gmail.com  
Backpatch: 9.5, where pg_rewind was introduced  

commit   : fa5098da1ab11daaeba788a2f4106394218b6761    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 27 Mar 2016 22:48:31 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 27 Mar 2016 22:48:31 +0200    

This was a relatively harmless leak, as createBackupLabel() is only  
called once per pg_rewind invocation.  
  
Author: Michael Paquier  
Reported-By: Michael Paquier  
Discussion: CAB7nPqRnOw30gOXe2_SPLjh37bgm4V+txbYAPwoXb97nGQ297w@mail.gmail.com  
Backpatch: 9.5, where pg_rewind was introduced  

commit   : ec8a30ef2a2b5cf4221231a324d1bd3310fe8f2c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 27 Mar 2016 17:47:55 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 27 Mar 2016 17:47:55 +0200    

Returning the direct result of bit arithmetic, in a macro intended to be  
used in a boolean manner, can be problematic if the return value is  
stored in a variable of type 'bool'. If bool is implemented using C99's  
_Bool, that can lead to comparison failures if the variable is then  
compared again with the expression (see ginStepRight() for an example  
that fails), as _Bool forces the result to be 0/1. That happens in some  
configurations of newer MSVC compilers.  It's also problematic when  
storing the result of such an expression in a narrower type.  
  
Several gin macros have been declared in that style since gin's initial  
commit in 8a3631f8d86.  
  
There's a lot more macros like this, but this is the only one causing  
regression test failures; and I don't want to commit and backpatch a  
larger patch with lots of conflicts just before the next set of minor  
releases.  
  
Discussion: 20150811154237.GD17575@awork2.anarazel.de  
Backpatch: All supported branches  

commit   : 12aa56d4d629addbe9cfdb578a3255288eded319    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Mar 2016 15:58:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Mar 2016 15:58:44 -0400    

We really need to sync all of our IANA-derived timezone code with upstream,  
but that's going to be a large patch and I certainly don't care to shove  
such a thing into stable branches immediately before a release.  As a  
stopgap, copy just the tzcode2016c logic that checks validity of timezone  
abbreviations.  This prevents getting multiple "time zone abbreviation  
differs from POSIX standard" bleats with tzdata 2014b and later.  

commit   : 31d02ebf74db9b79d76d4d072b8fd6d9a6f877bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Mar 2016 19:03:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Mar 2016 19:03:08 -0400    

DST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai,  
Astrakhan, Kirov, Sakhalin, Ulyanovsk regions).  Historical corrections  
for Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd).  
  
As of 2015b, the keepers of the IANA timezone database started to use  
numeric time zone abbreviations (e.g., "+04") instead of inventing  
abbreviations not found in the wild like "ASTT".  This causes our rather  
old copy of zic to whine "warning: time zone abbreviation differs from  
POSIX standard" several times during "make install".  This warning is  
harmless according to the IANA folk, and I don't see any problems with  
these abbreviations in some simple tests; but it seems like now would be  
a good time to update our copy of the tzcode stuff.  I'll look into that  
soon.  

commit   : 8aa6e97805a79eb30ac9c36acb1126280c2ffbdf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 23 Mar 2016 15:58:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 23 Mar 2016 15:58:34 -0400    

Unfortunately, every version of glibc thus far tested has bugs whereby  
strcoll() ordering does not match strxfrm() ordering as required by  
the standard.  This can result in, for example, corrupted indexes.  
Disabling abbreviated keys in these cases slows down non-C-collation  
string sorting considerably, but there seems to be no practical  
alternative.  Users who are confident that their libc implementations  
are solid in this regard can re-enable the optimization by compiling  
with TRUST_STRXFRM.  
  
Users who have built indexes using PostgreSQL 9.5 or PostgreSQL 9.5.1  
should REINDEX if there is a possibility that they may have been  
affected by this problem.  
  
Report by Marc-Olaf Jaschke.  Investigation mostly by Tom Lane, with  
help from Peter Geoghegan, Noah Misch, Stephen Frost, and me.  Patch  
by me, reviewed by Peter Geoghegan and Tom Lane.  

commit   : 1548c781888be14d2f24d65fbd591198fabef3a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Mar 2016 11:00:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Mar 2016 11:00:39 -0400    

User-facing (even tested by regression tests) error conditions were thrown  
with elog(), hence had wrong SQLSTATE and were untranslatable.  And the  
error message texts weren't up to project style, either.  

commit   : 5f95521b3a4ede720d8927383d79b11e37b6bc80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Mar 2016 10:43:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Mar 2016 10:43:13 -0400    

jsonb_set() could produce wrong answers or incorrect error reports, or in  
the worst case even crash, when trying to convert a path-array element into  
an integer for use as an array subscript.  Per report from Vitaly Burovoy.  
Back-patch to 9.5 where the faulty code was introduced (in commit  
c6947010ceb42143).  
  
Michael Paquier  

commit   : 147112d0984331d92b8c2faad885788c7cfd9fd2    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 23 Mar 2016 11:33:26 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 23 Mar 2016 11:33:26 +0000    

commit   : d8d5a00b182009f6fdb426a40ac677c4fda56be7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Mar 2016 17:56:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Mar 2016 17:56:06 -0400    

In commit afb9249d06f47d7a, we (probably I) made ExecLockRows assign  
null test tuples to all relations of the query while setting up to do an  
EvalPlanQual recheck for a newly-updated locked row.  This was sheerest  
brain fade: we should only set test tuples for relations that are lockable  
by the LockRows node, and in particular empty test tuples are only sensible  
for inheritance child relations that weren't the source of the current  
tuple from their inheritance tree.  Setting a null test tuple for an  
unrelated table causes it to return NULLs when it should not, as exhibited  
in bug #14034 from Bronislav Houdek.  To add insult to injury, doing it the  
wrong way required two loops where one would suffice; so the corrected code  
is even a bit shorter and faster.  
  
Add a regression test case based on his example, and back-patch to 9.5  
where the bug was introduced.  

commit   : 2f38b3e7dda4c3532b6bbc8676a8d30d528cd74e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 19 Mar 2016 18:36:35 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 19 Mar 2016 18:36:35 -0400    

Modern Perl has removed psed from its core distribution, so it might not  
be readily available on some build platforms. We therefore replace its  
use with a Perl script generated by s2p, which is equivalent to the sed  
script. The latter is retained for non-MSVC builds to avoid creating a  
new hard dependency on Perl for non-Windows tarball builds.  
  
Backpatch to all live branches.  
  
Michael Paquier and me.  

commit   : e1936470ea10311614ff893113d40873b630d521    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Mar 2016 17:19:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Mar 2016 17:19:37 -0400    

A couple makefiles had misspelled the magic .PHONY target as PHONY.  

commit   : 853d40b60e593d81c01c3d5f3be289e05189b292    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Mar 2016 20:17:04 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Mar 2016 20:17:04 -0300    

I wrote "brin_summarize_new_pages" instead, in docs as well as in the  
commit message of commit ac443d1034d9.  
  
Bug: #14030  
Reported-By: Chris Pacejo  

commit   : e52e22d93233e46b308c9bb778d17cf9bc5b0970    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Mar 2016 16:46:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Mar 2016 16:46:23 -0400    

Aleksander Alekseev  

commit   : d0a585c6997de6aebd5866c9c1791a1badfcee0a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Mar 2016 15:50:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Mar 2016 15:50:33 -0400    

In HEAD, fix incorrect field width for hours part of OF when tm_gmtoff is  
negative.  This was introduced by commit 2d87eedc1d4468d3 as a result of  
falsely applying a pattern that's correct when + signs are omitted, which  
is not the case for OF.  
  
In 9.4, fix missing abs() call that allowed a sign to be attached to the  
minutes part of OF.  This was fixed in 9.5 by 9b43d73b3f9bef27, but for  
inscrutable reasons not back-patched.  
  
In all three versions, ensure that the sign of tm_gmtoff is correctly  
reported even when the GMT offset is less than 1 hour.  
  
Add regression tests, which evidently we desperately need here.  
  
Thomas Munro and Tom Lane, per report from David Fetter  

commit   : 8ee2e5f78cd7f99d41ddf2c396d83adb6f9df2db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Mar 2016 23:18:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Mar 2016 23:18:07 -0400    

This didn't work because when we dropped and re-established a database  
connection, we did not bother to reset session-specific state such as  
the statements-are-prepared flags.  
  
The st->prepared[] array certainly needs to be flushed, and I cleared a  
couple of other fields as well that couldn't possibly retain meaningful  
state for a new connection.  
  
In passing, fix some bogus comments and strange field order choices.  
  
Per report from Robins Tharakan.  

commit   : 3f14d8d59457f98b8ddbbc29cffae9260037aad5    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Mar 2016 18:04:48 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Mar 2016 18:04:48 -0400    

INSERT ... ON CONFLICT's precheck may have to wait on the outcome of  
another insertion, which may or may not itself be a speculative  
insertion.  This wait is not necessarily associated with an exclusion  
constraint, but was always reported that way in log messages if the wait  
happened to involve a tuple that had no speculative token.  
  
Initially discovered through use of ON CONFLICT DO NOTHING, where  
spurious references to exclusion constraints in log messages were more  
likely.  
  
Patch by Peter Geoghegan.  
Reviewed by Julien Rouhaud.  
  
Back-patch to 9.5 where INSERT ... ON CONFLICT was added.  

commit   : 755ebfa41786e6b6b482af435cba79d57548a5e7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Mar 2016 17:57:17 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Mar 2016 17:57:17 -0300    

commit   : b4ce97aa5f603e039ed40af6a208c6f585d1ba9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Mar 2016 13:19:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Mar 2016 13:19:57 -0400    

Previously, we included <xlocale.h> only if necessary to get the definition  
of type locale_t.  According to notes in PGAC_TYPE_LOCALE_T, this is  
important because on some versions of glibc that file supplies an  
incompatible declaration of locale_t.  (This info may be obsolete, because  
on my RHEL6 box that seems to be the *only* definition of locale_t; but  
there may still be glibc's in the wild for which it's a live concern.)  
  
It turns out though that on FreeBSD and maybe other BSDen, you can get  
locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from  
<xlocale.h>.  This was leaving us compiling calls to mbstowcs_l() and  
friends with no visible prototype, which causes a warning and could  
possibly cause actual trouble, since it's not declared to return int.  
  
Hence, adjust the configure checks so that we'll include <xlocale.h>  
either if it's necessary to get type locale_t or if it's necessary to  
get a declaration of mbstowcs_l().  
  
Report and patch by Aleksander Alekseev, somewhat whacked around by me.  
Back-patch to all supported branches, since we have been using  
mbstowcs_l() since 9.1.  

commit   : 1bee54e5143f4925297954690c56920d720b7078    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Mar 2016 11:31:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Mar 2016 11:31:22 -0400    

On the machines I tried this on, pressing TAB after SECURITY LABEL led to  
being offered ON and FOR as intended, plus random other keywords (varying  
across machines).  But if you were a bit more unlucky you'd get a crash,  
as reported by nummervet@mail.ru in bug #14019.  
  
Seems to have been an aboriginal error in the SECURITY LABEL patch,  
commit 4d355a8336e0f226.  Hence, back-patch to all supported versions.  
There's no bug in HEAD, though, thanks to our recent tab-completion  
rewrite.  

commit   : aa9c4e71ceccf239a268b0b6611a9260d0f94a74    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Mar 2016 16:44:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Mar 2016 16:44:10 -0400    

Commit d88976cfa1302e8d removed this code from ginFreeScanKeys():  
-		if (entry->list)  
-			pfree(entry->list);  
evidently in the belief that that ItemPointer array is allocated in the  
keyCtx and so would be reclaimed by the following MemoryContextReset.  
Unfortunately, it isn't and it won't.  It'd likely be a good idea for  
that to become so, but as a simple and back-patchable fix in the  
meantime, restore this code to ginFreeScanKeys().  
  
Also, add a similar pfree to where startScanEntry() is about to zero out  
entry->list.  I am not sure if there are any code paths where this  
change prevents a leak today, but it seems like cheap future-proofing.  
  
In passing, make the initial allocation of so->entries[] use palloc  
not palloc0.  The code doesn't depend on unused entries being zero;  
if it did, the array-enlargement code in ginFillScanEntry() would be  
wrong.  So using palloc0 initially can only serve to confuse readers  
about what the invariant is.  
  
Per report from Felipe de Jesús Molina Bravo, via Jaime Casanova in  
<CAJGNTeMR1ndMU2Thpr8GPDUfiHTV7idELJRFusA5UXUGY1y-eA@mail.gmail.com>  

commit   : a7915f114aad83c93548dffe6c947e7f441fc175    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Mar 2016 00:21:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Mar 2016 00:21:07 -0500    

This longstanding functionality evidently got lost in commit  
3d6d1b585524aab6.  Noted while studying an OOM report from Jaime  
Casanova.  Backpatch to 9.5 where the bug was introduced.  

commit   : 1598dc15bab35a9fd061babbae716777259d3147    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Mar 2016 18:16:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Mar 2016 18:16:24 -0500    

Commit a2dabf0e1dda93c8 had the bright idea that it could modify a "const"  
global variable if it merely casted away const from a pointer.  This does  
not work on platforms where the compiler puts "const" variables into  
read-only storage.  Depressingly, we evidently have no such platforms in  
our buildfarm ... an oversight I have now remedied.  (The one platform  
that is known to catch this is recent OS X with -fno-common.)  
  
Per report from Chris Ruprecht.  Back-patch to 9.5 where the bogus  
code was introduced.  

commit   : c84c87ccc0e219a3f263aea9ec80068022ca1cc0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 10 Mar 2016 13:15:08 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 10 Mar 2016 13:15:08 -0300    

The chapter "Interfacing Extensions To Indexes" and CREATE OPERATOR  
CLASS reference page were missed when BRIN was added.  We document  
all our other index access methods there, so make sure BRIN complies.  
  
Author: Álvaro Herrera  
Reported-By: Julien Rouhaud, Tom Lane  
Reviewed-By: Emre Hasegeli  
Discussion: https://www.postgresql.org/message-id/56CF604E.9000303%40dalibo.com  
Backpatch: 9.5, where BRIN was introduced  

commit   : ad9a15d3f156dd42f6ed5e47fff1fa77e974c351    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 Mar 2016 13:48:58 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 10 Mar 2016 13:48:58 +0100    

The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit  
build that is later used on a CPU that supports AVX2 instructions using a  
version of Windows before 7SP1/2008R2SP1.  
  
Detect this combination, and in those cases turn off the generation of  
FMA3, per recommendation from the Visual Studio team.  
  
The bug is actually in the CRT shipping with Visual Studio 2013, but  
Microsoft have stated they're only fixing it in newer major versions.  
The fix is therefor conditioned specifically on being built with this  
version of Visual Studio, and not previous or later versions.  
  
Author: Christian Ullrich  

commit   : 301cc3549c29aaa58abdd9377a339cd86afeff15    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Mar 2016 18:53:53 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Mar 2016 18:53:53 -0800    

Renaming a file using rename(2) is not guaranteed to be durable in face  
of crashes. Use the previously added durable_rename()/durable_link_or_rename()  
in various places where we previously just renamed files.  
  
Most of the changed call sites are arguably not critical, but it seems  
better to err on the side of too much durability.  The most prominent  
known case where the previously missing fsyncs could cause data loss is  
crashes at the end of a checkpoint. After the actual checkpoint has been  
performed, old WAL files are recycled. When they're filled, their  
contents are fdatasynced, but we did not fsync the containing  
directory. An OS/hardware crash in an unfortunate moment could then end  
up leaving that file with its old name, but new content; WAL replay  
would thus not replay it.  
  
Reported-By: Tomas Vondra  
Author: Michael Paquier, Tomas Vondra, Andres Freund  
Discussion: 56583BDD.9060302@2ndquadrant.com  
Backpatch: All supported branches  

commit   : 63b06e8fa6bce0e92b9209531757a2ba5393802d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Mar 2016 18:53:53 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Mar 2016 18:53:53 -0800    

Renaming a file using rename(2) is not guaranteed to be durable in face  
of crashes; especially on filesystems like xfs and ext4 when mounted  
with data=writeback. To be certain that a rename() atomically replaces  
the previous file contents in the face of crashes and different  
filesystems, one has to fsync the old filename, rename the file, fsync  
the new filename, fsync the containing directory.  This sequence is not  
generally adhered to currently; which exposes us to data loss risks. To  
avoid having to repeat this arduous sequence, introduce  
durable_rename(), which wraps all that.  
  
Also add durable_link_or_rename(). Several places use link() (with a  
fallback to rename()) to rename a file, trying to avoid replacing the  
target file out of paranoia. Some of those rename sequences need to be  
durable as well. There seems little reason extend several copies of the  
same logic, so centralize the link() callers.  
  
This commit does not yet make use of the new functions; they're used in  
a followup commit.  
  
Author: Michael Paquier, Andres Freund  
Discussion: 56583BDD.9060302@2ndquadrant.com  
Backpatch: All supported branches  

commit   : b2ce9485bdf8e67494717b9d21978ef7592f9be1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Mar 2016 14:51:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Mar 2016 14:51:01 -0500    

An index search using a row comparison such as ROW(a, b) > ROW('x', 'y')  
would stop upon reaching a NULL entry in the "b" column, ignoring the  
fact that there might be non-NULL "b" values associated with later values  
of "a".  This happens because _bt_mark_scankey_required() marks the  
subsidiary scankey for "b" as required, which is just wrong: it's for  
a column after the one with the first inequality key (namely "a"), and  
thus can't be considered a required match.  
  
This bit of brain fade dates back to the very beginnings of our support  
for indexed ROW() comparisons, in 2006.  Kind of astonishing that no one  
came across it before Glen Takahashi, in bug #14010.  
  
Back-patch to all supported versions.  
  
Note: the given test case doesn't actually fail in unpatched 9.1, evidently  
because the fix for bug #6278 (i.e., stopping at nulls in either scan  
direction) is required to make it fail.  I'm sure I could devise a case  
that fails in 9.1 as well, perhaps with something involving making a cursor  
back up; but it doesn't seem worth the trouble.  

commit   : fd1cf9d8407589fae354e1a5b852f33eedc7f67f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 17:34:09 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 17:34:09 -0800    

Python's allocator does some low-level tricks for efficiency;  
unfortunately they trigger valgrind errors. Those tricks can be disabled  
making instrumentation easier; but few people testing postgres will have  
such a build of python. So add broad suppressions of the resulting  
errors.  
  
See also https://svn.python.org/projects/python/trunk/Misc/README.valgrind  
  
This possibly will suppress valid errors, but without it it's basically  
impossible to use valgrind with plpython code.  
  
Author: Andres Freund  
Backpatch: 9.4, where we started to maintain valgrind suppressions  

commit   : 9a5f1073f52bbcf81793dbbcc22c04c4364f490f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 19:21:28 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 19:21:28 -0800    

Author: Andres Freund  
Backpatch: 9.4, where we started to maintain valgrind suppressions  

commit   : 598a01de69b9e8b3cd106935e41db45d1b4853c4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 14:59:29 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 14:59:29 -0800    

ltree/ltree_gist/ltxtquery's headers stores data at MAXALIGN alignment,  
requiring some padding bytes. So far we left these uninitialized. Zero  
those by using palloc0.  
  
Author: Andres Freund  
Reported-By: Andres Freund / valgrind / buildarm animal skink  
Backpatch: 9.1-  

commit   : 68dababfe3417399bddd4b10107458c6c13e8626    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 13:33:24 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 8 Mar 2016 13:33:24 -0800    

plperl_ref_from_pg_array() didn't consider the case that postgrs arrays  
can have 0 dimensions (when they're empty) and accessed the first  
dimension without a check. Fix that by special casing the empty array  
case.  
  
Author: Alex Hunsaker  
Reported-By: Andres Freund / valgrind / buildfarm animal skink  
Discussion: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de  
Backpatch: 9.1-  

commit   : bfb6686e4253809cd55ee8b1ae60edece9a52490    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 8 Mar 2016 14:30:12 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 8 Mar 2016 14:30:12 -0500    

Commit 385f337c9f39b21dca96ca4770552a10a6d5af24 added a new argument  
to the FDW GetForeignPlan method, but failed to update the documentation  
to match.  
  
Etsuro Fujita  

commit   : 38e8f157b721d26fe08384650c606a235d51f8a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Mar 2016 21:52:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Mar 2016 21:52:30 -0500    

David Rowley  

commit   : 250e5bd7129d0b54594dc225f7380545189b70c1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Mar 2016 14:24:52 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 7 Mar 2016 14:24:52 -0800    

Coverity and inspection for the issue addressed in fd45d16f found some  
questionable code.  
  
Specifically coverity noticed that the wrong length was added in  
ReorderBufferSerializeChange() - without immediate negative consequences  
as the variable isn't used afterwards.  During code-review and testing I  
noticed that a bit of space was wasted when allocating tuple bufs in  
several places.  Thirdly, the debug memset()s in  
ReorderBufferGetTupleBuf() reduce the error checking valgrind can do.  
  
Backpatch: 9.4, like c8f621c43.  

commit   : 45b87cc57fe02f571de33ce20b4d7bec881a785a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Mar 2016 10:40:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Mar 2016 10:40:44 -0500    

A thinko in a96761391 caused pg_ctl to get it exactly backwards when  
deciding whether to report problems to the Windows eventlog or to stderr.  
Per bug #14001 from Manuel Mathar, who also identified the fix.  
Like the previous patch, back-patch to all supported branches.  

commit   : 5d1826fe76e9c82ec938edf054c2e3de52f5285c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 6 Mar 2016 16:27:20 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 6 Mar 2016 16:27:20 -0800    

In c8f621c43 I forgot to account for MAXALIGN when allocating a new  
tuplebuf in ReorderBufferGetTupleBuf(). That happens to currently not  
cause active problems on a number of platforms because the affected  
pointer is already aligned, but others, like ppc and hppa, trigger this  
in the regression test, due to a debug memset clearing memory.  
  
Fix that.  
  
Backpatch: 9.4, like the previous commit.  

commit   : c2d61adc32fe0f91b735f85263ecdd82589dba80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Mar 2016 19:21:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Mar 2016 19:21:03 -0500    

There were two places in spell.c that supposed that they could search  
for a location in a string produced by lowerstr() and then transpose  
the offset into the original string.  But this fails completely if  
lowerstr() transforms any characters into characters of different byte  
length, as can happen in Turkish UTF8 for instance.  
  
We'd added some comments about this coding in commit 51e78ab4ff328296,  
but failed to realize that it was not merely confusing but wrong.  
  
Coverity complained about this code years ago, but in such an opaque  
fashion that nobody understood what it was on about.  I'm not entirely  
sure that this issue *is* what it's on about, actually, but perhaps  
this patch will shut it up -- and in any case the problem is clear.  
  
Back-patch to all supported branches.  

commit   : ababe02ac2fa814c4e076e2ff92cd84e4222e5c7    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 6 Mar 2016 12:25:47 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 6 Mar 2016 12:25:47 +0100    

Author: Guillaume Lelarge  

commit   : 5990a034adfe4b777b07be10bd71730f1868e48d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Mar 2016 18:02:20 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Mar 2016 18:02:20 -0800    

When decoding the old version of an UPDATE or DELETE change, and if that  
tuple was bigger than MaxHeapTupleSize, we either Assert'ed out, or  
failed in more subtle ways in non-assert builds.  Normally individual  
tuples aren't bigger than MaxHeapTupleSize, with big datums toasted.  
But that's not the case for the old version of a tuple for logical  
decoding; the replica identity is logged as one piece. With the default  
replica identity btree limits that to small tuples, but that's not the  
case for FULL.  
  
Change the tuple buffer infrastructure to separate allocate over-large  
tuples, instead of always going through the slab cache.  
  
This unfortunately requires changing the ReorderBufferTupleBuf  
definition, we need to store the allocated size someplace. To avoid  
requiring output plugins to recompile, don't store HeapTupleHeaderData  
directly after HeapTupleData, but point to it via t_data; that leaves  
rooms for the allocated size.  As there's no reason for an output plugin  
to look at ReorderBufferTupleBuf->t_data.header, remove the field. It  
was just a minor convenience having it directly accessible.  
  
Reported-By: Adam Dratwiński  
Discussion: CAKg6ypLd7773AOX4DiOGRwQk1TVOQKhNwjYiVjJnpq8Wo+i62Q@mail.gmail.com  

commit   : e76e365be9e7fc30f19d21962461a0046d15ea5d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Mar 2016 18:02:20 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Mar 2016 18:02:20 -0800    

Somehow I managed to flip the order of restoring old & new tuples when  
de-spooling a change in a large transaction from disk. This happens to  
only take effect when a change is spooled to disk which has old/new  
versions of the tuple. That only is the case for UPDATEs where he  
primary key changed or where replica identity is changed to FULL.  
  
The tests didn't catch this because either spooled updates, or updates  
that changed primary keys, were tested; not both at the same time.  
  
Found while adding tests for the following commit.  
  
Backpatch: 9.4, where logical decoding was added  

commit   : 6e759cefe809cb7852cdf6ea3088d8604a817185    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Mar 2016 18:02:20 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Mar 2016 18:02:20 -0800    

Logical decoding's reorderbuffer keeps transactions in an LSN ordered  
list for efficiency. To make that's efficiently possible upper-level  
xids are forced to be logged before nested subtransaction xids.  That  
only works though if these records are all looked at: Unfortunately we  
didn't do so for e.g. row level locks, which are otherwise uninteresting  
for logical decoding.  
  
This could lead to errors like:  
"ERROR: subxact logged without previous toplevel record".  
  
It's not sufficient to just look at row locking records, the xid could  
appear first due to a lot of other types of records (which will trigger  
the transaction to be marked logged with MarkCurrentTransactionIdLoggedIfAny).  
So invent infrastructure to tell reorderbuffer about xids seen, when  
they'd otherwise not pass through reorderbuffer.c.  
  
Reported-By: Jarred Ward  
Bug: #13844  
Discussion: 20160105033249.1087.66040@wrigleys.postgresql.org  
Backpatch: 9.4, where logical decoding was added  

commit   : f95f1ce003d1453d78a8dd05577d6c61b251d48d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sun, 6 Mar 2016 02:29:04 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sun, 6 Mar 2016 02:29:04 +0900    

Previously recovery_min_apply_delay was applied even before recovery  
had reached consistency. This could cause us to wait a long time  
unexpectedly for read-only connections to be allowed. It's problematic  
because the standby was useless during that wait time.  
  
This patch changes recovery_min_apply_delay so that it's applied once  
the database has reached the consistent state. That is, even if the delay  
is set, the standby tries to replay WAL records as fast as possible until  
it has reached consistency.  
  
Author: Michael Paquier  
Reviewed-By: Julien Rouhaud  
Reported-By: Greg Clough  
Backpatch: 9.4, where recovery_min_apply_delay was added  
Bug: #13770  
Discussion: http://www.postgresql.org/message-id/20151111155006.2644.84564@wrigleys.postgresql.org  

commit   : 763b8f5d904517c3dffaaa43331a719c80d6e5b0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 13:47:05 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 13:47:05 -0500    

Rushabh Lathia  

commit   : 369c0b09080812943a2efcebe91cf4b271bc4f86    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 12:11:30 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 12:11:30 -0500    

I wasn't careful enough when back-patching.  

commit   : 7963731f94fd57293a651aa2a9a2e31dd11d6541    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 12:05:15 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 12:05:15 -0500    

Dmitriy Sarafannikov, reviewed by Michael Paquier and Haribabu Kommi,  
with a minor fix by me.  

commit   : 0315dfa8f4afa8390383119330ca0bf241be4ad4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 11:53:20 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Mar 2016 11:53:20 -0500    

The existing code confuses the byte length of the string (which is  
relevant when passing it to pg_strncasecmp) with the character length  
of the string (which is relevant when it is used with the SQL substring  
function).  Separate those two concepts.  
  
Report and patch by Kyotaro Horiguchi, reviewed by Thomas Munro and  
reviewed and further revised by me.  

commit   : 9b3f0c10e7ae60eb0f9ca41f01fb5cc2cbf9cf00    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 4 Mar 2016 12:59:47 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 4 Mar 2016 12:59:47 -0300    

This makes the flag more visible for testers using the default file as a  
template, increasing the likelyhood that the test suite will be run.  
Also have the flag be displayed in the fake "configure" output, if set.  
  
This patch is two new lines only, but perltidy decides to shift things  
around which makes it appear a bit bigger.  
  
Author: Michaël Paquier  
Reviewed-by: Craig Ringer  
Discussion: https://www.postgresql.org/message-id/CAB7nPqRet6UAP2APhZAZw%3DVhJ6w-Q-gGLdZkrOqFgd2vc9-ZDw%40mail.gmail.com  

commit   : 684f4a0ddedaa41aacd6539d509f922c6d23a1e2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 3 Mar 2016 17:09:08 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 3 Mar 2016 17:09:08 -0800    

Otherwise running installcheck-force on a server with  
synchronous_commit=off will result in the tests failing. All the other  
tests already do so...  
  
Backpatch: 9.4, where logical decoding was added  

commit   : bf7ced5e2dc8622f88129437a9adafc0bdd83041    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 3 Mar 2016 09:50:38 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 3 Mar 2016 09:50:38 +0000    

606c0123d627 attempted to reduce cost of index scans using > and <  
strategies, though got that completely wrong in a few complex cases.  
  
Revert whole patch until we find a safe optimization.  

commit   : f8a75881f90f88f4dc54f3692e4e1691cf2c0a91    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 2 Mar 2016 23:42:21 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 2 Mar 2016 23:42:21 -0800    

When adding replication origins in 5aa235042, I somehow managed to set  
the timestamp of decoded transactions to InvalidXLogRecptr when decoding  
one made without a replication origin. Fix that, and the wrong type of  
the new commit_time variable.  
  
This didn't trigger a regression test failure because we explicitly  
don't show commit timestamps in the regression tests, as they obviously  
are variable. Add a test that checks that a decoded commit's timestamp  
is within minutes of NOW() from before the commit.  
  
Reported-By: Weiping Qu  
Diagnosed-By: Artur Zakirov  
Discussion: 56D4197E.9050706@informatik.uni-kl.de,  
    56D42918.1010108@postgrespro.ru  
Backpatch: 9.5, where 5aa235042 originates.  

commit   : 429d6846572fe43dc11496adfeaecadf23925e3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Mar 2016 23:31:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Mar 2016 23:31:39 -0500    

A thinko concerning nesting depth caused json_to_record() to produce bogus  
output if a field of its input object contained a sub-object with a field  
name matching one of the requested output column names.  Per bug #13996  
from Johann Visagie.  
  
I added a regression test case based on his example, plus parallel tests  
for json_to_recordset, jsonb_to_record, jsonb_to_recordset.  The latter  
three do not exhibit the same bug (which suggests that we may be missing  
some opportunities to share code...) but testing seems like a good idea  
in any case.  
  
Back-patch to 9.4 where these functions were introduced.  

commit   : ca778d01e7f0f216bf2a8b0f45952c4c3ef5321a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Feb 2016 19:11:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Feb 2016 19:11:38 -0500    

This error message was written with only ON SELECT rules in mind, but since  
then we also made RETURNING-clause targetlists go through the same logic.  
This means that you got a rather off-topic error message if you tried to  
add a rule with RETURNING to a table having dropped columns.  Ideally we'd  
just support that, but some preliminary investigation says that it might be  
a significant amount of work.  Seeing that Nicklas Avén's complaint is the  
first one we've gotten about this in the ten years or so that the code's  
been like that, I'm unwilling to put much time into it.  Instead, improve  
the error report by issuing a different message for RETURNING cases, and  
revise the associated comment based on this investigation.  
  
Discussion: 1456176604.17219.9.camel@jordogskog.no  

commit   : 9ca3789191f80c6e6ac01c12171d4fba4c95f55d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Feb 2016 18:11:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Feb 2016 18:11:58 -0300    

Author: Amit Langote  

commit   : 6f3f50ad4a304b5617275b5c8592a2a3abb129b2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Feb 2016 17:53:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 29 Feb 2016 17:53:55 -0300    

The docs were advising to use /usr/local/pgsql/man instead, but that's  
wrong.  
  
Reported-By: Slawomir Sudnik  
Backpatch-To: 9.1  
Bug: #13894  

commit   : 28d65f99e21429b7138d8dddcc2b6217ae0e6763    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Feb 2016 10:48:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Feb 2016 10:48:40 -0500    

It's harmless, but might confuse readers.  Seems to have been introduced  
in 6bc8ef0b7f1f1df3.  Back-patch, just to avoid cosmetic cross-branch  
differences.  
  
Amit Langote  

commit   : f1dfcf63d9f076d9c200c0d7ee670899149e302a    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 29 Feb 2016 12:31:25 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 29 Feb 2016 12:31:25 +0000    

When converting an RTE with securityQuals into a security barrier  
subquery RTE, ensure that the Vars in the new subquery's targetlist  
all have varlevelsup = 0 so that they correctly refer to the  
underlying base relation being wrapped.  
  
The original code was creating new Vars by copying them from existing  
Vars referencing the base relation found elsewhere in the query, but  
failed to account for the fact that such Vars could come from sublink  
subqueries, and hence have varlevelsup > 0. In practice it looks like  
this could only happen with nested security barrier views, where the  
outer view has a WHERE clause containing a correlated subquery, due to  
the order in which the Vars are processed.  
  
Bug: #13988  
Reported-by: Adam Guthrie  
Backpatch-to: 9.4, where updatable SB views were introduced  

commit   : 2d43c45e9d84d711a616d2fca7eb1b040ac5ddaf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Feb 2016 23:39:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Feb 2016 23:39:20 -0500    

A failure partway through PGLC_localeconv() led to a situation where  
the next call would call free_struct_lconv() a second time, leading  
to free() on already-freed strings, typically leading to a core dump.  
Add a flag to remember whether we need to do that.  
  
Per report from Thom Brown.  His example case only provokes the failure  
as far back as 9.4, but nonetheless this code is obviously broken, so  
back-patch to all supported branches.  

commit   : 573cffc7a057f3147c23ea4d30a14c3e731a977a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Feb 2016 20:50:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Feb 2016 20:50:20 -0300    

Backpatch to: 9.4  

commit   : 0887382c2f2fd4c56b964a5cb2c945db14cd5f06    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 24 Feb 2016 23:41:54 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 24 Feb 2016 23:41:54 -0500    

Back-patch to 9.5, where the suites were introduced.  

commit   : 4324d1104df32305668a10d91d074b6a7ac82d8f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 24 Feb 2016 23:41:33 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 24 Feb 2016 23:41:33 -0500    

Back-patch to 9.4, where the suite was introduced.  

commit   : 815a31cdd18ff92ec6aff323fb3d2b6175acabbf    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 21 Feb 2016 22:48:44 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 21 Feb 2016 22:48:44 -0800    

In 4b4b680c3 I accidentally used sizeof(PrivateRefCountArray) instead of  
sizeof(PrivateRefCountEntry) when creating the refcount overflow  
hashtable. As the former is bigger than the latter, this luckily only  
resulted in a slightly increased memory usage when many buffers are  
pinned in a backend.  
  
Reported-By: Takashi Horikawa  
Discussion: 73FA3881462C614096F815F75628AFCD035A48C3@BPXM01GP.gisp.nec.co.jp  
Backpatch: 9.5, where thew new ref count infrastructure was introduced  

commit   : 68d68ff8333c106962d4a936e07eba24d63a2e07    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 21 Feb 2016 10:30:49 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 21 Feb 2016 10:30:49 -0500    

Some over-eager copy-and-pasting on my part resulted in a nonsense  
result being returned in this case. I have adopted the same pattern for  
handling this case as is used in the one argument form of the function,  
i.e. we just skip over the code that adds values to the object.  
  
Diagnosis and patch from Michael Paquier, although not quite his  
solution.  
  
Fixes bug #13936.  
  
Backpatch to 9.5 where jsonb_object was introduced.  

commit   : a397f8268a6a315b8c6579124637cddc8f79ea71    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 21 Feb 2016 09:04:59 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 21 Feb 2016 09:04:59 +0900    

With suggentions from Tom Lane.  

commit   : 377a1af56a5ad6e5c47e0a5141abbd912169f750    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 19 Feb 2016 22:47:50 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 19 Feb 2016 22:47:50 -0500    

Architecture reference material specifies this order, and s_lock.h  
inline assembly agrees.  The former order failed to provide mutual  
exclusion to lwlock.c and perhaps to other clients.  The two xlc  
buildfarm members, hornet and mandrill, have failed sixteen times with  
duplicate key errors involving pg_class_oid_index or pg_type_oid_index.  
Back-patch to 9.5, where commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340  
introduced atomics.  
  
Reviewed by Andres Freund and Tom Lane.  

commit   : c479024d325a02e0eb352e5b7f1873b4c51a5205    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 19 Feb 2016 08:31:39 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 19 Feb 2016 08:31:39 +0000    

StartupSUBTRANS() incorrectly handled cases near the max pageid in the subtrans  
data structure, which in some cases could lead to errors in startup for Hot  
Standby.  
This patch wraps the pageids correctly, avoiding any such errors.  
Identified by exhaustive crash testing by Jeff Janes.  
  
Jeff Janes  

commit   : 6f43c4d34844c400a159c40909ff227ca1d870cc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Feb 2016 18:32:26 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Feb 2016 18:32:26 -0500    

Suppress creation of the pg_upgrade delete script when the new data  
directory is inside the old data directory.  
  
Reported-by: IRC  
  
Backpatch-through: 9.3, where delete script tests were added  

commit   : 0276bbd6234a54c5e646f728131d204068fd0800    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Feb 2016 15:40:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Feb 2016 15:40:35 -0500    

Dead or half-dead index leaf pages were incorrectly reported as live, as a  
consequence of a code rearrangement I made (during a moment of severe brain  
fade, evidently) in commit d287818eb514d431.  
  
The index metapage was not counted in index_size, causing that result to  
not agree with the actual index size on-disk.  
  
Index root pages were not counted in internal_pages, which is inconsistent  
compared to the case of a root that's also a leaf (one-page index), where  
the root would be counted in leaf_pages.  Aside from that inconsistency,  
this could lead to additional transient discrepancies between the reported  
page counts and index_size, since it's possible for pgstatindex's scan to  
see zero or multiple pages marked as BTP_ROOT, if the root moves due to  
a split during the scan.  With these fixes, index_size will always be  
exactly one page more than the sum of the displayed page counts.  
  
Also, the index_size result was incorrectly documented as being measured in  
pages; it's always been measured in bytes.  (While fixing that, I couldn't  
resist doing some small additional wordsmithing on the pgstattuple docs.)  
  
Including the metapage causes the reported index_size to not be zero for  
an empty index.  To preserve the desired property that the pgstattuple  
regression test results are platform-independent (ie, BLCKSZ configuration  
independent), scale the index_size result in the regression tests.  
  
The documentation issue was reported by Otsuka Kenji, and the inconsistent  
root page counting by Peter Geoghegan; the other problems noted by me.  
Back-patch to all supported branches, because this has been broken for  
a long time.  

commit   : 2ce19f8a57f5f5eba3d86dc8457d2e992df5af8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Feb 2016 21:08:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Feb 2016 21:08:15 -0500    

A function name that's double-quoted in SQL can contain almost any  
characters, but we were using that name directly as part of the name  
generated for the Python-level function, and Python doesn't like  
anything that isn't pretty much a standard identifier.  To fix,  
replace anything that isn't an ASCII letter or digit with an underscore  
in the generated name.  This doesn't create any risk of duplicate Python  
function names because we were already appending the function OID to  
the generated name to ensure uniqueness.  Per bug #13960 from Jim Nasby.  
  
Patch by Jim Nasby, modified a bit by me.  Back-patch to all  
supported branches.  

commit   : 6ce8236ff40c8b5aeea93d2a155be1ef3210b8c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Feb 2016 13:43:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Feb 2016 13:43:03 -0500    

Clarify the description of which transactions will block a CREATE INDEX  
CONCURRENTLY command from proceeding, and mention that the index might  
still not be usable after CREATE INDEX completes.  (This happens if the  
index build detected broken HOT chains, so that pg_index.indcheckxmin gets  
set, and there are open old transactions preventing the xmin horizon from  
advancing past the index's initial creation.  I didn't want to explain what  
broken HOT chains are, though, so I omitted an explanation of exactly when  
old transactions prevent the index from being used.)  
  
Per discussion with Chris Travers.  Back-patch to all supported branches,  
since the same text appears in all of them.  

commit   : 3970b510ad1964f1825d159ffc1b41b85d74ece7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 16 Feb 2016 12:42:35 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 16 Feb 2016 12:42:35 -0500    

Reported-by: Tatsuo Ishii  
  
Backpatch-through: 9.5  

commit   : ce18d6bd30de7150e5423f62d62c27b9431f2c05    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 16 Feb 2016 15:36:52 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 16 Feb 2016 15:36:52 +0900    

Change "In this case" to "In the example above" to clarify what it  
actually refers to.  

commit   : 177ff78ddb11de94d653e4b3a93c16358b32af2d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Feb 2016 14:49:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 16 Feb 2016 14:49:47 +0900    

In runtime.sgml, the old formulas for calculating the reasonable  
values of SEMMNI and SEMMNS were incorrect. They have forgotten to  
count the number of semaphores which both the checkpointer process  
(introduced in 9.2) and the background worker processes (introduced  
in 9.3) need.  
  
This commit fixes those formulas so that they count the number of  
semaphores which the checkpointer process and the background worker  
processes need.  
  
Report and patch by Kyotaro Horiguchi. Only the patch for 9.3 was  
modified by me. Back-patch to 9.2 where the checkpointer process was  
added and the number of needed semaphores was increased.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Fujii Masao  
Backpatch: 9.2  
Discussion: http://www.postgresql.org/message-id/20160203.125119.66820697.horiguchi.kyotaro@lab.ntt.co.jp  

commit   : 73ca21c7ac2aa44f88b6ddb4cc4fc43cb2067e5e    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 15 Feb 2016 16:37:16 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 15 Feb 2016 16:37:16 -0800    

In commit 7b4bfc87 the DATA and DESCR entries for the new  
row_security_active() function were inadvertantly put after  
the PROVOLATILE defines, rather than before as they should  
have been placed. Move them up where they belong.  
  
Backpatch to 9.5 where the new entries were introduced.  

commit   : 1bad289a8085aa5e550f70c50b3e63362ddbd31f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Feb 2016 20:33:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Feb 2016 20:33:43 -0300    

The original code wasn't careful to test the file descriptor returned by  
PQsocket() for an invalid socket.  If an invalid socket did turn up,  
that would amount to calling FD_ISSET with fd = -1, whereby undefined  
behavior can be invoked.  
  
To fix, test file descriptor for validity and stop further processing if  
that fails.  
  
Problem noticed by Coverity.  
  
There is an existing FD_ISSET callsite that does check for invalid  
sockets beforehand, but the error message reported by it was  
strerror(errno); in testing the aforementioned change, that turns out to  
result in "bad socket: Success" which isn't terribly helpful.  Instead  
use PQerrorMessage() in both places which is more likely to contain an  
useful error message.  
  
Backpatch-through: 9.1.  

commit   : d2ab9b0ac3e59f6423913669f14a9fe15ab6dc59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Feb 2016 17:11:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Feb 2016 17:11:52 -0500    

Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,  
and hence complain about the character range checks I added in commit  
3bb3f42f3749d40b8d4de65871e8d828b18d4a45.  This is a bit of a pain since  
the regex library doesn't really want to assume that chr is unsigned.  
However, since any such reconfiguration would involve manual edits of  
regcustom.h anyway, we can put it on the shoulders of whoever wants to  
do that to adjust this new range-checking macro correctly.  
  
Per gripes from Coverity and Andres.  

commit   : 2dcaebea079d6e3c2c78bbf3b0948bf5ef707e21    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 10 Feb 2016 20:34:57 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 10 Feb 2016 20:34:57 -0500    

Thirty seconds was not consistently enough for promotion to complete on  
buildfarm members sungazer and tern.  Experiments suggest 43s would have  
been enough.  Back-patch to 9.5, where pg_rewind was introduced.  

commit   : 725f0ce29690b7e98d18290c9ab69b7a2bab3715    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 10 Feb 2016 20:34:02 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 10 Feb 2016 20:34:02 -0500    

Many automated test suites call pg_ctl.  Buildfarm members axolotl,  
hornet, mandrill, shearwater, sungazer and tern have failed when server  
shutdown took longer than the pg_ctl default 60s timeout.  This addition  
permits slow hosts to easily raise the timeout without us editing a  
--timeout argument into every test suite pg_ctl call.  Back-patch to 9.1  
(all supported versions) for the sake of automated testing.  
  
Reviewed by Tom Lane.  

commit   : b10635bb5b2e5f4e7e4a5e5a3313dcd70cf0509c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Feb 2016 19:30:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Feb 2016 19:30:11 -0500    

It turns out that on FreeBSD-derived platforms (including OS X), the  
*scanf() family of functions is pretty much brain-dead about multibyte  
characters.  In particular it will apply isspace() to individual bytes  
of input even when those bytes are part of a multibyte character, thus  
allowing false recognition of a field-terminating space.  
  
We appear to have little alternative other than instituting a coding  
rule that *scanf() is not to be used if the input string might contain  
multibyte characters.  (There was some discussion of relying on "%ls",  
but that probably just moves the portability problem somewhere else,  
and besides it doesn't fully prevent BSD *scanf() from using isspace().)  
  
This patch is a down payment on that: it gets rid of use of sscanf()  
to parse ispell dictionary files, which are certainly at great risk  
of having a problem.  The code is cleaner this way anyway, though  
a bit longer.  
  
In passing, improve a few comments.  
  
Report and patch by Artur Zakirov, reviewed and somewhat tweaked by me.  
Back-patch to all supported branches.