PostgreSQL 9.5.3 commit log

commit   : ba37ac217791dfdf2b327c4b75e7083b6b03a2f5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 May 2016 16:50:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 May 2016 16:50:23 -0400    

commit   : e51547e05a44101667ef277c89319647e52c0f62    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 9 May 2016 10:05:46 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 9 May 2016 10:05:46 -0400    

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

commit   : 828fe491488b170f6f2952ef794178969f2aa206    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 May 2016 17:26:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 May 2016 17:26:24 -0400    

commit   : 673bceaf3f24a7a3d3ed346d07cedc6524ad888d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 May 2016 13:16:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 May 2016 13:16:50 -0400    

In the documentation for nextval(), point out explicitly that INSERT ...  
ON CONFLICT will call nextval() if needed for the insertion case, whether  
or not it ends up following the ON CONFLICT path.  This seems to be a  
matter of some confusion, cf bug #14126, so let's be clear about it.  
  
Also mention the issue in the CREATE SEQUENCE reference page, since that  
is another place where people might expect such things to be covered.  
  
Minor wording improvements nearby, as well.  
  
Back-patch to 9.5 where ON CONFLICT was introduced.  

commit   : a3c17b2af89cd46b47df3483bb693312d7521795    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    

OpenSSL has an unfortunate tendency to mix per-session state error  
handling with per-thread error handling.  This can cause problems when  
programs that link to libpq with OpenSSL enabled have some other use of  
OpenSSL; without care, one caller of OpenSSL may cause problems for the  
other caller.  Backend code might similarly be affected, for example  
when a third party extension independently uses OpenSSL without taking  
the appropriate precautions.  
  
To fix, don't trust other users of OpenSSL to clear the per-thread error  
queue.  Instead, clear the entire per-thread queue ahead of certain I/O  
operations when it appears that there might be trouble (these I/O  
operations mostly need to call SSL_get_error() to check for success,  
which relies on the queue being empty).  This is slightly aggressive,  
but it's pretty clear that the other callers have a very dubious claim  
to ownership of the per-thread queue.  Do this is both frontend and  
backend code.  
  
Finally, be more careful about clearing our own error queue, so as to  
not cause these problems ourself.  It's possibly that control previously  
did not always reach SSLerrmessage(), where ERR_get_error() was supposed  
to be called to clear the queue's earliest code.  Make sure  
ERR_get_error() is always called, so as to spare other users of OpenSSL  
the possibility of similar problems caused by libpq (as opposed to  
problems caused by a third party OpenSSL library like PHP's OpenSSL  
extension).  Again, do this is both frontend and backend code.  
  
See bug #12799 and https://bugs.php.net/bug.php?id=68276  
  
Based on patches by Dave Vitek and Peter Eisentraut.  
  
From: Peter Geoghegan <[email protected]>  

commit   : ab32a4057229dc59ee83614b1fcc7fe242213a78    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 6 May 2016 23:45:12 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 May 2016 23:45:12 -0400    

These were accidentally broken by the great backpatching of  
331828b754378733cb5c2e49227603e7354e4e39.  

commit   : 196870f2fca7a4eec6f5b795dc75799f41e3ec7b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 22:05:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 22:05:51 -0400    

This patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much  
simpler solution for the case where the new cluster would choose to create  
a TOAST table but the old cluster doesn't have one: just don't create a  
TOAST table.  
  
The existing code failed in at least two different ways if the situation  
arose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the  
lock sanity check in create_toast_table failed; (2) pg_upgrade did not  
provide a pg_type OID for the new toast table, so that the crosscheck in  
TypeCreate failed.  While both these problems were introduced by later  
patches, they show that the hack being used to cause TOAST table creation  
is overwhelmingly fragile (and untested).  I also note that before the  
TypeCreate crosscheck was added, the code would have resulted in assigning  
an indeterminate pg_type OID to the toast table, possibly causing a later  
OID conflict in that catalog; so that it didn't really work even when  
committed.  
  
If we simply don't create a TOAST table, there will only be a problem if  
the code tries to store a tuple that's wider than a page, and field  
compression isn't sufficient to get it under a page.  Given that the TOAST  
creation threshold is intended to be about a quarter of a page, it's very  
hard to believe that cross-version differences in the do-we-need-a-toast-  
table heuristic could result in an observable problem.  So let's just  
follow the old version's conclusion about whether a TOAST table is needed.  
  
(If we ever do change needs_toast_table() so much that this conclusion  
doesn't apply, we can devise a solution at that time, and hopefully do  
it in a less klugy way than 4c6780fd17aa43ed did.)  
  
Back-patch to 9.3, like the previous patch.  
  
Discussion: <[email protected]>  

commit   : 504af1fe0497bceb0421a63fd8ef18e069ae057a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 12:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 12:09:20 -0400    

to_timestamp() handles the TH/th format codes by advancing over two input  
characters, whatever those are.  It failed to notice whether there were  
two characters available to be skipped, making it possible to advance  
the pointer past the end of the input string and keep on parsing.  
A similar risk existed in the handling of "Y,YYY" format: it would advance  
over three characters after the "," whether or not three characters were  
available.  
  
