PostgreSQL 9.2.18 commit log

Stamp 9.2.18.

  
commit   : 01de6f3fd80721583baf2378ee8fe2b06a448ed0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 16:33:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 16:33:27 -0400    

Click here for diff

  
  

Last-minute updates for release notes.

  
commit   : c5081941f921bd342529b255ed2af1adccc253ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 11:56:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 11:56:10 -0400    

Click here for diff

  
Security: CVE-2016-5423, CVE-2016-5424  
  

Fix several one-byte buffer over-reads in to_number

  
commit   : b0134fe84da073f5c8ed4bbfac4a7111c1f7d799    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 11:12:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 11:12:59 -0400    

Click here for diff

  
Several places in NUM_numpart_from_char(), which is called from the SQL  
function to_number(text, text), could accidentally read one byte past  
the end of the input buffer (which comes from the input text datum and  
is not null-terminated).  
  
1. One leading space character would be skipped, but there was no check  
   that the input was at least one byte long.  This does not happen in  
   practice, but for defensiveness, add a check anyway.  
  
2. Commit 4a3a1e2cf apparently accidentally doubled that code that skips  
   one space character (so that two spaces might be skipped), but there  
   was no overflow check before skipping the second byte.  Fix by  
   removing that duplicate code.  
  
3. A logic error would allow a one-byte over-read when looking for a  
   trailing sign (S) placeholder.  
  
In each case, the extra byte cannot be read out directly, but looking at  
it might cause a crash.  
  
The third item was discovered by Piotr Stefaniak, the first two were  
found and analyzed by Tom Lane and Peter Eisentraut.  
  

Translation updates

  
commit   : e990c738b4f96befb43daa11c7d352a8d68d127d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 10:48:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 10:48:56 -0400    

Click here for diff

  
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 940819d75443c03de7554441c3b1e2bc42f76c8f  
  

Fix two errors with nested CASE/WHEN constructs.

  
commit   : 8b32516db20c836d6e3c31d81adf75b3a297663d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 10:33:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 10:33:47 -0400    

Click here for diff

  
ExecEvalCase() tried to save a cycle or two by passing  
&econtext->caseValue_isNull as the isNull argument to its sub-evaluation of  
the CASE value expression.  If that subexpression itself contained a CASE,  
then *isNull was an alias for econtext->caseValue_isNull within the  
recursive call of ExecEvalCase(), leading to confusion about whether the  
inner call's caseValue was null or not.  In the worst case this could lead  
to a core dump due to dereferencing a null pointer.  Fix by not assigning  
to the global variable until control comes back from the subexpression.  
Also, avoid using the passed-in isNull pointer transiently for evaluation  
of WHEN expressions.  (Either one of these changes would have been  
sufficient to fix the known misbehavior, but it's clear now that each of  
these choices was in itself dangerous coding practice and best avoided.  
There do not seem to be any similar hazards elsewhere in execQual.c.)  
  
Also, it was possible for inlining of a SQL function that implements the  
equality operator used for a CASE comparison to result in one CASE  
expression's CaseTestExpr node being inserted inside another CASE  
expression.  This would certainly result in wrong answers since the  
improperly nested CaseTestExpr would be caused to return the inner CASE's  
comparison value not the outer's.  If the CASE values were of different  
data types, a crash might result; moreover such situations could be abused  
to allow disclosure of portions of server memory.  To fix, teach  
inline_function to check for "bare" CaseTestExpr nodes in the arguments of  
a function to be inlined, and avoid inlining if there are any.  
  
Heikki Linnakangas, Michael Paquier, Tom Lane  
  
Report: https://github.com/greenplum-db/gpdb/pull/327  
Report: <4DDCEEB8.50602@enterprisedb.com>  
Security: CVE-2016-5423  
  

Obstruct shell, SQL, and conninfo injection via database and role names.

  
commit   : e8f4922c8683881236b1feb11d4e8ea35ab41cd7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
Due to simplistic quoting and confusion of database names with conninfo  
strings, roles with the CREATEDB or CREATEROLE option could escalate to  
superuser privileges when a superuser next ran certain maintenance  
commands.  The new coding rule for PQconnectdbParams() calls, documented  
at conninfo_array_parse(), is to pass expand_dbname=true and wrap  
literal database names in a trivial connection string.  Escape  
zero-length values in appendConnStrVal().  Back-patch to 9.1 (all  
supported versions).  
  
Nathan Bossart, Michael Paquier, and Noah Misch.  Reviewed by Peter  
Eisentraut.  Reported by Nathan Bossart.  
  
Security: CVE-2016-5424  
  

Promote pg_dumpall shell/connstr quoting functions to src/fe_utils.

  
commit   : f1d0b09cf17ee12481a62faa9413f9cc3f3f8112    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
Rename these newly-extern functions with terms more typical of their new  
neighbors.  No functional changes; a subsequent commit will use them in  
more places.  Back-patch to 9.1 (all supported versions).  Back branches  
lack src/fe_utils, so instead rename the functions in place; the  
subsequent commit will copy them into the other programs using them.  
  
Security: CVE-2016-5424  
  

Back-patch “Only quote libpq connection string values that need quoting.”

  
commit   : a19edcd2407d7dc8677513d1770e41b11a851163    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:53 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:53 -0400    

Click here for diff

  
Back-patch commit 2953cd6d17210935098c803c52c6df5b12a725b9 and certain  
runPgDump() bits of 3dee636e0404885d07885d41c0d70e50c784f324 to 9.2 and  
9.1.  This synchronizes their doConnStrQuoting() implementations with  
later releases.  Subsequent security patches will modify that function.  
  
Security: CVE-2016-5424  
  

