PostgreSQL 9.0.20 commit log

Last-minute updates for release notes.

  
commit   : 760e7ad47959acc3908d3824a20e784f6aed9001    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2015 18:33:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2015 18:33:58 -0400    

Click here for diff

  
Revise description of CVE-2015-3166, in line with scaled-back patch.  
Change release date.  
  
Security: CVE-2015-3166  
  

Revert error-throwing wrappers for the printf family of functions.

  
commit   : cf893530aff6d3acb893e0fbd80fd9d814605b74    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2015 18:18:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2015 18:18:56 -0400    

Click here for diff

  
This reverts commit 16304a013432931e61e623c8d85e9fe24709d9ba, except  
for its changes in src/port/snprintf.c; as well as commit  
cac18a76bb6b08f1ecc2a85e46c9d2ab82dd9d23 which is no longer needed.  
  
Fujii Masao reported that the previous commit caused failures in psql on  
OS X, since if one exits the pager program early while viewing a query  
result, psql sees an EPIPE error from fprintf --- and the wrapper function  
thought that was reason to panic.  (It's a bit surprising that the same  
does not happen on Linux.)  Further discussion among the security list  
concluded that the risk of other such failures was far too great, and  
that the one-size-fits-all approach to error handling embodied in the  
previous patch is unlikely to be workable.  
  
This leaves us again exposed to the possibility of the type of failure  
envisioned in CVE-2015-3166.  However, that failure mode is strictly  
hypothetical at this point: there is no concrete reason to believe that  
an attacker could trigger information disclosure through the supposed  
mechanism.  In the first place, the attack surface is fairly limited,  
since so much of what the backend does with format strings goes through  
stringinfo.c or psprintf(), and those already had adequate defenses.  
In the second place, even granting that an unprivileged attacker could  
control the occurrence of ENOMEM with some precision, it's a stretch to  
believe that he could induce it just where the target buffer contains some  
valuable information.  So we concluded that the risk of non-hypothetical  
problems induced by the patch greatly outweighs the security risks.  
We will therefore revert, and instead undertake closer analysis to  
identify specific calls that may need hardening, rather than attempt a  
universal solution.  
  
We have kept the portion of the previous patch that improved snprintf.c's  
handling of errors when it calls the platform's sprintf().  That seems to  
be an unalloyed improvement.  
  
Security: CVE-2015-3166  
  

Fix off-by-one error in Assertion.

  
commit   : 59cc2f58e6cd7bb247cb7b92eb460df0d06fab07    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 19 May 2015 19:21:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 19 May 2015 19:21:46 +0300    

Click here for diff

  
The point of the assertion is to ensure that the arrays allocated in stack  
are large enough, but the check was one item short.  
  
This won't matter in practice because MaxIndexTuplesPerPage is an  
overestimate, so you can't have that many items on a page in reality.  
But let's be tidy.  
  
Spotted by Anastasia Lubennikova. Backpatch to all supported versions, like  
the patch that added the assertion.  
  

Don’t MultiXactIdIsRunning when in recovery

  
commit   : 850e1a566eb68b32df240c49843ac498603a11c8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 May 2015 17:44:21 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 May 2015 17:44:21 -0300    

Click here for diff

  
In 9.1 and earlier, it is possible for index_getnext() to try to examine  
a heap buffer for possible HOT-prune when in recovery; this causes a  
problem when a multixact is found in a tuple's Xmax, because  
GetMultiXactIdMembers refuses to run when in recovery, raising an error:  
	ERROR:  cannot GetMultiXactIdMembers() during recovery  
  
This can be solved easily by having MultiXactIdIsRunning always return  
false when in recovery, which is reasonable because a HOT standby cannot  
acquire further tuple locks nor update/delete tuples.  
  
(Note: it doesn't look like this specific code path has a problem in  
9.2, because instead of doing HeapTupleSatisfiesUpdate directly,  
heap_hot_search_buffer uses HeapTupleIsSurelyDead instead.  Still, there  
may be other paths affected by the same bug, for instance in pgrowlocks,  
and the multixact code hasn't changed; so apply the same fix  
throughout.)  
  
Apply this fix to 9.0 through 9.2.  In 9.3 the multixact code has been  
changed completely and is no longer subject to this problem.  
  
Per report from Marko Tiikkaja,  
https://www.postgresql.org/message-id/54EB3283.2080305@joh.to  
Analysis by Andres Freund  
  

Stamp 9.0.20.

  
commit   : 730912f9a3111ead7200756eca14fedf44a449e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2015 14:38:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2015 14:38:36 -0400    

Click here for diff

  
  

Fix error message in pre_sync_fname.

  
commit   : 89c8fb65b22346f64849a719aea79a4f817193f0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 18 May 2015 12:53:09 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 18 May 2015 12:53:09 -0400    

Click here for diff

  
The old one didn't include %m anywhere, and required extra  
translation.  
  
Report by Peter Eisentraut. Fix by me. Review by Tom Lane.  
  

Last-minute updates for release notes.

  
commit   : e369bbb3894ecc7b6074b7999909cd34b831ab12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2015 12:09:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2015 12:09:03 -0400    

Click here for diff

  
Add entries for security issues.  
  
Security: CVE-2015-3165 through CVE-2015-3167  
  

pgcrypto: Report errant decryption as “Wrong key or corrupt data”.

  
commit   : b84e5c017cca6a5f259899f525b077497d35da47    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    

Click here for diff

  
This has been the predominant outcome.  When the output of decrypting  
with a wrong key coincidentally resembled an OpenPGP packet header,  
pgcrypto could instead report "Corrupt data", "Not text data" or  
"Unsupported compression algorithm".  The distinct "Corrupt data"  
message added no value.  The latter two error messages misled when the  
decrypted payload also exhibited fundamental integrity problems.  Worse,  
error message variance in other systems has enabled cryptologic attacks;  
see RFC 4880 section "14. Security Considerations".  Whether these  
pgcrypto behaviors are likewise exploitable is unknown.  
  
In passing, document that pgcrypto does not resist side-channel attacks.  
Back-patch to 9.0 (all supported versions).  
  
Security: CVE-2015-3167  
  

Check return values of sensitive system library calls.

  
commit   : 9b5e831e342d14caeebece6c705616f10880b00d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    

