PostgreSQL 9.2.20 commit log

commit   : 903bfef382f286a75e82b8b9edd93b2bdc6cfd96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Feb 2017 10:24:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Feb 2017 10:24:25 -0500    

The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,  
not inserts, since the problem would arise from an update incorrectly  
being made HOT.  Noted by Alvaro.  

commit   : 0021ce274319215fdc481ae29f059068f7a5bf0a    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 7 Feb 2017 10:17:02 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 7 Feb 2017 10:17:02 -0500    

Now that we're checking that the number_of_jobs passed in isn't zero or  
negative, we need to actually initialize number_of_jobs to '1' when it  
isn't set.  
  
Pointed out by Rushabh Lathia, though not his patch.  
  
Discussion: https://postgr.es/m/CAGPqQf2u1T3J=ANhCw1CuvzqjD80oWvMg2-2wmfG08gCm9hhHA@mail.gmail.com  

commit   : 06a0f6de31b35b0b11255ca84737d57fe74f3863    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2017 16:52:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2017 16:52:27 -0500    

commit   : a254f0d461db82dd930a11ea377b74e29ccd0d98    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2017 15:30:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2017 15:30:17 -0500    

commit   : bcd7b47c2834e5a7e78ce45f2b0281eb679588d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2017 13:19:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Feb 2017 13:19:51 -0500    

The problem with the original coding here is that we might receive (and  
clear) a relcache invalidation signal for the target relation down inside  
one of the index_open calls we're doing.  Since the target is open, we  
would not drop the relcache entry, just reset its rd_indexvalid and  
rd_indexlist fields.  But RelationGetIndexAttrBitmap() kept going, and  
would eventually cache and return potentially-obsolete attribute bitmaps.  
  
The case where this matters is where the inval signal was from a CREATE  
INDEX CONCURRENTLY telling us about a new index on a formerly-unindexed  
column.  (In all other cases, the lock we hold on the target rel should  
prevent any concurrent change in index state.)  Even just returning the  
stale attribute bitmap is not such a problem, because it shouldn't matter  
during the transaction in which we receive the signal.  What hurts is  
caching the stale data, because it can survive into later transactions,  
breaking CREATE INDEX CONCURRENTLY's expectation that later transactions  
will not create new broken HOT chains.  The upshot is that there's a window  
for building corrupted indexes during CREATE INDEX CONCURRENTLY.  
  
This patch fixes the problem by rechecking that the set of index OIDs  
is still the same at the end of RelationGetIndexAttrBitmap() as it was  
at the start.  If not, we loop back and try again.  That's a little  
more than is strictly necessary to fix the bug --- in principle, we  
could return the stale data but not cache it --- but it seems like a  
bad idea on general principles for relcache to return data it knows  
is stale.  
  
There might be more hazards of the same ilk, or there might be a better  
way to fix this one, but this patch definitely improves matters and seems  
unlikely to make anything worse.  So let's push it into today's releases  
even as we continue to study the problem.  
  
Pavan Deolasee and myself  
  
Discussion: https://postgr.es/m/CABOikdM2MUq9cyZJi1KyLmmkCereyGp5JQ4fuwKoyKEde_mzkQ@mail.gmail.com  

commit   : e39a63ab02abd4482ffd0b6f22ba5e488fb25b14    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Feb 2017 12:26:42 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Feb 2017 12:26:42 -0500    

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

commit   : 863e70aa7f4dbfab6d94f6c708986610d62ddce3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Feb 2017 09:47:39 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 6 Feb 2017 09:47:39 -0500    

Also improve the message style a bit while we're here.  

commit   : 16b74c472157527b297d19838dd33e3474287207    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Feb 2017 12:04:04 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Feb 2017 12:04:04 +0200    

Commit 181bdb90ba fixed the typo in the .sql file, but forgot to update the  
expected output.  

commit   : 2a931efb76facac47b499afb64b05ab33ededc10    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Feb 2017 11:33:58 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Feb 2017 11:33:58 +0200    

Backpatch to all supported versions, where applicable, to make backpatching  
of future fixes go more smoothly.  
  
Josh Soref  
  
Discussion: https://www.postgresql.org/message-id/CACZqfqCf+5qRztLPgmmosr-B0Ye4srWzzw_mo4c_8_B_mtjmJQ@mail.gmail.com  

commit   : c5c755862348ec52007ae18e489be07395cbb023    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Feb 2017 14:12:35 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Feb 2017 14:12:35 +0200    

These were left out by mistake back when support for KOI8-U encoding was  
added.  
  
Extracted from Kyotaro Horiguchi's larger patch.  

commit   : ef878cc2cda4e8b314e7eda02a8fd688d0afce66    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2017 11:40:22 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Jan 2017 11:40:22 -0500    

DST law changes in northern Cyprus (new zone Asia/Famagusta), Russia (new  
zone Europe/Saratov), Tonga, Antarctica/Casey.  Historical corrections for  
Asia/Aqtau, Asia/Atyrau, Asia/Gaza, Asia/Hebron, Italy, Malta.  Replace  
invented zone abbreviation "TOT" for Tonga with numeric UTC offset; but  
as in the past, we'll keep accepting "TOT" for input.  

commit   : 3f6e085fe3a69d325d6af0142df7c99ffc725bd2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jan 2017 08:33:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jan 2017 08:33:58 -0500    

Clean up hastily-composed comment.  Normalize whitespace.  
  
Erik Rijkers and myself  

commit   : 15c54e8363a28ab89e31bafebe6b093a77540b1d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 27 Jan 2017 12:19:50 +0000    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 27 Jan 2017 12:19:50 +0000    

commit   : 14d0e290cbe72aac7911c159f40406dd7242353e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 26 Jan 2017 16:47:04 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 26 Jan 2017 16:47:04 -0800    

The new function allows to cast from one NodeTag based type to  
another, while asserting that the conversion is valid.  This replaces  
the common pattern of doing a cast and a Assert(IsA(ptr, type))  
close-by.  
  
As this seems likely to be used pervasively, we decided to backpatch  
this change the addition of this macro. Otherwise backpatched fixes  
are more likely not to work on back-branches.  
  
On branches before 9.6, where we do not yet rely on inline functions  
being available, the type assertion is only performed if PG_USE_INLINE  
support is detected. The cast obviously is performed regardless.  
  
For the benefit of verifying the macro compiles in the back-branches,  
this commit contains a single use of the new macro. On master, a  
somewhat larger conversion will be committed separately.  
  
Author: Peter Eisentraut and Andres Freund  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/c5d387d9-3440-f5e0-f9d4-71d53b9fbe52@2ndquadrant.com  
Backpatch: 9.2-  