Fix Windows shell argument quoting.

  
commit   : 4837155292f67f10576f3d7204ffd5379bbe3a7b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
The incorrect quoting may have permitted arbitrary command execution.  
At a minimum, it gave broader control over the command line to actors  
supposed to have control over a single argument.  Back-patch to 9.1 (all  
supported versions).  
  
Security: CVE-2016-5424  
  

Reject, in pg_dumpall, names containing CR or LF.

  
commit   : ffbdab65d3451d72762319829b4bc26dc71a8b48    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
These characters prematurely terminate Windows shell command processing,  
causing the shell to execute a prefix of the intended command.  The  
chief alternative to rejecting these characters was to bypass the  
Windows shell with CreateProcess(), but the ability to use such names  
has little value.  Back-patch to 9.1 (all supported versions).  
  
This change formally revokes support for these characters in database  
names and roles names.  Don't document this; the error message is  
self-explanatory, and too few users would benefit.  A future major  
release may forbid creation of databases and roles so named.  For now,  
check only at known weak points in pg_dumpall.  Future commits will,  
without notice, reject affected names from other frontend programs.  
  
Also extend the restriction to pg_dumpall --dbname=CONNSTR arguments and  
--file arguments.  Unlike the effects on role name arguments and  
database names, this does not reflect a broad policy change.  A  
migration to CreateProcess() could lift these two restrictions.  
  
Reviewed by Peter Eisentraut.  
  
Security: CVE-2016-5424  
  

Field conninfo strings throughout src/bin/scripts.

  
commit   : a466ea33c0acbf9938144ffd9eecdabbb69e8f46    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
These programs nominally accepted conninfo strings, but they would  
proceed to use the original dbname parameter as though it were an  
unadorned database name.  This caused "reindexdb dbname=foo" to issue an  
SQL command that always failed, and other programs printed a conninfo  
string in error messages that purported to print a database name.  Fix  
both problems by using PQdb() to retrieve actual database names.  
Continue to print the full conninfo string when reporting a connection  
failure.  It is informative there, and if the database name is the sole  
problem, the server-side error message will include the name.  Beyond  
those user-visible fixes, this allows a subsequent commit to synthesize  
and use conninfo strings without that implementation detail leaking into  
messages.  As a side effect, the "vacuuming database" message now  
appears after, not before, the connection attempt.  Back-patch to 9.1  
(all supported versions).  
  
Reviewed by Michael Paquier and Peter Eisentraut.  
  
Security: CVE-2016-5424  
  

Introduce a psql “\connect -reuse-previous=on|off” option.

  
commit   : f744e8906f7d029af2b9860469d8ebf77cb47e56    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
The decision to reuse values of parameters from a previous connection  
has been based on whether the new target is a conninfo string.  Add this  
means of overriding that default.  This feature arose as one component  
of a fix for security vulnerabilities in pg_dump, pg_dumpall, and  
pg_upgrade, so back-patch to 9.1 (all supported versions).  In 9.3 and  
later, comment paragraphs that required update had already-incorrect  
claims about behavior when no connection is open; fix those problems.  
  
Security: CVE-2016-5424  
  

Sort out paired double quotes in \connect, \password and \crosstabview.

  
commit   : 0cc3b12d284fb0e693abfd24e3950a19d3478380    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Click here for diff

  
In arguments, these meta-commands wrongly treated each pair as closing  
the double quoted string.  Make the behavior match the documentation.  
This is a compatibility break, but I more expect to find software with  
untested reliance on the documented behavior than software reliant on  
today's behavior.  Back-patch to 9.1 (all supported versions).  
  
Reviewed by Tom Lane and Peter Eisentraut.  
  
Security: CVE-2016-5424  
  

Release notes for 9.5.4, 9.4.9, 9.3.14, 9.2.18, 9.1.23.

  
commit   : 22f9b3dd3d92fa3f8f250c3cca468e6c27ca2b34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 21:31:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 21:31:02 -0400    

Click here for diff

  
  

Fix misestimation of n_distinct for a nearly-unique column with many nulls.

  
commit   : 127d73009a6d8ea7c17c6fe55458a2bfcf6a1593    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 18:52:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 18:52:02 -0400    

Click here for diff

  
If ANALYZE found no repeated non-null entries in its sample, it set the  
column's stadistinct value to -1.0, intending to indicate that the entries  
are all distinct.  But what this value actually means is that the number  
of distinct values is 100% of the table's rowcount, and thus it was  
overestimating the number of distinct values by however many nulls there  
are.  This could lead to very poor selectivity estimates, as for example  
in a recent report from Andreas Joseph Krogh.  We should discount the  
stadistinct value by whatever we've estimated the nulls fraction to be.  
(That is what will happen if we choose to use a negative stadistinct for  
a column that does have repeated entries, so this code path was just  
inconsistent.)  
  
In addition to fixing the stadistinct entries stored by several different  
ANALYZE code paths, adjust the logic where get_variable_numdistinct()  
forces an "all distinct" estimate on the basis of finding a relevant unique  
index.  Unique indexes don't reject nulls, so there's no reason to assume  
that the null fraction doesn't apply.  
  
Back-patch to all supported branches.  Back-patching is a bit of a judgment  
call, but this problem seems to affect only a few users (else we'd have  
identified it long ago), and it's bad enough when it does happen that  
destabilizing plan choices in a worse direction seems unlikely.  
  
Patch by me, with documentation wording suggested by Dean Rasheed  
  
Report: <VisenaEmail.26.df42f82acae38a58.156463942b8@tc7-visena>  
Discussion: <16143.1470350371@sss.pgh.pa.us>  
  

Teach libpq to decode server version correctly from future servers.

  
commit   : 3e40d9227f98088afcaf4f00c7025c465dad3551    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 18:58:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 18:58:12 -0400    

