PostgreSQL 9.6.5 commit log

commit   : 254bb39b720426f7a4616cb6b40f810c44b24b20    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 17:21:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 17:21:42 -0400    

commit   : c72a656725ef07fb8752333e0f3bdaf3c0aee999    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 11:40:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Aug 2017 11:40:47 -0400    

Discussion: https://postgr.es/m/CAFcNs+pJ6_Ud-zg3vY_Y0mzfESdM34Humt8avKrAKq_H+v18Cg@mail.gmail.com  

commit   : 8e80a5e25e85db2f1b9918cc230e4e198e653dc0    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 28 Aug 2017 10:17:39 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 28 Aug 2017 10:17:39 -0400    

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

commit   : 5376ddb91eb6486f541e82657f423b9e54d2532e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 27 Aug 2017 17:35:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 27 Aug 2017 17:35:04 -0400    

commit   : 0cd9071130832d051048e051c00d93819436800c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 14:19:35 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 14:19:35 -0400    

Author: Thomas Munro <[email protected]>  

commit   : 562ac271931684207009ac9fcc4d7e5d3ba9cb0c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 09:56:38 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 Aug 2017 09:56:38 -0400    

This was erroneously removed in  
55a70a023c3daefca9bbd68bfbe6862af10ab479.  

commit   : 6c036d01089cee0c1cbabdd140d00cf24912013e    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 22 Aug 2017 07:46:05 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 22 Aug 2017 07:46:05 -0700    

2cd70845240 / c6293249d change the way individual attributes in a  
TupleDesc are stored / accessed.  To reduce the effort of making  
extensions compatible with postgresql 11, and to ease future  
backpatching, backpatch introduction of TupleDescAttr() to all  
releases.  Do not backpatch change in storage, as that'd be a breaking  
change for existing and working extensions.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/[email protected]  
Backpatch: 9.2-  

commit   : 41803d55a2036f9a9602db88169250dd55f9d8cf    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 19 Aug 2017 13:39:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 19 Aug 2017 13:39:38 -0400    

Commit 3eb9a5e7c unintentionally introduced an ordering dependency  
into restore_toc_entries_prefork().  The existing coding of  
reduce_dependencies() contains a check to skip moving a TOC entry  
to the ready_list if it wasn't initially in the pending_list.  
This used to suffice to prevent reduce_dependencies() from trying to  
move anything into the ready_list during restore_toc_entries_prefork(),  
because the pending_list stayed empty throughout that phase; but it no  
longer does.  The problem doesn't manifest unless the TOC has been  
reordered by SortTocFromFile, which is how I missed it in testing.  
  
To fix, just add a test for ready_list == NULL, converting the call  
with NULL from a poor man's sanity check into an explicit command  
not to touch TOC items' list membership.  Clarify some of the comments  
around this; in particular, note the primary purpose of the check for  
pending_list membership, which is to ensure that we can't try to restore  
the same item twice, in case a TOC list forces it to be restored before  
its dependency count goes to zero.  
  
Per report from Fabrízio de Royes Mello.  Back-patch to 9.3, like the  
previous commit.  
  
Discussion: https://postgr.es/m/CAFcNs+pjuv0JL_x4+=71TPUPjdLHOXA4YfT32myj_OrrZb4ohA@mail.gmail.com  

commit   : c343314882f1c9461eeb227ce7807f2aa8515470    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 13:13:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 17 Aug 2017 13:13:47 -0400    

It now emerges that we can only rely on Perl to tell us we must use  
-D_USE_32BIT_TIME_T if it's Perl 5.13.4 or later.  For older versions,  
revert to our previous practice of assuming we need that symbol in  
all 32-bit Windows builds.  This is not ideal, but inquiring into  
which compiler version Perl was built with seems far too fragile.  
In any case, we had not previously had complaints about these old  
Perl versions, so let's assume this is Good Enough.  (It's still  
better than the situation ante commit 5a5c2feca, in that at least  
the effects are confined to PL/Perl rather than the whole PG build.)  
  
Back-patch to all supported versions, like 5a5c2feca and predecessors.  
  
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com  

commit   : 2a028de1aea29b876b54fdbcac07a41d659125dc    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 17 Aug 2017 11:19:07 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 17 Aug 2017 11:19:07 -0400    

Spotted by Tom Lane  
  
Discussion: http://postgr.es/m/[email protected]  

commit   : 3d7a1e2b96b60353c63742d4a8270c67a17744f4    
  
author   : Michael Meskes <[email protected]>    
date     : Mon, 14 Aug 2017 11:29:34 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Mon, 14 Aug 2017 11:29:34 +0200    

commit   : 954490fecb4ee65e1f3fd5c38f65aaab64ea2099    
  
author   : Michael Meskes <[email protected]>    
date     : Tue, 15 Aug 2017 16:06:56 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Tue, 15 Aug 2017 16:06:56 +0200    