commit   : fe6120f9b359d3ac20f235fbf9938bcd850b1598    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2017 12:17:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jan 2017 12:17:47 -0500    

!foo means "the tsvector does not contain foo", and therefore it should  
match an empty tsvector.  ts_match_vq() overenthusiastically supposed  
that an empty tsvector could never match any query, so it forcibly  
returned FALSE, the wrong answer.  Remove the premature optimization.  
  
Our behavior on this point was inconsistent, because while seqscans and  
GIST index searches both failed to match empty tsvectors, GIN index  
searches would find them, since GIN scans don't rely on ts_match_vq().  
That makes this certainly a bug, not a debatable definition disagreement,  
so back-patch to all supported branches.  
  
Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me.  
  
Discussion: https://postgr.es/m/20170126025524.1434.97828@wrigleys.postgresql.org  

commit   : 38bec18056b86f793afa642b2f991ea6ec1b8491    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jan 2017 07:02:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 25 Jan 2017 07:02:25 +0900    

Previously ValidXLOGHeader() could not handle properly the case where  
we re-read the WAL segment after reading its subsequent segment having  
larger TLI. This case can happen, for example, when the WAL record is split  
across two segments having different TLI. In this case, since the segment  
we're re-reading has the smaller TLI than its subsequent segment we've  
already read, ValidXLOGHeader() reported an error "out-of-sequence TLI"  
even though TLI sequence was valid (i.e., TLI doesn't go backwards across  
successive WAL pages and segments).  
  
This issue was fixed by commit 7fcbf6a405ffc12a4546a25b98592ee6733783fc  
in 9.3 or later though there is no mention to the bug fix in its commit log.  
It changed the WAL check code so that it verifies TLI for pages that are  
later than the last remembered LSN. This patch applies the same change to  
9.2 where the issue still existed.  
  
Author: Takayuki Tsunakawa and Amit Kapila  
Reviewed-By: Robert Haas  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F5E15E5@G01JPEXMBYT05  

commit   : dbaa621cb77b2eccf2fb4ae0e651276bb3336612    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 24 Jan 2017 10:42:27 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 24 Jan 2017 10:42:27 +0900    

This reverts commit 0b7bcf7ad2f1061664e6b517a3b4feabee0af00a, which  
tried to fix the comments to reflect the change of API of the function  
but actually the change had been made only for 9.5 or later.  

commit   : 0b7bcf7ad2f1061664e6b517a3b4feabee0af00a    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 24 Jan 2017 09:39:11 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 24 Jan 2017 09:39:11 +0900    

The interface for the function was changed in  
d72731a70450b5e7084991b9caa15cb58a2820df but the comments of the  
function was not updated.  
  
Patch by Yugo Nagata.  

commit   : f21f81c08e1667846df294ad03d04aca09544297    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 17 Jan 2017 12:00:00 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 17 Jan 2017 12:00:00 -0500    

commit   : 5dff230eb1c3c72dd9f0e8fbf2040d65b96e1fba    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2017 15:55:45 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 20 Jan 2017 15:55:45 -0500    

When (1) autovacuum = off and (2) there's at least one database with  
an XID age greater than autovacuum_freeze_max_age and (3) all tables  
in that database that need vacuuming are already being processed by a  
worker and (4) the autovacuum launcher is started, a kind of infinite  
loop occurs.  The launcher starts a worker and immediately exits.  The  
worker, finding no worker to do, immediately starts the launcher,  
supposedly so that the next database can be processed.  But because  
datfrozenxid for that database hasn't been advanced yet, the new  
worker gets put right back into the same database as the old one,  
where it once again starts the launcher and exits.  High-speed ping  
pong ensues.  
  
There are several possible ways to break the cycle; this seems like  
the safest one.  
  
Amit Khandekar (code) and Robert Haas (comments), reviewed by  
Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CAJ3gD9eWejf72HKquKSzax0r+epS=nAbQKNnykkMA0E8c+rMDg@mail.gmail.com  

commit   : 154875a77b924c48d95a18f6496058753715bb8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2017 16:33:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jan 2017 16:33:18 -0500    

Thinko in commit a4523c5aa.  It doesn't really affect anything at  
present, but it would be a problem if any tests added later in this  
file ought to get index-only-scan plans.  Back-patch, like the previous  
commit, just to avoid surprises in case we add such a test and then  
back-patch it.  
  
Nikita Glukhov  
  
Discussion: https://postgr.es/m/8b70135d-ad38-bdd8-ac92-71e2b3c273cf@postgrespro.ru  

commit   : 5462e3486dfeb5876d1c5a408eecab12b9fc4545    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Jan 2017 18:06:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Jan 2017 18:06:13 -0300    

These macros work fine when they are used directly in an "if" test or  
similar, but as soon as the return values are assigned to boolean  
variables (or passed as boolean arguments to some function), they become  
bugs, hopefully caught by compiler warnings.  To avoid future problems,  
fix the definitions so that they return actual booleans.  
  
To further minimize the risk that somebody uses them in back-patched  
fixes that only work correctly in branches starting from the current  
master and not in old ones, back-patch the change to supported branches  
as appropriate.  
  
See also commit af4472bcb88ab36b9abbe7fd5858e570a65a2d1a, and the long  
discussion (and larger patch) in the thread mentioned in its commit  
message.  
  
Discussion: https://postgr.es/m/18672.1483022414@sss.pgh.pa.us  

commit   : c73157ca0e058806a956b8126f158dcb513b1881    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Jan 2017 17:32:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 17 Jan 2017 17:32:45 +0900    

Previously multiple sessions could execute pg_start_backup() and  
pg_stop_backup() to start and stop an exclusive backup at the same time.  
This could trigger the assertion failure of  
"FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)".  
This happend because, even while pg_start_backup() was starting  
an exclusive backup, other session could run pg_stop_backup()  
concurrently and mark the backup as not-in-progress unconditionally.  
  
This patch introduces ExclusiveBackupState indicating the state of  
an exclusive backup. This state is used to ensure that there is only  
one session running pg_start_backup() or pg_stop_backup() at  
the same time, to avoid the assertion failure.  
  
Back-patch to all supported versions.  
  
Author: Michael Paquier  
Reviewed-By: Kyotaro Horiguchi and me  
Reported-By: Andreas Seltenreich  
Discussion: <87mvktojme.fsf@credativ.de>  

commit   : 5e1e2e75d25b7fd7152fa2b41998efd2dac9c275    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Jan 2017 13:27:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Jan 2017 13:27:47 -0500    

A client copy can't work inside a function because the FE/BE wire protocol  
doesn't support nesting of a COPY operation within query results.  (Maybe  
it could, but the protocol spec doesn't suggest that clients should support  
this, and libpq for one certainly doesn't.)  
  