Click here for diff

  
Beginning with the next development cycle, PG servers will report two-part  
not three-part version numbers.  Fix libpq so that it will compute the  
correct numeric representation of such server versions for reporting by  
PQserverVersion().  It's desirable to get this into the field and  
back-patched ASAP, so that older clients are more likely to understand the  
new server version numbering by the time any such servers are in the wild.  
  
(The results with an old client would probably not be catastrophic anyway  
for a released server; for example "10.1" would be interpreted as 100100  
which would be wrong in detail but would not likely cause an old client to  
misbehave badly.  But "10devel" or "10beta1" would result in sversion==0  
which at best would result in disabling all use of modern features.)  
  
Extracted from a patch by Peter Eisentraut; comments added by me  
  
Patch: <802ec140-635d-ad86-5fdf-d3af0e260c22@2ndquadrant.com>  
  

Update time zone data files to tzdata release 2016f.

  
commit   : 7822792f74c404dd87a2cba4352de4640ef0893c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 12:58:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 12:58:17 -0400    

Click here for diff

  
DST law changes in Kemerovo and Novosibirsk.  Historical corrections for  
Azerbaijan, Belarus, and Morocco.  Asia/Novokuznetsk and Asia/Novosibirsk  
now use numeric time zone abbreviations instead of invented ones.  Zones  
for Antarctic bases and other locations that have been uninhabited for  
portions of the time span known to the tzdata database now report "-00"  
rather than "zzz" as the zone abbreviation for those time spans.  
  
Also, I decided to remove some of the timezone/data/ files that we don't  
use.  At one time that subdirectory was a complete copy of what IANA  
distributes in the tzdata tarballs, but that hasn't been true for a long  
time.  There seems no good reason to keep shipping those specific files  
but not others; they're just bloating our tarballs.  
  

doc: Remove documentation of nonexistent information schema columns

  
commit   : 49afd5e9ddfcb0f69ce417f612b7bbb672db07d8    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 13:45:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 13:45:55 -0400    

Click here for diff

  
These were probably copied in by accident.  
  
From: Clément Prévost <prevostclement@gmail.com>  
  

doc: OS collation changes can break indexes

  
commit   : 0f2b9d9cce905941bb4c507167c993c0264caea9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Aug 2016 17:13:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Aug 2016 17:13:10 -0400    

Click here for diff

  
Discussion: 20160702155517.GD18610@momjian.us  
  
Reviewed-by: Christoph Berg  
  
Backpatch-through: 9.1  
  

Fix pg_dump’s handling of public schema with both -c and -C options.

  
commit   : a5a7caaa1b5c6a00ee3fb891cd330cce862e33b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 12:48:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 12:48:51 -0400    

Click here for diff

  
Since -c plus -C requests dropping and recreating the target database  
as a whole, not dropping individual objects in it, we should assume that  
the public schema already exists and need not be created.  The previous  
coding considered only the state of the -c option, so it would emit  
"CREATE SCHEMA public" anyway, leading to an unexpected error in restore.  
  
Back-patch to 9.2.  Older versions did not accept -c with -C so the  
issue doesn't arise there.  (The logic being patched here dates to 8.0,  
cf commit 2193121fa, so it's not really wrong that it didn't consider  
the case at the time.)  
  
Note that versions before 9.6 will still attempt to emit REVOKE/GRANT  
on the public schema; but that happens without -c/-C too, and doesn't  
seem to be the focus of this complaint.  I considered extending this  
stanza to also skip the public schema's ACL, but that would be a  
misfeature, as it'd break cases where users intentionally changed that  
ACL.  The real fix for this aspect is Stephen Frost's work to not dump  
built-in ACLs, and that's not going to get back-ported.  
  
Per bugs #13804 and #14271.  Solution found by David Johnston and later  
rediscovered by me.  
  
Report: <20151207163520.2628.95990@wrigleys.postgresql.org>  
Report: <20160801021955.1430.47434@wrigleys.postgresql.org>  
  

Fixed array checking code for “unsigned long long” datatypes in libecpg.

  
commit   : 295edbecf73eb479257077c4c70e36f55ee6d3ef    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 1 Aug 2016 06:36:27 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 1 Aug 2016 06:36:27 +0200    

Click here for diff

  
  

Fix pg_basebackup so that it accepts 0 as a valid compression level.

  
commit   : a216177599928d409d90fe06678e1cc6fb2be234    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 1 Aug 2016 17:36:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 1 Aug 2016 17:36:14 +0900    

Click here for diff

  
The help message for pg_basebackup specifies that the numbers 0 through 9  
are accepted as valid values of -Z option. But, previously -Z 0 was rejected  
as an invalid compression level.  
  
Per discussion, it's better to make pg_basebackup treat 0 as valid  
compression level meaning no compression, like pg_dump.  
  
Back-patch to all supported versions.  
  
Reported-By: Jeff Janes  
Reviewed-By: Amit Kapila  
Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hVfM0B64b1_bPVKRqg@mail.gmail.com  
  

Doc: remove claim that hash index creation depends on effective_cache_size.

  
commit   : de818d4c735a0cffd172e111dc38c040d4cacead    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Jul 2016 18:32:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Jul 2016 18:32:34 -0400    

Click here for diff

  
This text was added by commit ff213239c, and not long thereafter obsoleted  
by commit 4adc2f72a (which made the test depend on NBuffers instead); but  
nobody noticed the need for an update.  Commit 9563d5b5e adds some further  
dependency on maintenance_work_mem, but the existing verbiage seems to  
cover that with about as much precision as we really want here.  Let's  
just take it all out rather than leaving ourselves open to more errors of  
omission in future.  (That solution makes this change back-patchable, too.)  
  