commit   : d01fc51c003ce6e7b0ac96204a1d82f1ba505b70    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 21:05:21 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 21:05:21 -0400    

Although not confirmed and probably rare, if the newly allocated memory  
is not already zero, this could possibly have caused some problems.  
  
Also reorder the initializations slightly so they match the order of the  
struct definition.  
  
Author: Wong, Yi Wen <[email protected]>  
Reviewed-by: Masahiko Sawada <[email protected]>  

commit   : dce90c7c8c011c2214f53d12b877bf5fcf9ecdd9    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:27:22 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:27:22 -0400    

This appears to have been an omission in the original commit  
0d692a0dc9f.  All related information_schema views already include  
foreign tables.  
  
Reported-by: Nicolas Thauvin <[email protected]>  

commit   : 62c9eaf5535df8efb417600add99f6e0d111dac2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:10:38 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 19:10:38 -0400    

Author: Pavel Stehule <[email protected]>  

commit   : c4dd62db1995d17b85c77d901b5eba8f25dfe2ff    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 10:17:35 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 15 Aug 2017 10:17:35 -0400    

commit   : 624b6f328a1b8d0ee21023543ca63552c98a300e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 15:43:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 15:43:20 -0400    

Stress testing by Andreas Seltenreich disclosed longstanding problems that  
occur if a FATAL exit (e.g. due to receipt of SIGTERM) occurs while we are  
trying to execute a ROLLBACK of an already-failed transaction.  In such a  
case, xact.c is in TBLOCK_ABORT state, so that AbortOutOfAnyTransaction  
would skip AbortTransaction and go straight to CleanupTransaction.  This  
led to an assert failure in an assert-enabled build (due to the ROLLBACK's  
portal still having a cleanup hook) or without assertions, to a FATAL exit  
complaining about "cannot drop active portal".  The latter's not  
disastrous, perhaps, but it's messy enough to want to improve it.  
  
We don't really want to run all of AbortTransaction in this code path.  
The minimum required to clean up the open portal safely is to do  
AtAbort_Memory and AtAbort_Portals.  It seems like a good idea to  
do AtAbort_Memory unconditionally, to be entirely sure that we are  
starting with a safe CurrentMemoryContext.  That means that if the  
main loop in AbortOutOfAnyTransaction does nothing, we need an extra  
step at the bottom to restore CurrentMemoryContext = TopMemoryContext,  
which I chose to do by invoking AtCleanup_Memory.  This'll result in  
calling AtCleanup_Memory twice in many of the paths through this function,  
but that seems harmless and reasonably inexpensive.  
  
The original motivation for the assertion in AtCleanup_Portals was that  
we wanted to be sure that any user-defined code executed as a consequence  
of the cleanup hook runs during AbortTransaction not CleanupTransaction.  
That still seems like a valid concern, and now that we've seen one case  
of the assertion firing --- which means that exactly that would have  
happened in a production build --- let's replace the Assert with a runtime  
check.  If we see the cleanup hook still set, we'll emit a WARNING and  
just drop the hook unexecuted.  
  
This has been like this a long time, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3883be3eae9741f7d99862ea0be1657f6dc3e92a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 11:48:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Aug 2017 11:48:59 -0400    

Commit 3c163a7fc's original choice to ignore all #define symbols whose  
names begin with underscore turns out to be too simplistic.  On Windows,  
some Perl installations are built with -D_USE_32BIT_TIME_T, and we must  
absorb that or we get the wrong result for sizeof(PerlInterpreter).  
  
This effectively re-reverts commit ef58b87df, which injected that symbol  
in a hacky way, making it apply to all of Postgres not just PL/Perl.  
More significantly, it did so on *all* 32-bit Windows builds, even when  
the Perl build to be used did not select this option; so that it fails  
to work properly with some newer Perl builds.  
  
By making this change, we would be introducing an ABI break in 32-bit  
Windows builds; but fortunately we have not used type time_t in any  
exported Postgres APIs in a long time.  So it should be OK, both for  
PL/Perl itself and for third-party extensions, if an extension library  
is built with a different _USE_32BIT_TIME_T setting than the core code.  
  
Patch by me, based on research by Ashutosh Sharma and Robert Haas.  
Back-patch to all supported branches, as commit 3c163a7fc was.  
  
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com  

commit   : a64b5a9927e982d26244a9f92e0155e47ab44336    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 13 Aug 2017 16:15:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 13 Aug 2017 16:15:14 -0400    

The sole useful effect of this function, to check that no catcache  
entries have positive refcounts at transaction end, has really been  
obsolete since we introduced ResourceOwners in PG 8.1.  We reduced the  
checks to assertions years ago, so that the function was a complete  
no-op in production builds.  There have been previous discussions about  
removing it entirely, but consensus up to now was that it had some small  
value as a cross-check for bugs in the ResourceOwner logic.  
  