In most PLs, this prohibition is enforced by spi.c, but SQL functions don't  
use SPI.  A comparison of _SPI_execute_plan() and init_execution_state()  
shows that rejecting client COPY is the only discrepancy in what they  
allow, so there's no other similar bugs.  
  
This is an astonishingly ancient oversight, so back-patch to all supported  
branches.  
  
Report: https://postgr.es/m/BY2PR05MB2309EABA3DEFA0143F50F0D593780@BY2PR05MB2309.namprd05.prod.outlook.com  

commit   : c59a1a89035674c6efacc596d652528cebba37ec    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 11 Jan 2017 15:46:16 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 11 Jan 2017 15:46:16 -0500    

pg_restore will currently accept invalid values for the number of  
parallel jobs to run (eg: -1), unlike pg_dump which does check that the  
value provided is reasonable.  
  
Worse, '-1' is actually a valid, independent, parameter (as an alias for  
--single-transaction), leading to potentially completely unexpected  
results from a command line such as:  
  
  -> pg_restore -j -1  
  
Where a user would get neither parallel jobs nor a single-transaction.  
  
Add in validity checking of the parallel jobs option, as we already have  
in pg_dump, before we try to open up the archive.  Also move the check  
that we haven't been asked to run more parallel jobs than possible on  
Windows to the same place, so we do all the option validity checking  
before opening the archive.  
  
Back-patch all the way, though for 9.2 we're adding the Windows-specific  
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched  
originally.  
  
Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net  

commit   : e0d59c6ef57bad6f9a4f1de0c5635be2eb7fea5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jan 2017 11:33:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jan 2017 11:33:51 -0500    

array_fill(..., array[0]) produced an empty array, which is probably  
what users expect, but it was a one-dimensional zero-length array  
which is not our standard representation of empty arrays.  Also, for  
no very good reason, it rejected empty input arrays; that case should  
be allowed and produce an empty output array.  
  
In passing, remove the restriction that the input array(s) have lower  
bound 1.  That seems rather pointless, and it would have needed extra  
complexity to make the check deal with empty input arrays.  
  
Per bug #14487 from Andrew Gierth.  It's been broken all along, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20170105152156.10135.64195@wrigleys.postgresql.org  

commit   : 6c4cf2be81e4b783402aecf49df2f1120e42b99b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jan 2017 18:00:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jan 2017 18:00:12 -0500    

Inheritance operations must treat the OID column, if any, much like  
regular user columns.  But MergeAttributesIntoExisting() neglected to  
do that, leading to weird results after a table with OIDs is associated  
to a parent with OIDs via ALTER TABLE ... INHERIT.  
  
Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some  
adjustments by me.  It's been broken all along, so back-patch to  
all supported branches.  
  
Discussion: https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28298@lab.ntt.co.jp  

commit   : 83a25a5209d93615e6d5f3eee4ef649853478498    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Jan 2017 13:11:48 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 3 Jan 2017 13:11:48 -0500    

Backpatch-through: certain files through 9.2  

commit   : 7e3ae545594874d853e358fffe029c6266509727    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Jan 2017 14:09:01 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Jan 2017 14:09:01 +0200    

That was written when we still had "crypt" authentication, and it was  
referring to the fact that an older client might support "crypt"  
authentication but not "md5". But we haven't supported "crypt" for years.  
(As soon as we add a new authentication mechanism that doesn't work with  
MD5 hashes, we'll need a similar notice again. But this text as it's worded  
now is just wrong.)  
  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/9a7263eb-0980-2072-4424-440bb2513dc7@iki.fi  

commit   : fce04516ec5e34dcad18d1dc60e1373a292c218e    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 2 Jan 2017 14:12:38 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 2 Jan 2017 14:12:38 -0800    

In GetCachedPlan(), initialize 'plan' to silence a compiler warning, but  
also add an Assert() to make sure we don't ever actually fall through  
with 'plan' still being set to NULL, since we are about to dereference  
it.  
  
Back-patch back to 9.2.  
  
Author: Stephen Frost  
Discussion: https://postgr.es/m/20161129152102.GR13284%40tamriel.snowman.net  

commit   : b12b1743b48a7b7753098be342754477e6129921    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 2 Jan 2017 13:51:10 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 2 Jan 2017 13:51:10 -0800    

Bison >=3.0 issues warnings about  
  
    %name-prefix="base_yy"  
  
instead of the now preferred  
  
    %name-prefix "base_yy"  
  
but the latter doesn't work with Bison 2.3 or less.  So for now we  
silence the deprecation warnings.  
  
Back-patch to 9.2 and 9.3 -- the newer branches already have this fix.  
  
Author: Peter Eisentraut  
Discussion: https://postgr.es/m/677.1483384145%40sss.pgh.pa.us  

commit   : ce15751eed7ebdc44d6c1ce642606f5adfef0dc3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Dec 2016 18:05:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Dec 2016 18:05:34 -0500    

Must use HH24 not HH to read a hour value exceeding 12.  
  
This was already fixed in HEAD in commit d3cd36a13, but I didn't think  
of backpatching it.  
  
Report: https://postgr.es/m/20161229170043.10139.21416@wrigleys.postgresql.org  

commit   : beae7d5f0eae0b5ed63151a79b3d5ee853e0925c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Dec 2016 15:43:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Dec 2016 15:43:55 -0500    

interval_transform() contained two separate bugs that caused it to  
sometimes mistakenly decide that a cast from interval to restricted  
interval is a no-op and throw it away.  
  
First, it was wrong to rely on dt.h's field type macros to have an  
ordering consistent with the field's significance; in one case they do  
not.  This led to mistakenly treating YEAR as less significant than MONTH,  
so that a cast from INTERVAL MONTH to INTERVAL YEAR was incorrectly  
discarded.  
  
Second, fls(1<<k) produces k+1 not k, so comparing its output directly  
to SECOND was wrong.  This led to supposing that a cast to INTERVAL  
MINUTE was really a cast to INTERVAL SECOND and so could be discarded.  
  
To fix, get rid of the use of fls(), and make a function based on  
intervaltypmodout to produce a field ID code adapted to the need here.  
  
Per bug #14479 from Piotr Stefaniak.  Back-patch to 9.2 where transform  
functions were introduced, because this code was born broken.  
  
Discussion: https://postgr.es/m/20161227172307.10135.7747@wrigleys.postgresql.org  

commit   : 3ba8beda0004742ead13eeeb7d9d17c226746326    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 27 Dec 2016 11:23:46 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 27 Dec 2016 11:23:46 -0500    

In addition to space accounted for by tuple_len, dead_tuple_len and  
free_space, the table_len includes page overhead, the item pointers  
table and padding bytes.  
  