Noted by Peter Geoghegan.  
  
Discussion: <CAM3SWZRVANbj9GA9j40fAwheQCZQtSwqTN1GBTVwRrRbmSf7cg@mail.gmail.com>  
  

doc: apply hypen fix that was not backpatched

  
commit   : aea496cac1d61a382ec0e81e9681654f70c3e8c2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 14:52:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 14:52:17 -0400    

Click here for diff

  
Head patch was 42ec6c2da699e8e0b1774988fa97297a2cdf716c.  
  
Reported-by: Alexander Law  
  
Discussion: 5785FBE7.7060508@gmail.com  
  
Backpatch-through: 9.1  
  

Guard against empty buffer in gets_fromFile()’s check for a newline.

  
commit   : 76c10ca318df0e7f2b2e2840ae496d7000d1ca37    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 18:57:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 18:57:24 -0400    

Click here for diff

  
Per the fgets() specification, it cannot return without reading some data  
unless it reports EOF or error.  So the code here assumed that the data  
buffer would necessarily be nonempty when we go to check for a newline  
having been read.  However, Agostino Sarubbo noticed that this could fail  
to be true if the first byte of the data is a NUL (\0).  The fgets() API  
doesn't really work for embedded NULs, which is something I don't feel  
any great need for us to worry about since we generally don't allow NULs  
in SQL strings anyway.  But we should not access off the end of our own  
buffer if the case occurs.  Normally this would just be a harmless read,  
but if you were unlucky the byte before the buffer would contain '\n'  
and we'd overwrite it with '\0', and if you were really unlucky that  
might be valuable data and psql would crash.  
  
Agostino reported this to pgsql-security, but after discussion we concluded  
that it isn't worth treating as a security bug; if you can control the  
input to psql you can do far more interesting things than just maybe-crash  
it.  Nonetheless, it is a bug, so back-patch to all supported versions.  
  

Fix assorted fallout from IS [NOT] NULL patch.

  
commit   : 7b8526e5d6e0a010d4461aa565ff4cc13c2dc447    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 16:09:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 16:09:15 -0400    

Click here for diff

  
Commits 4452000f3 et al established semantics for NullTest.argisrow that  
are a bit different from its initial conception: rather than being merely  
a cache of whether we've determined the input to have composite type,  
the flag now has the further meaning that we should apply field-by-field  
testing as per the standard's definition of IS [NOT] NULL.  If argisrow  
is false and yet the input has composite type, the construct instead has  
the semantics of IS [NOT] DISTINCT FROM NULL.  Update the comments in  
primnodes.h to clarify this, and fix ruleutils.c and deparse.c to print  
such cases correctly.  In the case of ruleutils.c, this merely results in  
cosmetic changes in EXPLAIN output, since the case can't currently arise  
in stored rules.  However, it represents a live bug for deparse.c, which  
would formerly have sent a remote query that had semantics different  
from the local behavior.  (From the user's standpoint, this means that  
testing a remote nested-composite column for null-ness could have had  
unexpected recursive behavior much like that fixed in 4452000f3.)  
  
In a related but somewhat independent fix, make plancat.c set argisrow  
to false in all NullTest expressions constructed to represent "attnotnull"  
constructs.  Since attnotnull is actually enforced as a simple null-value  
check, this is a more accurate representation of the semantics; we were  
previously overpromising what it meant for composite columns, which might  
possibly lead to incorrect planner optimizations.  (It seems that what the  
SQL spec expects a NOT NULL constraint to mean is an IS NOT NULL test, so  
arguably we are violating the spec and should fix attnotnull to do the  
other thing.  If we ever do, this part should get reverted.)  
  
Back-patch, same as the previous commit.  
  
Discussion: <10682.1469566308@sss.pgh.pa.us>  
  

Improve documentation about CREATE TABLE … LIKE.

  
commit   : a9a998180aa417b972a4502a4ed9c69c35a7e556    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 13:26:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 13:26:59 -0400    

Click here for diff

  
The docs failed to explain that LIKE INCLUDING INDEXES would not preserve  
the names of indexes and associated constraints.  Also, it wasn't mentioned  
that EXCLUDE constraints would be copied by this option.  The latter  
oversight seems enough of a documentation bug to justify back-patching.  
  
In passing, do some minor copy-editing in the same area, and add an entry  
for LIKE under "Compatibility", since it's not exactly a faithful  
implementation of the standard's feature.  
  
Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>  
  

Register atexit hook only once in pg_upgrade.

  
commit   : 737f25cfedf05884c6ffa468b4e1024b5bcc3b81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 11:39:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 11:39:11 -0400    

Click here for diff

  
start_postmaster() registered stop_postmaster_atexit as an atexit(3)  
callback each time through, although the obvious intention was to do  
so only once per program run.  The extra registrations were harmless,  
so long as we didn't exceed ATEXIT_MAX, but still it's a bug.  
  
Artur Zakirov, with bikeshedding by Kyotaro Horiguchi and me  
  
Discussion: <d279e817-02b5-caa6-215f-cfb05dce109a@postgrespro.ru>  
  

Fix incorrect description of udt_privileges view in documentation.

  
commit   : 5e50a6718ac523be2fd9265463ecbbf21da43f25    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 Jul 2016 22:34:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 Jul 2016 22:34:42 +0900    

Click here for diff

  
The description of udt_privileges view contained an incorrect copy-pasted word.  
  
Back-patch to 9.2 where udt_privileges view was added.  
  
Author: Alexander Law  
  

Fix constant-folding of ROW(…) IS [NOT] NULL with composite fields.

  
commit   : bcdd8a19490974f73a2473d3a3cece8d3558d676    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jul 2016 15:25:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jul 2016 15:25:02 -0400    

