PostgreSQL 9.1.24 commit log

commit   : e85493559c4678f54d30b6b4e04b17c03a3192d7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 24 Oct 2016 16:19:49 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 24 Oct 2016 16:19:49 -0400    

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Per buildfarm.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

commit   : 0499bd26915f2b4119560142855db3df59d1b8a4    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Sep 2016 20:02:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Sep 2016 20:02:17 -0400    

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

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

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

commit   : 380dad29dcc0475383e61b21e94b823eb2743cbc    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Sep 2016 17:29:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Sep 2016 17:29:32 -0400    

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

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

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

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

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

commit   : 3570ea4248caafcd44d015eaaf7f5924e2b58781    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Aug 2016 14:37:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Aug 2016 14:37:51 -0400    

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

commit   : 9942376a5b61c824daf653e6aca0bf5c8516f7ab    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Aug 2016 15:51:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Aug 2016 15:51:11 -0400    

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

commit   : 7e01c8ef3a298620e7239ea54799675d7ad6f4e1    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 14 Aug 2016 15:06:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 14 Aug 2016 15:06:02 -0400    

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

commit   : 99396e63f2bbb265dc68bd541157a62251ffa8a3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Aug 2016 20:51:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 12 Aug 2016 20:51:59 -0400    

Back-patch 9.4-era commit 384f933046dc9e9a2b416f5f7b3be30b93587c63 into  
the previous branches.  Although that was only advertised as repairing a  
problem with missed header-file dependencies, it turns out to also be  
important for parallel make safety.  The previous coding allowed two  
independent make jobs to get launched concurrently in contrib/spi.  
Normally this would be OK, because they are building independent targets;  
but if --enable-depend is in use, it's unsafe, because one make run might  
try to read a .deps file that the other one is in process of rewriting.  
This is evidently the cause of buildfarm member francolin's recent failure  
in the 9.2 branch.  I believe this patch will result in only one subsidiary  
make run, making it safe(r).  
  
Report: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=francolin&dt=2016-08-12%2017%3A12%3A52  

commit   : 74ffae95347562c31578dea153ba9aa6b0f2fa44    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 11 Aug 2016 10:20:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 11 Aug 2016 10:20:34 -0400    

This table apparently got renamed somewhere between 9.1 and 9.2.  
Per buildfarm.  

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

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

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

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

Per discussion with David Johnston.