PostgreSQL 9.3.15 commit log

Stamp 9.3.15.

  
commit   : 59a0c01e3d88910e92a24e388f346670f4f696ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Oct 2016 16:15:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Oct 2016 16:15:40 -0400    

Click here for diff

  
  

Translation updates

  
commit   : 959853027a6b2bf5e532ce81f8b9d2fa28a72d1a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 24 Oct 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 24 Oct 2016 12:00:00 -0400    

Click here for diff

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

Release notes for 9.6.1, 9.5.5, 9.4.10, 9.3.15, 9.2.19, 9.1.24.

  
commit   : 7b2e2a3ddfbaf5da14a448c5b5c88159da89f840    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Oct 2016 22:13:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Oct 2016 22:13:28 -0400    

Click here for diff

  
  

Avoid testing tuple visibility without buffer lock in RI_FKey_check().

  
commit   : 676c603755090c94f0072d435c54f440fda6b9d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Oct 2016 15:01:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Oct 2016 15:01:24 -0400    

Click here for diff

  
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: <19391.1477244876@sss.pgh.pa.us>  
  

Doc: wording tweak for PERL, PYTHON, TCLSH configuration variables.

  
commit   : 8acf92e9f308e8856b5fd4e44a0adfdb3d0c710a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Oct 2016 11:01:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Oct 2016 11:01:35 -0400    

Click here for diff

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

Fix EXPLAIN so that it doesn’t emit invalid XML in corner cases.

  
commit   : edb5143063ba2f63b37178df1fe2783dc6c9927f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Oct 2016 17:17:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Oct 2016 17:17:50 -0400    

Click here for diff

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

Sync our copy of the timezone library with IANA release tzcode2016h.

  
commit   : 92da7527892ebd5fccba62b4e07f04cbac805163    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Oct 2016 15:40:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Oct 2016 15:40:07 -0400    

Click here for diff

  
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.  
  

Update time zone data files to tzdata release 2016h.

  
commit   : ff68f434f6eaff386cbfec477859279039303bdc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Oct 2016 15:20:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 20 Oct 2016 15:20:11 -0400    

Click here for diff

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

Another portability fix for tzcode2016g update.

  
commit   : 4d6c7599b65b6bbd2357883662ea61beccddf81d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 23:32:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 23:32:08 -0400    

Click here for diff

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

Windows portability fix.

  
commit   : c8321040c97f3e23f0b0d2c7e0dcd98de11cfd48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 19:28:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 19:28:11 -0400    

Click here for diff

  
Per buildfarm.  
  

Sync our copy of the timezone library with IANA release tzcode2016g.

  
commit   : ad6f67179e66ae434f75008588b580580164faa3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 18:55:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 18:55:52 -0400    

Click here for diff

  
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.  
  

Suppress “Factory” zone in pg_timezone_names view for tzdata >= 2016g.

  
commit   : a5fcfa8919ab76526d8f516565dd5c20b5d7b305    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 18:11:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 18:11:49 -0400    

Click here for diff

  
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.  
  

Update time zone data files to tzdata release 2016g.

  
commit   : 7abda82ef42a118138ab8d1c9cfa424cd54918ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 17:56:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Oct 2016 17:56:38 -0400    

Click here for diff

  
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.  
  

Fix WAL-logging of FSM and VM truncation.

  
commit   : 1c02ee314bc17ba0ff226c33a64935d02ff1208a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 19 Oct 2016 14:43:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 19 Oct 2016 14:43:34 +0300    

Click here for diff

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

Fix cidin() to handle values above 2^31 platform-independently.

  
commit   : ff5ef6add448a180909f1c45151b0aa9929982d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Oct 2016 12:24:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Oct 2016 12:24:46 -0400    

Click here for diff

  
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: <20161018152550.1413.6439@wrigleys.postgresql.org>  
  

Fix assorted integer-overflow hazards in varbit.c.

  
commit   : be680535e9c1ffdfcb9d06c1704a3fb4e1b3303e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Oct 2016 16:28:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Oct 2016 16:28:34 -0400    

Click here for diff

  
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: <87d1j2zqtz.fsf@credativ.de>  
  

Fix another bug in merging of inherited CHECK constraints.

  
commit   : f0bf0f233cdb18086f0dcbcac1625e125d8badca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Oct 2016 17:05:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Oct 2016 17:05:15 -0400    

Click here for diff

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

Fix copy-pasto in comment.

  
commit   : 086b99ec0987fcaacf192d018e8de7dd126fb8ac    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Oct 2016 12:07:54 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 12 Oct 2016 12:07:54 +0300    

Click here for diff

  
Amit Langote  
  

Improve documentation for CREATE RECURSIVE VIEW.

  
commit   : cf3e2c3983a8d315ab0ab893ff8b83196e7f8164    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Oct 2016 10:08:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Oct 2016 10:08:45 -0400    

Click here for diff

  
It was perhaps not entirely clear that internal self-references shouldn't  
be schema-qualified even if the view name is written with a schema.  
Spell it out.  
  