Backpatch to live branches.  

commit   : 607d0cd14872aeabcd98bd168a50efa595ea7844    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Dec 2016 14:58:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Dec 2016 14:58:02 -0500    

hashname() asserted that the key string it is given is shorter than  
NAMEDATALEN.  That should surely always be true if the input is in fact a  
regular value of type "name".  However, for reasons of coding convenience,  
we allow plain old C strings to be treated as "name" values in many places.  
Some SQL functions accept arbitrary "text" inputs, convert them to C  
strings, and pass them otherwise-untransformed to syscache lookups for name  
columns, allowing an overlength input value to trigger hashname's Assert.  
  
This would be a DOS problem, except that it only happens in assert-enabled  
builds which aren't recommended for production.  In a production build,  
you'll just get a name lookup error, since regardless of the hash value  
computed by hashname, the later equality comparison checks can't match.  
Likewise, if the catalog lookup is done by seqscan or indexscan searches,  
there will just be a lookup error, since the name comparison functions  
don't contain any similar length checks, and will see an overlength input  
as unequal to any stored entry.  
  
After discussion we concluded that we should simply remove this Assert.  
It's inessential to hashname's own functionality, and having such an  
assertion in only some paths for name lookup is more of a foot-gun than  
a useful check.  There may or may not be a case for the affected callers  
to do something other than let the name lookup fail, but we'll consider  
that separately; in any case we probably don't want to change such  
behavior in the back branches.  
  
Per report from Tushar Ahuja.  Back-patch to all supported branches.  
  
Report: https://postgr.es/m/7d0809ee-6f25-c9d6-8e74-5b2967830d49@enterprisedb.com  
Discussion: https://postgr.es/m/17691.1482523168@sss.pgh.pa.us  

commit   : 071538f3491d3d055a7574b8cd38a40b084a01e4    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 24 Dec 2016 01:42:16 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 24 Dec 2016 01:42:16 -0500    

The -v/--verbose option was not included in the output from --help for  
pg_dumpall even though it's in the pg_dumpall documentation and has  
apparently been around since pg_dumpall was reimplemented in C in 2002.  
  
Fix that by adding it.  
  
Pointed out by Daniel Westermann.  
  
Back-patch to all supported branches.  
  
Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com  

commit   : 26b55d669092e8b69104f49d16f8cc250a7a41ee    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 23 Dec 2016 21:01:51 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 23 Dec 2016 21:01:51 -0500    

When providing tab completion for ALTER DEFAULT PRIVILEGES, we are  
including the list of roles as possible options for completion after the  
GRANT or REVOKE.  Further, we accept FOR ROLE/IN SCHEMA at the same time  
and in either order, but the tab completion was only working for one or  
the other.  Lastly, we weren't using the actual list of allowed kinds of  
objects for default privileges for completion after the 'GRANT X ON' but  
instead were completeing to what 'GRANT X ON' supports, which isn't the  
ssame at all.  
  
Address these issues by improving the forward tab-completion for ALTER  
DEFAULT PRIVILEGES and then constrain and correct how the tail  
completion is done when it is for ALTER DEFAULT PRIVILEGES.  
  
Back-patch the forward/tail tab-completion to 9.6, where we made it easy  
to handle such cases.  
  
For 9.5 and earlier, correct the initial tab-completion to at least be  
correct as far as it goes and then add a check for GRANT/REVOKE to only  
tab-complete when the GRANT/REVOKE is the start of the command, so we  
don't try to do tab-completion after we get to the GRANT/REVOKE part of  
the ALTER DEFAULT PRIVILEGES command, which is better than providing  
incorrect completions.  
  
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it  
up and added a few comments.  All bugs in the 9.5 and earlier patch are  
mine.  
  
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com  

commit   : de651a6e5db25d462bde0a47cb4f8f45c45a6a6d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Dec 2016 13:54:40 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Dec 2016 13:54:40 -0500    

You can't just cast a HashMetaPage to a Page, because the meta page  
data is stored after the page header, not at offset 0.  Fortunately,  
this didn't break anything because it happens to find hashm_bsize  
at the offset at which it expects to find pd_pagesize_version, and  
the values are close enough to the same that this works out.  
  
Still, it's a bug, so back-patch to all supported versions.  
  
Mithun Cy, revised a bit by me.  

commit   : 44de099f89c2a2d94c78f80f09555fd9b5792583    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 22 Dec 2016 09:46:46 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 22 Dec 2016 09:46:46 -0800    

When libpq encounters a connection-level error, e.g. runs out of memory  
while forming a result, there will be no error associated with PGresult,  
but a message will be placed into PGconn's error buffer. postgres_fdw  
takes care to use the PGconn error message when PGresult does not have  
one, but dblink has been negligent in that regard. Modify dblink to mirror  
what postgres_fdw has been doing.  
  
Back-patch to all supported branches.  
  
Author: Joe Conway  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com  

commit   : 501c9107487d33e234f4af8bf77f2aa64c05e6d3    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 22 Dec 2016 08:28:13 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 22 Dec 2016 08:28:13 +0100    

Patch by Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>  

commit   : fb0ab06dc4f4c90b85c220418445f4c8f15a59ca    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 21 Dec 2016 15:48:50 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 21 Dec 2016 15:48:50 -0800    

When dblink or postgres_fdw detects an error on the remote side of the  
connection, it will try to construct a local error message as best it  
can using libpq's PQresultErrorField(). When no primary message is  
available, it was bailing out with an unhelpful "unknown error". Make  
that message better and more style guide compliant. Per discussion  
on hackers.  
  
Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.  
  
Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us  

commit   : 6e2c21ec5d1c2950c275818a4de6f98ac37da5de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Dec 2016 17:39:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Dec 2016 17:39:33 -0500    

The U&'...' and U&"..." syntaxes silently discarded a surrogate pair  
start (that is, a code between U+D800 and U+DBFF) if it occurred at  
the very end of the string.  This seems like an obvious oversight,  
since we throw an error for every other invalid combination of surrogate  
characters, including the very same situation in E'...' syntax.  
  
This has been wrong since the pair processing was added (in 9.0),  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/19113.1482337898@sss.pgh.pa.us  

commit   : da57166b7dceae917a73f414d9d13e07d4354066    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 21 Dec 2016 13:47:32 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 21 Dec 2016 13:47:32 -0500    

In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the  
cast or transform if it happened to use a built-in function because we  
weren't including the information about built-in functions when querying  
pg_proc from getFuncs().  
  
Modify the query in getFuncs() to also gather information about  
functions which are used by user-defined casts and transforms (where  
"user-defined" means "has an OID >= FirstNormalObjectId").  This also  
adds to the TAP regression tests for 9.6 and master to cover these  
types of objects.  
  