In principle this might be exploitable to disclose contents of server  
memory.  But the security team concluded that it would be very hard to use  
that way, because the parsing loop would stop upon hitting any zero byte,  
and TH/th format codes can't be consecutive --- they have to follow some  
other format code, which would have to match whatever data is there.  
So it seems impractical to examine memory very much beyond the end of the  
input string via this bug; and the input string will always be in local  
memory not in disk buffers, making it unlikely that anything very  
interesting is close to it in a predictable way.  So this doesn't quite  
rise to the level of needing a CVE.  
  
Thanks to Wolf Roediger for reporting this bug.  

commit   : 4edbb265cee0b468d444b4aabb1b236334f09c3a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 May 2016 20:08:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 May 2016 20:08:58 -0400    

DST law changes in Russia (Magadan, Tomsk regions) and Venezuela.  
Historical corrections for Russia.  There are new zone names Europe/Kirov  
and Asia/Tomsk reflecting the fact that these regions now have different  
time zone histories from adjacent regions.  

commit   : e4a58520fc3328455b46cf9bf589904133faa016    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 May 2016 12:33:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 May 2016 12:33:13 -0400    

Somebody added pg_replication_origin, pg_replication_origin_status and  
pg_replication_slots to catalogs.sgml without a whole lot of concern for  
either alphabetical order or the difference between a table and a view.  
Clean up the mess.  
  
Back-patch to 9.5, not so much because this is critical as because if  
I don't it will result in a cross-branch divergence in release-9.5.sgml,  
which would be a maintenance hazard.  

commit   : c792440fe0770fb6dfcb478fe70b00c326021f8f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 4 May 2016 14:07:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 4 May 2016 14:07:00 -0400    

From: Alexander Law <[email protected]>  

commit   : b0088f7dfffbb9b20b5b75692e94ca729d52270d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 3 May 2016 21:06:25 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 3 May 2016 21:06:25 -0400    

From: Alexander Law <[email protected]>  

commit   : 5e7a7703bd5d51628b2ff4999a6b08455e25f1ca    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 May 2016 11:18:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 May 2016 11:18:10 -0400    

awk's equality-comparison operator is "==" not "=".  We got this right  
in many places, but not in configure's checks for supported version  
numbers of flex and perl.  It hadn't been noticed because unsupported  
versions are so old as to be basically extinct in the wild, and because  
the only consequence is whether or not a WARNING flies by during  
configure.  
  
Daniel Gustafsson noted the problem with respect to the test for flex,  
I found the other by reviewing other awk calls.  

commit   : ad5993d866f9fde16c454fe24b0a216c99ace355    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 2 May 2016 10:07:49 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 2 May 2016 10:07:49 +0300    

CHECK_PAGE_OFFSET_RANGE() has been unused forever.  
CHECK_RELATION_BLOCK_RANGE() has been unused in pgstatindex.c ever since  
bt_page_stats() and bt_page_items() functions were moved from pgstattuple  
to pageinspect module. It still exists in pageinspect/btreefuncs.c.  
  
Daniel Gustafsson  

commit   : 25f462b656a065f5ba023f9398ab81afc90d1244    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 1 May 2016 21:33:31 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 1 May 2016 21:33:31 -0400    

From: Guillaume Lelarge <[email protected]>  

commit   : f25d0619c7bcc787b7b67d6bd29f9627a47ff57e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Apr 2016 20:19:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Apr 2016 20:19:38 -0400    

Given a three-or-more-way equivalence class, such as X.Y = Y.Y = Z.Z,  
it was possible for the planner to omit one of the quals needed to  
enforce that all members of the equivalence class are actually equal.  
This only happened in the case of a parameterized join node for two  
of the relations, that is a plan tree like  
  
	Nested Loop  
	  ->  Scan X  
	  ->  Nested Loop  
	    ->  Scan Y  
	    ->  Scan Z  
	          Filter: Z.Z = X.X  
  
The eclass machinery normally expects to apply X.X = Y.Y when those  
two relations are joined, but in this shape of plan tree they aren't  
joined until the top node --- and, if the lower nested loop is marked  
as parameterized by X, the top node will assume that the relevant eclass  
condition(s) got pushed down into the lower node.  On the other hand,  
the scan of Z assumes that it's only responsible for constraining Z.Z  
to match any one of the other eclass members.  So one or another of  
the required quals sometimes fell between the cracks, depending on  
whether consideration of the eclass in get_joinrel_parampathinfo()  
for the lower nested loop chanced to generate X.X = Y.Y or X.X = Z.Z  
as the appropriate constraint there.  If it generated the latter,  
it'd erroneously suppose that the Z scan would take care of matters.  
To fix, force X.X = Y.Y to be generated and applied at that join node  
when this case occurs.  
  
