PostgreSQL 9.3.8 commit log

commit   : 00ca051844e6a5a1746d9088d2c92b3fd1bcf151    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2015 15:08:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2015 15:08:17 -0400    

commit   : 1ed04113c278e6bc15bccd9a496bb6beff2b0baf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2015 13:27:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2015 13:27:43 -0400    

Also sneak entries for commits 97ff2a564 et al into the sections for  
the previous releases in the relevant branches.  Those fixes did go out  
in the previous releases, but missed getting documented.  

commit   : c2b68b1f7d6de9e749d037a09c5875742e8e6250    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 17:02:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 17:02:58 -0400    

The fsync code from the backend essentially assumes that somebody's already  
validated PGDATA, at least to the extent of it being a readable directory.  
That's safe enough for initdb's normal code path too, but "initdb -S"  
doesn't have any other processing at all that touches the target directory.  
To have reasonable error-case behavior, add a pg_check_dir call.  
Per gripe from Peter E.  

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

The argument that this is a sufficiently-expected case to be silently  
ignored seems pretty thin.  Andres had brought it up back when we were  
still considering that most fsync failures should be hard errors, and it  
probably would be legit not to fail hard for ETXTBSY --- but the same is  
true for EROFS and other cases, which is why we gave up on hard failures.  
ETXTBSY is surely not a normal case, so logging the failure seems fine  
from here.  

commit   : 52fc948444dde2d10f261e66766e6842231a9d46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 13:05:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 13:05:16 -0400    

Make initdb's version of this logic look as much like the backend's  
as possible.  This is much less critical than in the backend since not  
so many people use "initdb -S", but we want the same corner-case error  
handling in both cases.  
  
Back-patch to 9.3 where initdb -S option was introduced.  Before that,  
initdb only had to deal with freshly-created data directories, wherein  
no failures should be expected.  
  
Abhijit Menon-Sen  

commit   : 81f3d3b7c335ac04b58bf981d2fb315e57111b21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 17:33:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 17:33:03 -0400    

Commit 2ce439f3379aed857517c8ce207485655000fc8e introduced a rather serious  
regression, namely that if its scan of the data directory came across any  
un-fsync-able files, it would fail and thereby prevent database startup.  
Worse yet, symlinks to such files also caused the problem, which meant that  
crash restart was guaranteed to fail on certain common installations such  
as older Debian.  
  
After discussion, we agreed that (1) failure to start is worse than any  
consequence of not fsync'ing is likely to be, therefore treat all errors  
in this code as nonfatal; (2) we should not chase symlinks other than  
those that are expected to exist, namely pg_xlog/ and tablespace links  
under pg_tblspc/.  The latter restriction avoids possibly fsync'ing a  
much larger part of the filesystem than intended, if the user has left  
random symlinks hanging about in the data directory.  
  
This commit takes care of that and also does some code beautification,  
mainly moving the relevant code into fd.c, which seems a much better place  
for it than xlog.c, and making sure that the conditional compilation for  
the pre_sync_fname pass has something to do with whether pg_flush_data  
works.  
  
I also relocated the call site in xlog.c down a few lines; it seems a  
bit silly to be doing this before ValidateXLOGDirectoryStructure().  
  
The similar logic in initdb.c ought to be made to match this, but that  
change is noncritical and will be dealt with separately.  
  
Back-patch to all active branches, like the prior commit.  
  
Abhijit Menon-Sen and Tom Lane  

commit   : 27bae8d964f7eeb61e7e6e57586e7cb9b571b94c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 11:24:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 11:24:37 -0400    

Seems to have been an oversight in the original leakproofness patch.  
Per report and patch from Jeevan Chalke.  
  
In passing, prettify some awkward leakproof-related code in AlterFunction.  

commit   : 5c8e43a492c9885ea5d541b8d0d391a871ad8427    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 May 2015 19:14:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 May 2015 19:14:40 -0400    

specparse.y and specscanner.l used "string" as a token name.  Now, bison  
likes to define each token name as a macro for the token code it assigns,  
which means those names are basically off-limits for any other use within  
the grammar file or included headers.  So names as generic as "string" are  
dangerous.  This is what was causing the recent failures on protosciurus:  
some versions of Solaris' sys/kstat.h use "string" as a field name.  
With late-model bison we don't see this problem because the token macros  
aren't defined till later (that is why castoroides didn't show the problem  
even though it's on the same machine).  But protosciurus uses bison 1.875  
which defines the token macros up front.  
  
This land mine has been there from day one; we'd have found it sooner  
except that protosciurus wasn't trying to run the isolation tests till  
recently.  
  
To fix, rename the token to "string_literal" which is hopefully less  
likely to collide with names used by system headers.  Back-patch to  
all branches containing the isolation tests.  

commit   : 9e980e7d00e8cb637804eef6fad3f5b38ac19786    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2015 22:14:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2015 22:14:59 -0400    

According to recent tests, this case now works fine, so there's no reason  
to reject it anymore.  (Even if there are still some OpenBSD platforms  
in the wild where it doesn't work, removing the check won't break any case  
that worked before.)  
  
We can actually remove the entire test that discovers whether libpython  
is threaded, since without the OpenBSD case there's no need to know that  
at all.  
  
Per report from Davin Potts.  Back-patch to all active branches.  

commit   : 605326ed32cfc548f1b7bf6610b5efcda6f477ca    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 May 2015 15:09:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 May 2015 15:09:05 -0300    

Multixact truncation is now handled differently, and this file hadn't  
gotten the memo.  
  
Per note from Amit Langote.  I didn't use his patch, though.  
  
Also update the description of infomask bits, which weren't completely up  
to date either.  This commit also propagates b01a4f6838 back to 9.3 and  
9.4, which apparently I failed to do back then.  

commit   : 887e4b79f09a01f79ce2bbd0fb5846a316328a3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 13:03:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 13:03:45 -0400    

The name objectType is widely used as a field name, and it's pure luck that  
this conflict has not caused pgindent to go crazy before.  It messed up  
pg_audit.c pretty good though.  Since pg_shdepend.c doesn't export this  
typedef and only uses it in three places, changing that seems saner than  
changing the field usages.  
  
Back-patch because we're contemplating using the union of all branch  
typedefs for future pgindent runs, so this won't fix anything if it  
stays the same in back branches.  

commit   : c6b7b9a9cef1253ad12122959d0e78f62d8aee1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 May 2015 20:41:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 May 2015 20:41:55 -0400    

Since 7.3.2, libpq has been coded in such a way that the only SSL protocol  
it would allow was TLS v1.  That approach is looking increasingly obsolete.  
In commit 820f08cabdcbb899 we fixed it to allow TLS >= v1, but did not  
back-patch the change at the time, partly out of caution and partly because  
the question was confused by a contemporary server-side change to reject  
the now-obsolete SSL protocol v3.  9.4 has now been out long enough that  
it seems safe to assume the change is OK; hence, back-patch into 9.0-9.3.  
  
(I also chose to back-patch some relevant comments added by commit  
326e1d73c476a0b5, but did *not* change the server behavior; hence, pre-9.4  
servers will continue to allow SSL v3, even though no remotely modern  
client will request it.)  
  
Per gripe from Jan Bilek.