Discussion: <871sznz69m.fsf@metapensiero.it>  
  

In PQsendQueryStart(), avoid leaking any left-over async result.

  
commit   : 455eaf9847ab0bb7a8dc6046be976053020c43bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2016 10:35:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Oct 2016 10:35:58 -0400    

Click here for diff

  
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>  
  

Fix two bugs in merging of inherited CHECK constraints.

  
commit   : 56a047f46a95222b0917e4509af6e1dc533c0b02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Oct 2016 19:29:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Oct 2016 19:29:28 -0400    

Click here for diff

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

Remove user_relns() SRF from regression tests.

  
commit   : d491346839ea74d7efbebfe1d56a34617cb8b196    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Oct 2016 18:43:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Oct 2016 18:43:01 -0400    

Click here for diff

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

Clear OpenSSL error queue after failed X509_STORE_load_locations() call.

  
commit   : b5afc6f678616900ecfd69d6ebaa90533b231c65    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Oct 2016 12:53:47 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Oct 2016 12:53:47 +0300    

Click here for diff

  
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.  
  

Don’t share SSL_CTX between libpq connections.

  
commit   : fde92dc226ebc355cd93ef443d116fc168b06968    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Oct 2016 12:20:39 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Oct 2016 12:20:39 +0300    

Click here for diff

  
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: <20160920101051.1355.79453@wrigleys.postgresql.org>  
  

Do ClosePostmasterPorts() earlier in SubPostmasterMain().

  
commit   : 2bf77540326adbebeaa3a06d2a927c887e3a70b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Oct 2016 17:15:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Oct 2016 17:15:10 -0400    

Click here for diff

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

Retry opening new segments in pg_xlogdump –folllow

  
commit   : 4bff35cca56ce665422e69c47a931793eb6e9d04    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 30 Sep 2016 11:19:30 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 30 Sep 2016 11:19:30 +0200    

Click here for diff

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

worker_spi: Call pgstat_report_stat.

  
commit   : 3c97a7ca46c0734446b5f5be8a4c469434b371d7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Sep 2016 12:38:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Sep 2016 12:38:33 -0400    

Click here for diff

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

Include where needed

  
commit   : 1f55a050d585db075a85d5157586c65409c89a70    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2016 01:05:21 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Sep 2016 01:05:21 -0300    

Click here for diff

  
<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.  
  

Document has_type_privilege().

  
commit   : 1308f76ea117b1c029ae743d4e2486c0bdd95731    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2016 11:50:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2016 11:50:36 -0400    

Click here for diff

  
Evidently an oversight in commit 729205571.  Back-patch to 9.2 where  
privileges for types were introduced.  
  
Report: <20160922173517.8214.88959@wrigleys.postgresql.org>  
  

Doc: fix examples of # operators so they actually work.

  
commit   : 444183934955275c21f37625ea72fc6e6a222d21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 14:22:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 14:22:07 -0400    

Click here for diff

  
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: <20160923081530.1517.75670@wrigleys.postgresql.org>  
  

Fix incorrect logic for excluding range constructor functions in pg_dump.

  
commit   : f39bb487da8da057386180601d4d93d67cd15421    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 13:49:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 13:49:27 -0400    

Click here for diff

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

Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes.

  
commit   : 73df86a37ba54e35ba8d9e09bc9fe5699b196829    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2016 11:34:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2016 11:34:44 -0400    

Click here for diff

  
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: <32468.1474548308@sss.pgh.pa.us>  
  

doc: Fix documentation to match actual make output

  
commit   : 46bee23dee6c76a8810ed354f00f017f8603ccd6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

Click here for diff

  
based on patch from Takeshi Ideriha <iderihatakeshi@gmail.com>  
  

doc: Correct ALTER USER MAPPING example

  
commit   : 40e96756ab760caf42aed10590865249d969d094    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

Click here for diff

  
The existing example threw an error.  
  
From: gabrielle <gorthx@gmail.com>  
  

Fix ecpg -? option on Windows, add -V alias for –version.

  
commit   : b31f335bfe65321f1d23d312d3fd69c00334f5da    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 18 Sep 2016 13:46:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 18 Sep 2016 13:46:32 +0300    

Click here for diff

  
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>  
  

Improve unreachability recognition in elog() macro.

  
commit   : 0db3c5552a16c0e73e0c24a36a3bacc77820bf02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2016 17:54:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2016 17:54:23 -0400    

Click here for diff

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

Fix locking a tuple updated by an aborted (sub)transaction

  
commit   : dfe7121dfbeec0eb13b09b04eaf9c6ca1d1f21be    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2016 15:54:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2016 15:54:29 -0300    

Click here for diff

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

Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

  
commit   : e1dddf3e89eca53a397f3ceb8deafe6bb87682d7    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 11:45:16 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 11:45:16 +0100    

Click here for diff

  
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  
  