Click here for diff

  
The SQL standard appears to specify that IS [NOT] NULL's tests of field  
nullness are non-recursive, ie, we shouldn't consider that a composite  
field with value ROW(NULL,NULL) is null for this purpose.  
ExecEvalNullTest got this right, but eval_const_expressions did not,  
leading to weird inconsistencies depending on whether the expression  
was such that the planner could apply constant folding.  
  
Also, adjust the docs to mention that IS [NOT] DISTINCT FROM NULL can be  
used as a substitute test if a simple null check is wanted for a rowtype  
argument.  That motivated reordering things so that IS [NOT] DISTINCT FROM  
is described before IS [NOT] NULL.  In HEAD, I went a bit further and added  
a table showing all the comparison-related predicates.  
  
Per bug #14235.  Back-patch to all supported branches, since it's certainly  
undesirable that constant-folding should change the semantics.  
  
Report and patch by Andrew Gierth; assorted wordsmithing and revised  
regression test cases by me.  
  
Report: <20160708024746.1410.57282@wrigleys.postgresql.org>  
  

Make the AIX case of Makefile.shlib safe for parallel make.

  
commit   : a4daf59eef9845a93c73056f6983b375c2a41fe9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Jul 2016 20:30:03 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Jul 2016 20:30:03 -0400    

Click here for diff

  
Use our typical approach, from src/backend/parser.  Back-patch to 9.1  
(all supported versions).  
  

Make contrib regression tests safe for Danish locale.

  
commit   : a1e75055368e28985cec9cc2c6fc133f4e144da2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 16:52:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 16:52:36 -0400    

Click here for diff

  
In btree_gin and citext, avoid some not-particularly-interesting  
dependencies on the sorting of 'aa'.  In tsearch2, use COLLATE "C" to  
remove an uninteresting dependency on locale sort order (and thereby  
allow removal of a variant expected-file).  
  
Also, in citext, avoid assuming that lower('I') = 'i'.  This isn't relevant  
to Danish but it does fail in Turkish.  
  

Make pltcl regression tests safe for Danish locale.

  
commit   : 52502e7a599f1ad013a88da226387a02de5d9639    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 14:24:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 14:24:07 -0400    

Click here for diff

  
Another peculiarity of Danish locale is that it has an unusual idea  
of how to sort upper vs. lower case.  One of the pltcl test cases has  
an issue with that.  Now that COLLATE works in all supported branches,  
we can just change the test to be locale-independent, and get rid of  
the variant expected file that used to support non-C locales.  
  

Fix MSVC build for changes in zic.

  
commit   : 4d37b7cffcfc5468c5a17cf41d96372b36dab1ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jul 2016 17:53:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jul 2016 17:53:31 -0400    

Click here for diff

  
Ooops, I missed back-patching commit f5f15ea6a along with the other stuff.  
  

Sync back-branch copies of the timezone code with IANA release tzcode2016c.

  
commit   : cd951aa614530ce562f47ca78120fc2bf5b58ba9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jul 2016 15:59:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jul 2016 15:59:36 -0400    

Click here for diff

  
Back-patch commit 1c1a7cbd6a1600c9, along with subsequent portability  
fixes, into all active branches.  Also, back-patch commits 696027727 and  
596857043 (addition of zic -P option) into 9.1 and 9.2, just to reduce  
differences between the branches.  src/timezone/ is now largely identical  
in all active branches, except that in 9.1, pgtz.c retains the  
initial-timezone-selection code that was moved over to initdb in 9.2.  
  
Ordinarily we wouldn't risk this much code churn in back branches, but it  
seems necessary in this case, because among the changes are two feature  
additions in the "zic" zone data file compiler (a larger limit on the  
number of allowed DST transitions, and addition of a "%z" escape in zone  
abbreviations).  IANA have not yet started to use those features in their  
tzdata files, but presumably they will before too long.  If we don't update  
then we'll be unable to adopt new timezone data.  Also, installations built  
with --with-system-tzdata (which includes most distro-supplied builds, I  
believe) might fail even if we don't update our copies of the data files.  
There are assorted bug fixes too, mostly affecting obscure timezones or  
post-2037 dates.  
  
Discussion: <13601.1468868947@sss.pgh.pa.us>  
  

Use correct symbol for minimum int64 value

  
commit   : 6c0be49b2ab7a673656d385ba09fc0c1657c6e33    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Jul 2016 09:37:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Jul 2016 09:37:33 -0400    

Click here for diff

  
The old code used SEQ_MINVALUE to get the smallest int64 value.  This  
was done as a convenience to avoid having to deal with INT64_IS_BUSTED,  
but that is obsolete now.  Also, it is incorrect because the smallest  
int64 value is actually SEQ_MINVALUE-1.  Fix by writing out the constant  
the long way, as it is done elsewhere in the code.  
  

Fix crash in close_ps() for NaN input coordinates.

  
commit   : 89b301104a6c5522bb9dc91565ac0e2cb5f4ddb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 14:42:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 14:42:37 -0400    

Click here for diff

  
The Assert() here seems unreasonably optimistic.  Andreas Seltenreich  
found that it could fail with NaNs in the input geometries, and it  
seems likely to me that it might fail in corner cases due to roundoff  
error, even for ordinary input values.  As a band-aid, make the function  
return SQL NULL instead of crashing.  
  
Report: <87d1md1xji.fsf@credativ.de>  
  

Fix torn-page, unlogged xid and further risks from heap_update().

  
commit   : 941557f18b611bd2295aa159e790a53d6ffd31dd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 15 Jul 2016 17:49:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 15 Jul 2016 17:49:48 -0700    

