PostgreSQL 9.1.23 commit log

commit   : cb5b88af7dc7529dcdfd8c0ff71c5372877b7f19    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Aug 2016 16:35:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Aug 2016 16:35:15 -0400    

commit   : 6bb96c0a0699444ead4746e483fd56de3be5539c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Aug 2016 11:56:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Aug 2016 11:56:11 -0400    

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

commit   : d555d26429568e1a95f75c1a751933ebb63b82c6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 8 Aug 2016 11:12:59 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 8 Aug 2016 11:12:59 -0400    

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.  

commit   : 5b1da944c3026bb253f0700a758b5db3db06a223    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 8 Aug 2016 10:44:09 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 8 Aug 2016 10:44:09 -0400    

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

commit   : 5327b764a5ed98d290053a8cbc277b08fd55268a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 8 Aug 2016 10:33:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 8 Aug 2016 10:33:47 -0400    

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: <[email protected]>  
Security: CVE-2016-5423  

commit   : a2385cac135bb8498a12b1af2cde18244c7be2b1    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : d2dd5df5142b1faf2c96ddf5f0c0b358b14f1ac9    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : c761c9fee082623777466e6a5841056960fc006c    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:53 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:53 -0400    

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  

commit   : 2d69f5b12e5a99eea7bc175fa30e612384bf9e52    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : 61c2cd88deca0d7e4c0bfb0c17b4959f59e08167    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : ba8c4089d693305c817181ce099a32d6117abe24    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : cf7e5f55bfd56fc811018c5c56fd5fba6e9b87be    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : aed766ab55c7d0f25653427789f78a6e12c2ae7b    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

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  

commit   : e8ccfaf86f410e86730ea02a0d66040fb458ab46    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Aug 2016 21:31:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Aug 2016 21:31:02 -0400    

commit   : a449ad095d380ff32a9c38506c294f7afc687f1f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Aug 2016 18:52:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Aug 2016 18:52:02 -0400    

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: <[email protected]>  

commit   : 1f63b0e0923cf46046de00b923417f8b9a51ccb8    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 5 Aug 2016 18:58:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 5 Aug 2016 18:58:12 -0400    

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: <[email protected]>  

commit   : a44388ffe205114fc02c61cb1015a866d6e3daca    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 5 Aug 2016 12:58:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 5 Aug 2016 12:58:17 -0400    

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.  

commit   : 04e7940e7c9936cb5a2a87b89c8d55c67a27e51b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 3 Aug 2016 13:45:55 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 3 Aug 2016 13:45:55 -0400    

These were probably copied in by accident.  
  
From: Clément Prévost <[email protected]>  

commit   : 8b2f60b6eed6f4c24bd61c4189f83ca352bebf78    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 2 Aug 2016 17:13:10 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 2 Aug 2016 17:13:10 -0400    

Discussion: [email protected]  
  
Reviewed-by: Christoph Berg  
  
Backpatch-through: 9.1  

commit   : c15f502b642386ea9aaf7f9cb0c5c07ef1c9f27b    
  
author   : Michael Meskes <[email protected]>    
date     : Mon, 1 Aug 2016 06:36:27 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Mon, 1 Aug 2016 06:36:27 +0200    

commit   : 366f4a96248dc85a37b17c78ce41d2a531377ba0    
  
author   : Fujii Masao <[email protected]>    
date     : Mon, 1 Aug 2016 17:36:14 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Mon, 1 Aug 2016 17:36:14 +0900    

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  

commit   : 7004e1ccd445378481c78a143a71aac77947d83e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 31 Jul 2016 18:32:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 31 Jul 2016 18:32:34 -0400    

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>  

commit   : 0e8436914bd9110c216d9320a56b07f863ea6ddb    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 30 Jul 2016 14:52:17 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 30 Jul 2016 14:52:17 -0400    

Head patch was 42ec6c2da699e8e0b1774988fa97297a2cdf716c.  
  
Reported-by: Alexander Law  
  
Discussion: [email protected]  
  
Backpatch-through: 9.1  

commit   : 3a6b566434c6d177cc2e3bb067117dd3add2dff7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 18:57:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 18:57:24 -0400    

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.  

commit   : c0e5096fc8ef069c33c2c3d3ff7bf577bc78c643    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 16:09:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 16:09:15 -0400    

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: <[email protected]>  

commit   : f0795b394991874289658fb51d83dce9a11f026e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 13:26:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 13:26:59 -0400    

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: <[email protected]>  

commit   : ce100861687353998d3f1c2b28c61447e8102c58    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 11:39:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Jul 2016 11:39:11 -0400    

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: <[email protected]>  

commit   : d243bf77c2d3888fb263c55317c2453cb437d1de    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 26 Jul 2016 15:25:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 26 Jul 2016 15:25:02 -0400    

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: <[email protected]>  

commit   : b1fa6c0eb9fadc9eada014227a67eadfec936960    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 23 Jul 2016 20:30:03 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 23 Jul 2016 20:30:03 -0400    

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

commit   : ba64aed7004a88f66ef204cd8b18c2c5621b2f30    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Jul 2016 16:52:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Jul 2016 16:52:36 -0400    

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.  

commit   : f61ecd01e349cc45e9299ba48bba3fb4673fc319    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Jul 2016 14:24:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Jul 2016 14:24:07 -0400    

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.  

commit   : d70df7867f66885bdd09ebf03711d77481efd094    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 19 Jul 2016 17:53:31 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 19 Jul 2016 17:53:31 -0400    

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

commit   : 5db14fad050da78e0333ad6c303ba2fd25b1d772    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 19 Jul 2016 15:59:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 19 Jul 2016 15:59:36 -0400    

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: <[email protected]>  