However, it now emerges that it's possible to trigger these assertions  
if you hit an assert-enabled backend with SIGTERM during a call to  
SearchCatCacheList, because that function temporarily increases the  
refcounts of entries it's intending to add to a catcache list construct.  
In a normal ERROR scenario, the extra refcounts are cleaned up by  
SearchCatCacheList's PG_CATCH block; but in a FATAL exit we do a  
transaction abort and exit without ever executing PG_CATCH handlers.  
  
There's a case to be made that this is a generic hazard and we should  
consider restructuring elog(FATAL) handling so that pending PG_CATCH  
handlers do get run.  That's pretty scary though: it could easily create  
more problems than it solves.  Preliminary stress testing by Andreas  
Seltenreich suggests that there are not many live problems of this ilk,  
so we rejected that idea.  
  
There are more-localized ways to fix the problem; the most principled  
one would be to use PG_ENSURE_ERROR_CLEANUP instead of plain PG_TRY.  
But adding cycles to SearchCatCacheList isn't very appealing.  We could  
also weaken the assertions in AtEOXact_CatCache in some more or less  
ad-hoc way, but that just makes its raison d'etre even less compelling.  
In the end, the most reasonable solution seems to be to just remove  
AtEOXact_CatCache altogether, on the grounds that it's not worth trying  
to fix it.  It hasn't found any bugs for us in many years.  
  
Per report from Jeevan Chalke.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAM2+6=VEE30YtRQCZX7_sCFsEpoUkFBV1gZazL70fqLn8rcvBA@mail.gmail.com  

commit   : fdf89f7aac502718c098622b3e33a84aa6bde1d4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 11 Aug 2017 16:14:55 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 11 Aug 2017 16:14:55 -0400    

Since PostgreSQL 9.6, rolreplication no longer determines whether a role  
can run pg_start_backup() and pg_stop_backup(), so remove that.  
  
Add that this attribute determines whether a role can create and drop  
replication slots.  
  
Reported-by: Fujii Masao <[email protected]>  

commit   : e2e398473e3c425a8e84a592641acc0db7e22264    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Aug 2017 17:03:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Aug 2017 17:03:09 -0400    

find_composite_type_dependencies correctly found columns that are of  
the specified type, and columns that are of arrays of that type, but  
not columns that are domains or ranges over the given type, its array  
type, etc.  The most general way to handle this seems to be to assume  
that any type that is directly dependent on the specified type can be  
treated as a container type, and processed recursively (allowing us  
to handle nested cases such as ranges over domains over arrays ...).  
Since a type's array type already has such a dependency, we can drop  
the existing special case for the array type.  
  
The very similar logic in get_rels_with_domain was likewise a few  
bricks shy of a load, as it supposed that a directly dependent type  
could *only* be a sub-domain.  This is already wrong for ranges over  
domains, and it'll someday be wrong for arrays over domains.  
  
Add test cases illustrating the problems, and back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : fc2aafe4a55beb7fe73b9f4cbbb1e49f5b7cb2dd    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Aug 2017 12:05:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Aug 2017 12:05:53 -0400    

FreeBSD's make, for one, sets the MAKELEVEL environment variable when  
invoking commands.  In the special Makefile we provide to hand off control  
from a non-GNU make to GNU make, this causes GNU make to think it is a  
child make invocation rather than top-level.  That interferes with the hack  
added in commit dcae5facc to cause the temp-install tree to be made only by  
the top-level invocation of gmake.  Unset the variable to prevent that.  
  
Likewise unset MAKEFLAGS, which FreeBSD's make also sets, and which could  
easily confuse gmake.  There are no reports of actual trouble from that,  
but it seems better to be proactive.  
  
Back-patch to 9.5 where dcae5facc came in.  
  
Thomas Munro, hacked a bit more by me  
  
Discussion: https://postgr.es/m/CAEepm=1ueww35AXTkt1A3gyzZUqv5XCzh8RUNvJZAQAW=eOhVw@mail.gmail.com  

commit   : fe578cbd4b4262496d44cb5cd110eae3c4aff48c    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 8 Aug 2017 19:18:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 8 Aug 2017 19:18:12 -0400    

Commit 1efc7e538 did a poor job of emulating existing logic for touching  
Datums that might be expanded-object pointers.  It didn't check for typlen  
being -1 first, which meant it could crash on fixed-length pass-by-ref  
values, and probably on cstring values as well.  It also didn't use  
DatumGetPointer before VARATT_IS_EXTERNAL_EXPANDED, which while currently  
harmless is not according to documentation nor prevailing style.  
  
I also think the lack of any explanation as to why datumSerialize makes  
these particular nonobvious choices is pretty awful, so fix that.  
  
Per report from Jarred Ward.  Back-patch to 9.6 where this code came in.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1924ef41668773ad62d845eebc11ff35f17446ad    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 8 Aug 2017 18:46:16 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 8 Aug 2017 18:46:16 -0400