Click here for diff

  
When heap_update needs to look for a page for the new tuple version,  
because the current one doesn't have sufficient free space, or when  
columns have to be processed by the tuple toaster, it has to release the  
lock on the old page during that. Otherwise there'd be lock ordering and  
lock nesting issues.  
  
To avoid concurrent sessions from trying to update / delete / lock the  
tuple while the page's content lock is released, the tuple's xmax is set  
to the current session's xid.  
  
That unfortunately was done without any WAL logging, thereby violating  
the rule that no XIDs may appear on disk, without an according WAL  
record.  If the database were to crash / fail over when the page level  
lock is released, and some activity lead to the page being written out  
to disk, the xid could end up being reused; potentially leading to the  
row becoming invisible.  
  
There might be additional risks by not having t_ctid point at the tuple  
itself, without having set the appropriate lock infomask fields.  
  
To fix, compute the appropriate xmax/infomask combination for locking  
the tuple, and perform WAL logging using the existing XLOG_HEAP_LOCK  
record. That allows the fix to be backpatched.  
  
This issue has existed for a long time. There appears to have been  
partial attempts at preventing dangers, but these never have fully been  
implemented, and were removed a long time ago, in  
11919160 (cf. HEAP_XMAX_UNLOGGED).  
  
In master / 9.6, there's an additional issue, namely that the  
visibilitymap's freeze bit isn't reset at that point yet. Since that's a  
new issue, introduced only in a892234f830, that'll be fixed in a  
separate commit.  
  
Author: Masahiko Sawada and Andres Freund  
Reported-By: Different aspects by Thomas Munro, Noah Misch, and others  
Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com  
Backpatch: 9.1/all supported versions  
  

doc: Fix typos

  
commit   : 544ea9d7e0839695c3a796d3529fec92d503abb1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2016 22:28:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2016 22:28:03 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Fix GiST index build for NaN values in geometric types.

  
commit   : 042009f2441cea6ef0a01c3880a806e172629fbf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jul 2016 18:46:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jul 2016 18:46:00 -0400    

Click here for diff

  
GiST index build could go into an infinite loop when presented with boxes  
(or points, circles or polygons) containing NaN component values.  This  
happened essentially because the code assumed that x == x is true for any  
"double" value x; but it's not true for NaNs.  The looping behavior was not  
the only problem though: we also attempted to sort the items using simple  
double comparisons.  Since NaNs violate the trichotomy law, qsort could  
(in principle at least) get arbitrarily confused and mess up the sorting of  
ordinary values as well as NaNs.  And we based splitting choices on box size  
calculations that could produce NaNs, again resulting in undesirable  
behavior.  
  
To fix, replace all comparisons of doubles in this logic with  
float8_cmp_internal, which is NaN-aware and is careful to sort NaNs  
consistently, higher than any non-NaN.  Also rearrange the box size  
calculation to not produce NaNs; instead it should produce an infinity  
for a box with NaN on one side and not-NaN on the other.  
  
I don't by any means claim that this solves all problems with NaNs in  
geometric values, but it should at least make GiST index insertion work  
reliably with such data.  It's likely that the index search side of things  
still needs some work, and probably regular geometric operations too.  
But with this patch we're laying down a convention for how such cases  
ought to behave.  
  
Per bug #14238 from Guang-Dih Lei.  Back-patch to 9.2; the code used before  
commit 7f3bd86843e5aad8 is quite different and doesn't lock up on my simple  
test case, nor on the submitter's dataset.  
  
Report: <20160708151747.1426.60150@wrigleys.postgresql.org>  
Discussion: <28685.1468246504@sss.pgh.pa.us>  
  

doc: Update URL for PL/PHP

  
commit   : e1cbe5c962b278803d4c19a40109b7959aacee14    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jul 2016 12:13:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jul 2016 12:13:36 -0400    

Click here for diff

  
  

Fix TAP tests and MSVC scripts for pathnames with spaces.

  
commit   : fdf2ee62e6365b2da3a288a90f1607d4ce5caf92    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jul 2016 11:24:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jul 2016 11:24:04 -0400    

Click here for diff

  
Back-patch relevant parts of commit 30b2731bd into 9.1-9.3.  
  
Michael Paquier, Kyotaro Horiguchi  
  
Discussion: <20160704.160213.111134711.horiguchi.kyotaro@lab.ntt.co.jp>  
  

doc: mention dependency on collation libraries

  
commit   : cfb33bc33a233c77571e007102bc4242e402762a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jul 2016 11:22:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jul 2016 11:22:35 -0400    

Click here for diff

  
Document that index storage is dependent on the operating system's  
collation library ordering, and any change in that ordering can create  
invalid indexes.  
  
Discussion: 20160617154311.GB19359@momjian.us  
  
Backpatch-through: 9.1  
  

Make “postgres -C guc” print “” not “(null)” for null-valued GUCs.

  
commit   : dd41661d2c613c3e4f8328191758398bfbcbd598    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 11:55:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 11:55:18 -0400    

Click here for diff

  
Commit 0b0baf262 et al made this case print "(null)" on the grounds that  
that's what happened on platforms that didn't crash.  But neither behavior  
was actually intentional.  What we should print is just an empty string,  
for compatibility with the behavior of SHOW and other ways of examining  
string GUCs.  Those code paths don't distinguish NULL from empty strings,  
so we should not here either.  Per gripe from Alain Radix.  
  
Like the previous patch, back-patch to 9.2 where -C option was introduced.  
  
Discussion: <CA+YdpwxPUADrmxSD7+Td=uOshMB1KkDN7G7cf+FGmNjjxMhjbw@mail.gmail.com>  
  