Click here for diff

  
PostgreSQL already checked the vast majority of these, missing this  
handful that nearly cannot fail.  If putenv() failed with ENOMEM in  
pg_GSS_recvauth(), authentication would proceed with the wrong keytab  
file.  If strftime() returned zero in cache_locale_time(), using the  
unspecified buffer contents could lead to information exposure or a  
crash.  Back-patch to 9.0 (all supported versions).  
  
Other unchecked calls to these functions, especially those in frontend  
code, pose negligible security concern.  This patch does not address  
them.  Nonetheless, it is always better to check return values whose  
specification provides for indicating an error.  
  
In passing, fix an off-by-one error in strftime_win32()'s invocation of  
WideCharToMultiByte().  Upon retrieving a value of exactly MAX_L10N_DATA  
bytes, strftime_win32() would overrun the caller's buffer by one byte.  
MAX_L10N_DATA is chosen to exceed the length of every possible value, so  
the vulnerable scenario probably does not arise.  
  
Security: CVE-2015-3166  
  

Add error-throwing wrappers for the printf family of functions.

  
commit   : b08c7aff708b403298f8e006cce0e1e82349e88e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    

Click here for diff

  
All known standard library implementations of these functions can fail  
with ENOMEM.  A caller neglecting to check for failure would experience  
missing output, information exposure, or a crash.  Check return values  
within wrappers and code, currently just snprintf.c, that bypasses the  
wrappers.  The wrappers do not return after an error, so their callers  
need not check.  Back-patch to 9.0 (all supported versions).  
  
Popular free software standard library implementations do take pains to  
bypass malloc() in simple cases, but they risk ENOMEM for floating point  
numbers, positional arguments, large field widths, and large precisions.  
No specification demands such caution, so this commit regards every call  
to a printf family function as a potential threat.  
  
Injecting the wrappers implicitly is a compromise between patch scope  
and design goals.  I would prefer to edit each call site to name a  
wrapper explicitly.  libpq and the ECPG libraries would, ideally, convey  
errors to the caller rather than abort().  All that would be painfully  
invasive for a back-patched security fix, hence this compromise.  
  
Security: CVE-2015-3166  
  

Permit use of vsprintf() in PostgreSQL code.

  
commit   : 19f7adc0137fdd1fb20f1e59d4ced1ac19b67ecf    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    

Click here for diff

  
The next commit needs it.  Back-patch to 9.0 (all supported versions).  
  

Prevent a double free by not reentering be_tls_close().

  
commit   : 648e41a6e480dae85a5aa0c90e36487c7f09a229    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 May 2015 10:02:31 -0400    

Click here for diff

  
Reentering this function with the right timing caused a double free,  
typically crashing the backend.  By synchronizing a disconnection with  
the authentication timeout, an unauthenticated attacker could achieve  
this somewhat consistently.  Call be_tls_close() solely from within  
proc_exit_prepare().  Back-patch to 9.0 (all supported versions).  
  
Benkocs Norbert Attila  
  
Security: CVE-2015-3165  
  

Translation updates

  
commit   : 69cb7b977bfddcdf7e14b93c550fa810eca4876b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 May 2015 08:53:30 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 May 2015 08:53:30 -0400    

Click here for diff

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

Fix typos

  
commit   : bebf0c1bec8b899223883d70031a1f32ec42cf91    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 May 2015 22:21:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 May 2015 22:21:36 -0400    

Click here for diff

  
  

Release notes for 9.4.2, 9.3.7, 9.2.11, 9.1.16, 9.0.20.

  
commit   : 80dc760ba1c929dcfc12aa2c77be9a1b41a16925    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 May 2015 15:54:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 May 2015 15:54:20 -0400    

Click here for diff

  
  

Fix docs typo

  
commit   : 725d7ca165869463b1c6c9d6a40b678f2c5c9070    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2015 13:28:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2015 13:28:27 -0400    

Click here for diff

  
I don't think "respectfully" is what was meant here ...  
  

pg_upgrade: force timeline 1 in the new cluster

  
commit   : df161c94e7e0db33557fb4f19b111729b7dc4fb9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 May 2015 00:40:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 May 2015 00:40:18 -0400    