This is *extremely* hard to hit in practice, because various planner  
behaviors conspire to mask the problem; starting with the fact that the  
planner doesn't really like to generate a parameterized plan of the  
above shape.  (It might have been impossible to hit it before we  
tweaked things to allow this plan shape for star-schema cases.)  Many  
thanks to Alexander Kirkouski for submitting a reproducible test case.  
  
The bug can be demonstrated in all branches back to 9.2 where parameterized  
paths were introduced, so back-patch that far.  

commit   : eac3e16741e81c478ce0716683a72e7acc520c4a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 29 Apr 2016 14:18:51 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 29 Apr 2016 14:18:51 -0400    

per gripe from Michael Paquier.  

commit   : b71b4d8528d67198c190294d16bee8df66e42eb9    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 29 Apr 2016 09:49:31 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 29 Apr 2016 09:49:31 -0400    

reported by Christian Ullrich  

commit   : da52474f3d3cbdf38d8a6677a4ebedaf402ade3a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 29 Apr 2016 07:59:47 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 29 Apr 2016 07:59:47 -0400    

Adjust the way we detect the locale. As a result the minumum Windows  
version supported by VS2015 and later is Windows Vista. Add some tweaks  
to remove new compiler warnings. Remove documentation references to the  
now obsolete msysGit.  
  
Michael Paquier, somewhat edited by me, reviewed by Christian Ullrich.  
  
Backpatch to 9.5  

commit   : 2e1b4adf39178416740efba975757e413a9fb3f9    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 28 Apr 2016 22:09:48 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 28 Apr 2016 22:09:48 -0700    

Since 5a991ef8 we're explicitly asking for feedback from the receiving  
side when shutting down walsender, if there's not yet replicated  
data.  
  
Unfortunately we didn't remember (i.e. set waiting_for_ping_response to  
true) having asked for feedback, leading to scenarios in which replies  
were requested at a high frequency.  
  
I can't reproduce this problem on my laptop, I think that's because the  
problem requires a significant TCP window to manifest due to the  
!pq_is_send_pending() condition. But since this clearly is a bug, let's  
fix it.  There's quite possibly more wrong than just this though.  
  
While fiddling with WalSndDone(), I rewrote a hard to understand comment  
about looking at the flush vs. the write position.  
  
Reported-By: Nick Cleaton, Magnus Hagander  
Author: Nick Cleaton  
Discussion: CAFgz3kus=rC_avEgBV=+hRK5HYJ8vXskJRh8yEAbahJGTzF2VQ@mail.gmail.com  
    CABUevExsjROqDcD0A2rnJ6HK6FuKGyewJr3PL12pw85BHFGS2Q@mail.gmail.com  
Backpatch: 9.4, were 5a991ef8 introduced the use of feedback messages  
    during shutdown.  

commit   : 94a16531b37628de456e082ee0d60e309607e9dd    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    

Commit 23a41573c attempted to fix the DatumGetBool macro to ignore bits  
in a Datum that are to the left of the actual bool value.  But it did that  
by casting the Datum to bool; and on compilers that use C99 semantics for  
bool, that ends up being a whole-word test, not a 1-byte test.  This seems  
to be the true explanation for contrib/seg failing in VS2015.  To fix, use  
GET_1_BYTE() explicitly.  I think in the previous patch, I'd had some idea  
of not having to commit to bool being exactly 1 byte wide, but regardless  
of what the compiler's bool is, boolean columns and Datums are certainly  
1 byte wide.  
  
The previous fix was (eventually) back-patched into all active versions,  
so do likewise with this one.  

commit   : 695718f99c4b9581fe6cc12543b69f2654a07f3b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Apr 2016 11:48:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Apr 2016 11:48:10 -0400    

This reverts commit b1dd2f86ce7d43f23f6aae307bb22de826849e7d.  
That turns out to have been based on a faulty diagnosis of why the  
VS2015 build was misbehaving.  Instead, we need to fix DatumGetBool().  

commit   : f9989482d0a24cd69f574b805db770980603a5ca    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 26 Apr 2016 21:53:58 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Tue, 26 Apr 2016 21:53:58 -0400    

pg_atomic_compare_exchange_*_impl() were providing only the semantics of  
an acquire barrier.  Buildfarm members hornet and mandrill revealed this  
deficit beginning with commit 008608b9d51061b1f598c197477b3dc7be9c4a64.  
While we have no report of symptoms in 9.5, we can't rule out the  
possibility of certain compilers, hardware, or extension code relying on  
these functions' specified barrier semantics.  Back-patch to 9.5, where  
commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340 introduced atomics.  
  
Reviewed by Andres Freund.  

commit   : 46e006d64bd7ab34655c1e870786ae3932089a08    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 24 Apr 2016 20:44:22 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 24 Apr 2016 20:44:22 -0400    

From: Andreas Seltenreich <[email protected]>  

commit   : bdf7744f7375128be4eae6a72a9c9e3c65043558    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    

NetBSD has seen fit to invent a libc function named strtoi(), which  
conflicts with the long-established static functions of the same name in  
datetime.c and ecpg's interval.c.  While muttering darkly about intrusions  
on application namespace, we'll rename our functions to avoid the conflict.  
  