commit   : 84d67920450717d458cfaad7876fa8279fd7ced0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 17 Jul 2016 09:37:33 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 17 Jul 2016 09:37:33 -0400    

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.  

commit   : 608cc0c413d8bafc853065f80c3b05f84493032a    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 16 Jul 2016 14:42:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 16 Jul 2016 14:42:37 -0400    

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: <[email protected]>  

commit   : 37276017fba88b7c7557395e2fcdaa4a61ba49ac    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 15 Jul 2016 17:49:49 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 15 Jul 2016 17:49:49 -0700    

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  

commit   : 7d54d521a42fa981aa406e86bc2955f2cda5b0a8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 14 Jul 2016 22:27:48 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 14 Jul 2016 22:27:48 -0400    

From: Alexander Law <[email protected]>  

commit   : c816cc9ea369e7518d276a36875a42608b9e66f6    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Jul 2016 12:13:45 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Jul 2016 12:13:45 -0400    

commit   : 71af6c006ee5496bedc3002fa14fc20935bbfdd1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Jul 2016 11:24:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Jul 2016 11:24:04 -0400    

Back-patch relevant parts of commit 30b2731bd into 9.1-9.3.  
  
Michael Paquier, Kyotaro Horiguchi  
  
Discussion: <[email protected]>  

commit   : 76ecc20d3c80776ad459993a00194350b96e8789    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 2 Jul 2016 11:22:35 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 2 Jul 2016 11:22:35 -0400    

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: [email protected]  
  
Backpatch-through: 9.1  

commit   : 3f290d6270bd6233af07c1143f84efd79c363f93    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 21 Jun 2016 20:07:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 21 Jun 2016 20:07:58 -0400    

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: <[email protected]>  

commit   : 354b3a3ac814076dbe8b51bf94b203abbcb5b32f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 19 Jun 2016 14:01:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 19 Jun 2016 14:01:17 -0400    

In the 9.1 branch only, modify test_postmaster_connection() so that it  
will wait up to 10 seconds, not 5, for the postmaster pid file to appear.  
This is a much simpler and safer, if less complete, way of addressing  
the buildfarm instability issues we hoped to solve with c869a7d5b.  
  
Discussion: <[email protected]>  

commit   : d56c02f1ac9247295ec1e5143361020a91f708c8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 19 Jun 2016 13:45:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 19 Jun 2016 13:45:03 -0400    

This reverts commit c869a7d5b44e7164fadfb638786def05d510312a.  
As pointed out by Maksym Sobolyev in bug #14199, that approach doesn't  
work if the postmaster forks itself an extra time due to silent_mode  
being enabled.  We removed silent_mode in 9.2, so the pg_ctl change is  
fine in 9.2 and later, but it fails when that option is enabled in 9.1.  
Seeing that 9.1 is close to end-of-life, let's adopt the most conservative  
fix we can, which is to revert the pg_ctl change in the 9.1 branch.  
  
Discussion: <[email protected]>  

commit   : b9b925f83fbbed9ae7dd60d94dcd19eb6f6d2bcd    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 19 Jun 2016 13:11:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 19 Jun 2016 13:11:40 -0400    

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: <[email protected]>  

commit   : 7b97dafa2a885b968924604e58e030aebfd96b9f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 16 Jun 2016 17:16:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 16 Jun 2016 17:16:32 -0400    

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: <[email protected]>  

commit   : bdf39b2c577a107063dfbbe398ff77c5b65ba731    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 Jun 2016 13:53:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 13 Jun 2016 13:53:10 -0400    

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: <[email protected]>  

commit   : cbd72c72b0ac5f829538b8d96d35288626db1ff8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 Jun 2016 11:58:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 Jun 2016 11:58:01 -0400    

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>  

commit   : f4cb9ef57d4877fa585fd0d8a3a4d036ec5d8848    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 7 Jun 2016 18:55:18 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 7 Jun 2016 18:55:18 -0400    

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.  

commit   : 32ceb8dfbf3c2ae785a595db9821d16e92f8431b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Jun 2016 17:44:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Jun 2016 17:44:18 -0400    

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: <[email protected]>  

commit   : de887cc8afd2f7a7761108bfe001c3d451811b7a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 25 May 2016 19:39:49 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 25 May 2016 19:39:49 -0400    

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.  

commit   : 5551dac59c0601b49d57a3f897fb0a6d581e58ac    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 May 2016 15:47:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 May 2016 15:47:51 -0400    

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: <[email protected]>  

commit   : fe1731fca27008836f2208f4be8c22acf8ec1f67    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 24 May 2016 15:20:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 24 May 2016 15:20:12 -0400    

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>  

commit   : 7b40b2d90f44c1f4ef1bc130bd94decb15826676    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 May 2016 14:16:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 May 2016 14:16:41 -0400    

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>  

commit   : 57a72661b4e56aab0df1f04d2bd9eaf7da111652    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 May 2016 15:51:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 May 2016 15:51:57 -0400    

Mention it in the Notes section too, per suggestion from David Johnston.  
  
Discussion: <[email protected]>  

commit   : 608e466141a3e55365c76b5e7667f272d3b9deb1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 May 2016 14:59:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 May 2016 14:59:48 -0400    

Per bug #14152 from Alejandro Martínez.  Back-patch to all supported  
branches.  
  
Discussion: <[email protected]>  

commit   : 79e4deaf8305e0a7622c4555ddbba8637ca1784b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 13 May 2016 21:24:13 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 13 May 2016 21:24:13 -0400    

From: Alexander Law <[email protected]>  

commit   : a0da51d89946053340319512776a07b86ccc8824    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 May 2016 20:04:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 May 2016 20:04:12 -0400    

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.  

commit   : 2152762c532a33e0028248cce5bf97a06d2448e9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 10 May 2016 16:23:54 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 10 May 2016 16:23:54 -0300    

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