Stamp 9.4.3.
commit : de17fe43fa2d67a9d93bd70979a4744ea98fb076
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jun 2015 15:05:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jun 2015 15:05:57 -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 : 2491e17c72456616bea428e50599be6d56cbaad4
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.
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
initdb -S should now have an explicit check that $PGDATA is valid.
commit : 99f50dd720de59872bd842be3ec8eecea2be4b92
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.
M src/bin/initdb/initdb.c
Remove special cases for ETXTBSY from new fsync'ing logic.
commit : 70a4519b82beee9e7bffb17ae4e6d81bb3ab89d8
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
M src/bin/initdb/initdb.c
Adjust initdb to also not consider fsync'ing failures fatal.
commit : dbde225b144890fb5a40e21f8f624de18ead2f95
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
M src/bin/initdb/initdb.c
Fix fsync-at-startup code to not treat errors as fatal.
commit : a3ae3db438db9d0ed66a53264d2f0067d80ae4c9
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
Fix pg_get_functiondef() to print a function's LEAKPROOF property.
commit : d4a9f5519d300aeae813a872b3c9874a7e02564b
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.
M src/backend/commands/functioncmds.c
M src/backend/utils/adt/ruleutils.c
Fix portability issue in isolationtester grammar.
commit : 269cb4fbcad116d3ec497326f166b6690a6ffbd5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 May 2015 19:14:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 May 2015 19:14:39 -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.
M src/test/isolation/specparse.y
M src/test/isolation/specscanner.l
Revert "Add all structured objects passed to pushJsonbValue piecewise."
commit : c8c6a693ecb69d9f5f83da14e2501bc49f49612b
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 26 May 2015 22:54:55 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 26 May 2015 22:54:55 -0400
This reverts commit 54547bd87f49326d67051254c363e6597d16ffda.
This appears to have been a thinko on my part. I will try to come up
wioth a better solution.
M src/backend/utils/adt/jsonb_util.c
Remove configure check prohibiting threaded libpython on OpenBSD.
commit : 79f0f7cab81b03e930deea6220e8bbc5b46f392a
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.
M config/python.m4
M configure
Add all structured objects passed to pushJsonbValue piecewise.
commit : 10eb60c2dc9461b56cf90cf05032a078eef7243d
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 26 May 2015 11:16:52 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 26 May 2015 11:16:52 -0400
Commit 9b74f32cdbff8b9be47fc69164eae552050509ff did this for objects of
type jbvBinary, but in trying further to simplify some of the new jsonb
code I discovered that objects of type jbvObject or jbvArray passed as
WJB_ELEM or WJB_VALUE also caused problems. These too are now added
component by component.
Backpatch to 9.4.
M src/backend/utils/adt/jsonb_util.c
Update README.tuplock
commit : 833c3961d9f22b46c32eeb9c4e73d334864994ed
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.
M src/backend/access/heap/README.tuplock
Rename pg_shdepend.c's typedef "objectType" to SharedDependencyObjectType.
commit : 20bc3548d77a30eeae37e3cc86088fc52059ca4a
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
Unpack jbvBinary objects passed to pushJsonbValue
commit : 9b74f32cdbff8b9be47fc69164eae552050509ff
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 22 May 2015 10:21:41 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 22 May 2015 10:21:41 -0400
pushJsonbValue was accepting jbvBinary objects passed as WJB_ELEM or
WJB_VALUE data. While this succeeded, when those objects were later
encountered in attempting to convert the result to Jsonb, errors
occurred. With this change we ghuarantee that a JSonbValue constructed
from calls to pushJsonbValue does not contain any jbvBinary objects.
This cures a problem observed with jsonb_delete.
This means callers of pushJsonbValue no longer need to perform this
unpacking themselves. A subsequent patch will perform some cleanup in
that area.
The error was not triggered by any 9.4 code, but this is a publicly
visible routine, and so the error could be exercised by third party
code, therefore backpatch to 9.4.
Bug report from Peter Geoghegan, fix by me.
M src/backend/utils/adt/jsonb_util.c
M src/include/utils/jsonb.h
Fix spelling in comment
commit : 7d0d2b8da1fee13e473495ffdfc7d642b37ebd63
author : Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 19 May 2015 18:38:41 -0400
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 19 May 2015 18:38:41 -0400
M src/backend/access/transam/xlog.c