Document that dependency tracking doesn’t consider function bodies.

  
commit   : 85743887e847b187bb16ec1f0ca3b967bc124223    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2016 20:07:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2016 20:07:58 -0400    

Click here for diff

  
If there's anyplace in our SGML docs that explains this behavior, I can't  
find it right at the moment.  Add an explanation in "Dependency Tracking"  
which seems like the authoritative place for such a discussion.  Per  
gripe from Michelle Schwan.  
  
While at it, update this section's example of a dependency-related  
error message: they last looked like that in 8.3.  And remove the  
explanation of dependency updates from pre-7.3 installations, which  
is probably no longer worth anybody's brain cells to read.  
  
The bogus error message example seems like an actual documentation bug,  
so back-patch to all supported branches.  
  
Discussion: <20160620160047.5792.49827@wrigleys.postgresql.org>  
  

Docs: improve description of psql’s %R prompt escape sequence.

  
commit   : 09e592b3935d0ce2970cdebdd4c6bb7d7ac9c28e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jun 2016 13:11:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jun 2016 13:11:40 -0400    

Click here for diff

  
Dilian Palauzov pointed out in bug #14201 that the docs failed to mention  
the possibility of %R producing '(' due to an unmatched parenthesis.  
  
He proposed just adding that in the same style as the other options were  
listed; but it seemed to me that the sentence was already nearly  
unintelligible, so I rewrote it a bit more extensively.  
  
Report: <20160619121113.5789.68274@wrigleys.postgresql.org>  
  

Fix validation of overly-long IPv6 addresses.

  
commit   : f66e0fec386754e85edb3355b1d000c99a38f5cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 17:16:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 17:16:32 -0400    

Click here for diff

  
The inet/cidr types sometimes failed to reject IPv6 inputs with too many  
colon-separated fields, instead translating them to '::/0'.  This is the  
result of a thinko in the original ISC code that seems to be as yet  
unreported elsewhere.  Per bug #14198 from Stefan Kaltenbrunner.  
  
Report: <20160616182222.5798.959@wrigleys.postgresql.org>  
  

Avoid crash in “postgres -C guc” for a GUC with a null string value.

  
commit   : 23ed284a5dda5286bd91bb601f30e5e6fae478af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 12:17:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 12:17:03 -0400    

Click here for diff

  
Emit "(null)" instead, which was the behavior all along on platforms  
that don't crash, eg OS X.  Per report from Jehan-Guillaume de Rorthais.  
Back-patch to 9.2 where -C option was introduced.  
  
Michael Paquier  
  
Report: <20160615204036.2d35d86a@firost>  
  

Fix multiple minor infelicities in aclchk.c error reports.

  
commit   : cd05539ec7f5eba2c1370447f27d2343c96bbeee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 13:53:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 13:53:10 -0400    

Click here for diff

  
pg_type_aclmask reported the wrong type's OID when complaining that  
it could not find a type's typelem.  It also failed to provide a  
suitable errcode when the initially given OID doesn't exist (which  
is a user-facing error, since that OID can be user-specified).  
pg_foreign_data_wrapper_aclmask and pg_foreign_server_aclmask likewise  
lacked errcode specifications.  Trivial cosmetic adjustments too.  
  
The wrong-type-OID problem was reported by Petru-Florin Mihancea in  
bug #14186; the other issues noted by me while reading the code.  
These errors all seem to be aboriginal in the respective routines, so  
back-patch as necessary.  
  
Report: <20160613163159.5798.52928@wrigleys.postgresql.org>  
  

Clarify documentation of ceil/ceiling/floor functions.

  
commit   : a36c8219df2b3b93916bc5256df03e076c3615c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 11:58:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 11:58:00 -0400    

Click here for diff

  
Document these as "nearest integer >= argument" and "nearest integer <=  
argument", which will hopefully be less confusing than the old formulation.  
New wording is from Matlab via Dean Rasheed.  
  
I changed the pg_description entries as well as the SGML docs.  In the  
back branches, this will only affect installations initdb'd in the future,  
but it should be harmless otherwise.  
  
Discussion: <CAEZATCW3yzJo-NMSiQs5jXNFbTsCEftZS-Og8=FvFdiU+kYuSA@mail.gmail.com>  
  

nls-global.mk: search build dir for source files, too

  
commit   : 3dcdf9800be99a9b2409115c8aa542b234aa324f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:55:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:55:18 -0400    

Click here for diff

  
In VPATH builds, the build directory was not being searched for files in  
GETTEXT_FILES, leading to failure to construct the .pot files.  This has  
bit me all along, but never hard enough to get it fixed; I suppose not a  
lot of people uses VPATH and NLS-enabled builds, and those that do,  
don't do "make update-po" often.  
  
This is a longstanding problem, so backpatch all the way back.  
  

Don’t reset changes_since_analyze after a selective-columns ANALYZE.

  
commit   : 3201709de3a552113573f73d308b40bba8f73186    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jun 2016 17:44:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jun 2016 17:44:18 -0400    

Click here for diff

  
If we ANALYZE only selected columns of a table, we should not postpone  
auto-analyze because of that; other columns may well still need stats  
updates.  As committed, the counter is left alone if a column list is  
given, whether or not it includes all analyzable columns of the table.  
Per complaint from Tomasz Ostrowski.  
  
It's been like this a long time, so back-patch to all supported branches.  
  
Report: <ef99c1bd-ff60-5f32-2733-c7b504eb960c@ato.waw.pl>  
  

Avoid hot standby cancels from VAC FREEZE

  
commit   : 294509ea9bb3305230659fd76bd355aec6fcd039    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 May 2016 19:39:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 May 2016 19:39:49 -0400    