Back-patch to all supported branches, since this would affect attempts  
to build any of them on recent NetBSD.  
  
Thomas Munro  

commit   : 3debaa603ffbc3927e263ae3c7c23b0fcfbd8def    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 23 Apr 2016 14:48:02 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 23 Apr 2016 14:48:02 -0400    

From: Erik Rijkers <[email protected]>  

commit   : b1dd2f86ce7d43f23f6aae307bb22de826849e7d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 22 Apr 2016 11:54:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 22 Apr 2016 11:54:23 -0400    

It appears that we can no longer get away with using V0 call convention  
for bool-returning functions in newer versions of MSVC.  The compiler  
seems to generate code that doesn't clear the higher-order bits of the  
result register, causing the bool result Datum to often read as "true"  
when "false" was intended.  This is not very surprising, since the  
function thinks it's returning a bool-width result but fmgr_oldstyle  
assumes that V0 functions return "char *"; what's surprising is that  
that hack worked for so long on so many platforms.  
  
The only functions of this description in core+contrib are in contrib/seg,  
which we'd intentionally left mostly in V0 style to serve as a warning  
canary if V0 call convention breaks.  We could imagine hacking things  
so that they're still V0 (we'd have to redeclare the bool-returning  
functions as returning some suitably wide integer type, like size_t,  
at the C level).  But on the whole it seems better to convert 'em to V1.  
We can still leave the pointer- and int-returning functions in V0 style,  
so that the test coverage isn't gone entirely.  
  
Back-patch to 9.5, since our intention is to support VS2015 in 9.5  
and later.  There's no SQL-level change in the functions' behavior  
so back-patching should be safe enough.  
  
Discussion: <[email protected]>  
  
Michael Paquier, adjusted some by me  

commit   : 409c49c64a0549c39044ed6ea845ba0fb6c6190d    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 22 Apr 2016 05:18:59 -0400    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 22 Apr 2016 05:18:59 -0400    

This was missed when VS 2013 support was added.  
  
Michael Paquier  

commit   : 81deadd317fca3f3230af2468ac29b7c36825fa3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 23:17:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 23:17:36 -0400    

The implementation of that feature involves injecting nodes into the  
raw parsetree where explicit parentheses appear.  Various places in  
parse_expr.c that test to see "is this child node of type Foo" need to  
look through such nodes, else we'll get different behavior when  
operator_precedence_warning is on than when it is off.  Note that we only  
need to handle this when testing untransformed child nodes, since the  
AEXPR_PAREN nodes will be gone anyway after transformExprRecurse.  
  
Per report from Scott Ribe and additional code-reading.  Back-patch  
to 9.5 where this feature was added.  
  
Report: <[email protected]>  

commit   : 94c685a7cb58bad13cde78ce3c39206b460d5ae6    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    

