Stamp 9.0.21.
commit : b6ba1d7577177765e4f9721d01820c02bb8ae9ae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jun 2015 15:14:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jun 2015 15:14:19 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Release notes for 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21.
commit : 41e83da379ba602abcc4128670e1abd7b49808ce
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jun 2015 13:27:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M doc/src/sgml/release-9.0.sgml
Remove special cases for ETXTBSY from new fsync'ing logic.
commit : bf2f20c086a04e7705a4e856d6cc9ebda3eb0017
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.
M src/backend/storage/file/fd.c
Fix fsync-at-startup code to not treat errors as fatal.
commit : e4a04e5a4e1516acee2411a5a594d70f07fd5341
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
M src/backend/access/transam/xlog.c
M src/backend/storage/file/fd.c
M src/include/storage/fd.h
Remove configure check prohibiting threaded libpython on OpenBSD.
commit : b06649b7fe521ea0778ec2eb0bff041f4682d073
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 May 2015 22:15:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 May 2015 22:15:00 -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.
M config/python.m4
M configure
Rename pg_shdepend.c's typedef "objectType" to SharedDependencyObjectType.
commit : 991dee2e604486b4880bf6b995dc2f5064edaa1c
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.
M src/backend/catalog/pg_shdepend.c
Back-patch libpq support for TLS versions beyond v1.
commit : 4dddf8552801ef013c40b22915928559a6fb22a0
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.
M src/backend/libpq/be-secure.c
M src/interfaces/libpq/fe-secure.c