Click here for diff

  
VACUUM FREEZE generated false cancelations of standby queries on an  
otherwise idle master. Caused by an off-by-one error on cutoff_xid  
which goes back to original commit.  
  
Analysis and report by Marco Nenciarini  
  
Bug fix by Simon Riggs  
  
This is a correct backpatch of commit 66fbcb0d2e to branches 9.1 through  
9.4.  That commit was backpatched to 9.0 originally, but it was  
immediately reverted in 9.0-9.4 because it didn't compile.  
  

Fetch XIDs atomically during vac_truncate_clog().

  
commit   : 4cf0978ea2733548149ee7f11e588975daaf7609    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:47:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:47:51 -0400    

Click here for diff

  
Because vac_update_datfrozenxid() updates datfrozenxid and datminmxid  
in-place, it's unsafe to assume that successive reads of those values will  
give consistent results.  Fetch each one just once to ensure sane behavior  
in the minimum calculation.  Noted while reviewing Alexander Korotkov's  
patch in the same area.  
  
Discussion: <8564.1464116473@sss.pgh.pa.us>  
  

Avoid consuming an XID during vac_truncate_clog().

  
commit   : 2e7f0c34aa6dd2f4c02f57d9dd5c37eeeb661198    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:20:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:20:12 -0400    

Click here for diff

  
vac_truncate_clog() uses its own transaction ID as the comparison point in  
a sanity check that no database's datfrozenxid has already wrapped around  
"into the future".  That was probably fine when written, but in a lazy  
vacuum we won't have assigned an XID, so calling GetCurrentTransactionId()  
causes an XID to be assigned when otherwise one would not be.  Most of the  
time that's not a big problem ... but if we are hard up against the  
wraparound limit, consuming XIDs during antiwraparound vacuums is a very  
bad thing.  
  
Instead, use ReadNewTransactionId(), which not only avoids this problem  
but is in itself a better comparison point to test whether wraparound  
has already occurred.  
  
Report and patch by Alexander Korotkov.  Back-patch to all versions.  
  
Report: <CAPpHfdspOkmiQsxh-UZw2chM6dRMwXAJGEmmbmqYR=yvM7-s6A@mail.gmail.com>  
  

Fix latent crash in do_text_output_multiline().

  
commit   : fca2eb3d43226cb119b682fda7716c5a4c28a841    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 14:16:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 14:16:41 -0400    

Click here for diff

  
do_text_output_multiline() would fail (typically with a null pointer  
dereference crash) if its input string did not end with a newline.  Such  
cases do not arise in our current sources; but it certainly could happen  
in future, or in extension code's usage of the function, so we should fix  
it.  To fix, replace "eol += len" with "eol = text + len".  
  
While at it, make two cosmetic improvements: mark the input string const,  
and rename the argument from "text" to "txt" to dodge pgindent strangeness  
(since "text" is a typedef name).  
  
Even though this problem is only latent at present, it seems like a good  
idea to back-patch the fix, since it's a very simple/safe patch and it's  
not out of the realm of possibility that we might in future back-patch  
something that expects sane behavior from do_text_output_multiline().  
  
Per report from Hao Lee.  
  
Report: <CAGoxFiFPAGyPAJLcFxTB5cGhTW2yOVBDYeqDugYwV4dEd1L_Ag@mail.gmail.com>  
  

Further improve documentation about –quote-all-identifiers switch.

  
commit   : ae52f3bb5183fdbd7c2e449d38c803e01ba6831b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 15:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 15:51:57 -0400    

Click here for diff

  
Mention it in the Notes section too, per suggestion from David Johnston.  
  
Discussion: <20160520165824.22598.31426@wrigleys.postgresql.org>  
  

Improve documentation about pg_dump’s –quote-all-identifiers switch.

  
commit   : b215c624ebf00225b955c1ebafdf6be1b96d63a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 14:59:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 14:59:48 -0400    

Click here for diff

  
Per bug #14152 from Alejandro Martínez.  Back-patch to all supported  
branches.  
  
Discussion: <20160520165824.22598.31426@wrigleys.postgresql.org>  
  

doc: Fix typo

  
commit   : 8e6d6a72257f7ae2e7b6b53b8857c2e3c0c52af7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:24:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:24:13 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Ensure plan stability in contrib/btree_gist regression test.

  
commit   : b15ab18ed7e30d2e404f385c3b59d7b3768b141b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2016 20:04:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2016 20:04:12 -0400    

Click here for diff

  
Buildfarm member skink failed with symptoms suggesting that an  
auto-analyze had happened and changed the plan displayed for a  
test query.  Although this is evidently of low probability,  
regression tests that sometimes fail are no fun, so add commands  
to force a bitmap scan to be chosen.  
  

Fix autovacuum for shared relations

  
commit   : ca4c6d043ffa6233d4cc47ef2e117e2e52a79e11    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 May 2016 16:23:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 May 2016 16:23:54 -0300    

Click here for diff

  
The table-skipping logic in autovacuum would fail to consider that  
multiple workers could be processing the same shared catalog in  
different databases.  This normally wouldn't be a problem: firstly  
because autovacuum workers not for wraparound would simply ignore tables  
in which they cannot acquire lock, and secondly because most of the time  
these tables are small enough that even if multiple for-wraparound  
workers are stuck in the same catalog, they would be over pretty  
quickly.  But in cases where the catalogs are severely bloated it could  
become a problem.  
  
Backpatch all the way back, because the problem has been there since the  
beginning.  
  
Reported by Ondřej Světlík  
  
Discussion: https://www.postgresql.org/message-id/572B63B1.3030603%40flexibee.eu  
	https://www.postgresql.org/message-id/572A1072.5080308%40flexibee.eu