Given a left join containing a full join in its righthand side, with  
the left join's joinclause referencing only one side of the full join  
(in a non-strict fashion, so that the full join doesn't get simplified),  
the planner could fail with "failed to build any N-way joins" or related  
errors.  This happened because the full join was seen as overlapping the  
left join's RHS, and then recent changes within join_is_legal() caused  
that function to conclude that the full join couldn't validly be formed.  
Rather than try to rejigger join_is_legal() yet more to allow this,  
I think it's better to fix initsplan.c so that the required join order  
is explicit in the SpecialJoinInfo data structure.  The previous coding  
there essentially ignored full joins, relying on the fact that we don't  
flatten them in the joinlist data structure to preserve their ordering.  
That's sufficient to prevent a wrong plan from being formed, but as this  
example shows, it's not sufficient to ensure that the right plan will  
be formed.  We need to work a bit harder to ensure that the right plan  
looks sane according to the SpecialJoinInfos.  
  
Per bug #14105 from Vojtech Rylko.  This was apparently induced by  
commit 8703059c6 (though now that I've seen it, I wonder whether there  
are related cases that could have failed before that); so back-patch  
to all active branches.  Unfortunately, that patch also went into 9.0,  
so this bug is a regression that won't be fixed in that branch.  

commit   : d2e59cbc35c5e8f23148287e50e77dc3ddde8e00    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    

The coverage was rather lean for cases that bind() or listen() might  
return.  Add entries for everything that there's a direct equivalent  
for in the set of Unix errnos that elog.c has heard of.  

commit   : 575cbd48cd33328570a8c2ce7934d5d62cb4c3e6    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    

There's no longer a need for the MSVC-version-specific code stanza that  
forcibly redefines errno code symbols, because since commit 73838b52 we're  
unconditionally redefining them in the stanza before this one anyway.  
Now it's merely confusing and ugly, so get rid of it; and improve the  
comment that explains what's going on here.  
  
Although this is just cosmetic, back-patch anyway since I'm intending  
to back-patch some less-cosmetic changes in this same hunk of code.  

commit   : 20d4428f0986f2238231ee9d283e88b754876c75    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 15:44:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 15:44:18 -0400    

Fix Windows builds to report something useful rather than "could not bind  
IPv4 socket: No error" when bind() fails.  
  
Back-patch of commits d1b7d4877b9a71f4 and 22989a8e34168f57.  
  
Discussion: <[email protected]>  

commit   : 4b52cc2892b809c4a5216f15d91f95d174ca72a5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    

When we shoehorned "x op ANY (array)" into the SQL syntax, we created a  
fundamental ambiguity as to the proper treatment of a sub-SELECT on the  
righthand side: perhaps what's meant is to compare x against each row of  
the sub-SELECT's result, or perhaps the sub-SELECT is meant as a scalar  
sub-SELECT that delivers a single array value whose members should be  
compared against x.  The grammar resolves it as the former case whenever  
the RHS is a select_with_parens, making the latter case hard to reach ---  
but you can get at it, with tricks such as attaching a no-op cast to the  
sub-SELECT.  Parse analysis would throw away the no-op cast, leaving a  
parsetree with an EXPR_SUBLINK SubLink directly under a ScalarArrayOpExpr.  
ruleutils.c was not clued in on this fine point, and would naively emit  
"x op ANY ((SELECT ...))", which would be parsed as the first alternative,  
typically leading to errors like "operator does not exist: text = text[]"  
during dump/reload of a view or rule containing such a construct.  To fix,  
emit a no-op cast when dumping such a parsetree.  This might well be  
exactly what the user wrote to get the construct accepted in the first  
place; and even if she got there with some other dodge, it is a valid  
representation of the parsetree.  
  
Per report from Karl Czajkowski.  He mentioned only a case involving  
RLS policies, but actually the problem is very old, so back-patch to  
all supported branches.  
  
Report: <[email protected]>  

commit   : 0b8e0bf0ab74d2dc36437d4642b23eb8a78fdda8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    

In commit 2ffa86962077c588 we made pg_ctl recognize an environment variable  
PGCTLTIMEOUT to set the default timeout for starting and stopping the  
postmaster.  However, pg_regress uses pg_ctl only for the "stop" end of  
that; it has bespoke code for starting the postmaster, and that code has  
historically had a hard-wired 60-second timeout.  Further buildfarm  
experience says it'd be a good idea if that timeout were also controlled  
by PGCTLTIMEOUT, so let's make it so.  Like the previous patch, back-patch  
to all active branches.  
  
Discussion: <[email protected]>  

commit   : be27544569fc65b03d2a540fbebb712ab4b40407    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Apr 2016 14:25:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Apr 2016 14:25:15 -0400    

Commit 36a35c550ac114ca turned the interface between ginPlaceToPage and  
its subroutines in gindatapage.c and ginentrypage.c into a royal mess:  
page-update critical sections were started in one place and finished in  
another place not even in the same file, and the very same subroutine  
might return having started a critical section or not.  Subsequent patches  
band-aided over some of the problems with this design by making things  
even messier.  
  
One user-visible resulting problem is memory leaks caused by the need for  
the subroutines to allocate storage that would survive until ginPlaceToPage  
calls XLogInsert (as reported by Julien Rouhaud).  This would not typically  
be noticeable during retail index updates.  It could be visible in a GIN  
index build, in the form of memory consumption swelling to several times  
the commanded maintenance_work_mem.  
  
Another rather nasty problem is that in the internal-page-splitting code  
path, we would clear the child page's GIN_INCOMPLETE_SPLIT flag well before  
entering the critical section that it's supposed to be cleared in; a  
failure in between would leave the index in a corrupt state.  There were  
also assorted coding-rule violations with little immediate consequence but  
possible long-term hazards, such as beginning an XLogInsert sequence before  
entering a critical section, or calling elog(DEBUG) inside a critical  
section.  
  
To fix, redefine the API between ginPlaceToPage() and its subroutines  
by splitting the subroutines into two parts.  The "beginPlaceToPage"  
subroutine does what can be done outside a critical section, including  
full computation of the result pages into temporary storage when we're  
going to split the target page.  The "execPlaceToPage" subroutine is called  
within a critical section established by ginPlaceToPage(), and it handles  
the actual page update in the non-split code path.  The critical section,  
as well as the XLOG insertion call sequence, are both now always started  
and finished in ginPlaceToPage().  Also, make ginPlaceToPage() create and  
work in a short-lived memory context to eliminate the leakage problem.  
(Since a short-lived memory context had been getting created in the most  
common code path in the subroutines, this shouldn't cause any noticeable  
performance penalty; we're just moving the overhead up one call level.)  
  
In passing, fix a bunch of comments that had gone unmaintained throughout  
all this klugery.  
  
Report: <[email protected]>  

commit   : c6a5b6677d5f12ccf3c2373117bf630ead30b798    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Apr 2016 13:33:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Apr 2016 13:33:07 -0400    

Per discussion, there doesn't seem to be much value in having  
NUM_SPINLOCK_SEMAPHORES set to 1024: under any scenario where you are  
running more than a few backends concurrently, you really had better have a  
real spinlock implementation if you want tolerable performance.  And 1024  
semaphores is a sizable fraction of the system-wide SysV semaphore limit  
on many platforms.  Therefore, reduce this setting's default value to 128  
to make it less likely to cause out-of-semaphores problems.  

commit   : e2c183ef808466ed20c2d7877b9c10e13c897e16    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    

From: Alexander Law <[email protected]>  

commit   : 8f8e65d348af7aa6899eb722dddeb6b88c682769    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Apr 2016 12:11:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Apr 2016 12:11:27 -0400    

Careless coding added by commit 07cacba983ef79be could result in a crash  
or a bizarre error message if someone tried to select an index on the  
OID column as the replica identity index for a table.  Back-patch to 9.4  
where the feature was introduced.  
  
Discussion: CAKJS1f8TQYgTRDyF1_u9PVCKWRWz+DkieH=U7954HeHVPJKaKg@mail.gmail.com  
  
David Rowley  

commit   : edd57377f0db00a66d39029aa5239a96280887ef    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Apr 2016 00:02:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Apr 2016 00:02:26 -0400    

The code had a query-lifespan memory leak when encountering GIN entries  
that have posting lists (rather than posting trees, ie, there are a  
relatively small number of heap tuples containing this index key value).  
With a suitable data distribution this could add up to a lot of leakage.  
Problem seems to have been introduced by commit 36a35c550, so back-patch  
to 9.4.  
  
Julien Rouhaud  

commit   : 593f469a048f1479d19579a06ec32cce9ddfa190    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    

These aren't valid C89. Found thanks to gcc's -Wc90-c99-compat. These  
exist in differing places in most supported branches.  

commit   : e7a456174b2eca37b141952b6f7ef4254887f819    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 14 Apr 2016 19:42:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 14 Apr 2016 19:42:22 -0400    

When re-reading an update involving both an old tuple and a new tuple from  
disk, reorderbuffer.c was careless about whether the new tuple is suitably  
aligned for direct access --- in general, it isn't.  We'd missed seeing  
this in the buildfarm because the contrib/test_decoding tests exercise this  
code path only a few times, and by chance all of those cases have old  
tuples with length a multiple of 4, which is usually enough to make the  
access to the new tuple's t_len safe.  For some still-not-entirely-clear  
reason, however, Debian's sparc build gets a bus error, as reported by  
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?  
  
The lack of previous field reports is probably because you need all of  
these conditions to trigger a crash: an alignment-picky platform (not  
Intel), a transaction large enough to spill to disk, an update within  
that xact that changes a primary-key field and has an odd-length old tuple,  
and of course logical decoding tracing the transaction.  
  
Avoid the alignment assumption by using memcpy instead of fetching t_len  
directly, and add a test case that exposes the crash on picky platforms.  
Back-patch to 9.4 where the bug was introduced.  
  
Discussion: <[email protected]>  

commit   : ce47112b6a91a39b0dd9295c046d31dd7ec50fb8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 14 Apr 2016 12:18:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 14 Apr 2016 12:18:09 -0400    

It was declared as "pid_t", which would be fine except that none of  
the places that printed it in error messages took any thought for the  
possibility that it's not equivalent to "int".  This leads to warnings  
on some buildfarm members, and could possibly lead to actually wrong  
error messages on those platforms.  There doesn't seem to be any very  
good reason not to just make it "int"; it's only ever assigned from  
MyProcPid, which is int.  If we want to cope with PIDs that are wider  
than int, this is not the place to start.  
  
Also, fix the comment, which seems to perhaps be a leftover from a time  
when the field was only a bool?  
  
Per buildfarm.  Back-patch to 9.5 which has same issue.  

commit   : fb0f6393358519ec97623306bbfc6063426902fe    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    

As reported by Michael Feld, pg_upgrade'ing an installation having  
extensions with operator families that contain just a single operator class  
failed to reproduce the extension membership of those operator families.  
This caused no immediate ill effects, but would create problems when later  
trying to do a plain dump and restore, because the seemingly-not-part-of-  
the-extension operator families would appear separately in the pg_dump  
output, and then would conflict with the families created by loading the  
extension.  This has been broken ever since extensions were introduced,  
and many of the standard contrib extensions are affected, so it's a bit  
astonishing nobody complained before.  
  
The cause of the problem is a perhaps-ill-considered decision to omit  
such operator families from pg_dump's output on the grounds that the  
CREATE OPERATOR CLASS commands could recreate them, and having explicit  
CREATE OPERATOR FAMILY commands would impede loading the dump script into  
pre-8.3 servers.  Whatever the merits of that decision when 8.3 was being  
written, it looks like a poor tradeoff now.  We can fix the pg_upgrade  
problem simply by removing that code, so that the operator families are  
dumped explicitly (and then will be properly made to be part of their  
extensions).  
  
Although this fixes the behavior of future pg_upgrade runs, it does nothing  
to clean up existing installations that may have improperly-linked operator  
families.  Given the small number of complaints to date, maybe we don't  
need to worry about providing an automated solution for that; anyone who  
needs to clean it up can do so with manual "ALTER EXTENSION ADD OPERATOR  
FAMILY" commands, or even just ignore the duplicate-opfamily errors they  
get during a pg_restore.  In any case we need this fix.  
  
Back-patch to all supported branches.  
  
Discussion: <[email protected]>  

commit   : 079013f0b7e35f2fb14cdbe2667a1d9aac4f770e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Apr 2016 20:07:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Apr 2016 20:07:17 -0400    

When IF NOT EXISTS was added to CREATE TABLE AS, this logic didn't get  
the memo, possibly resulting in an Assert failure.  It looks like there  
would have been no ill effects in a non-Assert build, though.  Back-patch  
to 9.5 where the IF NOT EXISTS option was added.  
  
Stas Kelvich  

commit   : 8207c6baf8b42085bef442178ce8721ea726d9c7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Apr 2016 18:17:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Apr 2016 18:17:02 -0400    

It turns out that those PyErr_Clear() calls I removed from plpy_elog.c  
in 7e3bb080387f4143 et al were not quite as random as they appeared: they  
mask a Python 2.3.x bug.  (Specifically, it turns out that PyType_Ready()  
can fail if the error indicator is set on entry, and PLy_traceback's fetch  
of frame.f_code may be the first operation in a session that requires the  
"frame" type to be readied.  Ick.)  Put back the clear call, but in a more  
centralized place closer to what it's protecting, and this time with a  
comment warning what it's really for.  
  
Per buildfarm member prairiedog.  Although prairiedog was only failing  
on HEAD, it seems clearly possible for this to occur in older branches  
as well, so back-patch to 9.2 the same as the previous patch.  

commit   : ec91ee8f00af9c3960cdc3dd1ecb9e3bb7cfee86    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Apr 2016 23:15:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Apr 2016 23:15:55 -0400    

PLy_elog() could attempt to access strings that Python had already freed,  
because the strings that PLy_get_spi_error_data() returns are simply  
pointers into storage associated with the error "val" PyObject.  That's  
fine at the instant PLy_get_spi_error_data() returns them, but just after  
that PLy_traceback() intentionally releases the only refcount on that  
object, allowing it to be freed --- so that the strings we pass to  
ereport() are dangling pointers.  
  
In principle this could result in garbage output or a coredump.  In  
practice, I think the risk is pretty low, because there are no Python  
operations between where we decrement that refcount and where we use the  
strings (and copy them into PG storage), and thus no reason for Python  
to recycle the storage.  Still, it's clearly hazardous, and it leads to  
Valgrind complaints when running under a Valgrind that hasn't been  
lobotomized to ignore Python memory allocations.  
  
The code was a mess anyway: we fetched the error data out of Python  
(clearing Python's error indicator) with PyErr_Fetch, examined it, pushed  
it back into Python with PyErr_Restore (re-setting the error indicator),  
then immediately pulled it back out with another PyErr_Fetch.  Just to  
confuse matters even more, there were some gratuitous-and-yet-hazardous  
PyErr_Clear calls in the "examine" step, and we didn't get around to doing  
PyErr_NormalizeException until after the second PyErr_Fetch, making it even  
less clear which object was being manipulated where and whether we still  
had a refcount on it.  (If PyErr_NormalizeException did substitute a  
different "val" object, it's possible that the problem could manifest for  
real, because then we'd be doing assorted Python stuff with no refcount  
on the object we have string pointers into.)  
  
So, rearrange all that into some semblance of sanity, and don't decrement  
the refcount on the Python error objects until the end of PLy_elog().  
In HEAD, I failed to resist the temptation to reformat some messy bits  
from 5c3c3cd0a3046339 along the way.  
  
Back-patch as far as 9.2, because the code is substantially the same  
that far back.  I believe that 9.1 has the bug as well; but the code  
around it is rather different and I don't want to take a chance on  
breaking something for what seems a low-probability problem.  

commit   : bf73016e01f0b9eb7c9ad1916a75d1c3bf78f743    
  
author   : Teodor Sigaev <[email protected]>    
date     : Fri, 8 Apr 2016 21:25:32 +0300    
  
committer: Teodor Sigaev <[email protected]>    
date     : Fri, 8 Apr 2016 21:25:32 +0300    

Found during investigation of failure of skink buildfarm member and its  
valgrind report.  
  
Backpatch to all supported branches  

commit   : 8491679434d824bcb3a1d1713070261056683476    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    

Most of what is produced by the detailed verbosity level is of no  
interest at all, so switch to the normal level for more usable output.  
  
Christian Ullrich  
  
Backpatch to all live branches  

commit   : 0da7cf6e85f06f6dad50114a4686d73a3b794d1d    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 8 Apr 2016 12:31:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 8 Apr 2016 12:31:42 -0400    

Don't try to examine S_ISLNK(st.st_mode) after a failed lstat().  
It's undefined.  
  
Also, if the lstat() reported ENOENT, we do not wish that to be a hard  
error, but the code might nonetheless treat it as one (giving an entirely  
misleading error message, too) depending on luck-of-the-draw as to what  
S_ISLNK() returned.  
  
Don't throw error for ENOENT from rmdir(), either.  (We're not really  
expecting ENOENT because we just stat'd the file successfully; but  
if we're going to allow ENOENT in the symlink code path, surely the  
directory code path should too.)  
  
Generate an appropriate errcode for its-the-wrong-type-of-file complaints.  
(ERRCODE_SYSTEM_ERROR doesn't seem appropriate, and failing to write  
errcode() around it certainly doesn't work, and not writing an errcode  
at all is not per project policy.)  
  
Valgrind noticed the undefined S_ISLNK result; the other problems emerged  
while reading the code in the area.  
  
All of this appears to have been introduced in 8f15f74a44f68f9c.  
Back-patch to 9.5 where that commit appeared.  

commit   : 6929e7f0f481193a101aa721f6afe5e4382b696f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 5 Apr 2016 19:03:42 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 5 Apr 2016 19:03:42 -0300    

Commit b8a91d9d1c put the description of the new IF EXISTS clause in the  
wrong place -- move it where it belongs.  
  
Backpatch to 9.2.  

commit   : f3d17491c49362b78da0c1a5b0691821dcc8c435    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Apr 2016 18:05:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Apr 2016 18:05:23 -0400    

As noted by Julian Schauder in bug #14063, the configuration-file parser  
doesn't support embedded newlines in string literals.  While there might  
someday be a good reason to remove that restriction, there doesn't seem  
to be one right now.  However, ALTER SYSTEM SET could accept strings  
containing newlines, since many of the variable-specific value-checking  
routines would just see a newline as whitespace.  This led to writing a  
postgresql.auto.conf file that was broken and had to be removed manually.  
  
Pending a reason to work harder, just throw an error if someone tries this.  
  
In passing, fix several places in the ALTER SYSTEM logic that failed to  
provide an errcode() for an ereport(), and thus would falsely log the  
failure as an internal XX000 error.  
  
Back-patch to 9.4 where ALTER SYSTEM was introduced.  

commit   : 3644ac04c1ea27e596b77b7a02609b50b4742403    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Apr 2016 11:13:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Apr 2016 11:13:17 -0400    

The first iteration of the signal-checking loop would compute sigmask(0)  
which expands to 1<<(-1) which is undefined behavior according to the  
C standard.  The lack of field reports of trouble suggest that it  
evaluates to 0 on all existing Windows compilers, but that's hardly  
something to rely on.  Since signal 0 isn't a queueable signal anyway,  
we can just make the loop iterate from 1 instead, and save a few cycles  
as well as avoiding the undefined behavior.  
  
In passing, avoid evaluating the volatile expression UNBLOCKED_SIGNAL_QUEUE  
twice in a row; there's no reason to waste cycles like that.  
  
Noted by Aleksander Alekseev, though this isn't his proposed fix.  
Back-patch to all supported branches.  

commit   : c6d2fa1ab089110faee2810ef0fda1bccd4f1f6a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 30 Mar 2016 23:39:15 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 30 Mar 2016 23:39:15 -0300    

Author: Konstantin Knizhnik  

commit   : 6af513730c93ed3d7e9968bb88161cc347a2f9b1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 21:38:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 21:38:14 -0400    

The server hasn't paid attention to the TZ environment variable since  
commit ca4af308c32d03db, but that commit missed removing this documentation  
reference, as did commit d883b916a947a3c6 which added the reference where  
it now belongs (initdb).  
  
Back-patch to 9.2 where the behavior changed.  Also back-patch  
d883b916a947a3c6 as needed.  
  
Matthew Somerville  

commit   : ffd2a9eb5ede1340bd949c032ed8b7ef92b3ca09    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 29 Mar 2016 13:46:57 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 29 Mar 2016 13:46:57 -0400    

The description of what the per-transaction log file says for skipped  
transactions is just plain wrong.  
  
Report and patch by Tomas Vondra, reviewed by Fabien Coelho and  
modified by me.  

commit   : 491e847380740dac54d4ecae820261bbaa8aee44    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 11:54:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 11:54:57 -0400    

Whenever this function is used with the FORMAT_MESSAGE_FROM_SYSTEM flag,  
it's good practice to include FORMAT_MESSAGE_IGNORE_INSERTS as well.  
Otherwise, if the message contains any %n insertion markers, the function  
will try to fetch argument strings to substitute --- which we are not  
passing, possibly leading to a crash.  This is exactly analogous to the  
rule about not giving printf() a format string you're not in control of.  
  
Noted and patched by Christian Ullrich.  
Back-patch to all supported branches.  

commit   : 978894a41f335ccd21140c559ecdc22f42d2f142    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 28 Mar 2016 19:11:12 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 28 Mar 2016 19:11:12 -0300    

Documentation mentioned B-tree, GiST and GIN as able to do multicolumn  
indexes; I failed to add BRIN to the list.  
  
Author: Petr Jediný  
Reviewed-By: Fujii Masao, Emre Hasegeli