Fix mdtruncate() to close fd.c handle of deleted segments.

  
commit   : d2a5b2b28f24e2e98a799fa8877f790ba8e68ab2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Sep 2016 16:51:09 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Sep 2016 16:51:09 -0700    

Click here for diff

  
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: <20160908220748.oqh37ukwqqncbl3n@alap3.anarazel.de>  
Backpatch: all supported releases  
  

Add regression test coverage for non-default timezone abbreviation sets.

  
commit   : cfa193d981a38f1e41c53df0378a1aa2cd86a9b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 20:02:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 20:02:16 -0400    

Click here for diff

  
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.  
  

Remove vestigial references to “zic” in favor of “IANA database”.

  
commit   : 891ed9317d329aed4fe247f8b2a40cc6dbeab1c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 19:42:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 19:42:08 -0400    

Click here for diff

  
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.  
  

Don’t require dynamic timezone abbreviations to match underlying time zone.

  
commit   : ee78d488535e5dea4b3b4814094087443569a52f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Sep 2016 17:29:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Sep 2016 17:29:32 -0400    

Click here for diff

  
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: <20160902031551.15674.67337@wrigleys.postgresql.org>  
Discussion: <6189.1472820913@sss.pgh.pa.us>  
  

Suppress GCC 6 warning about self-comparison

  
commit   : 949878126e3aade9333d3af1fa766a87e5b40d24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Sep 2016 12:48:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Sep 2016 12:48:06 -0400    

Click here for diff

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

Prevent starting a standalone backend with standby_mode on.

  
commit   : baf111d31b01a658894bfbdf1bebae7c38515f5d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2016 08:52:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2016 08:52:13 -0400    

Click here for diff

  
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: <00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan>  
  

Fix pg_xlogdump so that it handles cross-page XLP_FIRST_IS_CONTRECORD record.

  
commit   : 5833306dd691f3827ad0856246864626ab1deeb8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 29 Aug 2016 14:34:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 29 Aug 2016 14:34:58 +0900    

Click here for diff

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

Fix instability in parallel regression tests.

  
commit   : 68bd9f795d49603941527d1bf357f5e74d164ece    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Aug 2016 09:57:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Aug 2016 09:57:09 -0400    

Click here for diff

  
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: <5983.1471371667@sss.pgh.pa.us>  
  

Fix improper repetition of previous results from a hashed aggregate.

  
commit   : aaad96e4026e7bb3033ac0127510f2c60116a1b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2016 14:37:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2016 14:37:51 -0400    

Click here for diff

  
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>  
  

Update Windows timezone mapping from Windows 7 and 10

  
commit   : e8aed974b0e2311c586b9e300a459e473e9a3271    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Aug 2016 12:32:42 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Aug 2016 12:32:42 +0200    

Click here for diff

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

Fix -e option in contrib/intarray/bench/bench.pl.

  
commit   : 7baa8bfca557be7b2af148b5f9eaa34a23f817f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2016 15:51:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2016 15:51:10 -0400    

Click here for diff

  
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: <B97BDCB7-A3B3-4734-90B5-EDD586941629@yesql.se>  
  

Fix assorted places in psql to print version numbers >= 10 in new style.

  
commit   : 41bea9904503f36b51ff94ee68edfa6b0f5cd3f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 15:58:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 15:58:31 -0400    

Click here for diff

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

Remove bogus dependencies on NUMERIC_MAX_PRECISION.

  
commit   : e8e20aadd97a752de4131596987a129c5992d917    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Aug 2016 15:06:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Aug 2016 15:06:02 -0400    

Click here for diff

  
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: <2895.1471195721@sss.pgh.pa.us>  
  

Fix regression test parallel-make hazard.

  
commit   : d90463bde1f640f00b77a4a82923ce92fd737901    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 20:51:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 20:51:59 -0400    

Click here for diff

  
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  
  

Fix inappropriate printing of never-measured times in EXPLAIN.

  
commit   : 16cc6d23b8d012edb92b3b4b5fccf5200127887c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 12:13:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 12:13:04 -0400    

Click here for diff

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

Fix busted Assert for CREATE MATVIEW … WITH NO DATA.

  
commit   : 942ff002f9ee170d276240c71400e2772458b114    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Aug 2016 11:22:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Aug 2016 11:22:25 -0400    

Click here for diff

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

Doc: write some for adminpack.

  
commit   : c4c91df0c53ad0c26f234c55c0b7aa5fbd3f71a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Aug 2016 21:39:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Aug 2016 21:39:50 -0400    

Click here for diff

  
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().  
  

Fix typo

  
commit   : d292af0ac0d447bfd6621bb25678064bb1f4beff    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 Aug 2016 19:07:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 Aug 2016 19:07:24 -0400    

Click here for diff

  
  

Doc: clarify description of CREATE/ALTER FUNCTION … SET FROM CURRENT.

  
commit   : e4b4a469441d7028ae73279481b28375b74ee3dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2016 13:39:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2016 13:39:24 -0400    

Click here for diff

  
Per discussion with David Johnston.