Click here for diff

  
Previously, this prevented promoted standby servers from being upgraded  
because of a missing WAL history file.  (Timeline 1 doesn't need a  
history file, and we don't copy WAL files anyway.)  
  
Report by Christian Echerer(?), Alexey Klyukin  
  
Backpatch through 9.0  
  

pg_upgrade: only allow template0 to be non-connectable

  
commit   : 2194aa92b7a65561c109875d8b904198c3cd0743    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 May 2015 00:10:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 16 May 2015 00:10:03 -0400    

Click here for diff

  
This patch causes pg_upgrade to error out during its check phase if:  
  
(1) template0 is marked connectable  
or  
(2) any other database is marked non-connectable  
  
This is done because, in the first case, pg_upgrade would fail because  
the pg_dumpall --globals restore would fail, and in the second case, the  
database would not be restored, leading to data loss.  
  
Report by Matt Landry (1), Stephen Frost (2)  
  
Backpatch through 9.0  
  

Update time zone data files to tzdata release 2015d.

  
commit   : 3c3749a3bf79dce21384a04981c34a6c8ec1780a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2015 19:35:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2015 19:35:29 -0400    

Click here for diff

  
DST law changes in Egypt, Mongolia, Palestine.  
Historical corrections for Canada and Chile.  
Revised zone abbreviation for America/Adak (HST/HDT not HAST/HADT).  
  

Docs: fix erroneous claim about max byte length of GB18030.

  
commit   : af4a9c19c23acddeb139bbedafeb90d987fb91bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2015 14:59:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2015 14:59:00 -0400    

Click here for diff

  
This encoding has characters up to 4 bytes long, not 2.  
  

Fix RBM_ZERO_AND_LOCK mode to not acquire lock on local buffers.

  
commit   : bd1cfde70e0f6165cd794488e88a57df9c233b43    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 13 May 2015 09:44:43 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 13 May 2015 09:44:43 +0300    

Click here for diff

  
Commit 81c45081 introduced a new RBM_ZERO_AND_LOCK mode to ReadBuffer, which  
takes a lock on the buffer before zeroing it. However, you cannot take a  
lock on a local buffer, and you got a segfault instead. The version of that  
patch committed to master included a check for !isLocalBuf, and therefore  
didn't crash, but oddly I missed that in the back-patched versions. This  
patch adds that check to the back-branches too.  
  
RBM_ZERO_AND_LOCK mode is only used during WAL replay, and in hash indexes.  
WAL replay only deals with shared buffers, so the only way to trigger the  
bug is with a temporary hash index.  
  
Reported by Artem Ignatyev, analysis by Tom Lane.  
  

Fix incorrect checking of deferred exclusion constraint after a HOT update.

  
commit   : b93c8eaf8c35485175358c552cd5adce0e197ec9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2015 12:25:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2015 12:25:28 -0400    

Click here for diff

  
If a row that potentially violates a deferred exclusion constraint is  
HOT-updated later in the same transaction, the exclusion constraint would  
be reported as violated when the check finally occurs, even if the row(s)  
the new row originally conflicted with have since been removed.  This  
happened because the wrong TID was passed to check_exclusion_constraint(),  
causing the live HOT-updated row to be seen as a conflicting row rather  
than recognized as the row-under-test.  
  
Per bug #13148 from Evan Martin.  It's been broken since exclusion  
constraints were invented, so back-patch to all supported branches.  
  

Recommend include_realm=1 in docs

  
commit   : c981e599916c828fe3fe2e7c3cf92949f81ebcd3    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 May 2015 19:39:52 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 May 2015 19:39:52 -0400    

Click here for diff

  
As discussed, the default setting of include_realm=0 can be dangerous in  
multi-realm environments because it is then impossible to differentiate  
users with the same username but who are from two different realms.  
  
Recommend include_realm=1 and note that the default setting may change  
in a future version of PostgreSQL and therefore users may wish to  
explicitly set include_realm to avoid issues while upgrading.  
  

Properly send SCM status updates when shutting down service on Windows

  
commit   : 78ce2dc8ee5dc393a2b2806bef922215e82d9db7    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 7 May 2015 15:04:13 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 7 May 2015 15:04:13 +0200    

Click here for diff

  
The Service Control Manager should be notified regularly during a shutdown  
that takes a long time. Previously we would increaes the counter, but forgot  
to actually send the notification to the system. The loop counter was also  
incorrectly initalized in the event that the startup of the system took long  
enough for it to increase, which could cause the shutdown process not to wait  
as long as expected.  
  
Krystian Bigaj, reviewed by Michael Paquier  
  

  
commit   : ba7bee837ec1cee4809cdbaeba2104be37dee5dc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 May 2015 15:54:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 May 2015 15:54:26 -0400    

Click here for diff

  
The patch to recurseively fsync pgdata needs this, but it was only  
introduced in 9.1.  
  

Fix some problems with patch to fsync the data directory.

  
commit   : 262fbcb9dd4a357a8b8147b6ac217b41e905be3a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 May 2015 08:30:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 May 2015 08:30:28 -0400    

Click here for diff

  
pg_win32_is_junction() was a typo for pgwin32_is_junction().  open()  
was used not only in a two-argument form, which breaks on Windows,  
but also where BasicOpenFile() should have been used.  
  
Per reports from Andrew Dunstan and David Rowley.  
  

Recursively fsync() the data directory after a crash.

  
commit   : 30ba0d0c21a825bc9c0565ea331be98068536b0e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 4 May 2015 12:06:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 4 May 2015 12:06:53 -0400    

Click here for diff

  
Otherwise, if there's another crash, some writes from after the first  
crash might make it to disk while writes from before the crash fail  
to make it to disk.  This could lead to data corruption.  
  
Back-patch to all supported versions.  
  
Abhijit Menon-Sen, reviewed by Andres Freund and slightly revised  
by me.  
  

Backport “Expose fsync_fname as a public API”.

  
commit   : f1d7516770739e1af5cf517c01aa3bfa7b02b86b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 4 May 2015 12:52:29 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 4 May 2015 12:52:29 -0400    

Click here for diff

  
Backport commit b0a48e996bd7ff336ea26344d3d97ad32b22a61a back to 9.0  
to allow back-patching another fix that uses fsync_fname.  
  

Build libecpg with -DFRONTEND in all supported versions.

  
commit   : e8837fc93ec053b18d4421a991f3230288e039bb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 26 Apr 2015 17:20:10 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 26 Apr 2015 17:20:10 -0400    

Click here for diff

  
Fix an oversight in commit 151e74719b0cc5c040bd3191b51b95f925773dd1 by  
back-patching commit 44c5d387eafb4ba1a032f8d7b13d85c553d69181 to 9.0.  
  

Prevent improper reordering of antijoins vs. outer joins.

  
commit   : 985da346ec740caf73ed1aefa9209cb4c3167c7e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Apr 2015 16:44:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Apr 2015 16:44:27 -0400    

Click here for diff

  
An outer join appearing within the RHS of an antijoin can't commute with  
the antijoin, but somehow I missed teaching make_outerjoininfo() about  
that.  In Teodor Sigaev's recent trouble report, this manifests as a  
"could not find RelOptInfo for given relids" error within eqjoinsel();  
but I think silently wrong query results are possible too, if the planner  
misorders the joins and doesn't happen to trigger any internal consistency  
checks.  It's broken as far back as we had antijoins, so back-patch to all  
supported branches.  
  

Build every ECPG library with -DFRONTEND.

  
commit   : 3f27ec4ee37d584a8e59741bb3f588804508f3cd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 24 Apr 2015 19:29:02 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 24 Apr 2015 19:29:02 -0400    

Click here for diff

  
Each of the libraries incorporates src/port files, which often check  
FRONTEND.  Build systems disagreed on whether to build libpgtypes this  
way.  Only libecpg incorporates files that rely on it today.  Back-patch  
to 9.0 (all supported versions) to forestall surprises.  
  

Fix deadlock at startup, if max_prepared_transactions is too small.

  
commit   : 223a946804aafeefc6cb26de276776eec576547d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Apr 2015 21:25:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Apr 2015 21:25:44 +0300    

Click here for diff

  
When the startup process recovers transactions by scanning pg_twophase  
directory, it should clear MyLockedGxact after it's done processing each  
transaction. Like we do during normal operation, at PREPARE TRANSACTION.  
Otherwise, if the startup process exits due to an error, it will try to  
clear the locking_backend field of the last recovered transaction. That's  
usually harmless, but if the error happens in MarkAsPreparing, while  
holding TwoPhaseStateLock, the shmem-exit hook will try to acquire  
TwoPhaseStateLock again, and deadlock with itself.  
  
This fixes bug #13128 reported by Grant McAlister. The bug was introduced  
by commit bb38fb0d, so backpatch to all supported versions like that  
commit.  
  

Fix typo in comment

  
commit   : 5feebfed83fe463035ce64e6c2b10c2319842ff8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 14 Apr 2015 12:12:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 14 Apr 2015 12:12:18 -0300    

Click here for diff

  
SLRU_SEGMENTS_PER_PAGE -> SLRU_PAGES_PER_SEGMENT  
  
I introduced this ancient typo in subtrans.c and later propagated it to  
multixact.c.  I fixed the latter in f741300c, but only back to 9.3;  
backpatch to all supported branches for consistency.  
  

Don’t archive bogus recycled or preallocated files after timeline switch.

  
commit   : 5b6938186a4a9608bd278409c2c3ee5afe6ad0c8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 13 Apr 2015 16:53:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 13 Apr 2015 16:53:49 +0300    

Click here for diff

  
After a timeline switch, we would leave behind recycled WAL segments that  
are in the future, but on the old timeline. After promotion, and after they  
become old enough to be recycled again, we would notice that they don't have  
a .ready or .done file, create a .ready file for them, and archive them.  
That's bogus, because the files contain garbage, recycled from an older  
timeline (or prealloced as zeros). We shouldn't archive such files.  
  
This could happen when we're following a timeline switch during replay, or  
when we switch to new timeline at end-of-recovery.  
  
To fix, whenever we switch to a new timeline, scan the data directory for  
WAL segments on the old timeline, but with a higher segment number, and  
remove them. Those don't belong to our timeline history, and are most  
likely bogus recycled or preallocated files. They could also be valid files  
that we streamed from the primary ahead of time, but in any case, they're  
not needed to recover to the new timeline.  
  

Fix autovacuum launcher shutdown sequence

  
commit   : 595bc97b5eb3c73111f3da0c0474d81efb0f43d0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Apr 2015 13:19:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Apr 2015 13:19:49 -0300    

Click here for diff

  
It was previously possible to have the launcher re-execute its main loop  
before shutting down if some other signal was received or an error  
occurred after getting SIGTERM, as reported by Qingqing Zhou.  
  
While investigating, Tom Lane further noticed that if autovacuum had  
been disabled in the config file, it would misbehave by trying to start  
a new worker instead of bailing out immediately -- it would consider  
itself as invoked in emergency mode.  
  
Fix both problems by checking the shutdown flag in a few more places.  
These problems have existed since autovacuum was introduced, so  
backpatch all the way back.  
  

Fix assorted inconsistent function declarations.

  
commit   : 248c096b265d1169a45f91c99fcc74b34544f290    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2015 16:56:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2015 16:56:21 -0400    

Click here for diff

  
While gcc doesn't complain if you declare a function "static" and then  
define it not-static, other compilers do; and in any case the code is  
highly misleading this way.  Add the missing "static" keywords to a  
couple of recent patches.  Per buildfarm member pademelon.  
  

Fix typo in libpq.sgml.

  
commit   : ceb5eb5dff6281f6a44525037cd4106af177470b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Apr 2015 12:15:20 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Apr 2015 12:15:20 +0900    

Click here for diff

  
Back-patch to all supported versions.  
  
Michael Paquier  
  

Fix incorrect matching of subexpressions in outer-join plan nodes.

  
commit   : da88191945c49159d2f6354f75d5cdc2ba5d36d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Apr 2015 19:55:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Apr 2015 19:55:15 -0400    

Click here for diff

  
Previously we would re-use input subexpressions in all expression trees  
attached to a Join plan node.  However, if it's an outer join and the  
subexpression appears in the nullable-side input, this is potentially  
incorrect for apparently-matching subexpressions that came from above  
the outer join (ie, targetlist and qpqual expressions), because the  
executor will treat the subexpression value as NULL when maybe it should  
not be.  
  
The case is fairly hard to hit because (a) you need a non-strict  
subexpression (else NULL is correct), and (b) we don't usually compute  
expressions in the outputs of non-toplevel plan nodes.  But we might do  
so if the expressions are sort keys for a mergejoin, for example.  
  
Probably in the long run we should make a more explicit distinction between  
Vars appearing above and below an outer join, but that will be a major  
planner redesign and not at all back-patchable.  For the moment, just hack  
set_join_references so that it will not match any non-Var expressions  
coming from nullable inputs to expressions that came from above the join.  
(This is somewhat overkill, in that a strict expression could still be  
matched, but it doesn't seem worth the effort to check that.)  
  
Per report from Qingqing Zhou.  The added regression test case is based  
on his example.  
  
This has been broken for a very long time, so back-patch to all active  
branches.  
  

Remove unnecessary variables in _hash_splitbucket().

  
commit   : 645081427d52bdfa88b79d886df2cbab5c72d406    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2015 16:49:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2015 16:49:12 -0400    

Click here for diff

  
Commit ed9cc2b5df59fdbc50cce37399e26b03ab2c1686 made it unnecessary to pass  
start_nblkno to _hash_splitbucket(), and for that matter unnecessary to  
have the internal nblkno variable either.  My compiler didn't complain  
about that, but some did.  I also rearranged the use of oblkno a bit to  
make that case more parallel.  
  
Report and initial patch by Petr Jelinek, rearranged a bit by me.  
Back-patch to all branches, like the previous patch.  
  

psql: fix \connect with URIs and conninfo strings

  
commit   : 557fcfae3f1532d9f4c77ea36720477e535e86bb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 1 Apr 2015 20:00:07 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 1 Apr 2015 20:00:07 -0300    

Click here for diff

  
psql was already accepting conninfo strings as the first parameter in  
\connect, but the way it worked wasn't sane; some of the other  
parameters would get the previous connection's values, causing it to  
connect to a completely unexpected server or, more likely, not finding  
any server at all because of completely wrong combinations of  
parameters.  
  
Fix by explicitely checking for a conninfo-looking parameter in the  
dbname position; if one is found, use its complete specification rather  
than mix with the other arguments.  Also, change tab-completion to not  
try to complete conninfo/URI-looking "dbnames" and document that  
conninfos are accepted as first argument.  
  
There was a weak consensus to backpatch this, because while the behavior  
of using the dbname as a conninfo is nowhere documented for \connect, it  
is reasonable to expect that it works because it does work in many other  
contexts.  Therefore this is backpatched all the way back to 9.0.  
  
To implement this, routines previously private to libpq have been  
duplicated so that psql can decide what looks like a conninfo/URI  
string.  In back branches, just duplicate the same code all the way back  
to 9.2, where URIs where introduced; 9.0 and 9.1 have a simpler version.  
In master, the routines are moved to src/common and renamed.  
  
Author: David Fetter, Andrew Dunstan.  Some editorialization by me  
(probably earning a Gierth's "Sloppy" badge in the process.)  
Reviewers: Andrew Gierth, Erik Rijkers, Pavel Stěhule, Stephen Frost,  
Robert Haas, Andrew Dunstan.  
  

Fix incorrect markup in documentation of window frame clauses.

  
commit   : 2eb59adcf215d7d4fa232342d282f81901a70735    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2015 20:02:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2015 20:02:40 -0400    

Click here for diff

  
You're required to write either RANGE or ROWS to start a frame clause,  
but the documentation incorrectly implied this is optional.  Noted by  
David Johnston.  
  

Remove spurious semicolons.

  
commit   : 6bd7e30465ea2eac5c786f7003480e685712df76    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 31 Mar 2015 15:12:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 31 Mar 2015 15:12:27 +0300    

Click here for diff

  
Petr Jelinek  
  

Run pg_upgrade and pg_resetxlog with restricted token on Windows

  
commit   : bf22a8e5854a4d3a190d2639d508a7827645a0c4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Mar 2015 17:18:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Mar 2015 17:18:10 -0400    

Click here for diff

  
As with initdb these programs need to run with a restricted token, and  
if they don't pg_upgrade will fail when run as a user with Adminstrator  
privileges.  
  
Backpatch to all live branches. On the development branch the code is  
reorganized so that the restricted token code is now in a single  
location. On the stable bramches a less invasive change is made by  
simply copying the relevant code to pg_upgrade.c and pg_resetxlog.c.  
  
Patches and bug report from Muhammad Asif Naeem, reviewed by Michael  
Paquier, slightly edited by me.  
  

Fix bogus concurrent use of _hash_getnewbuf() in bucket split code.

  
commit   : 8f3c577212017c32d93e2558bd1c83fcf08b1dba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2015 16:40:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2015 16:40:05 -0400    

Click here for diff

  
_hash_splitbucket() obtained the base page of the new bucket by calling  
_hash_getnewbuf(), but it held no exclusive lock that would prevent some  
other process from calling _hash_getnewbuf() at the same time.  This is  
contrary to _hash_getnewbuf()'s API spec and could in fact cause failures.  
In practice, we must only call that function while holding write lock on  
the hash index's metapage.  
  
An additional problem was that we'd already modified the metapage's bucket  
mapping data, meaning that failure to extend the index would leave us with  
a corrupt index.  
  
Fix both issues by moving the _hash_getnewbuf() call to just before we  
modify the metapage in _hash_expandtable().  
  
Unfortunately there's still a large problem here, which is that we could  
also incur ENOSPC while trying to get an overflow page for the new bucket.  
That would leave the index corrupt in a more subtle way, namely that some  
index tuples that should be in the new bucket might still be in the old  
one.  Fixing that seems substantially more difficult; even preallocating as  
many pages as we could possibly need wouldn't entirely guarantee that the  
bucket split would complete successfully.  So for today let's just deal  
with the base case.  
  
Per report from Antonin Houska.  Back-patch to all active branches.  
  

Add vacuum_delay_point call in compute_index_stats’s per-sample-row loop.

  
commit   : 152c94632f1ece90fccc87ff1fabe809a89e3024    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Mar 2015 15:04:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Mar 2015 15:04:09 -0400    

Click here for diff

  
Slow functions in index expressions might cause this loop to take long  
enough to make it worth being cancellable.  Probably it would be enough  
to call CHECK_FOR_INTERRUPTS here, but for consistency with other  
per-sample-row loops in this file, let's use vacuum_delay_point.  
  
Report and patch by Jeff Janes.  Back-patch to all supported branches.  
  

Fix ExecOpenScanRelation to take a lock on a ROW_MARK_COPY relation.

  
commit   : 6997f226f5de7e02b6afd2d8ff67cf40f20e878b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2015 15:53:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2015 15:53:06 -0400    

Click here for diff

  
ExecOpenScanRelation assumed that any relation listed in the ExecRowMark  
list has been locked by InitPlan; but this is not true if the rel's  
markType is ROW_MARK_COPY, which is possible if it's a foreign table.  
  
In most (possibly all) cases, failure to acquire a lock here isn't really  
problematic because the parser, planner, or plancache would have taken the  
appropriate lock already.  In principle though it might leave us vulnerable  
to working with a relation that we hold no lock on, and in any case if the  
executor isn't depending on previously-taken locks otherwise then it should  
not do so for ROW_MARK_COPY relations.  
  
Noted by Etsuro Fujita.  Back-patch to all active versions, since the  
inconsistency has been there a long time.  (It's almost certainly  
irrelevant in 9.0, since that predates foreign tables, but the code's  
still wrong on its own terms.)  
  

Replace insertion sort in contrib/intarray with qsort().

  
commit   : 40b0c10b763dfe4d6b171a58a2bd49cc3f880087    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Mar 2015 23:22:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Mar 2015 23:22:03 -0400    

Click here for diff

  
It's all very well to claim that a simplistic sort is fast in easy  
cases, but O(N^2) in the worst case is not good ... especially if the  
worst case is as easy to hit as "descending order input".  Replace that  
bit with our standard qsort.  
  
Per bug #12866 from Maksym Boguk.  Back-patch to all active branches.  
  

Remove workaround for ancient incompatibility between readline and libedit.

  
commit   : 396ef6fd8de2222cb8151e0da8710fd42514e5c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Mar 2015 13:43:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Mar 2015 13:43:00 -0400    

Click here for diff

  
GNU readline defines the return value of write_history() as "zero if OK,  
else an errno code".  libedit's version of that function used to have a  
different definition (to wit, "-1 if error, else the number of lines  
written to the file").  We tried to work around that by checking whether  
errno had become nonzero, but this method has never been kosher according  
to the published API of either library.  It's reportedly completely broken  
in recent Ubuntu releases: psql bleats about "No such file or directory"  
when saving ~/.psql_history, even though the write worked fine.  
  
However, libedit has been following the readline definition since somewhere  
around 2006, so it seems all right to finally break compatibility with  
ancient libedit releases and trust that the return value is what readline  
specifies.  (I'm not sure when the various Linux distributions incorporated  
this fix, but I did find that OS X has been shipping fixed versions since  
10.5/Leopard.)  
  
If anyone is still using such an ancient libedit, they will find that psql  
complains it can't write ~/.psql_history at exit, even when the file was  
written correctly.  This is no worse than the behavior we're fixing for  
current releases.  
  
Back-patch to all supported branches.  
  

Fix documentation for libpq’s PQfn().

  
commit   : a07bd32f2b130a67bf285f8ef5f1fe4ebcc3a5b8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Mar 2015 13:35:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Mar 2015 13:35:28 -0400    

Click here for diff

  
The SGML docs claimed that 1-byte integers could be sent or received with  
the "isint" options, but no such behavior has ever been implemented in  
pqGetInt() or pqPutInt().  The in-code documentation header for PQfn() was  
even less in tune with reality, and the code itself used parameter names  
matching neither the SGML docs nor its libpq-fe.h declaration.  Do a bit  
of additional wordsmithing on the SGML docs while at it.  
  
Since the business about 1-byte integers is a clear documentation bug,  
back-patch to all supported branches.  
  

Fix user mapping object description

  
commit   : 71b8e8e6cf12fb550977c4debbef036f90a94734    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Mar 2015 18:03:16 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Mar 2015 18:03:16 -0300    

Click here for diff

  
We were using "user mapping for user XYZ" as description for user mappings, but  
that's ambiguous because users can have mappings on multiple foreign  
servers; therefore change it to "for user XYZ on server UVW" instead.  
Object identities for user mappings are also updated in the same way, in  
branches 9.3 and above.  
  
The incomplete description string was introduced together with the whole  
SQL/MED infrastructure by commit cae565e503 of 8.4 era, so backpatch all  
the way back.  
  

  
commit   : 6b61b641163a0cfea00360a357c1ff0aabfc1535    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 1 Mar 2015 13:05:23 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 1 Mar 2015 13:05:23 -0500    

Click here for diff

  
When the library already exists in the build directory, "ar" preserves  
members not named on its command line.  This mattered when, for example,  
a "configure" rerun dropped a file from $(LIBOBJS).  libpgport carried  
the obsolete member until "make clean".  Back-patch to 9.0 (all  
supported versions).  
  

Reconsider when to wait for WAL flushes/syncrep during commit.

  
commit   : 82e0d6eb519e2b35340c0195cfb3806f3663406a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 26 Feb 2015 12:50:08 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 26 Feb 2015 12:50:08 +0100    

Click here for diff

  
Up to now RecordTransactionCommit() waited for WAL to be flushed (if  
synchronous_commit != off) and to be synchronously replicated (if  
enabled), even if a transaction did not have a xid assigned. The primary  
reason for that is that sequence's nextval() did not assign a xid, but  
are worthwhile to wait for on commit.  
  
This can be problematic because sometimes read only transactions do  
write WAL, e.g. HOT page prune records. That then could lead to read only  
transactions having to wait during commit. Not something people expect  
in a read only transaction.  
  
This lead to such strange symptoms as backends being seemingly stuck  
during connection establishment when all synchronous replicas are  
down. Especially annoying when said stuck connection is the standby  
trying to reconnect to allow syncrep again...  
  
This behavior also is involved in a rather complicated <= 9.4 bug where  
the transaction started by catchup interrupt processing waited for  
syncrep using latches, but didn't get the wakeup because it was already  
running inside the same overloaded signal handler. Fix the issue here  
doesn't properly solve that issue, merely papers over the problems. In  
9.5 catchup interrupts aren't processed out of signal handlers anymore.  
  
To fix all this, make nextval() acquire a top level xid, and only wait for  
transaction commit if a transaction both acquired a xid and emitted WAL  
records.  If only a xid has been assigned we don't uselessly want to  
wait just because of writes to temporary/unlogged tables; if only WAL  
has been written we don't want to wait just because of HOT prunes.  
  
The xid assignment in nextval() is unlikely to cause overhead in  
real-world workloads. For one it only happens SEQ_LOG_VALS/32 values  
anyway, for another only usage of nextval() without using the result in  
an insert or similar is affected.  
  
Discussion: 20150223165359.GF30784@awork2.anarazel.de,  
    369698E947874884A77849D8FE3680C2@maumau,  
    5CF4ABBA67674088B3941894E22A0D25@maumau  
  
Per complaint from maumau and Thom Brown  
  
Backpatch all the way back; 9.0 doesn't have syncrep, but it seems  
better to be consistent behavior across all maintained branches.  
  

Free SQLSTATE and SQLERRM no earlier than other PL/pgSQL variables.

  
commit   : 40a9a16760ab803694583d7f3549a7ad7bc11d75    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 25 Feb 2015 23:48:28 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 25 Feb 2015 23:48:28 -0500    

Click here for diff

  
"RETURN SQLERRM" prompted plpgsql_exec_function() to read from freed  
memory.  Back-patch to 9.0 (all supported versions).  Little code ran  
between the premature free and the read, so non-assert builds are  
unlikely to witness user-visible consequences.  
  

Fix dumping of views that are just VALUES(…) but have column aliases.

  
commit   : 7a501bcbfc64d9e66fa6e83ed57b1804203da3e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2015 12:01:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Feb 2015 12:01:12 -0500    

Click here for diff

  
The "simple" path for printing VALUES clauses doesn't work if we need  
to attach nondefault column aliases, because there's noplace to do that  
in the minimal VALUES() syntax.  So modify get_simple_values_rte() to  
detect nondefault aliases and treat that as a non-simple case.  This  
further exposes that the "non-simple" path never actually worked;  
it didn't produce valid syntax.  Fix that too.  Per bug #12789 from  
Curtis McEnroe, and analysis by Andrew Gierth.  
  
Back-patch to all supported branches.  Before 9.3, this also requires  
back-patching the part of commit 092d7ded29f36b0539046b23b81b9f0bf2d637f1  
that created get_simple_values_rte() to begin with; inserting the extra  
test into the old factorization of that logic would've been too messy.  
  

Guard against spurious signals in LockBufferForCleanup.

  
commit   : 87b7fcc87277142f584a9c1646abe52a8a79365d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Feb 2015 16:11:11 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Feb 2015 16:11:11 +0100    

Click here for diff

  
When LockBufferForCleanup() has to wait for getting a cleanup lock on a  
buffer it does so by setting a flag in the buffer header and then wait  
for other backends to signal it using ProcWaitForSignal().  
Unfortunately LockBufferForCleanup() missed that ProcWaitForSignal() can  
return for other reasons than the signal it is hoping for. If such a  
spurious signal arrives the wait flags on the buffer header will still  
be set. That then triggers "ERROR: multiple backends attempting to wait  
for pincount 1".  
  
The fix is simple, unset the flag if still set when retrying. That  
implies an additional spinlock acquisition/release, but that's unlikely  
to matter given the cost of waiting for a cleanup lock.  Alternatively  
it'd have been possible to move responsibility for maintaining the  
relevant flag to the waiter all together, but that might have had  
negative consequences due to possible floods of signals. Besides being  
more invasive.  
  
This looks to be a very longstanding bug. The relevant code in  
LockBufferForCleanup() hasn't changed materially since its introduction  
and ProcWaitForSignal() was documented to return for unrelated reasons  
since 8.2.  The master only patch series removing ImmediateInterruptOK  
made it much easier to hit though, as ProcSendSignal/ProcWaitForSignal  
now uses a latch shared with other tasks.  
  
Per discussion with Kevin Grittner, Tom Lane and me.  
  
Backpatch to all supported branches.  
  
Discussion: 11553.1423805224@sss.pgh.pa.us  
  

Fix potential deadlock with libpq non-blocking mode.

  
commit   : 8878eaaa841a0d8c8683277aad054006a8e7a2e6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 23 Feb 2015 13:32:34 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 23 Feb 2015 13:32:34 +0200    

Click here for diff

  
If libpq output buffer is full, pqSendSome() function tries to drain any  
incoming data. This avoids deadlock, if the server e.g. sends a lot of  
NOTICE messages, and blocks until we read them. However, pqSendSome() only  
did that in blocking mode. In non-blocking mode, the deadlock could still  
happen.  
  
To fix, take a two-pronged approach:  
  
1. Change the documentation to instruct that when PQflush() returns 1, you  
should wait for both read- and write-ready, and call PQconsumeInput() if it  
becomes read-ready. That fixes the deadlock, but applications are not going  
to change overnight.  
  
2. In pqSendSome(), drain the input buffer before returning 1. This  
alleviates the problem for applications that only wait for write-ready. In  
particular, a slow but steady stream of NOTICE messages during COPY FROM  
STDIN will no longer cause a deadlock. The risk remains that the server  
attempts to send a large burst of data and fills its output buffer, and at  
the same time the client also sends enough data to fill its output buffer.  
The application will deadlock if it goes to sleep, waiting for the socket  
to become write-ready, before the server's data arrives. In practice,  
NOTICE messages and such that the server might be sending are usually  
short, so it's highly unlikely that the server would fill its output buffer  
so quickly.  
  
Backpatch to all supported versions.  
  

Minor cleanup of column-level priv fix

  
commit   : 2ed7ef9219f24e99f416b120b1f1841c375c1b51    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 17 Feb 2015 15:36:51 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 17 Feb 2015 15:36:51 -0500    

Click here for diff

  
Commit 9406884af19e2620a14059e64d4eb6ab430ab328 cleaned up  
column-privilege related leaks in various error-message paths, but ended  
up including a few more things than it should have in the back branches.  
  
Specifically, there's no need for the GetModifiedColumns macro in  
execMain.c as 9.1 and older didn't include the row in check constraint  
violations.  Further, the regression tests added to check those cases  
aren't necessary.  
  
This patch removes the GetModifiedColumns macro from execMain.c, removes  
the comment which was added to trigger.c related to the duplicate macro  
definition, and removes the check-constraint-related regression tests.  
  
Pointed out by Robert.  
  
Back-patched to 9.1 and 9.0.  
  

Remove code to match IPv4 pg_hba.conf entries to IPv4-in-IPv6 addresses.

  
commit   : e48ce4f33d97623409f849d944e9e6e2dbd51e1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Feb 2015 12:49:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Feb 2015 12:49:18 -0500    

Click here for diff

  
In investigating yesterday's crash report from Hugo Osvaldo Barrera, I only  
looked back as far as commit f3aec2c7f51904e7 where the breakage occurred  
(which is why I thought the IPv4-in-IPv6 business was undocumented).  But  
actually the logic dates back to commit 3c9bb8886df7d56a and was simply  
broken by erroneous refactoring in the later commit.  A bit of archives  
excavation shows that we added the whole business in response to a report  
that some 2003-era Linux kernels would report IPv4 connections as having  
IPv4-in-IPv6 addresses.  The fact that we've had no complaints since 9.0  
seems to be sufficient confirmation that no modern kernels do that, so  
let's just rip it all out rather than trying to fix it.  
  
Do this in the back branches too, thus essentially deciding that our  
effective behavior since 9.0 is correct.  If there are any platforms on  
which the kernel reports IPv4-in-IPv6 addresses as such, yesterday's fix  
would have made for a subtle and potentially security-sensitive change in  
the effective meaning of IPv4 pg_hba.conf entries, which does not seem like  
a good thing to do in minor releases.  So let's let the post-9.0 behavior  
stand, and change the documentation to match it.  
  
In passing, I failed to resist the temptation to wordsmith the description  
of pg_hba.conf IPv4 and IPv6 address entries a bit.  A lot of this text  
hasn't been touched since we were IPv4-only.  
  

Fix misuse of memcpy() in check_ip().

  
commit   : c99ef9aff19590564bae374024669f9b38147be9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Feb 2015 16:17:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Feb 2015 16:17:48 -0500    

Click here for diff

  
The previous coding copied garbage into a local variable, pretty much  
ensuring that the intended test of an IPv6 connection address against a  
promoted IPv4 address from pg_hba.conf would never match.  The lack of  
field complaints likely indicates that nobody realized this was supposed  
to work, which is unsurprising considering that no user-facing docs suggest  
it should work.  
  
In principle this could have led to a SIGSEGV due to reading off the end of  
memory, but since the source address would have pointed to somewhere in the  
function's stack frame, that's quite unlikely.  What led to discovery of  
the bug is Hugo Osvaldo Barrera's report of a crash after an OS upgrade,  
which is probably because he is now running a system in which memcpy raises  
abort() upon detecting overlapping source and destination areas.  (You'd  
have to additionally suppose some things about the stack frame layout to  
arrive at this conclusion, but it seems plausible.)  
  
This has been broken since the code was added, in commit f3aec2c7f51904e7,  
so back-patch to all supported branches.  
  

pg_regress: Write processed input/*.source into output dir

  
commit   : 55535e018b8bed719d54f14a5fb7f33d95a5122e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 14 Feb 2015 21:33:41 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 14 Feb 2015 21:33:41 -0500    

Click here for diff

  
Before, it was writing the processed files into the input directory,  
which is incorrect in a vpath build.  
  

Fix broken #ifdef for __sparcv8

  
commit   : 61165fae050c8dec07d2bac4aad30754fd6b0d6b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 13 Feb 2015 23:51:23 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 13 Feb 2015 23:51:23 +0200    

Click here for diff

  
Rob Rowan. Backpatch to all supported versions, like the patch that added  
the broken #ifdef.  
  

pg_upgrade: quote directory names in delete_old_cluster script

  
commit   : 4ae178f6073b891bb98dd6681bd209fcb8d6c3e7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 Feb 2015 22:06:04 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 Feb 2015 22:06:04 -0500    

Click here for diff

  
This allows the delete script to properly function when special  
characters appear in directory paths, e.g. spaces.  
  
Backpatch through 9.0  
  

pg_upgrade: preserve freeze info for postgres/template1 dbs

  
commit   : 85dac37eefb826d42b7bd943d561e6f09ff20c21    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 Feb 2015 21:02:06 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 11 Feb 2015 21:02:06 -0500    

Click here for diff

  
pg_database.datfrozenxid and pg_database.datminmxid were not preserved  
for the 'postgres' and 'template1' databases.  This could cause missing  
clog file errors on access to user tables and indexes after upgrades in  
these databases.  
  
Backpatch through 9.0  
  

Fixed array handling in ecpg.

  
commit   : ce2fcc58ee0ed80ba49124061994924a7e164e11    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 11 Feb 2015 11:13:11 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 11 Feb 2015 11:13:11 +0100    

Click here for diff

  
When ecpg was rewritten to the new protocol version not all variable types  
were corrected. This patch rewrites the code for these types to fix that. It  
also fixes the documentation to correctly tell the status of array handling.  
  
Conflicts:  
	doc/src/sgml/ecpg.sgml  
  

Fix pg_dump’s heuristic for deciding which casts to dump.

  
commit   : 8e70f3c40a0a983c40ea533b631a0738b76faf53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Feb 2015 22:38:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Feb 2015 22:38:29 -0500    

Click here for diff

  
Back in 2003 we had a discussion about how to decide which casts to dump.  
At the time pg_dump really only considered an object's containing schema  
to decide what to dump (ie, dump whatever's not in pg_catalog), and so  
we chose a complicated idea involving whether the underlying types were to  
be dumped (cf commit a6790ce85752b67ad994f55fdf1a450262ccc32e).  But users  
are allowed to create casts between built-in types, and we failed to dump  
such casts.  Let's get rid of that heuristic, which has accreted even more  
ugliness since then, in favor of just looking at the cast's OID to decide  
if it's a built-in cast or not.  
  
In passing, also fix some really ancient code that supposed that it had to  
manufacture a dependency for the cast on its cast function; that's only  
true when dumping from a pre-7.3 server.  This just resulted in some wasted  
cycles and duplicate dependency-list entries with newer servers, but we  
might as well improve it.  
  
Per gripes from a number of people, most recently Greg Sabino Mullane.  
Back-patch to all supported branches.  
  

Fix GEQO to not assume its join order heuristic always works.

  
commit   : 72bbca27e814418db259516df632076abba86ad5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Feb 2015 20:37:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Feb 2015 20:37:31 -0500    

Click here for diff

  
Back in commit 400e2c934457bef4bc3cc9a3e49b6289bd761bc0 I rewrote GEQO's  
gimme_tree function to improve its heuristic for modifying the given tour  
into a legal join order.  In what can only be called a fit of hubris,  
I supposed that this new heuristic would *always* find a legal join order,  
and ripped out the old logic that allowed gimme_tree to sometimes fail.  
  
The folly of this is exposed by bug #12760, in which the "greedy" clumping  
behavior of merge_clump() can lead it into a dead end which could only be  
recovered from by un-clumping.  We have no code for that and wouldn't know  
exactly what to do with it if we did.  Rather than try to improve the  
heuristic rules still further, let's just recognize that it *is* a  
heuristic and probably must always have failure cases.  So, put back the  
code removed in the previous commit to allow for failure (but comment it  
a bit better this time).  
  
It's possible that this code was actually fully correct at the time and  
has only been broken by the introduction of LATERAL.  But having seen this  
example I no longer have much faith in that proposition, so back-patch to  
all supported branches.  
  

Add missing float.h include to snprintf.c.

  
commit   : 00331a0f23f25944d495260796c29778649a5041    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Feb 2015 13:27:31 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Feb 2015 13:27:31 +0100    

Click here for diff

  
On windows _isnan() (which isnan() is redirected to in port/win32.h)  
is declared in float.h, not math.h.  
  
Per buildfarm animal currawong.  
  
Backpatch to all supported branches.