Back-patch all the way for casts, back to 9.5 for transforms.  
  
Discussion: https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net  

commit   : 59a3898914d73fdf7bcac895098e7a164b64f4fe    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 21 Dec 2016 13:47:32 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 21 Dec 2016 13:47:32 -0500    

We didn't start ensuring that all built-in objects had OIDs less than  
16384 until 8.1, so for 8.0 servers we still need to query the value out  
of pg_database.  We need this, in particular, to distinguish which casts  
were built-in and which were user-defined.  
  
For HEAD, we only worry about going back to 8.0, for the back-branches,  
we also ensure that 7.0-7.4 work.  
  
Discussion: https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net  

commit   : c8f8ed5c2d2336a178ba7393a90501ff7d91b42f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 Dec 2016 12:50:20 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 Dec 2016 12:50:20 +0200    

The calculation didn't take into account the NULL terminator. That lead  
to overwriting the palloc'd buffer by one byte, if the input consists  
entirely of backslashes. For example "format('%L', E'\\')".  
  
Fixes bug #14468. Backpatch to all supported versions.  
  
Report: https://www.postgresql.org/message-id/20161216105001.13334.42819%40wrigleys.postgresql.org  

commit   : 2b7d715c0d987c5f5663afe081825ecccd2d8848    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Dec 2016 14:32:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Dec 2016 14:32:42 -0500    

This is a trivial update (consisting in fact only in the addition of  
a comment).  The point is just to get back to being synced with an  
official release of tzcode, rather than some ad-hoc point in their  
commit history, which is where commit 1f87181e1 left it.  

commit   : 60314e28eb02c82eb658aaf3c7fcf253004acbb4    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 13 Dec 2016 19:08:09 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 13 Dec 2016 19:08:09 -0600    

When there is both a serialization failure and a unique violation,  
throw the former rather than the latter.  When initially pushed,  
this was viewed as a feature to assist application framework  
developers, so that they could more accurately determine when to  
retry a failed transaction, but a test case presented by Ian  
Jackson has shown that this patch can prevent serialization  
anomalies in some cases where a unique violation is caught within a  
subtransaction, the work of that subtransaction is discarded, and  
no error is thrown.  That makes this a bug fix, so it is being  
back-patched to all supported branches where it is not already  
present (i.e., 9.2 to 9.5).  
  
Discussion: https://postgr.es/m/1481307991-16971-1-git-send-email-ian.jackson@eu.citrix.com  
Discussion: https://postgr.es/m/22607.56276.807567.924144@mariner.uk.xensource.com  

commit   : 2d48131ed1442f87e196dfe99e4904a69f1daed3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Dec 2016 18:04:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Dec 2016 18:04:28 -0500    

Back-patch commit 92fb64983 into the pre-9.6 branches.  
  
Without this, ecpg fails to build with the latest version of flex.  
It's not unreasonable that people would want to compile our old branches  
with recent tools.  Per report from Дилян Палаузов.  
  
Discussion: https://postgr.es/m/d845c1af-e18d-6651-178f-9f08cdf37e10@aegee.org  

commit   : 329361cfa3209f65f44808535b2e9b7708781d89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Dec 2016 17:44:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Dec 2016 17:44:17 -0500    

Back-patch commit 72b1e3a21 into the pre-9.6 branches.  
  
As noted in the original commit, this has some extra benefits: we can  
narrow the scope of the -Wno-error flag that's forced on scan.c.  Also,  
since these grammar and lexer files are so large, splitting them into  
separate build targets should have some advantages in build speed,  
particularly in parallel or ccache'd builds.  
  
However, the real reason for doing this now is that it avoids symbol-  
redefinition warnings (or worse) with the latest version of flex.  
It's not unreasonable that people would want to compile our old branches  
with recent tools.  Per report from Дилян Палаузов.  
  
Discussion: https://postgr.es/m/d845c1af-e18d-6651-178f-9f08cdf37e10@aegee.org  

commit   : f4ccee408d7fc9d52adf9a9153130f1298e3acb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Dec 2016 13:09:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Dec 2016 13:09:57 -0500    

When ts_rewrite()'s replacement argument is an empty tsquery, it's supposed  
to simplify any operator nodes whose operand(s) become NULL; but it failed  
to do that reliably, because dropvoidsubtree() only examined the top level  
of the result tree.  Rather than make a second recursive pass, let's just  
give the responsibility to dofindsubquery() to simplify while it's doing  
the main replacement pass.  Per report from Andreas Seltenreich.  
  
Artur Zakirov, with some cosmetic changes by me.  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/8737i01dew.fsf@credativ.de  

commit   : 981885d1777e4ee20d1057de7f6507f259f67e9f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Dec 2016 15:27:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Dec 2016 15:27:23 -0500    

PLy_generate_spi_exceptions neglected to do Py_INCREF on the new exception  
objects, evidently supposing that PyModule_AddObject would do that --- but  
it doesn't.  This left us in a situation where a Python garbage collection  
cycle could result in deletion of exception object(s), causing server  
crashes or wrong answers if the exception objects are used later in the  
session.  
  
In addition, PLy_generate_spi_exceptions didn't bother to test for  
a null result from PyErr_NewException, which at best is inconsistent  
with the code in PLy_add_exceptions.  And PLy_add_exceptions, while it  
did do Py_INCREF on the exceptions it makes, waited to do that till  
after some PyModule_AddObject calls, creating a similar risk for  
failure if garbage collection happened within those calls.  
  
To fix, refactor to have just one piece of code that creates an  
exception object and adds it to the spiexceptions module, bumping the  
refcount first.  
  
Also, let's add an additional refcount to represent the pointer we're  
going to store in a C global variable or hash table.  This should only  
matter if the user does something weird like delete the spiexceptions  
Python module, but lack of paranoia has caused us enough problems in  
PL/Python already.  
  
The fact that PyModule_AddObject doesn't do a Py_INCREF of its own  
explains the need for the Py_INCREF added in commit 4c966d920, so we  
can improve the comment about that; also, this means we really want  
to do that before not after the PyModule_AddObject call.  
  
The missing Py_INCREF in PLy_generate_spi_exceptions was reported and  
diagnosed by Rafa de la Torre; the other fixes by me.  Back-patch  
to all supported branches.  
  
Discussion: https://postgr.es/m/CA+Fz15kR1OXZv43mDrJb3XY+1MuQYWhx5kx3ea6BRKQp6ezGkg@mail.gmail.com  

commit   : 082d1fb9e4ecc375adabfb3d039597a9377e8338    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Dec 2016 12:01:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Dec 2016 12:01:14 -0500    

