commit : 3f7928a2890b05908e7c1ef711d48e609c86982e author : Tom Lane <firstname.lastname@example.org> date : Mon, 1 Jun 2015 15:10:35 -0400 committer: Tom Lane <email@example.com> date : Mon, 1 Jun 2015 15:10:35 -0400
Release notes for 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21.
commit : 25e9e8984b25c7fd2145b4b759615d70ee4c23cf author : Tom Lane <firstname.lastname@example.org> date : Mon, 1 Jun 2015 13:27:44 -0400 committer: Tom Lane <email@example.com> date : Mon, 1 Jun 2015 13:27:44 -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.
Remove special cases for ETXTBSY from new fsync'ing logic.
commit : 77642a8197ed7fa3a5113bdca914e4685e957455 author : Tom Lane <firstname.lastname@example.org> date : Fri, 29 May 2015 15:11:36 -0400 committer: Tom Lane <email@example.com> 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.
Fix fsync-at-startup code to not treat errors as fatal.
commit : aa8377e64ff0ddac5342979d0afb050eb178ff8a author : Tom Lane <firstname.lastname@example.org> date : Thu, 28 May 2015 17:33:03 -0400 committer: Tom Lane <email@example.com> 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
Fix pg_get_functiondef() to print a function's LEAKPROOF property.
commit : f3c67aad433484cab9c997a99965992c0ffbdbe5 author : Tom Lane <firstname.lastname@example.org> date : Thu, 28 May 2015 11:24:37 -0400 committer: Tom Lane <email@example.com> 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.
Fix portability issue in isolationtester grammar.
commit : 44674d071f69ed0f9e076bffa9b5386dbede332e author : Tom Lane <firstname.lastname@example.org> date : Wed, 27 May 2015 19:14:40 -0400 committer: Tom Lane <email@example.com> 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.
Remove configure check prohibiting threaded libpython on OpenBSD.
commit : 1b14571201358b454d1a215952b3a942c1a4ce51 author : Tom Lane <firstname.lastname@example.org> date : Tue, 26 May 2015 22:14:59 -0400 committer: Tom Lane <email@example.com> 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.
Rename pg_shdepend.c's typedef "objectType" to SharedDependencyObjectType.
commit : e1f1807c7a4a9f08149a332817ad127be296320b author : Tom Lane <firstname.lastname@example.org> date : Sun, 24 May 2015 13:03:45 -0400 committer: Tom Lane <email@example.com> 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.
Back-patch libpq support for TLS versions beyond v1.
commit : b78fbfe65f755f072a9f56b5fc3a511167341490 author : Tom Lane <firstname.lastname@example.org> date : Thu, 21 May 2015 20:41:55 -0400 committer: Tom Lane <email@example.com> 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.