expandRTE() and get_rte_attribute_type() reported the exprType() and  
exprTypmod() values of the expressions in the first row of the VALUES as  
being the column type/typmod returned by the VALUES RTE.  That's fine for  
the data type, since we coerce all expressions in a column to have the same  
common type.  But we don't coerce them to have a common typmod, so it was  
possible for rows after the first one to return values that violate the  
claimed column typmod.  This leads to the incorrect result seen in bug  
#14448 from Hassan Mahmood, as well as some other corner-case misbehaviors.  
  
The desired behavior is the same as we use in other type-unification  
cases: report the common typmod if there is one, but otherwise return -1  
indicating no particular constraint.  
  
We fixed this in HEAD by deriving the typmods during transformValuesClause  
and storing them in the RTE, but that's not a feasible solution in the back  
branches.  Instead, just use a brute-force approach of determining the  
correct common typmod during expandRTE() and get_rte_attribute_type().  
Simple testing says that that doesn't really cost much, at least not in  
common cases where expandRTE() is only used once per query.  It turns out  
that get_rte_attribute_type() is typically never used at all on VALUES  
RTEs, so the inefficiency there is of no great concern.  
  
Report: https://postgr.es/m/20161205143037.4377.60754@wrigleys.postgresql.org  
Discussion: https://postgr.es/m/27429.1480968538@sss.pgh.pa.us  

commit   : a00ac62991fc9cce309e40979ca74ad54bf97b15    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 8 Dec 2016 14:09:09 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 8 Dec 2016 14:09:09 -0500    

Previously, it was thought that this only needed to be done for the  
benefit of possible standbys, so wal_level = minimal skipped it.  
But that's not safe, because during crash recovery we might replay  
XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively  
removes the directory that contains the new init fork.  So log it  
always.  
  
The user-visible effect of this bug is that if you create a database  
or tablespace, then create an unlogged table, then crash without  
checkpointing, then restart, accessing the table will fail, because  
the it won't have been properly reset.  This commit fixes that.  
  
Michael Paquier, per a report from Konstantin Knizhnik.  Wording of  
the comments per a suggestion from me.  

commit   : 311bc147ff0924b651f36910925a163c4f3b4a6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Dec 2016 12:39:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Dec 2016 12:39:24 -0500    

Ancient oversight in PageOutput(): if popen() fails, we'd better reset  
the SIGPIPE handler before returning stdout, because ClosePager() won't.  
Noticed while fixing the empty-PAGER issue.  

commit   : 1ec5cc025b419f78bf1b16c7e857e9849cde2425    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Dec 2016 12:19:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Dec 2016 12:19:57 -0500    

If the PAGER environment variable is set but contains an empty string,  
psql would pass it to "sh" which would silently exit, causing whatever  
query output we were printing to vanish entirely.  This is quite  
mystifying; it took a long time for us to figure out that this was the  
cause of Joseph Brenner's trouble report.  Rather than allowing that  
to happen, we should treat this as another way to specify "no pager".  
(We could alternatively treat it as selecting the default pager, but  
it seems more likely that the former is what the user meant to achieve  
by setting PAGER this way.)  
  
Nonempty, but all-white-space, PAGER values have the same behavior, and  
it's pretty easy to test for that, so let's handle that case the same way.  
  
Most other cases of faulty PAGER values will result in the shell printing  
some kind of complaint to stderr, which should be enough to diagnose the  
problem, so we don't need to work harder than this.  (Note that there's  
been an intentional decision not to be very chatty about apparent failure  
returns from the pager process, since that may happen if, eg, the user  
quits the pager with control-C or some such.  I'd just as soon not start  
splitting hairs about which exit codes might merit making our own report.)  
  
libpq's old PQprint() function was already on board with ignoring empty  
PAGER values, but for consistency, make it ignore all-white-space values  
as well.  
  
It's been like this a long time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAFfgvXWLOE2novHzYjmQK8-J6TmHz42G8f3X0SORM44+stUGmw@mail.gmail.com  

commit   : d83c942920d9a6b9fc7f1b11ab93bfc65be39a03    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Dec 2016 15:46:36 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Dec 2016 15:46:36 -0500    

This has no effect in the most conventional case, where no relevant DLL  
uses a debug build.  For an example where it does matter, given a debug  
build of MIT Kerberos, the krb_server_keyfile parameter usually had no  
effect.  Since nobody wants a Heisenbug, back-patch to 9.2 (all  
supported versions).  
  
Christian Ullrich, reviewed by Michael Paquier.  

commit   : a9265258af9597f3a69bcb8dadfc94cc6afdf0c7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Dec 2016 15:46:35 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Dec 2016 15:46:35 -0500    

In accordance with its own documentation, invoke CloseHandle() only when  
directed in the documentation for the function that furnished the  
handle.  GetModuleHandle() does not so direct.  We have been issuing  
this call only in the rare event that a CRT DLL contains no "_putenv"  
symbol, so lack of bug reports is uninformative.  Back-patch to 9.2 (all  
supported versions).  
  
Christian Ullrich, reviewed by Michael Paquier.  

commit   : 117818252d96cb6cb99c72da936d3371680c3768    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Dec 2016 15:46:35 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Dec 2016 15:46:35 -0500    

Replace use of plain 0 as a null pointer constant.  In comments, update  
terminology and lessen redundancy.  Back-patch to 9.2 (all supported  
versions) for the convenience of back-patching the next two commits.  
  
Christian Ullrich and Noah Misch, reviewed (in earlier versions) by  
Michael Paquier.  

commit   : 3e65fd045a924f4c4cfaa0f73857db28558afd11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Nov 2016 13:34:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Nov 2016 13:34:14 -0500    

Per bug #14441 from Mark Pether, the documentation could be misread,  
mainly because some of the examples failed to show what happens with  
a multicharacter "characters to trim" string.  Also, while the text  
description in most of these entries was fairly clear that the  
"characters" argument is a set of characters not a substring to match,  
some of them used variant wording that was a bit less clear.  
trim() itself suffered from both deficiencies and was thus pretty  
misinterpretable.  
  
Also fix failure to explain which of LEADING/TRAILING/BOTH is the  
default.  
  
Discussion: https://postgr.es/m/20161130011710.6539.53657@wrigleys.postgresql.org  

commit   : f45719997d3c8c8feb563ea9976ced15681de1ce    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 29 Nov 2016 10:35:16 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 29 Nov 2016 10:35:16 -0500    

The documentation around the -b/--blobs option to pg_dump seemed to  
imply that it might be possible to add blobs to a "schema-only" dump or  
similar.  Clarify that blobs are data and therefore will only be  
included in dumps where data is being included, even when -b is used to  
request blobs be included.  
  
The -b option has been around since before 9.2, so back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/20161119173316.GA13284@tamriel.snowman.net  

commit   : a982b02a49e13a488c95cacf90cb197b59d60069    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Nov 2016 13:31:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Nov 2016 13:31:35 -0500    

Commit 08dd23cec introduced an exception to the rule that extension member  
objects can only be dropped as part of dropping the whole extension,  
intending to allow such drops while running the extension's own creation or  
update scripts.  However, the exception was only applied at the outermost  
recursion level, because it was modeled on a pre-existing check to ignore  
dependencies on objects listed in pendingObjects.  Bug #14434 from Philippe  
Beaudoin shows that this is inadequate: in some cases we can reach an  
extension member object by recursion from another one.  (The bug concerns  
the serial-sequence case; I'm not sure if there are other cases, but there  
might well be.)  
  
To fix, revert 08dd23cec's changes to findDependentObjects() and instead  
apply the creating_extension exception regardless of stack level.  
  
Having seen this example, I'm a bit suspicious that the pendingObjects  
logic is also wrong and such cases should likewise be allowed at any  
recursion level.  However, changing that would interact in subtle ways  
with the recursion logic (at least it would need to be moved to after the  
recursing-from check).  Given that the code's been like that a long time,  
I'll refrain from touching it without a clear example showing it's wrong.  
  
Back-patch to all active branches.  In HEAD and 9.6, where suitable  
test infrastructure exists, add a regression test case based on the  
bug report.  
  
Report: <20161125151448.6529.33039@wrigleys.postgresql.org>  
Discussion: <13224.1480177514@sss.pgh.pa.us>  

commit   : 6a363a4c252329f1f97d80526eb55b3301abf1f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Nov 2016 13:44:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Nov 2016 13:44:48 -0500    

When dropping a foreign key constraint with ALTER TABLE DROP CONSTRAINT,  
we refuse the drop if there are any pending trigger events on the named  
table; this ensures that we won't remove the pg_trigger row that will be  
consulted by those events.  But we should make the same check for the  
referenced relation, else we might remove a due-to-be-referenced pg_trigger  
row for that relation too, resulting in "could not find trigger NNN" or  
"relation NNN has no triggers" errors at commit.  Per bug #14431 from  
Benjie Gillam.  Back-patch to all supported branches.  
  
Report: <20161124114911.6530.31200@wrigleys.postgresql.org>  

commit   : 05975ab0a62ce86c49dd607600148fba5c79c549    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Nov 2016 13:45:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Nov 2016 13:45:56 -0500    

When rebuilding an existing index, ALTER TABLE correctly kept the  
physical file in the same tablespace, but it messed up the pg_class  
entry if the index had been in the database's default tablespace  
and "default_tablespace" was set to some non-default tablespace.  
This led to an inaccessible index.  
  
Fix by fixing pg_get_indexdef_string() to always include a tablespace  
clause, whether or not the index is in the default tablespace.  The  
previous behavior was installed in commit 537e92e41, and I think it just  
wasn't thought through very clearly; certainly the possible effect of  
default_tablespace wasn't considered.  There's some risk in changing the  
behavior of this function, but there are no other call sites in the core  
code.  Even if it's being used by some third party extension, it's fairly  
hard to envision a usage that is okay with a tablespace clause being  
appended some of the time but can't handle it being appended all the time.  
  
Back-patch to all supported versions.  
  
Code fix by me, investigation and test cases by Michael Paquier.  
  
Discussion: <1479294998857-5930602.post@n3.nabble.com>  

commit   : 131483909726a2b5bd509d8bc3b980575f173481    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2016 17:56:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2016 17:56:16 -0500    

Create a section specifically for the syntactic rules around whole-row  
variable usage, such as expansion of "foo.*".  This was previously  
documented only haphazardly, with some critical info buried in  
unexpected places like xfunc-sql-composite-functions.  Per repeated  
questions in different mailing lists.  
  
Discussion: <16288.1479610770@sss.pgh.pa.us>  

commit   : ab33ecc8887a62987d236c45b2f3a235a301b80d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2016 14:02:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Nov 2016 14:02:52 -0500    

There are assorted references to RETURNING in Part II, but nothing  
that would qualify as an explanation of the feature, which seems  
like an oversight considering how useful it is.  Add something.  
  
Noted while looking for a place to point a cross-reference to ...  

commit   : 7e8cc250ac500740f17e229b80e98fba8e52b1e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2016 18:21:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Nov 2016 18:21:56 -0500    

The code was intentionally not very careful about leaking strdup'd  
strings in case of an error.  That was forgivable probably, but it  
also failed to notice strdup() failures, which could lead to subsequent  
null-pointer-dereference crashes, since many callers unsurprisingly  
didn't check for null pointers in the struct lconv fields.  An even  
worse problem is that it could throw error while we were setlocale'd  
to a non-C locale, causing unwanted behavior in subsequent libc calls.  
  
Rewrite to ensure that we cannot throw elog(ERROR) until after we've  
restored the previous locale settings, or at least attempted to.  
(I'm sorely tempted to make restore failure be a FATAL error, but  
will refrain for the moment.)  Having done that, it's not much more  
work to ensure that we clean up strdup'd storage on the way out, too.  
  
This code is substantially the same in all supported branches, so  
back-patch all the way.  
  
Michael Paquier and Tom Lane  
  
Discussion: <CAB7nPqRMbGqa_mesopcn4MPyTs34eqtVEK7ELYxvvV=oqS00YA@mail.gmail.com>  

commit   : 13aa9af378740795572294a800975254a969e890    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Nov 2016 16:17:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Nov 2016 16:17:19 -0500    

On Windows, libc will mask \r\n line endings for us, since we read the  
password file in text mode.  But that doesn't happen on Unix.  People  
who share password files across both systems might have \r\n line endings  
in a file they use on Unix, so as a convenience, ignore trailing \r.  
Per gripe from Josh Berkus.  
  
In passing, put the existing check for empty line somewhere where it's  
actually useful, ie after stripping the newline not before.  
  
Vik Fearing, adjusted a bit by me  
  
Discussion: <0de37763-5843-b2cc-855e-5d0e5df25807@agliodbs.com>  

commit   : e714cbe549c275c52b7b4553097f091d329eaec1    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 8 Nov 2016 18:34:59 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 8 Nov 2016 18:34:59 +0100    

commit   : 92b7b1058cf3ffb833085b953838af15add5ba29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Nov 2016 14:43:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Nov 2016 14:43:14 -0500    

For a very long time, pltcl's spi_exec and spi_execp commands have had  
a behavior of storing the current row number as an element of output  
arrays, but this was never documented.  Fix that.  
  
For an equally long time, pltcl_trigger_handler had a behavior of silently  
ignoring ".tupno" as an output column name, evidently so that the result  
of spi_exec could be used directly as a trigger result tuple.  Not sure  
how useful that really is, but in any case it's bad that it would break  
attempts to use ".tupno" as an actual column name.  We can fix it by not  
checking for ".tupno" until after we check for a column name match.  This  
comports with the effective behavior of spi_exec[p] that ".tupno" is only  
magic when you don't have an actual column named that.  
  
In passing, wordsmith the description of returning modified tuples from  
a pltcl trigger.  
  
Noted while working on Jim Nasby's patch to support composite results  
from pltcl.  The inability to return trigger tuples using ".tupno" as  
a column name is a bug, so back-patch to all supported branches.  

commit   : 6653dbafd8526a63b91a8b3a020b1616d17977ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Nov 2016 10:45:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Nov 2016 10:45:58 -0500    

The workaround the IANA guys chose to get rid of the clang warning  
we'd silenced in commit 23ed2ba81 turns out not to satisfy Coverity.  
Go back to the previous solution, ie, remove the useless comparison  
to SIZE_MAX.  (In principle, there could be machines out there where  
it's not useless because ptrdiff_t is wider than size_t.  But the whole  
thing is pretty academic anyway, as we could never approach this limit  
for any sane estimate of the amount of data that zic will ever be asked  
to work with.)  
  
Also, s/lineno/lineno_t/g, because if we accept their decision to start  
using "lineno" as a typedef, it is going to have very unpleasant  
consequences in our next pgindent run.  Noted that while fooling with  
pltcl yesterday.  

commit   : 07bc2fc4574c5edce135a96353c6a343c3ec4b0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Nov 2016 10:44:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Nov 2016 10:44:16 -0400    

This patch absorbs some unreleased fixes for symlink manipulation bugs  
introduced in tzcode 2016g.  Ordinarily I'd wait around for a released  
version, but in this case it seems like we could do with extra testing,  
in particular checking whether it works in EDB's VMware build environment.  
This corresponds to commit aec59156abbf8472ba201b6c7ca2592f9c10e077 in  
https://github.com/eggert/tz.  
  
Per a report from Sandeep Thakkar, building in an environment where hard  
links are not supported in the timezone data installation directory failed,  
because upstream code refactoring had broken the case of symlinking from an  
existing symlink.  Further experimentation also showed that the symlinks  
were sometimes made incorrectly, with too many or too few "../"'s in the  
symlink contents.  
  
Back-patch of commit 1f87181e12beb067d21b79493393edcff14c190b.  
  
Report: <CANFyU94_p6mqRQc2i26PFp5QAOQGB++AjGX=FO8LDpXw0GSTjw@mail.gmail.com>  
Discussion: http://mm.icann.org/pipermail/tz/2016-November/024431.html  

commit   : 606e16a7f96f150187da4b575f40510fcd7ca8ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Oct 2016 17:35:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Oct 2016 17:35:43 -0400    

tsquery_rewrite() tries to find matches to subsets of AND/OR conditions;  
for example, in the query 'a | b | c' the substitution subquery 'a | c'  
should match and lead to replacement of the first and third items.  
That's fine, but the matching algorithm apparently takes about O(2^N)  
for an N-clause query (I say "apparently" because the code is also both  
unintelligible and uncommented).  We could probably do better than that  
even without any extra assumptions --- but actually, we know that the  
subclauses are sorted, indeed are depending on that elsewhere in this very  
same function.  So we can just scan the two lists a single time to detect  
matches, as though we were doing a merge join.  
  
Also do a re-flattening call (QTNTernary()) in tsquery_rewrite_query, just  
to make sure that the tree fits the expectations of the next search cycle.  
I didn't try to devise a test case for this, but I'm pretty sure that the  
oversight could have led to failure to match in some cases where a match  
would be expected.  
  
Improve comments, and also stick a CHECK_FOR_INTERRUPTS into  
dofindsubquery, just in case it's still too slow for somebody.  
  
Per report from Andreas Seltenreich.  Back-patch to all supported branches.  
  
Discussion: <8760oasf2y.fsf@credativ.de>  

commit   : b0f8a273e678354d9c6c7cb02598e892942ad5b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Oct 2016 15:24:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Oct 2016 15:24:40 -0400    

QTNTernary() contains logic to flatten, eg, '(a & b) & c' into 'a & b & c',  
which is all well and good, but it tries to do that to NOT nodes as well,  
so that '!!a' gets changed to '!a'.  Explicitly restrict the conversion to  
be done only on AND and OR nodes, and add a test case illustrating the bug.  
  
In passing, provide some comments for the sadly naked functions in  
tsquery_util.c, and simplify some baroque logic in QTNFree(), which  
I think may have been leaking some items it intended to free.  
  
Noted while investigating a complaint from Andreas Seltenreich.  
Back-patch to all supported versions.  

commit   : 2be2838a7174b50592c32aba4863ff5f0049b083    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Oct 2016 14:27:40 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Oct 2016 14:27:40 -0400    

This bug exists as far back as 9.0, when Hot Standby was introduced,  
so back-patch to all supported branches.  
  
Report and patch by Takayuki Tsunakawa, reviewed by Michael Paquier  
and Kuntal Ghosh.  

commit   : 629575fa2da95943d491f3f821fd94413a78141b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Oct 2016 11:19:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 27 Oct 2016 11:19:51 -0400    

If a restartpoint flushed no dirty buffers, it could fail to update  
the minimum recovery point, leading to a minimum recovery point prior  
to the starting REDO location.  perform_base_backup() would interpret  
that as meaning that no WAL files at all needed to be included in the  
backup, failing an internal sanity check.  To fix, have restartpoints  
always update the minimum recovery point to just after the checkpoint  
record itself, so that the file (or files) containing the checkpoint  
record will always be included in the backup.  
  
Code by Amit Kapila, per a design suggestion by me, with some  
additional work on the code comment by me.  Test case by Michael  
Paquier.  Report by Kyotaro Horiguchi.  

commit   : 1c8364f3ae328be3f1af90b3208d0b5f18b2c48b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Oct 2016 13:40:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Oct 2016 13:40:41 -0400    

I broke this in commit f3094920a.  Apparently it's dead code anyway,  
at least as far as our buildfarm is concerned (and the upstream IANA  
code doesn't worry at all about symlink() not being present).  
But as long as the rest of our code is willing to guard against not  
having symlink(), this should too.  Noted while investigating a  
tangentially-related complaint from Sandeep Thakkar.  
  
Back-patch to keep branches in sync.