commit : 8ca336f4ac3f08a5f23e76c6e9a5f2c8064f5883
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Dec 2014 20:07:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Dec 2014 20:07:34 -0500
commit : 38a8323bdbb7524a96955fbaac90b12c94996b60
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 15 Dec 2014 16:18:13 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 15 Dec 2014 16:18:13 -0500
commit : e208b51f5491c85e0e967fe9798ace3f041fe0b7
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 15 Dec 2014 00:23:25 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 15 Dec 2014 00:23:25 -0500
doc: Add link to how to specify time zone names to initdb man page
commit : 93a5b1ff7842d91e1ce32c44660cc1e3e5a55317
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 14 Dec 2014 20:02:04 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 14 Dec 2014 20:02:04 -0500
Improve documentation around parameter-setting and ALTER SYSTEM.
commit : f4ec02c7cfd755be81dc0fe5dd0ccf2d49c2c30d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Dec 2014 18:09:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Dec 2014 18:09:55 -0500
The ALTER SYSTEM ref page hadn't been held to a very high standard, nor
was the feature well integrated into section 18.1 (parameter setting).
Also, though commit 4c4654afe had improved the structure of 18.1, it also
introduced a lot of poor wording, imprecision, and outright falsehoods.
Try to clean that up.
Update 9.4 release notes.
commit : 76547289b5b351799198c8ea6fae3f0e52d576e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Dec 2014 14:58:06 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Dec 2014 14:58:06 -0500
Set release date, do a final pass of wordsmithing, improve some other
new-in-9.4 documentation.
Improve recovery target settings documentation.
commit : 5fc34ba880e1223268ffbbe8be8621342c883151
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Dec 2014 13:46:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Dec 2014 13:46:46 -0500
Commit 815d71dee hadn't bothered to update the documentation to match the
behavioral change, and a lot of other text in this section was badly in
need of copy-editing.
Repair corner-case bug in array version of percentile_cont().
commit : 9ccae6360df4a8be845e28b0ab9042ab09e8c397
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Dec 2014 11:49:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Dec 2014 11:49:20 -0500
The code for advancing through the input rows overlooked the case that we
might already be past the first row of the row pair now being considered,
in case the previous percentile also fell between the same two input rows.
Report and patch by Andrew Gierth; logic rewritten a bit for clarity by me.
Revert misguided change to postgres_fdw FOR UPDATE/SHARE code.
commit : 1a1fb46da4ca6ac0385bdd43a33e15b64370dfdd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Dec 2014 12:41:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Dec 2014 12:41:52 -0500
In commit 462bd95705a0c23ba0b0ba60a78d32566a0384c1, I changed postgres_fdw
to rely on get_plan_rowmark() instead of get_parse_rowmark(). I still
think that's a good idea in the long run, but as Etsuro Fujita pointed out,
it doesn't work today because planner.c forces PlanRowMarks to have
markType = ROW_MARK_COPY for all foreign tables. There's no urgent reason
to change this in the back branches, so let's just revert that part of
yesterday's commit rather than trying to design a better solution under
time pressure.
Also, add a regression test case showing what postgres_fdw does with FOR
UPDATE/SHARE. I'd blithely assumed there was one already, else I'd have
realized yesterday that this code didn't work.
Fix planning of SELECT FOR UPDATE on child table with partial index.
commit : f2e20542dac2e25bc37440e66fd2769c29f2836b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 21:02:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 21:02:28 -0500
Ordinarily we can omit checking of a WHERE condition that matches a partial
index's condition, when we are using an indexscan on that partial index.
However, in SELECT FOR UPDATE we must include the "redundant" filter
condition in the plan so that it gets checked properly in an EvalPlanQual
recheck. The planner got this mostly right, but improperly omitted the
filter condition if the index in question was on an inheritance child
table. In READ COMMITTED mode, this could result in incorrectly returning
just-updated rows that no longer satisfy the filter condition.
The cause of the error is using get_parse_rowmark() when get_plan_rowmark()
is what should be used during planning. In 9.3 and up, also fix the same
mistake in contrib/postgres_fdw. It's currently harmless there (for lack
of inheritance support) but wrong is wrong, and the incorrect code might
get copied to someplace where it's more significant.
Report and fix by Kyotaro Horiguchi. Back-patch to all supported branches.
Fix corner case where SELECT FOR UPDATE could return a row twice.
commit : 0c12be853a4e0367164dd59437598c7078809e4d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 19:37:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 19:37:03 -0500
In READ COMMITTED mode, if a SELECT FOR UPDATE discovers it has to redo
WHERE-clause checking on rows that have been updated since the SELECT's
snapshot, it invokes EvalPlanQual processing to do that. If this first
occurs within a non-first child table of an inheritance tree, the previous
coding could accidentally re-return a matching row from an earlier,
already-scanned child table. (And, to add insult to injury, I think this
could make it miss returning a row that should have been returned, if the
updated row that this happens on should still have passed the WHERE qual.)
Per report from Kyotaro Horiguchi; the added isolation test is based on his
test case.
This has been broken for quite awhile, so back-patch to all supported
branches.
Fix assorted confusion between Oid and int32.
commit : 390ed56eb7fb8cc4ba2a7cd6360b41883601908e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 15:41:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 15:41:20 -0500
In passing, also make some debugging elog's in pgstat.c a bit more
consistently worded.
Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are
really old).
Mark Dilger identified and patched the type violations; the message
rewordings are mine.
Fix typo
commit : d0f8d0ded4e2d9bf77fd638c0cac281f83429c4d
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 10 Dec 2014 20:55:30 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 10 Dec 2014 20:55:30 -0500
Author: Fabrízio de Royes Mello <fabriziomello@gmail.com>
Fix minor thinko in convertToJsonb().
commit : 49b60a4be7cb8bbfb9d954cc5b81d0dc18b077df
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Dec 2014 19:06:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Dec 2014 19:06:27 -0500
The amount of space to reserve for the value's varlena header is
VARHDRSZ, not sizeof(VARHDRSZ). The latter coding accidentally
failed to fail because of the way the VARHDRSZ macro is currently
defined; but if we ever change it to return size_t (as one might
reasonably expect it to do), convertToJsonb() would have failed.
Spotted by Mark Dilger.
Give a proper error message if initdb password file is empty.
commit : eadd80c08ddfc485db84b9af7cca54a0d50ebe6d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 Dec 2014 14:27:56 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 Dec 2014 14:27:56 +0200
Used to say just "could not read password from file "...": Success", which
isn't very informative.
Mats Erik Andersson. Backpatch to all supported versions.
Print wal_log_hints in the rm_desc routing of a parameter-change record.
commit : 463dde8def8befec1e8f1f3c106c1ce1108ad54f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 Dec 2014 11:58:24 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 Dec 2014 11:58:24 +0200
It was an oversight in the original commit.
Also note in the sample config file that changing wal_log_hints requires a
restart.
Michael Paquier. Backpatch to 9.4, where wal_log_hints was added.
Fix PGXS vpath build when PostgreSQL is built with vpath
commit : f3d7077dad94d6ac864647eaa50f5dd0590a6c8d
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 4 Dec 2014 17:02:02 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 4 Dec 2014 17:02:02 -0500
PGXS computes srcdir from VPATH, PostgreSQL proper computes VPATH from
srcdir, and doing both results in an error from make. Conditionalize so
only one of these takes effect.
Remove USE_VPATH make variable from PGXS
commit : e907997f42faada60e5a26b116cc0b79b69309d1
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 19 Nov 2014 21:51:30 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 19 Nov 2014 21:51:30 -0500
The user can just set VPATH directly. There is no need to invent
another variable.
Fix SHLIB_PREREQS use in contrib, allowing PGXS builds
commit : 4e4b9002498b72c7000a675216470e8918fc0420
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 4 Dec 2014 07:58:12 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 4 Dec 2014 07:58:12 -0500
dblink and postgres_fdw use SHLIB_PREREQS = submake-libpq to build libpq
first. This doesn't work in a PGXS build, because there is no libpq to
build. So just omit setting SHLIB_PREREQS in this case.
Note that PGXS users can still use SHLIB_PREREQS (although it is not
documented). The problem here is only that contrib modules can be built
in-tree or using PGXS, and the prerequisite is only applicable in the
former case.
Commit 6697aa2bc25c83b88d6165340348a31328c35de6 previously attempted to
address this by creating a somewhat fake submake-libpq target in
Makefile.global. That was not the right fix, and it was also done in a
nonportable way, so revert that.
Move PG_AUTOCONF_FILENAME definition
commit : 3e2dc9703a4835ace14310f82369df0a4e8528f2
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 3 Dec 2014 19:54:01 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 3 Dec 2014 19:54:01 -0500
Since this is not something that a user should change,
pg_config_manual.h was an inappropriate place for it.
In initdb.c, remove the use of the macro, because utils/guc.h can't be
included by non-backend code. But we hardcode all the other
configuration file names there, so this isn't a disaster.
Fix typos
commit : 567737822a004dd23a105c5b7129ff98b2805ac7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Dec 2014 11:52:16 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Dec 2014 11:52:16 -0300
Improve error messages for malformed array input strings.
commit : 7a0be6782b5fc050ec93e386aec13f3100f498a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Dec 2014 18:23:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Dec 2014 18:23:20 -0500
Make the error messages issued by array_in() uniformly follow the style
ERROR: malformed array literal: "actual input string"
DETAIL: specific complaint here
and rewrite many of the specific complaints to be clearer.
The immediate motivation for doing this is a complaint from Josh Berkus
that json_to_record() produced an unintelligible error message when
dealing with an array item, because it tries to feed the JSON-format
array value to array_in(). Really it ought to be smart enough to
perform JSON-to-Postgres array conversion, but that's a future feature
not a bug fix. In the meantime, this change is something we agreed
we could back-patch into 9.4, and it should help de-confuse things a bit.
Don’t skip SQL backends in logical decoding for visibility computation.
commit : 10f1f93d8ae2d70fcaf350c62972fb6bac42ffc9
author : Andres Freund <andres@anarazel.de>
date : Tue, 2 Dec 2014 23:42:26 +0100
committer: Andres Freund <andres@anarazel.de>
date : Tue, 2 Dec 2014 23:42:26 +0100
The logical decoding patchset introduced PROC_IN_LOGICAL_DECODING flag
PGXACT flag, that allows such backends to be skipped when computing
the xmin horizon/snapshots. That's fine and sensible for walsenders
streaming out logical changes, but not at all fine for SQL backends
doing logical decoding. If the latter set that flag any change they
have performed outside of logical decoding will not be regarded as
visible - which e.g. can lead to that change being vacuumed away.
Note that not setting the flag for SQL backends isn't particularly
bothersome - the SQL backend doesn't do streaming, so it only runs for
a limited amount of time.
Per buildfarm member 'tick' and Alvaro.
Backpatch to 9.4, where logical decoding was introduced.
Fix JSON aggregates to work properly when final function is re-executed.
commit : f0eeba6f83ed16687d8743b34e519de45c3915ec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Dec 2014 15:02:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Dec 2014 15:02:40 -0500
Davide S. reported that json_agg() sometimes produced multiple trailing
right brackets. This turns out to be because json_agg_finalfn() attaches
the final right bracket, and was doing so by modifying the aggregate state
in-place. That's verboten, though unfortunately it seems there's no way
for nodeAgg.c to check for such mistakes.
Fix that back to 9.3 where the broken code was introduced. In 9.4 and
HEAD, likewise fix json_object_agg(), which had copied the erroneous logic.
Make some cosmetic cleanups as well.
Guard against bad “dscale” values in numeric_recv().
commit : ac0aa07e96b3ebf7b8b2bebfc56fc86fb90c14f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Dec 2014 15:25:05 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Dec 2014 15:25:05 -0500
We were not checking to see if the supplied dscale was valid for the given
digit array when receiving binary-format numeric values. While dscale can
validly be more than the number of nonzero fractional digits, it shouldn't
be less; that case causes fractional digits to be hidden on display even
though they're there and participate in arithmetic.
Bug #12053 from Tommaso Sala indicates that there's at least one broken
client library out there that sometimes supplies an incorrect dscale value,
leading to strange behavior. This suggests that simply throwing an error
might not be the best response; it would lead to failures in applications
that might seem to be working fine today. What seems the least risky fix
is to truncate away any digits that would be hidden by dscale. This
preserves the existing behavior in terms of what will be printed for the
transmitted value, while preventing subsequent arithmetic from producing
results inconsistent with that.
In passing, throw a specific error for the case of dscale being outside
the range that will fit into a numeric's header. Before you got "value
overflows numeric format", which is a bit misleading.
Back-patch to all supported branches.
Fix hstore_to_json_loose’s detection of valid JSON number values.
commit : f82132f4a15e2a02d984b3ba0ef5b10da1f489bd
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 1 Dec 2014 11:28:45 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 1 Dec 2014 11:28:45 -0500
We expose a function IsValidJsonNumber that internally calls the lexer
for json numbers. That allows us to use the same test everywhere,
instead of inventing a broken test for hstore conversions. The new
function is also used in datum_to_json, replacing the code that is now
moved to the new function.
Backpatch to 9.3 where hstore_to_json_loose was introduced.
Fix missing space in documentation
commit : 76394810f87d3c03f8a135cc6e9801acc6b0ad8d
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 1 Dec 2014 12:12:07 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 1 Dec 2014 12:12:07 +0100
Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd8 et al.
commit : 2e2c8455fa9f9bae80a1e1edd780b78362b82404
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Nov 2014 12:20:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Nov 2014 12:20:47 -0500
Coverity complained that the "else" added to fillPGconn() was unreachable,
which it was. Remove the dead code. In passing, rearrange the tests so as
not to bother trying to fetch values for options that can't be assigned.
Pre-9.3 did not have that issue, but it did have a "return" that should be
"goto oom_error" to ensure that a suitable error message gets filled in.
Remove PQhostaddr() from 9.4 release notes.
commit : 6bb6958fa2614a5f18e9ac992f8f9956db59e9d1
author : Noah Misch <noah@leadboat.com>
date : Sat, 29 Nov 2014 15:53:05 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sat, 29 Nov 2014 15:53:05 -0500
Apart from ignoring "hostaddr" set to the empty string, this behaves
identically to its predecessor. Back-patch to 9.4, where the original
commit first appeared.
Reviewed by Fujii Masao.
Revert “Add libpq function PQhostaddr().”
commit : 27b6f9ce7b12f82599f95f296abe7bb8942a6041
author : Noah Misch <noah@leadboat.com>
date : Sat, 29 Nov 2014 12:31:21 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sat, 29 Nov 2014 12:31:21 -0500
This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14. The
function returned the raw value of a connection parameter, a task served
by PQconninfo(). The next commit will reimplement the psql \conninfo
change that way. Back-patch to 9.4, where that commit first appeared.
Update transaction README for persistent multixacts
commit : 866c6ab456f97478ad7b316a8c9fbf7c9e9a3143
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 28 Nov 2014 18:06:18 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 28 Nov 2014 18:06:18 -0300
Previously \watch always ignored the user's \pset null setting.
\pset null setting should be ignored for \d and similar queries.
For those, the code can reasonably have an opinion about what
the presentation should be like, since it knows what SQL query
it's issuing. This argument surely doesn't apply to \watch,
so this commit makes \watch use the user's \pset null setting.
Back-patch to 9.3 where \watch was added.
Mark response messages for translation in pg_isready.
commit : 6e9d43eb02583ce29ffbbf732ab8f26e2a58e4cf
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 28 Nov 2014 02:12:45 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 28 Nov 2014 02:12:45 +0900
Back-patch to 9.3 where pg_isready was added.
Mats Erik Andersson
Free libxml2/libxslt resources in a safer order.
commit : e2d0c25917bef8c25bf6e9b1bcf2a75dbf8f07f0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Nov 2014 11:12:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Nov 2014 11:12:47 -0500
Mark Simonetti reported that libxslt sometimes crashes for him, and that
swapping xslt_process's object-freeing calls around to do them in reverse
order of creation seemed to fix it. I've not reproduced the crash, but
valgrind clearly shows a reference to already-freed memory, which is
consistent with the idea that shutdown of the xsltTransformContext is
trying to reference the already-freed stylesheet or input document.
With this patch, valgrind is no longer unhappy.
I have an inquiry in to see if this is a libxslt bug or if we're just
abusing the library; but even if it's a library bug, we'd want to adjust
our code so it doesn't fail with unpatched libraries.
Back-patch to all supported branches, because we've been doing this in
the wrong(?) order for a long time.
Allow “dbname” from connection string to be overridden in PQconnectDBParams
commit : 6c1d521af35e496639bbb39764c30115879af47f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 17:12:07 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 17:12:07 +0200
If the "dbname" attribute in PQconnectDBParams contained a connection string
or URI (and expand_dbname = TRUE), the database name from the connection
string could not be overridden by a subsequent "dbname" keyword in the
array. That was not intentional; all other options can be overridden.
Furthermore, any subsequent "dbname" caused the connection string from the
first dbname value to be processed again, overriding any values for the same
options that were given between the connection string and the second dbname
option.
In the passing, clarify in the docs that only the first dbname option in the
array is parsed as a connection string.
Alex Shulgin. Backpatch to all supported versions.
Check return value of strdup() in libpq connection option parsing.
commit : 811015ff9aafd2d5e03fbd931f7c6102b3d6516a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 12:55:00 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 12:55:00 +0200
An out-of-memory in most of these would lead to strange behavior, like
connecting to a different database than intended, but some would lead to
an outright segfault.
Alex Shulgin and me. Backpatch to all supported versions.
Fix mishandling of system columns in FDW queries.
commit : 3852eaba10bdcd8eafa5e64dbd853dc5c50e134c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 22 Nov 2014 16:01:08 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 22 Nov 2014 16:01:08 -0500
postgres_fdw would send query conditions involving system columns to the
remote server, even though it makes no effort to ensure that system
columns other than CTID match what the remote side thinks. tableoid,
in particular, probably won't match and might have some use in queries.
Hence, prevent sending conditions that include non-CTID system columns.
Also, create_foreignscan_plan neglected to check local restriction
conditions while determining whether to set fsSystemCol for a foreign
scan plan node. This again would bollix the results for queries that
test a foreign table's tableoid.
Back-patch the first fix to 9.3 where postgres_fdw was introduced.
Back-patch the second to 9.2. The code is probably broken in 9.1 as
well, but the patch doesn't apply cleanly there; given the weak state
of support for FDWs in 9.1, it doesn't seem worth fixing.
Etsuro Fujita, reviewed by Ashutosh Bapat, and somewhat modified by me
Improve documentation’s description of JOIN clauses.
commit : 0632eff4389a2682c49db7fbe16968bb076060a5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Nov 2014 16:00:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Nov 2014 16:00:27 -0500
In bug #12000, Andreas Kunert complained that the documentation was
misleading in saying "FROM T1 CROSS JOIN T2 is equivalent to FROM T1, T2".
That's correct as far as it goes, but the equivalence doesn't hold when
you consider three or more tables, since JOIN binds more tightly than
comma. I added a <note> to explain this, and ended up rearranging some
of the existing text so that the note would make sense in context.
In passing, rewrite the description of JOIN USING, which was unnecessarily
vague, and hadn't been helped any by somebody's reliance on markup as a
substitute for clear writing. (Mostly this involved reintroducing a
concrete example that was unaccountably removed by commit 032f3b7e166cfa28.)
Back-patch to all supported branches.
Avoid file descriptor leak in pg_test_fsync.
commit : a9f3280efee0d3c4f697ef33f28cbc8e626f9e86
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 19 Nov 2014 11:57:54 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 19 Nov 2014 11:57:54 -0500
In pg_receivexlog, in order to check whether the current WAL file is
being opened or not, its file descriptor has to be checked against -1
as an invalid value. But, oops, 7900e94 added the incorrect test
checking the descriptor against 1. This commit fixes that bug.
Back-patch to 9.4 where the bug was added.
Spotted by Magnus Hagander
Fix pg_receivexlog –slot so that it doesn’t prevent the server shutdown.
commit : 7900e94fbb2d36fe798f2deda56d71071957c0e0
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 19 Nov 2014 14:11:48 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 19 Nov 2014 14:11:48 +0900
When pg_receivexlog --slot is connecting to the server, at the shutdown
of the server, walsender keeps waiting for the last WAL record to be
replicated and flushed in pg_receivexlog. But previously pg_receivexlog
issued sync command only when WAL file was switched. So there was
the case where the last WAL was never flushed and walsender had to
keep waiting infinitely. This caused the server shutdown to get stuck.
pg_recvlogical handles this problem by calling fsync() when it receives
the request of immediate reply from the server. That is, at shutdown,
walsender sends the request, pg_recvlogical receives it, flushes the last
WAL record, and sends the flush location back to the server. Since
walsender can see that the last WAL record is successfully flushed, it can
exit cleanly.
This commit introduces the same logic as pg_recvlogical has,
to pg_receivexlog.
Back-patch to 9.4 where pg_receivexlog was changed so that it can use
the replication slot.
Original patch by Michael Paquier, rewritten by me.
Bug report by Furuya Osamu.
Don’t require bleeding-edge timezone data in timestamptz regression test.
commit : e1ab2fa823692e13b2302ba2959f297acb4f1758
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Nov 2014 21:36:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Nov 2014 21:36:43 -0500
The regression test cases added in commits b2cbced9e et al depended in part
on the Russian timezone offset changes of Oct 2014. While this is of no
particular concern for a default Postgres build, it was possible for a
build using --with-system-tzdata to fail the tests if the system tzdata
database wasn't au courant. Bjorn Munch and Christoph Berg both complained
about this while packaging 9.4rc1, so we probably shouldn't insist on the
system tzdata being up-to-date. Instead, make an equivalent test using a
zone change that occurred in Venezuela in 2007. With this patch, the
regression tests should pass using any tzdata set from 2012 or later.
(I can't muster much sympathy for somebody using --with-system-tzdata
on a machine whose system tzdata is more than three years out-of-date.)
Fix some bogus direct uses of realloc().
commit : 3aa3ae8e1d959681d3396fe176cd8086e3b26c55
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Nov 2014 13:28:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Nov 2014 13:28:09 -0500
pg_dump/parallel.c was using realloc() directly with no error check.
While the odds of an actual failure here seem pretty low, Coverity
complains about it, so fix by using pg_realloc() instead.
While looking for other instances, I noticed a couple of places in
psql that hadn't gotten the memo about the availability of pg_realloc.
These aren't bugs, since they did have error checks, but verbosely
inconsistent code is not a good thing.
Back-patch as far as 9.3. 9.2 did not have pg_dump/parallel.c, nor
did it have pg_realloc available in all frontend code.
Stamp 9.4rc1.
commit : d5bea1fbcc24a9880ddc2ede29a6fedb41de9292
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 15:54:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 15:54:40 -0500
Update 9.4 release notes for commits through today.
commit : c7b412380d5507fbaf1e4ff54844ac9bde9771c5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 14:47:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 14:47:13 -0500
Update time zone data files to tzdata release 2014j.
commit : ddf7db58420375c75e3fb1f5fc6cbb90c5ee9b0c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 12:08:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 12:08:02 -0500
DST law changes in the Turks & Caicos Islands (America/Grand_Turk) and
in Fiji. New zone Pacific/Bougainville for portions of Papua New Guinea.
Historical changes for Korea and Vietnam.
Fix WAL-logging of B-tree “unlink halfdead page” operation.
commit : 8607fdf0337051ca1da493ded5db15c41da08d66
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 17 Nov 2014 18:42:04 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 17 Nov 2014 18:42:04 +0200
There was some confusion on how to record the case that the operation
unlinks the last non-leaf page in the branch being deleted.
_bt_unlink_halfdead_page set the "topdead" field in the WAL record to
the leaf page, but the redo routine assumed that it would be an invalid
block number in that case. This commit fixes _bt_unlink_halfdead_page to
do what the redo routine expected.
This code is new in 9.4, so backpatch there.
Translation updates
commit : d8a7cdde585c49037cdfdc624223dd53cd868a30
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 16 Nov 2014 21:31:08 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 16 Nov 2014 21:31:08 -0500
commit : e668b366304b526a354f8ff5a3eed683c818f7a9
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 16 Nov 2014 15:48:30 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 16 Nov 2014 15:48:30 +0100
commit : 6d301af4c023ac5655d88acbe55f7f49036ee50c
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 16 Nov 2014 15:47:10 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 16 Nov 2014 15:47:10 +0100
Patch from Michael Paquier, mistake spotted by KOIZUMI Satoru
Fix initdb –sync-only to also sync tablespaces.
commit : f52b3c44632f99d53973be57e5c729cfc3d6430f
author : Andres Freund <andres@anarazel.de>
date : Fri, 14 Nov 2014 18:22:12 +0100
committer: Andres Freund <andres@anarazel.de>
date : Fri, 14 Nov 2014 18:22:12 +0100
630cd14426dc added initdb --sync-only, for use by pg_upgrade, by just
exposing the existing fsync code. That's wrong, because initdb so far
had absolutely no reason to deal with tablespaces.
Fix --sync-only by additionally explicitly syncing each of the
tablespaces.
Backpatch to 9.3 where --sync-only was introduced.
Abhijit Menon-Sen and Andres Freund
Sync unlogged relations to disk after they have been reset.
commit : e26a920acb77b953d1034e243d6a8c7294dbd25d
author : Andres Freund <andres@anarazel.de>
date : Fri, 14 Nov 2014 18:21:30 +0100
committer: Andres Freund <andres@anarazel.de>
date : Fri, 14 Nov 2014 18:21:30 +0100
Unlogged relations are only reset when performing a unclean
restart. That means they have to be synced to disk during clean
shutdowns. During normal processing that's achieved by registering a
buffer's file to be fsynced at the next checkpoint when flushed. But
ResetUnloggedRelations() doesn't go through the buffer manager, so
nothing will force reset relations to disk before the next shutdown
checkpoint.
So just make ResetUnloggedRelations() fsync the newly created main
forks to disk.
Discussion: 20140912112246.GA4984@alap3.anarazel.de
Backpatch to 9.1 where unlogged tables were introduced.
Abhijit Menon-Sen and Andres Freund
Ensure unlogged tables are reset even if crash recovery errors out.
commit : 1a2cb1ea84a1745247a7b41f1b0188889e815794
author : Andres Freund <andres@anarazel.de>
date : Fri, 14 Nov 2014 18:20:59 +0100
committer: Andres Freund <andres@anarazel.de>
date : Fri, 14 Nov 2014 18:20:59 +0100
Unlogged relations are reset at the end of crash recovery as they're
only synced to disk during a proper shutdown. Unfortunately that and
later steps can fail, e.g. due to running out of space. This reset
was, up to now performed after marking the database as having finished
crash recovery successfully. As out of space errors trigger a crash
restart that could lead to the situation that not all unlogged
relations are reset.
Once that happend usage of unlogged relations could yield errors like
"could not open file "...": No such file or directory". Luckily
clusters that show the problem can be fixed by performing a immediate
shutdown, and starting the database again.
To fix, just call ResetUnloggedRelations(UNLOGGED_RELATION_INIT)
earlier, before marking the database as having successfully recovered.
Discussion: 20140912112246.GA4984@alap3.anarazel.de
Backpatch to 9.1 where unlogged tables were introduced.
Abhijit Menon-Sen and Andres Freund
Document evaluation-order considerations for aggregate functions.
commit : df3e23e1b509001ac9336763404406bdcad04dcc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 Nov 2014 17:19:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 Nov 2014 17:19:29 -0500
The SELECT reference page didn't really address the question of when
aggregate function evaluation occurs, nor did the "expression evaluation
rules" documentation mention that CASE can't be used to control whether
an aggregate gets evaluated or not. Improve that.
Per discussion of bug #11661. Original text by Marti Raudsepp and Michael
Paquier, rewritten significantly by me.
Revert change to ALTER TABLESPACE summary.
commit : 2113f7215d2e13f07c277a86efae900b25d94dc1
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 14 Nov 2014 15:16:01 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 14 Nov 2014 15:16:01 -0500
When ALTER TABLESPACE MOVE ALL was changed to be ALTER TABLE ALL IN
TABLESPACE, the ALTER TABLESPACE summary should have been adjusted back
to its original definition.
Patch by Thom Brown (thanks!).
Allow interrupting GetMultiXactIdMembers
commit : 137e4da6df75a671d53bcc1e66097533c93c8732
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Nov 2014 15:14:02 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Nov 2014 15:14:02 -0300
This function has a loop which can lead to uninterruptible process
"stalls" (actually infinite loops) when some bugs are triggered. Avoid
that unpleasant situation by adding a check for interrupts in a place
that shouldn't degrade performance in the normal case.
Backpatch to 9.3. Older branches have an identical loop here, but the
aforementioned bugs are only a problem starting in 9.3 so there doesn't
seem to be any point in backpatching any further.
Improve logical decoding log messages
commit : 16695d601e73792c3e49f324b48ff25af96c83d9
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 13 Nov 2014 20:43:55 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 13 Nov 2014 20:43:55 -0500
Fix pg_dumpall to restore its ability to dump from ancient servers.
commit : 2c267e47afa4f9a7cc8f04f43e440dfdf9fd3ed7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Nov 2014 18:19:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Nov 2014 18:19:28 -0500
Fix breakage induced by commits d8d3d2a4f37f6df5d0118b7f5211978cca22091a
and 463f2625a5fb183b6a8925ccde98bb3889f921d9: pg_dumpall has crashed when
attempting to dump from pre-8.1 servers since then, due to faulty
construction of the query used for dumping roles from older servers.
The query was erroneous as of the earlier commit, but it wasn't exposed
unless you tried to use --binary-upgrade, which you presumably wouldn't
with a pre-8.1 server. However commit 463f2625a made it fail always.
In HEAD, also fix additional breakage induced in the same query by
commit 491c029dbc4206779cf659aa0ff986af7831d2ff, which evidently wasn't
tested against pre-8.1 servers either.
The bug is only latent in 9.1 because 463f2625a hadn't landed yet, but
it seems best to back-patch all branches containing the faulty query.
Gilles Darold
Fix and improve cache invalidation logic for logical decoding.
commit : 11868e1704cae36ee13303eaf9f5f5f656870426
author : Andres Freund <andres@anarazel.de>
date : Thu, 13 Nov 2014 19:06:43 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 13 Nov 2014 19:06:43 +0100
There are basically three situations in which logical decoding needs
to perform cache invalidation. During/After replaying a transaction
with catalog changes, when skipping a uninteresting transaction that
performed catalog changes and when erroring out while replaying a
transaction. Unfortunately these three cases were all done slightly
differently - partially because 8de3e410fa, which greatly simplifies
matters, got committed in the midst of the development of logical
decoding.
The actually problematic case was when logical decoding skipped
transaction commits (and thus processed invalidations). When used via
the SQL interface cache invalidation could access the catalog - bad,
because we didn't set up enough state to allow that correctly. It'd
not be hard to setup sufficient state, but the simpler solution is to
always perform cache invalidation outside a valid transaction.
Also make the different cache invalidation cases look as similar as
possible, to ease code review.
This fixes the assertion failure reported by Antonin Houska in
53EE02D9.7040702@gmail.com. The presented testcase has been expanded
into a regression test.
Backpatch to 9.4, where logical decoding was introduced.
Fix xmin/xmax horizon computation during logical decoding initialization.
commit : da668a5d8f92af33d1f01b20993f4e1cf3735973
author : Andres Freund <andres@anarazel.de>
date : Thu, 13 Nov 2014 19:06:43 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 13 Nov 2014 19:06:43 +0100
When building the initial historic catalog snapshot there were
scenarios where snapbuild.c would use incorrect xmin/xmax values when
starting from a xl_running_xacts record. The values used were always a
bit suspect, but happened to be correct in the easy to test
cases. Notably the values used when the the initial snapshot was
computed while no other transactions were running were correct.
This is likely to be the cause of the occasional buildfarm failures on
animals markhor and tick; but it's quite possible to reproduce
problems without CLOBBER_CACHE_ALWAYS.
Backpatch to 9.4, where logical decoding was introduced.
Fix race condition between hot standby and restoring a full-page image.
commit : 8fc23a9ed0a040d039431ef79b1bf166395ed180
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 13 Nov 2014 19:47:44 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 13 Nov 2014 19:47:44 +0200
There was a window in RestoreBackupBlock where a page would be zeroed out,
but not yet locked. If a backend pinned and locked the page in that window,
it saw the zeroed page instead of the old page or new page contents, which
could lead to missing rows in a result set, or errors.
To fix, replace RBM_ZERO with RBM_ZERO_AND_LOCK, which atomically pins,
zeroes, and locks the page, if it's not in the buffer cache already.
In stable branches, the old RBM_ZERO constant is renamed to RBM_DO_NOT_USE,
to avoid breaking any 3rd party extensions that might use RBM_ZERO. More
importantly, this avoids renumbering the other enum values, which would
cause even bigger confusion in extensions that use ReadBufferExtended, but
haven't been recompiled.
Backpatch to all supported versions; this has been racy since hot standby
was introduced.
Tweak row-level locking documentation
commit : 955b4ba7f6948359efcef1c47035d382f937e9f3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Nov 2014 14:45:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Nov 2014 14:45:58 -0300
Move the meat of locking levels to mvcc.sgml, leaving only a link to it
in the SELECT reference page.
Michael Paquier, with some tweaks by Álvaro
doc: Add index entry for “hypothetical-set aggregate”
commit : a3408059dd66b3b9929e04b3697213b31ccb5253
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 13 Nov 2014 11:57:16 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 13 Nov 2014 11:57:16 -0500
Explicitly support the case that a plancache’s raw_parse_tree is NULL.
commit : 40b85a3ab11e99096dc4489153cfdd4884cdecd3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Nov 2014 15:58:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Nov 2014 15:58:40 -0500
This only happens if a client issues a Parse message with an empty query
string, which is a bit odd; but since it is explicitly called out as legal
by our FE/BE protocol spec, we'd probably better continue to allow it.
Fix by adding tests everywhere that the raw_parse_tree field is passed to
functions that don't or shouldn't accept NULL. Also make it clear in the
relevant comments that NULL is an expected case.
This reverts commits a73c9dbab0165b3395dfe8a44a7dfd16166963c4 and
2e9650cbcff8c8fb0d9ef807c73a44f241822eee, which fixed specific crash
symptoms by hacking things at what now seems to be the wrong end, ie the
callee functions. Making the callees allow NULL is superficially more
robust, but it's not always true that there is a defensible thing for the
callee to do in such cases. The caller has more context and is better
able to decide what the empty-query case ought to do.
Per followup discussion of bug #11335. Back-patch to 9.2. The code
before that is sufficiently different that it would require development
of a separate patch, which doesn't seem worthwhile for what is believed
to be an essentially cosmetic change.
Fix several weaknesses in slot and logical replication on-disk serialization.
commit : 5005469cb2f2bf8a57344b43f97969292ebebb76
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Nov 2014 18:52:49 +0100
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Nov 2014 18:52:49 +0100
Heikki noticed in 544E23C0.8090605@vmware.com that slot.c and
snapbuild.c were missing the FIN_CRC32 call when computing/checking
checksums of on disk files. That doesn't lower the the error detection
capabilities of the checksum, but is inconsistent with other usages.
In a followup mail Heikki also noticed that, contrary to a comment,
the 'version' and 'length' struct fields of replication slot's on disk
data where not covered by the checksum. That's not likely to lead to
actually missed corruption as those fields are cross checked with the
expected version and the actual file length. But it's wrong
nonetheless.
As fixing these issues makes existing on disk files unreadable, bump
the expected versions of on disk files for both slots and logical
decoding historic catalog snapshots. This means that loading old
files will fail with
ERROR: "replication slot file ... has unsupported version 1"
and
ERROR: "snapbuild state file ... has unsupported version 1 instead of
2" respectively. Given the low likelihood of anybody already using
these new features in a production setup that seems acceptable.
Fixing these issues made me notice that there's no regression test
covering the loading of historic snapshot from disk - so add one.
Backpatch to 9.4 where these features were introduced.
Add interrupt checks to contrib/pg_prewarm.
commit : 57b2e1049e7fdb0ca7882c74520e409507462eb2
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Nov 2014 18:52:49 +0100
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Nov 2014 18:52:49 +0100
Currently the extension's pg_prewarm() function didn't check
interrupts once it started "warming" data. Since individual calls can
take a long while it's important for them to be interruptible.
Backpatch to 9.4 where pg_prewarm was introduced.
Use just one database connection in the “tablespace” test.
commit : c4d360d18259690442036c1ee07a899cbe4022a0
author : Noah Misch <noah@leadboat.com>
date : Wed, 12 Nov 2014 07:33:17 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 12 Nov 2014 07:33:17 -0500
On Windows, DROP TABLESPACE has a race condition when run concurrently
with other processes having opened files in the tablespace. This led to
a rare failure on buildfarm member frogmouth. Back-patch to 9.4, where
the reconnection was introduced.
Message improvements
commit : 8fb4218ef41da0baff4909c5d74f23513bac9950
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 11 Nov 2014 20:00:58 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 11 Nov 2014 20:00:58 -0500
Loop when necessary in contrib/pgcrypto’s pktreader_pull().
commit : 1c73485c695af2dfa7a7f7bec6e1ab8d4eaab7ab
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Nov 2014 17:22:15 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Nov 2014 17:22:15 -0500
This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key
or corrupt data" on messages whose length is 6 less than a power of 2.
Per bug #11905 from Connor Penhale. Fix by Marko Tiikkaja, regression
test case from Jeff Janes.
Fix dependency searching for case where column is visited before table.
commit : 951c2f6faf00a00ab824699c96376d1d8f5acc57
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Nov 2014 17:00:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Nov 2014 17:00:18 -0500
When the recursive search in dependency.c visits a column and then later
visits the whole table containing the column, it needs to propagate the
drop-context flags for the table to the existing target-object entry for
the column. Otherwise we might refuse the DROP (if not CASCADE) on the
incorrect grounds that there was no automatic drop pathway to the column.
Remarkably, this has not been reported before, though it's possible at
least when an extension creates both a datatype and a table using that
datatype.
Rather than just marking the column as allowed to be dropped, it might
seem good to skip the DROP COLUMN step altogether, since the later DROP
of the table will surely get the job done. The problem with that is that
the datatype would then be dropped before the table (since the whole
situation occurred because we visited the datatype, and then recursed to
the dependent column, before visiting the table). That seems pretty risky,
and the case is rare enough that it doesn't seem worth expending a lot of
effort or risk to make the drops happen in a safe order. So we just play
dumb and delete the column separately according to the existing drop
ordering rules.
Per report from Petr Jelinek, though this is different from his proposed
patch.
Back-patch to 9.1, where extensions were introduced. There's currently
no evidence that such cases can arise before 9.1, and in any case we would
also need to back-patch cb5c2ba2d82688d29b5902d86b993a54355cad4d to 9.0
if we wanted to back-patch this.
Ensure that RowExprs and whole-row Vars produce the expected column names.
commit : f449873623605bc1906f2a5daa56f2343c473e1b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Nov 2014 15:21:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Nov 2014 15:21:14 -0500
At one time it wasn't terribly important what column names were associated
with the fields of a composite Datum, but since the introduction of
operations like row_to_json(), it's important that looking up the rowtype
ID embedded in the Datum returns the column names that users would expect.
That did not work terribly well before this patch: you could get the column
names of the underlying table, or column aliases from any level of the
query, depending on minor details of the plan tree. You could even get
totally empty field names, which is disastrous for cases like row_to_json().
To fix this for whole-row Vars, look to the RTE referenced by the Var, and
make sure its column aliases are applied to the rowtype associated with
the result Datums. This is a tad scary because we might have to return
a transient RECORD type even though the Var is declared as having some
named rowtype. In principle it should be all right because the record
type will still be physically compatible with the named rowtype; but
I had to weaken one Assert in ExecEvalConvertRowtype, and there might be
third-party code containing similar assumptions.
Similarly, RowExprs have to be willing to override the column names coming
from a named composite result type and produce a RECORD when the column
aliases visible at the site of the RowExpr differ from the underlying
table's column names.
In passing, revert the decision made in commit 398f70ec070fe601 to add
an alias-list argument to ExecTypeFromExprList: better to provide that
functionality in a separate function. This also reverts most of the code
changes in d68581483564ec0f, which we don't need because we're no longer
depending on the tupdesc found in the child plan node's result slot to be
blessed.
Back-patch to 9.4, but not earlier, since this solution changes the results
in some cases that users might not have realized were buggy. We'll apply a
more restricted form of this patch in older branches.
pg_basebackup: Adjust tests for long file name issues
commit : ef52e3a7b4fbcddd64afb5b528f945d6bb21aeb1
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 7 Nov 2014 20:47:38 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 7 Nov 2014 20:47:38 -0500
Work around accidental test failures because the working directory path
is too long by creating a temporary directory in the (hopefully shorter)
system location, symlinking that to the working directory, and creating
the tablespaces using the shorter path.
doc: Update pg_receivexlog note
commit : 342bcee4aa142ce4b119838a4c5d6debd694539f
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 7 Nov 2014 20:15:22 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 7 Nov 2014 20:15:22 -0500
The old note about how to use pg_receivexlog as an alternative to
archive_command was obsoleted by replication slots.
Fix generation of SP-GiST vacuum WAL records.
commit : f36f4fbdca3de615acb2fc232f6bc72d6db19bde
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Nov 2014 21:14:35 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Nov 2014 21:14:35 +0200
I broke these in 8776faa81cb651322b8993422bdd4633f1f6a487. Backpatch to
9.4, where that was done.
Cope with more than 64K phrases in a thesaurus dictionary.
commit : eed245a113c299976e548f018c758617bc20efd0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Nov 2014 20:52:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Nov 2014 20:52:40 -0500
dict_thesaurus stored phrase IDs in uint16 fields, so it would get confused
and even crash if there were more than 64K entries in the configuration
file. It turns out to be basically free to widen the phrase IDs to uint32,
so let's just do so.
This was complained of some time ago by David Boutin (in bug #7793);
he later submitted an informal patch but it was never acted on.
We now have another complaint (bug #11901 from Luc Ouellette) so it's
time to make something happen.
This is basically Boutin's patch, but for future-proofing I also added a
defense against too many words per phrase. Note that we don't need any
explicit defense against overflow of the uint32 counters, since before that
happens we'd hit array allocation sizes that repalloc rejects.
Back-patch to all supported branches because of the crash risk.
Fix normalization of numeric values in JSONB GIN indexes.
commit : 42020f5deb5d3a3b6593152cc1a95dbfa5250275
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Nov 2014 11:41:06 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Nov 2014 11:41:06 -0500
The default JSONB GIN opclass (jsonb_ops) converts numeric data values
to strings for storage in the index. It must ensure that numeric values
that would compare equal (such as 12 and 12.00) produce identical strings,
else index searches would have behavior different from regular JSONB
comparisons. Unfortunately the function charged with doing this was
completely wrong: it could reduce distinct numeric values to the same
string, or reduce equivalent numeric values to different strings. The
former type of error would only lead to search inefficiency, but the
latter type of error would cause index entries that should be found by
a search to not be found.
Repairing this bug therefore means that it will be necessary for 9.4 beta
testers to reindex GIN jsonb_ops indexes, if they care about getting
correct results from index searches involving numeric data values within
the comparison JSONB object.
Per report from Thomas Fanghaenel.
Prevent the unnecessary creation of .ready file for the timeline history file.
commit : cc76577873945183352fa6e1e82cc14606c28fd3
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 6 Nov 2014 21:24:40 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 6 Nov 2014 21:24:40 +0900
Previously .ready file was created for the timeline history file at the end
of an archive recovery even when WAL archiving was not enabled.
This creation is unnecessary and causes .ready file to remain infinitely.
This commit changes an archive recovery so that it creates .ready file for
the timeline history file only when WAL archiving is enabled.
Backpatch to all supported versions.
Fix volatility markings of some contrib I/O functions.
commit : 26a95a1e521e4ae1a2ebdcc0db5745ee8d1285cc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Nov 2014 11:34:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Nov 2014 11:34:13 -0500
In general, datatype I/O functions are supposed to be immutable or at
worst stable. Some contrib I/O functions were, through oversight, not
marked with any volatility property at all, which made them VOLATILE.
Since (most of) these functions actually behave immutably, the erroneous
marking isn't terribly harmful; but it can be user-visible in certain
circumstances, as per a recent bug report from Joe Van Dyk in which a
cast to text was disallowed in an expression index definition.
To fix, just adjust the declarations in the extension SQL scripts. If we
were being very fussy about this, we'd bump the extension version numbers,
but that seems like more trouble (for both developers and users) than the
problem is worth.
A fly in the ointment is that chkpass_in actually is volatile, because
of its use of random() to generate a fresh salt when presented with a
not-yet-encrypted password. This is bad because of the general assumption
that I/O functions aren't volatile: the consequence is that records or
arrays containing chkpass elements may have input behavior a bit different
from a bare chkpass column. But there seems no way to fix this without
breaking existing usage patterns for chkpass, and the consequences of the
inconsistency don't seem bad enough to justify that. So for the moment,
just document it in a comment.
Since we're not bumping version numbers, there seems no harm in
back-patching these fixes; at least future installations will get the
functions marked correctly.
doc: Move misplaced paragraph
commit : 63ff971e06461e67b8108cf360c4a6eb03adb160
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 4 Nov 2014 16:10:58 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 4 Nov 2014 16:10:58 -0500
Drop no-longer-needed buffers during ALTER DATABASE SET TABLESPACE.
commit : a192d5d05dd943d8fde0c52f4a924690696daec1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Nov 2014 13:24:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Nov 2014 13:24:10 -0500
The previous coding assumed that we could just let buffers for the
database's old tablespace age out of the buffer arena naturally.
The folly of that is exposed by bug #11867 from Marc Munro: the user could
later move the database back to its original tablespace, after which any
still-surviving buffers would match lookups again and appear to contain
valid data. But they'd be missing any changes applied while the database
was in the new tablespace.
This has been broken since ALTER SET TABLESPACE was introduced, so
back-patch to all supported branches.
Docs: fix incorrect spelling of contrib/pgcrypto option.
commit : 21495a2bb7599fb7546b146ca33bd7c6157c1472
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Nov 2014 11:11:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Nov 2014 11:11:34 -0500
pgp_sym_encrypt's option is spelled "sess-key", not "enable-session-key".
Spotted by Jeff Janes.
In passing, improve a comment in pgp-pgsql.c to make it clearer that
the debugging options are intentionally undocumented.
Re-remove dependency on the DLL of pythonxx.def file.
commit : f229170c75f0ce64b1b9a0a362571d1f19089de4
author : Noah Misch <noah@leadboat.com>
date : Sun, 2 Nov 2014 21:43:30 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 2 Nov 2014 21:43:30 -0500
The reasons behind commit 0d147e43adcf5d2bff9caa073608f381a27439bf still
stand, so this reverts the non-cosmetic portion of commit
a7983e989d9cafc9cef49becfee054e34b1ed9b4. Back-patch to 9.4, where the
latter commit first appeared.
Make ECPG test programs depend on “ecpg$(X)”, not “ecpg”.
commit : 63d2c0c573ff2a9ba0391576dc569260b4de5dd9
author : Noah Misch <noah@leadboat.com>
date : Sun, 2 Nov 2014 21:43:25 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 2 Nov 2014 21:43:25 -0500
Cygwin builds require this of dependencies pertaining to pattern rules.
On Cygwin, stat("foo") in the absence of a file with that exact name can
locate foo.exe. While GNU make uses stat() for dependencies of ordinary
rules, it uses readdir() to assess dependencies of pattern rules.
Therefore, a pattern rule dependency should match any underlying file
name exactly. Back-patch to 9.4, where the dependency was introduced.
Fix win32setlocale.c const-related warnings.
commit : 94c1dec0d9c1da40ab956520ae093cdad478fcd4
author : Noah Misch <noah@leadboat.com>
date : Sun, 2 Nov 2014 21:43:20 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 2 Nov 2014 21:43:20 -0500
Back-patch to 9.2, like commit db29620d4d16e08241f965ccd70d0f65883ff0de.
Fix generation of INSTALL file by removing link
commit : 25ca2a69eab63729ed3195afbe0d175cf0e54d19
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 2 Nov 2014 20:17:32 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 2 Nov 2014 20:17:32 -0500
commit : 16381b2a78e5a3477b5a7ac956b7afc36efdcc58
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 2 Nov 2014 09:14:36 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 2 Nov 2014 09:14:36 -0500
Don't skip the TAP tests anymore when IPC::Run is not found. This will
fail normally now.
PL/Python: Fix example
commit : 4ffa8806ee5187526b592e1918cd17c1cdde802d
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 1 Nov 2014 11:31:35 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 1 Nov 2014 11:31:35 -0400
Revert "6f6b46c9c0ca3d96acbebc5499c32ee6369e1eec", which was broken.
Reported-by: Jonathan Rogers <jrogers@socialserve.com>
doc: Fix typos
commit : f41ed7b66a621134d5c7c39c74458fbfb1214255
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 31 Oct 2014 08:11:06 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 31 Oct 2014 08:11:06 -0400
doc: Wording and formatting improvements in new logical decoding docs
commit : 1414868d088cfb6cb85d57946f4a460efa7d31c6
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 30 Oct 2014 22:52:21 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 30 Oct 2014 22:52:21 -0400
commit : 7dacab976917c26cd9b6c4b36e53dbbf8261473b
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 30 Oct 2014 22:50:02 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 30 Oct 2014 22:50:02 -0400
Similar to 590eb0c14eebe834f716721a9659b77899cf3084, remove the options
list from the synopsis and elaborate in the main description.
Test IsInTransactionChain, not IsTransactionBlock, in vac_update_relstats.
commit : 7f4ece03d675a2a6cb6cec14f564744b5c01e5a4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Oct 2014 13:03:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Oct 2014 13:03:25 -0400
As noted by Noah Misch, my initial cut at fixing bug #11638 didn't cover
all cases where ANALYZE might be invoked in an unsafe context. We need to
test the result of IsInTransactionChain not IsTransactionBlock; which is
notationally a pain because IsInTransactionChain requires an isTopLevel
flag, which would have to be passed down through several levels of callers.
I chose to pass in_outer_xact (ie, the result of IsInTransactionChain)
rather than isTopLevel per se, as that seemed marginally more apropos
for the intermediate functions to know about.
“Pin”, rather than “keep”, dynamic shared memory mappings and segments.
commit : 1c49dae165bcee69bf3327d6ae20271d82cdf6bf
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 30 Oct 2014 11:35:55 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 30 Oct 2014 11:35:55 -0400
Nobody seemed concerned about this naming when it originally went in,
but there's a pending patch that implements the opposite of
dsm_keep_mapping, and the term "unkeep" was judged unpalatable.
"unpin" has existing precedent in the PostgreSQL code base, and the
English language, so use this terminology instead.
Per discussion, back-patch to 9.4.
Remove use of TAP subtests
commit : ae3eb9b8ef5638610da05038e40229d4f4e5c1fd
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 29 Oct 2014 19:41:19 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 29 Oct 2014 19:41:19 -0400
They turned out to be too much of a portability headache, because they
need a fairly new version of Test::More to work properly.
Avoid corrupting tables when ANALYZE inside a transaction is rolled back.
commit : 22b3003d70a88644f36cd91446631f474dfbfe41
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Oct 2014 18:12:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Oct 2014 18:12:04 -0400
VACUUM and ANALYZE update the target table's pg_class row in-place, that is
nontransactionally. This is OK, more or less, for the statistical columns,
which are mostly nontransactional anyhow. It's not so OK for the DDL hint
flags (relhasindex etc), which might get changed in response to
transactional changes that could still be rolled back. This isn't a
problem for VACUUM, since it can't be run inside a transaction block nor
in parallel with DDL on the table. However, we allow ANALYZE inside a
transaction block, so if the transaction had earlier removed the last
index, rule, or trigger from the table, and then we roll back the
transaction after ANALYZE, the table would be left in a corrupted state
with the hint flags not set though they should be.
To fix, suppress the hint-flag updates if we are InTransactionBlock().
This is safe enough because it's always OK to postpone hint maintenance
some more; the worst-case consequence is a few extra searches of pg_index
et al. There was discussion of instead using a transactional update,
but that would change the behavior in ways that are not all desirable:
in most scenarios we're better off keeping ANALYZE's statistical values
even if the ANALYZE itself rolls back. In any case we probably don't want
to change this behavior in back branches.
Per bug #11638 from Casey Shobe. This has been broken for a good long
time, so back-patch to all supported branches.
Tom Lane and Michael Paquier, initial diagnosis by Andres Freund
Reset error message at PQreset()
commit : fcca871203568a4d34bc026029bee51e8d246ae2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 29 Oct 2014 14:32:01 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 29 Oct 2014 14:32:01 +0200
If you call PQreset() repeatedly, and the connection cannot be
re-established, the error messages from the failed connection attempts
kept accumulating in the error string.
Fixes bug #11455 reported by Caleb Epstein. Backpatch to all supported
versions.
Remove obsolete commentary.
commit : d1f8e7a01501c71db3ee0bcd19aab79b1ddc662e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Oct 2014 18:36:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Oct 2014 18:36:02 -0400
Since we got rid of non-MVCC catalog scans, the fourth reason given for
using a non-transactional update in index_update_stats() is obsolete.
The other three are still good, so we're not going to change the code,
but fix the comment.
Remove unnecessary assignment.
commit : 3345ba4d0d28435518b5979120618a610dea4e13
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 28 Oct 2014 20:26:20 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 28 Oct 2014 20:26:20 +0200
Newer toolchains append the extension implicitly if missing, but
buildfarm member narwhal (gcc 3.4.2, ld 2.15.91 20040904) does not.
This affects most core libraries having an exports.txt file, namely
libpq and the ECPG support libraries. On Windows Server 2003, Windows
API functions that load and unload DLLs internally will mistakenly
unload a libpq whose DLL header reports "LIBPQ" instead of "LIBPQ.dll".
When, subsequently, control would return to libpq, the backend crashes.
Back-patch to 9.4, like commit 846e91e0223cf9f2821c3ad4dfffffbb929cb027.
Before that commit, we used a different linking technique that yielded
"libpq.dll" in the DLL header.
Commit 53566fc0940cf557416b13252df57350a4511ce4 worked around this by
eliminating a call to a function that loads and unloads DLLs internally.
That commit is no longer necessary for correctness, but its improving
consistency with the MSVC build remains valid.
Add missing equals signs to pg_recvlogical documentation.
commit : 89fbe97fcad3cfbc5d09d2a9f66aaf31e3164b94
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 27 Oct 2014 08:53:16 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 27 Oct 2014 08:53:16 -0400
commit : c366e1d169481a780857458f1064ae93007fd140
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Oct 2014 10:50:41 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Oct 2014 10:50:41 +0200
1. The comparison for matching terms used only the CRC to decide if there's
a match. Two different terms with the same CRC gave a match.
2. It assumed that if the second operand has more terms than the first, it's
never a match. That assumption is bogus, because there can be duplicate
terms in either operand.
Rewrite the implementation in a way that doesn't have those bugs.
Backpatch to all supported versions.
Fix undersized result buffer in pset_quoted_string().
commit : c53a82b99d98df393d7ba308bf1586b2201d0d65
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Oct 2014 19:17:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Oct 2014 19:17:57 -0400
The malloc request was 1 byte too small for the worst-case output.
This seems relatively unlikely to cause any problems in practice,
as the worst case only occurs if the input string contains no
characters other than single-quote or newline, and even then
malloc alignment padding would probably save the day. But it's
definitely a bug.
David Rowley
Improve planning of btree index scans using ScalarArrayOpExpr quals.
commit : 859e2b9dd4de94ef9a9ad34da3e39572e4f1d66f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Oct 2014 16:12:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Oct 2014 16:12:26 -0400
Since we taught btree to handle ScalarArrayOpExpr quals natively (commit
9e8da0f75731aaa7605cf4656c21ea09e84d2eb1), the planner has always included
ScalarArrayOpExpr quals in index conditions if possible. However, if the
qual is for a non-first index column, this could result in an inferior plan
because we can no longer take advantage of index ordering (cf. commit
807a40c551dd30c8dd5a0b3bd82f5bbb1e7fd285). It can be better to omit the
ScalarArrayOpExpr qual from the index condition and let it be done as a
filter, so that the output doesn't need to get sorted. Indeed, this is
true for the query introduced as a test case by the latter commit.
To fix, restructure get_index_paths and build_index_paths so that we
consider paths both with and without ScalarArrayOpExpr quals in non-first
index columns. Redesign the API of build_index_paths so that it reports
what it found, saving useless second or third calls.
Report and patch by Andrew Gierth (though rather heavily modified by me).
Back-patch to 9.2 where this code was introduced, since the issue can
result in significant performance regressions compared to plans produced
by 9.1 and earlier.
Fix TAP tests with Perl 5.12
commit : 76e190d52225fc1124efc7d77f773643405b263e
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 26 Oct 2014 10:26:36 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 26 Oct 2014 10:26:36 -0400
Perl 5.12 ships with a somewhat broken version of Test::Simple, so skip
the tests if that is found.
The relevant fix is
0.98 Wed, 23 Feb 2011 14:38:02 +1100
Bug Fixes
* subtest() should not fail if $? is non-zero. (Aaron Crane)
Fix TAP tests with Perl 5.8
commit : 6b531cd077eeacce25106f5456876b57ad68a834
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 26 Oct 2014 09:47:01 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 26 Oct 2014 09:47:01 -0400
The prove program included in Perl 5.8 does not support the --ext
option, so don't use that and use wildcards on the command line instead.
Note that the tests will still all be skipped, because, for instance,
the version of Test::More is too old, but at least the regular
mechanisms for handling that will apply, instead of failing to call
prove altogether.
Work around Windows locale name with non-ASCII character.
commit : c3c2d986977b60e3db26601d44ab029ef99156cc
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 24 Oct 2014 19:56:03 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 24 Oct 2014 19:56:03 +0300
Windows has one a locale whose name contains a non-ASCII character:
"Norwegian (Bokmål)" (that's an 'a' with a ring on top). That causes
trouble; when passing it setlocale(), it's not clear what encoding the
argument should be in. Another problem is that the locale name is stored in
pg_database catalog table, and the encoding used there depends on what
server encoding happens to be in use when the database is created. For
example, if you issue the CREATE DATABASE when connected to a UTF-8
database, the locale name is stored in pg_database in UTF-8. As long as all
locale names are pure ASCII, that's not a problem.
To work around that, map the troublesome locale name to a pure-ASCII alias
of the same locale, "norwegian-bokmal".
Now, this doesn't change the existing values that are already in
pg_database and in postgresql.conf. Old clusters will need to be fixed
manually. Instructions for that need to be put in the release notes.
This fixes bug #11431 reported by Alon Siman-Tov. Backpatch to 9.2;
backpatching further would require more work than seems worth it.
Make the locale comparison in pg_upgrade more lenient
commit : 4bdf5e57552456d0d12e33ead0dbfc124f4d4b81
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 24 Oct 2014 19:26:44 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 24 Oct 2014 19:26:44 +0300
If the locale names are not equal, try to canonicalize both of them by
passing them to setlocale(). Before, we only canonicalized the old cluster's
locale if upgrading from a 8.4-9.2 server, but we also need to canonicalize
when upgrading from a pre-8.4 server. That was an oversight in the code. But
we should also canonicalize on newer server versions, so that we cope if the
canonical form changes from one release to another. I'm about to do just
that to fix bug #11431, by mapping a locale name that contains non-ASCII
characters to a pure-ASCII alias of the same locale.
This is partial backpatch of commit 33755e8edf149dabfc0ed9b697a84f70b0cca0de
in master. Apply to 9.2, 9.3 and 9.4. The canonicalization code didn't exist
before 9.2. In 9.2 and 9.3, this effectively also back-patches the changes
from commit 58274728fb8e087049df67c0eee903d9743fdeda, to be more lax about
the spelling of the encoding in the locale names.
Improve ispell dictionary’s defenses against bad affix files.
commit : 1cf54b00ba2100083390223a8244430643c1ec07
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Oct 2014 13:11:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Oct 2014 13:11:31 -0400
Don't crash if an ispell dictionary definition contains flags but not
any compound affixes. (This isn't a security issue since only superusers
can install affix files, but still it's a bad thing.)
Also, be more careful about detecting whether an affix-file FLAG command
is old-format (ispell) or new-format (myspell/hunspell). And change the
error message about mixed old-format and new-format commands into something
intelligible.
Per bug #11770 from Emre Hasegeli. Back-patch to all supported branches.
Prevent the already-archived WAL file from being archived again.
commit : 6d12cc1f01c867fd7317ac5580b02c04f313d9ce
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 23 Oct 2014 16:21:27 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 23 Oct 2014 16:21:27 +0900
Previously the archive recovery always created .ready file for
the last WAL file of the old timeline at the end of recovery even when
it's restored from the archive and has .done file. That is, there was
the case where the WAL file had both .ready and .done files.
This caused the already-archived WAL file to be archived again.
This commit prevents the archive recovery from creating .ready file
for the last WAL file if it has .done file, in order to prevent it from
being archived again.
This bug was added when cascading replication feature was introduced,
i.e., the commit 5286105800c7d5902f98f32e11b209c471c0c69c.
So, back-patch to 9.2, where cascading replication was added.
Reviewed by Michael Paquier
Ensure libpq reports a suitable error message on unexpected socket EOF.
commit : b53942e59644d79c2df7951523a50dc4d2d97668
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Oct 2014 18:41:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Oct 2014 18:41:47 -0400
The EOF-detection logic in pqReadData was a bit confused about who should
set up the error message in case the kernel gives us read-ready-but-no-data
rather than ECONNRESET or some other explicit error condition. Since the
whole point of this situation is that the lower-level functions don't know
there's anything wrong, pqReadData itself must set up the message. But
keep the assumption that if an errno was reported, a message was set up at
lower levels.
Per bug #11712 from Marko Tiikkaja. It's been like this for a very long
time, so back-patch to all supported branches.
MinGW: Use -static-libgcc when linking a DLL.
commit : 2f51f424bb362dadeb4fabf03845961e563da4ba
author : Noah Misch <noah@leadboat.com>
date : Tue, 21 Oct 2014 22:55:47 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 21 Oct 2014 22:55:47 -0400
When commit 846e91e0223cf9f2821c3ad4dfffffbb929cb027 switched the linker
driver from dlltool/dllwrap to gcc, it became possible for linking to
choose shared libgcc. Backends having loaded a module dynamically
linked to libgcc can exit abnormally, which the postmaster treats like a
crash. Resume use of static libgcc exclusively, like 9.3 and earlier.
Back-patch to 9.4.
MinGW: Link with shell32.dll instead of shfolder.dll.
commit : 9e02e20ab6df093e1ab751157dfb5c51a420187b
author : Noah Misch <noah@leadboat.com>
date : Tue, 21 Oct 2014 22:55:43 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 21 Oct 2014 22:55:43 -0400
This improves consistency with the MSVC build. On buildfarm member
narwhal, since commit 846e91e0223cf9f2821c3ad4dfffffbb929cb027,
shfolder.dll:SHGetFolderPath() crashes when dblink calls it by way of
pqGetHomeDirectory(). Back-patch to 9.4, where that commit first
appeared. How it caused this regression remains a mystery. This is a
partial revert of commit 889f03812916b146ae504c0fad5afdc7bf2e8a2a, which
adopted shfolder.dll for Windows NT 4.0 compatibility. PostgreSQL 8.2
dropped support for that operating system.
Update expected/sequence_1.out.
commit : 7a14edb83e1c5c3c683cf0c8a90870e3bda9d22c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Oct 2014 18:26:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Oct 2014 18:26:01 -0400
The last three updates to the sequence regression test have all forgotten
to touch the alternate expected-output file. Sigh.
Michael Paquier
Flush unlogged table’s buffers when copying or moving databases.
commit : 5607e996f4ba93a4c56ea94f10d1fcc876b4bf42
author : Andres Freund <andres@anarazel.de>
date : Mon, 20 Oct 2014 23:43:46 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 20 Oct 2014 23:43:46 +0200
CREATE DATABASE and ALTER DATABASE .. SET TABLESPACE copy the source
database directory on the filesystem level. To ensure the on disk
state is consistent they block out users of the affected database and
force a checkpoint to flush out all data to disk. Unfortunately, up to
now, that checkpoint didn't flush out dirty buffers from unlogged
relations.
That bug means there could be leftover dirty buffers in either the
template database, or the database in its old location. Leading to
problems when accessing relations in an inconsistent state; and to
possible problems during shutdown in the SET TABLESPACE case because
buffers belonging files that don't exist anymore are flushed.
This was reported in bug #10675 by Maxim Boguk.
Fix by Pavan Deolasee, modified somewhat by me. Reviewed by MauMau and
Fujii Masao.
Backpatch to 9.1 where unlogged tables were introduced.
Correct volatility markings of a few json functions.
commit : 6e0a053a963024698de8ba315eed7455520d1a92
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 20 Oct 2014 14:55:35 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 20 Oct 2014 14:55:35 -0400
json_agg and json_object_agg and their associated transition functions
should have been marked as stable rather than immutable, as they call IO
functions indirectly. Changing this probably isn't going to make much
difference, as you can't use an aggregate function in an index
expression, but we should be correct nevertheless.
json_object, on the other hand, should be marked immutable rather than
stable, as it does not call IO functions.
As discussed on -hackers, this change is being made without bumping the
catalog version, as we don't want to do that at this stage of the cycle,
and the changes are very unlikely to affect anyone.
Fix mishandling of FieldSelect-on-whole-row-Var in nested lateral queries.
commit : 33343b862ce17ff51699789625684d0cccd60ede
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Oct 2014 12:23:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Oct 2014 12:23:44 -0400
If an inline-able SQL function taking a composite argument is used in a
LATERAL subselect, and the composite argument is a lateral reference,
the planner could fail with "variable not found in subplan target list",
as seen in bug #11703 from Karl Bartel. (The outer function call used in
the bug report and in the committed regression test is not really necessary
to provoke the bug --- you can get it if you manually expand the outer
function into "LATERAL (SELECT inner_function(outer_relation))", too.)
The cause of this is that we generate the reltargetlist for the referenced
relation before doing eval_const_expressions() on the lateral sub-select's
expressions (cf find_lateral_references()), so what's scheduled to be
emitted by the referenced relation is a whole-row Var, not the simplified
single-column Var produced by optimizing the function's FieldSelect on the
whole-row Var. Then setrefs.c fails to match up that lateral reference to
what's available from the outer scan.
Preserving the FieldSelect optimization in such cases would require either
major planner restructuring (to recursively do expression simplification
on sub-selects much earlier) or some amazingly ugly kluge to change the
reltargetlist of a possibly-already-planned relation. It seems better
just to skip the optimization when the Var is from an upper query level;
the case is not so common that it's likely anyone will notice a few
wasted cycles.
AFAICT this problem only occurs for uplevel LATERAL references, so
back-patch to 9.3 where LATERAL was added.
psql: Improve \pset without arguments
commit : 48b2d88c10746257c77a8c4c2f645ccfc6bb0afe
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 18 Oct 2014 21:58:17 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 18 Oct 2014 21:58:17 -0400
Revert the output of the individual backslash commands that change print
settings back to the 9.3 way (not showing the command name in
parentheses). Implement \pset without arguments separately, showing all
settings with values in a table form.
doc: Clean up pg_recvlogical reference page
commit : 5c8758e6ed54ff9e2c5ec72af619bbd52578659c
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 18 Oct 2014 09:10:12 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 18 Oct 2014 09:10:12 -0400
This needed a general cleanup of wording, typos, outdated terminology,
formatting, and hard-to-understand and borderline incorrect information.
Also tweak the pg_receivexlog page a bit to make the two more
consistent.
Declare mkdtemp() only if we’re providing it.
commit : b45f048ed899502c982f249d90608ca09b7939e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 22:55:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 22:55:23 -0400
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welton.
We might have to go to the extent of probing to see if the system headers
declare the function, but let's not do that until it's demonstrated to be
necessary.
Oversight in commit 9e6b1bf258170e62dac555fc82ff0536dfe01d29. Back-patch
to all supported branches, as that was.
Avoid core dump in _outPathInfo() for Path without a parent RelOptInfo.
commit : 16bbe5a3cc937096a4ad0dab050360eb87e0c813
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 22:33:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 22:33:04 -0400
Nearly all Paths have parents, but a ResultPath representing an empty FROM
clause does not. Avoid a core dump in such cases. I believe this is only
a hazard for debugging usage, not for production, else we'd have heard
about it before. Nonetheless, back-patch to 9.1 where the troublesome code
was introduced. Noted while poking at bug #11703.
Fix core dump in pg_dump –binary-upgrade on zero-column composite type.
commit : 3205b30bb7a82c8228230a15308a56b302603521
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 12:49:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 12:49:03 -0400
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
had no attributes, since then the query would return no rows.
Back-patch to all supported versions. It seems to not really be a problem
in 9.0 because that version rejects the syntax "create type t as ()", but
we might as well keep the logic similar in all affected branches.
Report and fix by Rushabh Lathia.
Support timezone abbreviations that sometimes change.
commit : 4b3b44b141a0163ca15fd3eb38589a5aefc499bd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Oct 2014 15:22:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Oct 2014 15:22:13 -0400
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
Print planning time only in EXPLAIN ANALYZE, not plain EXPLAIN.
commit : 9bb6b7c5ed617b34edf1a962c9405359822418d3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Oct 2014 18:50:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Oct 2014 18:50:16 -0400
We've gotten enough push-back on that change to make it clear that it
wasn't an especially good idea to do it like that. Revert plain EXPLAIN
to its previous behavior, but keep the extra output in EXPLAIN ANALYZE.
Per discussion.
Internally, I set this up as a separate flag ExplainState.summary that
controls printing of planning time and execution time. For now it's
just copied from the ANALYZE option, but we could consider exposing it
to users.
Don’t let protected variable access to be reordered after spinlock release.
commit : 4971c36b46c63c0b36a38df6a4b6ad9f303e4620
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 Oct 2014 10:01:00 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 Oct 2014 10:01:00 +0300
LWLockAcquireWithVar needs to set the protected variable while holding
the spinlock. Need to use a volatile pointer to make sure it doesn't get
reordered by the compiler. The other functions that accessed the protected
variable already got this right.
9.4 only. Earlier releases didn't have this code, and in master, spinlock
release acts as a compiler barrier.
Fix deadlock with LWLockAcquireWithVar and LWLockWaitForVar.
commit : 4dbc7606cfc8188646a2e302ef5e6a5ec3c962af
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 Oct 2014 09:55:26 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 Oct 2014 09:55:26 +0300
LWLockRelease should release all backends waiting with LWLockWaitForVar,
even when another backend has already been woken up to acquire the lock,
i.e. when releaseOK is false. LWLockWaitForVar can return as soon as the
protected value changes, even if the other backend will acquire the lock.
Fix that by resetting releaseOK to true in LWLockWaitForVar, whenever
adding itself to the wait queue.
This should fix the bug reported by MauMau, where the system occasionally
hangs when there is a lot of concurrent WAL activity and a checkpoint.
Backpatch to 9.4, where this code was added.
Fix typo in docs.
commit : 79ec6e399f1377a56633c0e4b4c8ed768c230ec2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 Oct 2014 09:45:00 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 Oct 2014 09:45:00 +0300
commit : 590eb0c14eebe834f716721a9659b77899cf3084
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 13 Oct 2014 22:17:34 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 13 Oct 2014 22:17:34 -0400
The way the ALTER VIEW / SET options were listed in the synopsis was
very confusing. Move the list to the main description, similar to how
the ALTER TABLE reference page does it.
doc: Fix copy-and-paste mistakes
commit : 44992e68375a27410089ad43a706ffa80f311783
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 13 Oct 2014 22:10:01 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 13 Oct 2014 22:10:01 -0400
commit : ec757c2735fdc6e845fd9edd8da65db35d9c4836
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 13 Oct 2014 22:07:30 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 13 Oct 2014 22:07:30 -0400
The previous quoting caused "make -C src/bin check" to ignore, rather
than add to, any LD_LIBRARY_PATH content from the environment.
Back-patch to 9.4, where the macro was introduced.
Suppress dead, unportable src/port/crypt.c code.
commit : 62698dae6b4fd066f8d4e4a4f0a41c3155769d3d
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Oct 2014 23:27:06 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Oct 2014 23:27:06 -0400
This file used __int64, which is specific to native Windows, rather than
int64. Suppress the long-unused union field of this type. Noticed on
Cygwin x86_64 with -lcrypt not installed. Back-patch to 9.0 (all
supported versions).
pg_recvlogical: Improve –help output
commit : 1b031ae62e7cdf2f99848cd35cdb2166babdaa87
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 12 Oct 2014 01:45:25 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 12 Oct 2014 01:45:25 -0400
List the actions first, as they are the most important options. Group
the other options more sensibly, consistent with the man page. Correct
a few typographical errors, clarify some things.
Also update the pg_receivexlog --help output to make it a bit more
consistent with that of pg_recvlogical.
Message improvements
commit : 7ce2a45aeb12d3d32a5b5e334f99a67264613fc1
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 12 Oct 2014 01:02:56 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 12 Oct 2014 01:02:56 -0400
Improve documentation about JSONB array containment behavior.
commit : 308ab77b89ec1662f24b5ab4013ff0d1bd4153a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Oct 2014 14:29:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Oct 2014 14:29:51 -0400
Fix bogus optimization in JSONB containment tests.
commit : 86b889494a71bd6c9574de04d6612d367bc5a423
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Oct 2014 14:13:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Oct 2014 14:13:54 -0400
When determining whether one JSONB object contains another, it's okay to
make a quick exit if the first object has fewer pairs than the second:
because we de-duplicate keys within objects, it is impossible that the
first object has all the keys the second does. However, the code was
applying this rule to JSONB arrays as well, where it does *not* hold
because arrays can contain duplicate entries. The test was really in
the wrong place anyway; we should do it within JsonbDeepContains, where
it can be applied to nested objects not only top-level ones.
Report and test cases by Alexander Korotkov; fix by Peter Geoghegan and
Tom Lane.
Fix broken example in PL/pgSQL document.
commit : a0c58b55220f190e8be9cfe0cadb4d478e13fac2
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 10 Oct 2014 03:18:01 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 10 Oct 2014 03:18:01 +0900
Back-patch to all supported branches.
Marti Raudsepp, per a report from Marko Tiikkaja
Fix array overrun in ecpg’s version of ParseDateTime().
commit : 80ddb590b6729fb398cad00b0774f2d10e954b0d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Oct 2014 21:23:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Oct 2014 21:23:20 -0400
The code wrote a value into the caller's field[] array before checking
to see if there was room, which of course is backwards. Per report from
Michael Paquier.
I fixed the equivalent bug in the backend's version of this code way back
in 630684d3a130bb93, but failed to think about ecpg's copy. Fortunately
this doesn't look like it would be exploitable for anything worse than a
core dump: an external attacker would have no control over the single word
that gets written.
Stamp 9.4beta3.
commit : abc1a8e509180a96dab45538643abeb25a955190
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Oct 2014 14:32:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Oct 2014 14:32:17 -0400
Rename pg_recvlogical’s –create/–drop to –create-slot/–drop-slot.
commit : 0cd700477466d260ed9c61d0af87df18f7cbfd1a
author : Andres Freund <andres@anarazel.de>
date : Mon, 6 Oct 2014 12:11:52 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 6 Oct 2014 12:11:52 +0200
A future patch (9.5 only) adds slot management to pg_receivexlog. The
verbs create/drop don't seem descriptive enough there. It seems better
to rename pg_recvlogical's commands now, in beta, than live with the
inconsistency forever.
The old form (e.g. --drop) will still be accepted by virtue of most
getopt_long() options accepting abbreviations for long commands.
Backpatch to 9.4 where pg_recvlogical was introduced.
Author: Michael Paquier and Andres Freund
Discussion: CAB7nPqQtt79U6FmhwvgqJmNyWcVCbbV-nS72j_jyPEopERg9rg@mail.gmail.com
Translation updates
commit : 6af3a67235ba6d31819bc7e4a2dae151721dc257
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 5 Oct 2014 23:22:24 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 5 Oct 2014 23:22:24 -0400
Update 9.4 release notes for commits through today.
commit : 0e7cb5fbd2f4fcdadfe697d5ed92b9b82e3529ef
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Oct 2014 14:14:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Oct 2014 14:14:07 -0400
Add entries for recent changes, including noting the JSONB format change
and the recent timezone data changes. We should remove those two items
before 9.4 final: the JSONB change will be of no interest in the long
run, and it's not normally our habit to mention timezone updates in
major-release notes. But it seems important to document them temporarily
for beta testers.
I failed to resist the temptation to wordsmith a couple of existing
entries, too.
Eliminate one background-worker-related flag variable.
commit : c6fda5a19f7d43089801f445733d48ba2a7229d4
author : Robert Haas <rhaas@postgresql.org>
date : Sat, 4 Oct 2014 21:25:41 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Sat, 4 Oct 2014 21:25:41 -0400
Teach sigusr1_handler() to use the same test for whether a worker
might need to be started as ServerLoop(). Aside from being perhaps
a bit simpler, this prevents a potentially-unbounded delay when
starting a background worker. On some platforms, select() doesn't
return when interrupted by a signal, but is instead restarted,
including a reset of the timeout to the originally-requested value.
If signals arrive often enough, but no connection requests arrive,
sigusr1_handler() will be executed repeatedly, but the body of
ServerLoop() won't be reached. This change ensures that, even in
that case, background workers will eventually get launched.
This is far from a perfect fix; really, we need select() to return
control to ServerLoop() after an interrupt, either via the self-pipe
trick or some other mechanism. But that's going to require more
work and discussion, so let's do this for now to at least mitigate
the damage.
Per investigation of test_shm_mq failures on buildfarm member anole.
Update time zone data files to tzdata release 2014h.
commit : bb7c8f99ac829c5fe5d3bd3a20b2642d55abdb62
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Oct 2014 14:18:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Oct 2014 14:18:29 -0400
Most zones in the Russian Federation are subtracting one or two hours
as of 2014-10-26. Update the meanings of the abbreviations IRKT, KRAT,
MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, YEKT to match.
The IANA timezone database has adopted abbreviations of the form AxST/AxDT
for all Australian time zones, reflecting what they believe to be current
majority practice Down Under. These names do not conflict with usage
elsewhere (other than ACST for Acre Summer Time, which has been in disuse
since 1994). Accordingly, adopt these names into our "Default" timezone
abbreviation set. The "Australia" abbreviation set now contains only
CST,EAST,EST,SAST,SAT,WST, all of which are thought to be mostly historical
usage. Note that SAST has also been changed to be South Africa Standard
Time in the "Default" abbreviation set.
Add zone abbreviations SRET (Asia/Srednekolymsk) and XJT (Asia/Urumqi),
and use WSST/WSDT for western Samoa.
Also a DST law change in the Turks & Caicos Islands (America/Grand_Turk),
and numerous corrections for historical time zone data.
Update time zone abbreviations lists.
commit : d13913c820c2b6ea418d51106c199d01c50eb14b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Oct 2014 17:44:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Oct 2014 17:44:38 -0400
This updates known_abbrevs.txt to be what it should have been already,
were my -P patch not broken; and updates some tznames/ entries that
missed getting any love in previous timezone data updates because zic
failed to flag the change of abbreviation.
The non-cosmetic updates:
* Remove references to "ADT" as "Arabia Daylight Time", an abbreviation
that's been out of use since 2007; therefore, claiming there is a conflict
with "Atlantic Daylight Time" doesn't seem especially helpful. (We have
left obsolete entries in the files when they didn't conflict with anything,
but that seems like a different situation.)
* Fix entirely incorrect GMT offsets for CKT (Cook Islands), FJT, FJST
(Fiji); we didn't even have them on the proper side of the date line.
(Seems to have been aboriginal errors in our tznames data; there's no
evidence anything actually changed recently.)
* FKST (Falkland Islands Summer Time) is now used all year round, so
don't mark it as a DST abbreviation.
* Update SAKT (Sakhalin) to mean GMT+11 not GMT+10.
In cosmetic changes, I fixed a bunch of wrong (or at least obsolete)
claims about abbreviations not being present in the zic files, and
tried to be consistent about how obsolete abbreviations are labeled.
Note the underlying timezone/data files are still at release 2014e;
this is just trying to get us in sync with what those files actually
say before we go to the next update.
Fix bogus logic for zic -P option.
commit : 03163139c9553c6ee4c26a73e21aaef5da22be45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Oct 2014 14:48:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Oct 2014 14:48:11 -0400
The quick hack I added to zic to dump out currently-in-use timezone
abbreviations turns out to have a nasty bug: within each zone, it was
printing the last "struct ttinfo" to be *defined*, not necessarily the
last one in use. This was mainly a problem in zones that had changed the
meaning of their zone abbreviation (to another GMT offset value) and later
changed it back.
As a result of this error, we'd missed out updating the tznames/ files
for some jurisdictions that have changed their zone abbreviations since
the tznames/ files were originally created. I'll address the missing data
updates in a separate commit.
Don’t balance vacuum cost delay when per-table settings are in effect
commit : 23a8cae6bcdadb1569336cf911cbeb772fda099b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 3 Oct 2014 13:01:27 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 3 Oct 2014 13:01:27 -0300
When there are cost-delay-related storage options set for a table,
trying to make that table participate in the autovacuum cost-limit
balancing algorithm produces undesirable results: instead of using the
configured values, the global values are always used,
as illustrated by Mark Kirkwood in
http://www.postgresql.org/message-id/52FACF15.8020507@catalyst.net.nz
Since the mechanism is already complicated, just disable it for those
cases rather than trying to make it cope. There are undesirable
side-effects from this too, namely that the total I/O impact on the
system will be higher whenever such tables are vacuumed. However, this
is seen as less harmful than slowing down vacuum, because that would
cause bloat to accumulate. Anyway, in the new system it is possible to
tweak options to get the precise behavior one wants, whereas with the
previous system one was simply hosed.
This has been broken forever, so backpatch to all supported branches.
This might affect systems where cost_limit and cost_delay have been set
for individual tables.
Check for GiST index tuples that don’t fit on a page.
commit : 925e10dc57cdf0efb7268a65b411f1e58ac5116d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 3 Oct 2014 12:07:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 3 Oct 2014 12:07:10 +0300
The page splitting code would go into infinite recursion if you try to
insert an index tuple that doesn't fit even on an empty page.
Per analysis and suggested fix by Andrew Gierth. Fixes bug #11555, reported
by Bryan Seitz (analysis happened over IRC). Backpatch to all supported
versions.
Fix typo in error message.
commit : 80f9a368be91d179cddd9666f8cb66132e52727d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Oct 2014 15:51:31 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Oct 2014 15:51:31 +0300
Fix some more problems with nested append relations.
commit : 07afbca2e7e8b1699ea2dc7b581d59c99287fff8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Oct 2014 19:30:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Oct 2014 19:30:27 -0400
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
Fix damange from wrongly split commit in fdf81c9a6cf94.
commit : 6d89b0860cba23761db3d08523c28e4da79bcbcd
author : Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 19:24:50 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 19:24:50 +0200
Unfortunately I mistakenly split the commit wrongly into two parts,
leaving one part of renaming StreamLog to StreamLogicalLog in the
second commit. Which isn't backported to 9.4...
Fix it in 9.4 only, as master already is 'fixed' by the subsequent
commit.
Noticed by Jan Wieck and the buildfarm.
pg_recvlogical.c code review.
commit : 0cadfee37fba0e60a763c62b2d9010b9a2f15b5e
author : Andres Freund <andres@anarazel.de>
date : Mon, 29 Sep 2014 15:35:40 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 29 Sep 2014 15:35:40 +0200
Several comments still referred to 'initiating', 'freeing', 'stopping'
replication slots. These were terms used during different phases of
the development of logical decoding, but are no long accurate.
Also rename StreamLog() to StreamLogicalLog() and add 'void' to the
prototype.
Author: Michael Paquier, with some editing by me.
Backpatch to 9.4 where pg_recvlogical was introduced.
Remove num_xloginsert_locks GUC, replace with a #define
commit : fc0acf43878bcd70dc1b701b054521d8553d2088
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 1 Oct 2014 16:37:15 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 1 Oct 2014 16:37:15 +0300
I left the GUC in place for the beta period, so that people could experiment
with different values. No-one's come up with any data that a different value
would be better under some circumstances, so rather than try to document to
users what the GUC, let's just hard-code the current value, 8.
Block signals while computing the sleep time in postmaster’s main loop.
commit : e14ed8e2f5382185c9cd0215bf88dc90eb1907cb
author : Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 14:23:43 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 14:23:43 +0200
DetermineSleepTime() was previously called without blocked
signals. That's not good, because it allows signal handlers to
interrupt its workings.
DetermineSleepTime() was added in 9.3 with the addition of background
workers (da07a1e856511), where it only read from
BackgroundWorkerList.
Since 9.4, where dynamic background workers were added (7f7485a0cde),
the list is also manipulated in DetermineSleepTime(). That's bad
because the list now can be persistently corrupted if modified by both
a signal handler and DetermineSleepTime().
This was discovered during the investigation of hangs on buildfarm
member anole. It's unclear whether this bug is the source of these
hangs or not, but it's worth fixing either way. I have confirmed that
it can cause crashes.
It luckily looks like this only can cause problems when bgworkers are
actively used.
Discussion: 20140929193733.GB14400@awork2.anarazel.de
Backpatch to 9.3 where background workers were introduced.
Improve documentation about binary/textual output mode for output plugins.
commit : ce84b0682cd169738797f74ec8acc1701b9da40c
author : Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 13:13:59 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 13:13:59 +0200
Discussion: CAB7nPqQrqFzjqCjxu4GZzTrD9kpj6HMn9G5aOOMwt1WZ8NfqeA@mail.gmail.com,
CAB7nPqQXc_+g95zWnqaa=mVQ4d3BVRs6T41frcEYi2ocUrR3+A@mail.gmail.com
Per discussion between Michael Paquier, Robert Haas and Andres Freund
Backpatch to 9.4 where logical decoding was introduced.
Rename CACHE_LINE_SIZE to PG_CACHE_LINE_SIZE.
commit : f78319fec8eb8aed34d6e1e43ca35fb0a9bfe108
author : Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 11:54:05 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 1 Oct 2014 11:54:05 +0200
As noted in http://bugs.debian.org/763098 there is a conflict between
postgres' definition of CACHE_LINE_SIZE and the definition by various
*bsd platforms. It's debatable who has the right to define such a
name, but postgres' use was only introduced in 375d8526f290 (9.4), so
it seems like a good idea to rename it.
Discussion: 20140930195756.GC27407@msg.df7cb.de
Per complaint of Christoph Berg in the above email, although he's not
the original bug reporter.
Backpatch to 9.4 where the define was introduced.
Correct stdin/stdout usage in COPY .. PROGRAM
commit : 721a8bb54602624b24d416f8d9b7b8f97701ecbd
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 30 Sep 2014 15:55:28 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 30 Sep 2014 15:55:28 -0400
The COPY documentation incorrectly stated, for the PROGRAM case,
that we read from stdin and wrote to stdout. Fix that, and improve
consistency by referring to the 'PostgreSQL' user instead of the
'postgres' user, as is done in the rest of the COPY documentation.
Pointed out by Peter van Dijk.
Back-patch to 9.3 where COPY .. PROGRAM was introduced.
Change JSONB’s on-disk format for improved performance.
commit : f6b7d4fbbb72cedd53adb3bf10428dab559bb909
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Sep 2014 12:29:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Sep 2014 12:29:24 -0400
The original design used an array of offsets into the variable-length
portion of a JSONB container. However, such an array is basically
uncompressible by simple compression techniques such as TOAST's LZ
compressor. That's bad enough, but because the offset array is at the
front, it tended to trigger the give-up-after-1KB heuristic in the TOAST
code, so that the entire JSONB object was stored uncompressed; which was
the root cause of bug #11109 from Larry White.
To fix without losing the ability to extract a random array element in O(1)
time, change this scheme so that most of the JEntry array elements hold
lengths rather than offsets. With data that's compressible at all, there
tend to be fewer distinct element lengths, so that there is scope for
compression of the JEntry array. Every N'th entry is still an offset.
To determine the length or offset of any specific element, we might have
to examine up to N preceding JEntrys, but that's still O(1) so far as the
total container size is concerned. Testing shows that this cost is
negligible compared to other costs of accessing a JSONB field, and that
the method does largely fix the incompressible-data problem.
While at it, rearrange the order of elements in a JSONB object so that
it's "all the keys, then all the values" not alternating keys and values.
This doesn't really make much difference right at the moment, but it will
allow providing a fast path for extracting individual object fields from
large JSONB values stored EXTERNAL (ie, uncompressed), analogously to the
existing optimization for substring extraction from large EXTERNAL text
values.
Bump catversion to denote the incompatibility in on-disk format.
We will need to fix pg_upgrade to disallow upgrading jsonb data stored
with 9.4 betas 1 and 2.
Heikki Linnakangas and Tom Lane
Fix identify_locking_dependencies for schema-only dumps.
commit : 4e23c47a3bb7a198c87940b6e9ac96edfa53962b
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 26 Sep 2014 11:21:35 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 26 Sep 2014 11:21:35 -0400
Without this fix, parallel restore of a schema-only dump can deadlock,
because when the dump is schema-only, the dependency will still be
pointing at the TABLE item rather than the TABLE DATA item.
Robert Haas and Tom Lane
Remove ill-conceived ban on zero length json object keys.
commit : d99d0e60eaa8334b698a070cb919202607660a65
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 25 Sep 2014 15:08:42 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 25 Sep 2014 15:08:42 -0400
We removed a similar ban on this in json_object recently, but the ban in
datum_to_json was left, which generate4d sprutious errors in othee json
generators, notable json_build_object.
Along the way, add an assertion that datum_to_json is not passed a null
key. All current callers comply with this rule, but the assertion will
catch any possible future misbehaviour.
Fix VPATH builds of the replication parser from git for some !gcc compilers.
commit : 2024ead21b8ac64f0d6cd13d0c1c2cb8d596238e
author : Andres Freund <andres@anarazel.de>
date : Thu, 25 Sep 2014 15:22:26 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 25 Sep 2014 15:22:26 +0200
Some compilers don't automatically search the current directory for
included files. 9cc2c182fc2 fixed that for builds from tarballs by
adding an include to the source directory. But that doesn't work when
the scanner is generated in the VPATH directory. Use the same search
path as the other parsers in the tree.
One compiler that definitely was affected is solaris' sun cc.
Backpatch to 9.1 which introduced using an actual parser for
replication commands.
Return NULL from json_object_agg if it gets no rows.
commit : bda1d14360404ef58c4647888032158991051b14
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 25 Sep 2014 08:18:18 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 25 Sep 2014 08:18:18 -0400
This makes it consistent with the docs and with all other builtin
aggregates apart from count().
Fix bogus variable-mangling in security_barrier_replace_vars().
commit : 54b8ed6c24736d7ad55f56dbaa2696ae05c4bded
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Sep 2014 15:59:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Sep 2014 15:59:37 -0400
This function created new Vars with varno different from varnoold, which
is a condition that should never prevail before setrefs.c does the final
variable-renumbering pass. The created Vars could not be seen as equal()
to normal Vars, which among other things broke equivalence-class processing
for them. The consequences of this were indeed visible in the regression
tests, in the form of failure to propagate constants as one would expect.
I stumbled across it while poking at bug #11457 --- after intentionally
disabling join equivalence processing, the security-barrier regression
tests started falling over with fun errors like "could not find pathkey
item to sort", because of failure to match the corrupted Vars to normal
ones.
Fix typos in descriptions of json_object functions.
commit : 2c7946e4b8a623f7972fd87f8a1226e48f74ca7f
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 24 Sep 2014 11:24:42 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 24 Sep 2014 11:24:42 -0400
Fix incorrect search for “x?” style matches in creviterdissect().
commit : 6eaf7e5bea958c93fda306c846997414184d2526
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Sep 2014 20:25:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Sep 2014 20:25:33 -0400
When the number of allowed iterations is limited (either a "?" quantifier
or a bound expression), the last sub-match has to reach to the end of the
target string. The previous coding here first tried the shortest possible
match (one character, usually) and then gave up and back-tracked if that
didn't work, typically leading to failure to match overall, as shown in
bug #11478 from Christoph Berg. The minimum change to fix that would be to
not decrement k before "goto backtrack"; but that would be a pretty stupid
solution, because we'd laboriously try each possible sub-match length
before finally discovering that only ending at the end can work. Instead,
force the sub-match endpoint limit up to the end for even the first
shortest() call if we cannot have any more sub-matches after this one.
Bug introduced in my rewrite that added the iterdissect logic, commit
173e29aa5deefd9e71c183583ba37805c8102a72. The shortest-first search code
was too closely modeled on the longest-first code, which hasn't got this
issue since it tries a match reaching to the end to start with anyway.
Back-patch to all affected branches.
Log ALTER SYSTEM statements as DDL
commit : fcfd7d26a2f99e99ad5bba6a982963dc3c9b0da0
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 22 Sep 2014 20:50:17 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 22 Sep 2014 20:50:17 -0400
Per discussion in bug #11350, log ALTER SYSTEM commands at the
log_statement=ddl level, rather than at the log_statement=all level.
Pointed out by Tomonari Katsumata.
Back-patch to 9.4 where ALTER SYSTEM was introduced.
Process withCheckOption exprs in setrefs.c
commit : c4bee09c0e1fc7fb2281ba1e125ab17c5e9a20e7
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 22 Sep 2014 20:22:16 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 22 Sep 2014 20:22:16 -0400
While withCheckOption exprs had been handled in many cases by
happenstance, they need to be handled during set_plan_references and
more specifically down in set_plan_refs for ModifyTable plan nodes.
This is to ensure that the opfuncid's are set for operators referenced
in the withCheckOption exprs.
Identified as an issue by Thom Brown
Patch by Dean Rasheed
Back-patch to 9.4, where withCheckOption was introduced.
Fix mishandling of CreateEventTrigStmt’s eventname field.
commit : e3e065d3779d82640e93298c06106c16c1948090
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 22 Sep 2014 16:05:51 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 22 Sep 2014 16:05:51 -0400
Fix failure of contrib/auto_explain to print per-node timing information.
commit : 47288bd08c0169ecb5eb50742336cc0df813777e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Sep 2014 13:18:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Sep 2014 13:18:59 -0400
This has been broken since commit af7914c6627bcf0b0ca614e9ce95d3f8056602bf,
which added the EXPLAIN (TIMING) option. Although that commit included
updates to auto_explain, they evidently weren't tested very carefully,
because the code failed to print node timings even when it should, due to
failure to set es.timing in the ExplainState struct. Reported off-list by
Neelakanth Nadgir of Salesforce.
In passing, clean up the documentation for auto_explain's options a
little bit, including re-ordering them into what seems to me a more
logical order.
Mark x86’s memory barrier inline assembly as clobbering the cpu flags.
commit : f9edfc1aa9ea4f0bae87eabcac261d82370c7de4
author : Andres Freund <andres@anarazel.de>
date : Fri, 19 Sep 2014 17:04:00 +0200
committer: Andres Freund <andres@anarazel.de>
date : Fri, 19 Sep 2014 17:04:00 +0200
x86's memory barrier assembly was marked as clobbering "memory" but
not "cc" even though 'addl' sets various flags. As it turns out gcc on
x86 implicitly assumes "cc" on every inline assembler statement, so
it's not a bug. But as that's poorly documented and might get copied
to architectures or compilers where that's not the case, it seems
better to be precise.
Discussion: 20140919100016.GH4277@alap3.anarazel.de
To keep the code common, backpatch to 9.2 where explicit memory
barriers were introduced.
Fix TAP checks when current directory name contains spaces
commit : 78b488d2e3d884e58a670f052400573b33824e04
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 17 Sep 2014 00:54:12 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 17 Sep 2014 00:54:12 -0400
Add some quotes in the makefile snippet that creates the temporary
installation, so that it can handle spaces in the directory name and
possibly some other oddities.
Fix the return type of GIN triConsistent support functions to “char”.
commit : 4c054ad18ecc4aa7fdc9a6760d029c64eaab1cdd
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 16 Sep 2014 09:11:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 16 Sep 2014 09:11:49 +0300
They were marked to return a boolean, but they actually return a
GinTernaryValue, which is more like a "char". It makes no practical
difference, as the triConsistent functions cannot be called directly from
SQL because they have "internal" arguments, but this nevertheless seems
more correct.
Also fix the GinTernaryValue name in the documentation. I renamed the enum
earlier, but neglected the docs.
Alexander Korotkov. This is new in 9.4, so backpatch there.
Handle border = 3 in expanded mode
commit : 1597e6c212d3930edb6f58390a511526cc043377
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 12 Sep 2014 11:24:09 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 12 Sep 2014 11:24:09 -0400
In psql, expanded mode was not being displayed correctly when using
the normal ascii or unicode linestyles and border set to '3'. Now,
per the documentation, border '3' is really only sensible for HTML
and LaTeX formats, however, that's no excuse for ascii/unicode to
break in that case, and provisions had been made for psql to cleanly
handle this case (and it did, in non-expanded mode).
This was broken when ascii/unicode was initially added a good five
years ago because print_aligned_vertical_line wasn't passed in the
border setting being used by print_aligned_vertical but instead was
given the whole printTableContent. There really isn't a good reason
for vertical_line to have the entire printTableContent structure, so
just pass in the printTextFormat and border setting (similar to how
this is handled in horizontal_line).
Pointed out by Pavel Stehule, fix by me.
Back-patch to all currently-supported versions.
This patch allows us to execute ALTER SYSTEM RESET command to
remove the configuration entry from postgresql.auto.conf.
Vik Fearing, reviewed by Amit Kapila and me.
Fix GIN data page split ratio calculation.
commit : 79ee6370ee803b36c2649cfb7655affa2c1007f1
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 12 Sep 2014 11:23:59 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 12 Sep 2014 11:23:59 +0300
The code that tried to split a page at 75/25 ratio, when appending to the
end of an index, was buggy in two ways. First, there was a silly typo that
caused it to just fill the left page as full as possible. But the logic as
it was intended wasn't correct either, and would actually have given a ratio
closer to 60/40 than 75/25.
Gaetano Mendola spotted the typo. Backpatch to 9.4, where this code was added.
Fix power_var_int() for large integer exponents.
commit : 1c603198a497173b4947fc669fdeda4706b09eb8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Sep 2014 23:30:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Sep 2014 23:30:54 -0400
The code for raising a NUMERIC value to an integer power wasn't very
careful about large powers. It got an outright wrong answer for an
exponent of INT_MIN, due to failure to consider overflow of the Abs(exp)
operation; which is fixable by using an unsigned rather than signed
exponent value after that point. Also, even though the number of
iterations of the power-computation loop is pretty limited, it's easy for
the repeated squarings to result in ridiculously enormous intermediate
values, which can take unreasonable amounts of time/memory to process,
or even overflow the internal "weight" field and so produce a wrong answer.
We can forestall misbehaviors of that sort by bailing out as soon as the
weight value exceeds what will fit in int16, since then the final answer
must overflow (if exp > 0) or underflow (if exp < 0) the packed numeric
format.
Per off-list report from Pavel Stehule. Back-patch to all supported
branches.
Fix vacuumdb –analyze-in-stages –all order
commit : 330bf85c4936fa6f0b59d4baad54cd8e1ce11604
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 11 Sep 2014 21:08:59 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 11 Sep 2014 21:08:59 -0400
When running vacuumdb --analyze-in-stages --all, it needs to run the
first stage across all databases before the second one, instead of
running all stages in a database before processing the next one.
Also respect the --quiet option with --analyze-in-stages.
pg_upgrade: preserve the timestamp epoch
commit : 022aea346def58d5dd17dd0e012f925e8688d439
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Sep 2014 18:39:46 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Sep 2014 18:39:46 -0400
This is useful for replication tools like Slony and Skytools. This is a
backpatch of a74a4aa23bb95b590ff01ee564219d2eacea3706.
Report by Sergey Konoplev
Backpatch through 9.3
Remove dead InRecovery check.
commit : b8b4124011322b7e376f9e21b3d335a85a28f54c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 11 Sep 2014 22:43:56 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 11 Sep 2014 22:43:56 +0300
The previous coding first generated a uniform random value between 0.0 and
1.0, then converted that to an integer between 1 and 10000, and divided that
again by 10000. Those conversions are unnecessary; we can use the double
value that pg_erand48() returns directly. While we're at it, put the logic
into a helper function, getPoissonRand().
The largest delay generated by the old coding was about 9.2 times the
average, because of the way the uniformly distributed value used for the
calculation was truncated to 1/10000 granularity. The new coding doesn't
have such clamping. With my laptop's DBL_MIN value, the maximum delay with
the new coding is about 700x the average. That seems acceptable - any
reasonable pgbench session should last long enough to average that out.
Backpatch to 9.4.
Change the way latency is calculated with pgbench –rate option.
commit : 8c9dd69fc2638701653c90bbf291884f8ca23d56
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 11 Sep 2014 12:40:01 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 11 Sep 2014 12:40:01 +0300
The reported latency values now include the "schedule lag" time, that is,
the time between the transaction's scheduled start time and the time it
actually started. This relates better to a model where requests arrive at a
certain rate, and we are interested in the response time to the end user or
application, rather than the response time of the database itself.
Also, when --rate is used, include the schedule lag time in the log output.
The --rate option is new in 9.4, so backpatch to 9.4. It seems better to
make this change in 9.4, while we're still in the beta period, than ship a
9.4 version that calculates the values differently than 9.5.
Handle old versions of Test::More
commit : 958a828fea254307d7699aea4310f0654dc48990
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 10 Sep 2014 20:39:28 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 10 Sep 2014 20:39:28 -0400
Apparently, older versions of "prove" (couldn't identify the exact
version from the changelog) don't look into the t/ directory for tests
by default, so specify it explicitly.
doc: improve configuration management section
commit : 1e6ba64080d0906e428cc3f58e612f8c237fc755
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 10 Sep 2014 20:50:15 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 10 Sep 2014 20:50:15 -0400
Preserve AND/OR flatness while extracting restriction OR clauses.
commit : f003419791f35eeab0150cd097bcf7929622b0fc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Sep 2014 18:35:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Sep 2014 18:35:17 -0400
The code I added in commit f343a880d5555faf1dad0286c5632047c8f599ad was
careless about preserving AND/OR flatness: it could create a structure with
an OR node directly underneath another one. That breaks an assumption
that's fairly important for planning efficiency, not to mention triggering
various Asserts (as reported by Benjamin Smith). Add a trifle more logic
to handle the case properly.
Fix typo in solaris spinlock fix.
commit : 21dcc48dc7ec48bf7b2a40c619e1c96ca4d2477c
author : Andres Freund <andres@anarazel.de>
date : Tue, 9 Sep 2014 13:57:38 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 9 Sep 2014 13:57:38 +0200
Some Sparc CPUs can be run in various coherence models, ranging from
RMO (relaxed) over PSO (partial) to TSO (total). Solaris has always
run CPUs in TSO mode while in userland, but linux didn't use to and
the various *BSDs still don't. Unfortunately the sparc TAS/S_UNLOCK
were only correct under TSO. Fix that by adding the necessary memory
barrier instructions. On sparcv8+, which should be all relevant CPUs,
these are treated as NOPs if the current consistency model doesn't
require the barriers.
Discussion: 20140630222854.GW26930@awork2.anarazel.de
Will be backpatched to all released branches once a few buildfarm
cycles haven't shown up problems. As I've no access to sparc, this is
blindly written.
doc: Reflect renaming of Mac OS X to OS X
commit : 18af7938c1efa1ad18c876fcc471020c0ad9db07
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 9 Sep 2014 13:56:29 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 9 Sep 2014 13:56:29 -0400
Now that ALTER TABLE .. ALL IN TABLESPACE has replaced the previous
ALTER TABLESPACE approach, it makes sense to move the calls down in
to ProcessUtilitySlow where the rest of ALTER TABLE is handled.
This also means that event triggers will support ALTER TABLE .. ALL
(which was the impetus for the original change, though it has other
good qualities also).
Álvaro Herrera
Back-patch to 9.4 as the original rework was.
Fix psql \s to work with recent libedit, and add pager support.
commit : fd66ccf7db638664a7867cc18e253d770c783d33
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Sep 2014 16:09:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Sep 2014 16:09:49 -0400
psql's \s (print command history) doesn't work at all with recent libedit
versions when printing to the terminal, because libedit tries to do an
fchmod() on the target file which will fail if the target is /dev/tty.
(We'd already noted this in the context of the target being /dev/null.)
Even before that, it didn't work pleasantly, because libedit likes to
encode the command history file (to ensure successful reloading), which
renders it nigh unreadable, not to mention significantly different-looking
depending on exactly which libedit version you have. So let's forget using
write_history() for this purpose, and instead print the data ourselves,
using logic similar to that used to iterate over the history for newline
encoding/decoding purposes.
While we're at it, insert the ability to use the pager when \s is printing
to the terminal. This has been an acknowledged shortcoming of \s for many
years, so while you could argue it's not exactly a back-patchable bug fix
it still seems like a good improvement. Anyone who's seriously annoyed
at this can use "\s /dev/tty" or local equivalent to get the old behavior.
Experimentation with this showed that the history iteration logic was
actually rather broken when used with libedit. It turns out that with
libedit you have to use previous_history() not next_history() to advance
to more recent history entries. The easiest and most robust fix for this
seems to be to make a run-time test to verify which function to call.
We had not noticed this because libedit doesn't really need the newline
encoding logic: its own encoding ensures that command entries containing
newlines are reloaded correctly (unlike libreadline). So the effective
behavior with recent libedits was that only the oldest history entry got
newline-encoded or newline-decoded. However, because of yet other bugs in
history_set_pos(), some old versions of libedit allowed the existing loop
logic to reach entries besides the oldest, which means there may be libedit
~/.psql_history files out there containing encoded newlines in more than
just the oldest entry. To ensure we can reload such files, it seems
appropriate to back-patch this fix, even though that will result in some
incompatibility with older psql versions (ie, multiline history entries
written by a psql with this fix will look corrupted to a psql without it,
if its libedit is reasonably up to date).
Stepan Rutz and Tom Lane
Documentation fix: sum(float4) returns float4, not float8.
commit : b1a7c9e387f77b85aa14eb342f0432fcdb6ddc35
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Sep 2014 22:40:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Sep 2014 22:40:41 -0400
The old claim is from my commit d06ebdb8d3425185d7e641d15e45908658a0177d of
2000-07-17, but it seems to have been a plain old thinko; sum(float4) has
been distinct from sum(float8) since Berkeley days. Noted by KaiGai Kohei.
While at it, mention the existence of sum(money), which is also of
embarrassingly ancient vintage.
Tab completion for ALTER .. ALL IN TABLESPACE
commit : 4231599328f75d6549831f65223a22236a43a5c9
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 7 Sep 2014 08:04:35 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 7 Sep 2014 08:04:35 -0400
Update the tab completion for the changes made in
3c4cf080879b386d4ed1814667aca025caafe608, which rework 'MOVE ALL' to be
'ALTER .. ALL IN TABLESPACE'.
Fujii Masao
Back-patch to 9.4, as the original change was.
docs: Improve pg_isready details about username/dbname
commit : 31189e8627cdbdb72d16d0314d95b1aea913e616
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 6 Sep 2014 12:43:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 6 Sep 2014 12:43:11 -0400
The link to the NIST web page about DES standards leads to nowhere, and
according to archive.org has been forwarded to an unrelated page for
many years. Therefore, just remove that link. More up to date
information can be found via Wikipedia, for example.
Fix segmentation fault that an empty prepared statement could cause.
The syntax summary previously failed to clarify that the first
argument is also optional. The textual description did mention it,
but all the way at the bottom. It fits better with the command
overview, so move it there, and fix the summary also.
Back-patch to 9.4 where \pset without arguments was supported.
Dilip Kumar, reviewed by Fabien Coelho
Update URL reference material in /contrib/isn docs
commit : 42c73ef9b7e5eb552b972bc05335746f54e34f98
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 3 Sep 2014 17:22:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 3 Sep 2014 17:22:20 -0400
The regression tests for contrib/test_decoding regularly failed on
postgres instances that were very slow. Either because the hardware
itself was slow or because very expensive debugging options like
CLOBBER_CACHE_ALWAYS were used.
The reason they failed was just that some additional transactions were
decoded. Analyze and vacuum, triggered by autovac.
To fix just add a option to test_decoding to only display transactions
in which a change was actually displayed. That's not pretty because it
removes information from the tests; but better than constantly failing
tests in very likely harmless ways.
Backpatch to 9.4 where logical decoding was introduced.
Discussion: 20140629142511.GA26930@awork2.anarazel.de
Declare lwlock.c’s LWLockAcquireCommon() as a static inline.
commit : 92b2c136580869fe9286a4d880d592d74f55d5b7
author : Andres Freund <andres@anarazel.de>
date : Mon, 1 Sep 2014 00:17:18 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 1 Sep 2014 00:17:18 +0200
68a2e52bbaf98f136 has introduced LWLockAcquireCommon() containing the
previous contents of LWLockAcquire() plus added functionality. The
latter then calls it, just like LWLockAcquireWithVar(). Because the
majority of callers don't need the added functionality, declare the
common code as inline. The compiler then can optimize away the unused
code. Doing so is also useful when looking at profiles, to
differentiate the users.
Backpatch to 9.4, the first branch to contain LWLockAcquireCommon().
doc: Various typo/grammar fixes
commit : ae70b9f0ec1f967aa84844274f26f519450b6b49
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 30 Aug 2014 11:01:47 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 30 Aug 2014 11:01:47 -0500
Errors detected using Topy (https://github.com/intgr/topy), all
changes verified by hand and some manual tweaks added.
Marti Raudsepp
Individual changes backpatched, where applicable, as far as 9.0.
commit : f08b5e7577e70f9aee80d04e94864bb5053f7555
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 29 Aug 2014 09:05:35 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 29 Aug 2014 09:05:35 -0400
Also update docs to mention which function are super-user-only.
Report by sys-milan@statpro.com
Backpatch through 9.4
Fix bug in compressed GIN data leaf page splitting code.
commit : 08bff295a7e7ac66a35f42e92e97782b9af64cdc
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 29 Aug 2014 14:19:34 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 29 Aug 2014 14:19:34 +0300
The list of posting lists it's dealing with can contain placeholders for
deleted posting lists. The placeholders are kept around so that they can
be WAL-logged, but we must be careful to not try to access them.
This fixes bug #11280, reported by Mårten Svantesson. Backpatch to 9.4,
where the compressed data leaf page code was added.
Assorted message improvements
commit : c573e9d7760869a0db6343b2a7353309045e05ab
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 29 Aug 2014 00:01:34 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 29 Aug 2014 00:01:34 -0400
commit : f41381e240f4312017f9f70fea194e59d8cc3a2e
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 28 Aug 2014 23:59:03 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 28 Aug 2014 23:59:03 -0400
It was changed when ALTER TABLESPACE / MOVE was added but then not
updated when that was moved back out.
Fix citext upgrade script for disallowance of oidvector element assignment.
commit : c45af8fa111ea381b428ab31adcaa5ecd032f06a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Aug 2014 18:21:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Aug 2014 18:21:11 -0400
In commit 45e02e3232ac7cc5ffe36f7986159b5e0b1f6fdc, we intentionally
disallowed updates on individual elements of oidvector columns. While that
still seems like a sane idea in the abstract, we (I) forgot that citext's
"upgrade from unpackaged" script did in fact perform exactly such updates,
in order to fix the problem that citext indexes should have a collation
but would not in databases dumped or upgraded from pre-9.1 installations.
Even if we wanted to add casts to allow such updates, there's no practical
way to do so in the back branches, so the only real alternative is to make
citext's kluge even klugier. In this patch, I cast the oidvector to text,
fix its contents with regexp_replace, and cast back to oidvector. (Ugh!)
Since the aforementioned commit went into all active branches, we have to
fix this in all branches that contain the now-broken update script.
Per report from Eric Malm.
Fix FOR UPDATE NOWAIT on updated tuple chains
commit : eeab936ba94de70ee5f03e167331f1399914b6db
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Aug 2014 19:15:18 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Aug 2014 19:15:18 -0400
If SELECT FOR UPDATE NOWAIT tries to lock a tuple that is concurrently
being updated, it might fail to honor its NOWAIT specification and block
instead of raising an error.
Fix by adding a no-wait flag to EvalPlanQualFetch which it can pass down
to heap_lock_tuple; also use it in EvalPlanQualFetch itself to avoid
blocking while waiting for a concurrent transaction.
Authors: Craig Ringer and Thomas Munro, tweaked by Álvaro
http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com
Per Thomas Munro in the course of his SKIP LOCKED feature submission,
who also provided one of the isolation test specs.
Backpatch to 9.4, because that's as far back as it applies without
conflicts (although the bug goes all the way back). To that branch also
backpatch Thomas Munro's new NOWAIT test cases, committed in master by
Heikki as commit 9ee16b49f0aac819bd4823d9b94485ef608b34e8 .
Fix Var handling for security barrier views
commit : d4b8418a04f41dc991dc364a0a6eab64b16f2e83
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 26 Aug 2014 23:08:41 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 26 Aug 2014 23:08:41 -0400
In some cases, not all Vars were being correctly marked as having been
modified for updatable security barrier views, which resulted in invalid
plans (eg: when security barrier views were created over top of
inheiritance structures).
In passing, be sure to update both varattno and varonattno, as _equalVar
won't consider the Vars identical otherwise. This isn't known to cause
any issues with updatable security barrier views, but was noticed as
missing while working on RLS and makes sense to get fixed.
Back-patch to 9.4 where updatable security barrier views were
introduced.
Fix superuser concurrent refresh of matview owned by another.
commit : 06414c0f68e9f8039c1de40d009f12fa96c49192
author : Kevin Grittner <kgrittn@postgresql.org>
date : Tue, 26 Aug 2014 10:00:42 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Tue, 26 Aug 2014 10:00:42 -0500
Use SECURITY_LOCAL_USERID_CHANGE while building temporary tables;
only escalate to SECURITY_RESTRICTED_OPERATION while potentially
running user-supplied code. The more secure mode was preventing
temp table creation. Add regression tests to cover this problem.
This fixes Bug #11208 reported by Bruno Emanuel de Andrade Silva.
Backpatch to 9.4, where the bug was introduced.
upgrade docs: highlight pg_upgrade, warn about globals preservation
commit : 3a3d3f9ec01f1f7333e3bbcd5ba9398fd19ad8d9
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 25 Aug 2014 15:34:50 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 25 Aug 2014 15:34:50 -0400
There's no point in setting up a context error callback when doing
conditional lock acquisition, because we never actually wait and so the
able wouldn't be able to see it.
Backpatch to 9.4, where this was added.
Fix typos in some error messages thrown by extension scripts when fed to psql.
commit : 0bfce7618420c6f1eece55577c61ef2a7a12f80b
author : Andres Freund <andres@anarazel.de>
date : Mon, 25 Aug 2014 18:30:28 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 25 Aug 2014 18:30:28 +0200
Some of the many error messages introduced in 458857cc missed 'FROM
unpackaged'. Also e016b724 and 45ffeb7e forgot to quote extension
version numbers.
Backpatch to 9.1, just like 458857cc which introduced the messages. Do
so because the error messages thrown when the wrong command is copy &
pasted aren't easy to understand.
Don’t track DEALLOCATE in pg_stat_statements.
commit : 642aadff7ff6704e2afee360ca98b78a4fba6629
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Aug 2014 19:13:24 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Aug 2014 19:13:24 +0300
We also don't track PREPARE, nor do we track planning time in general, so
let's ignore DEALLOCATE as well for consistency.
Backpatch to 9.4, but not further than that. Although it seems unlikely that
anyone is relying on the current behavior, this is a behavioral change.
Fabien Coelho
doc: Improve pg_restore help output
commit : 73e47b703b3b5bfc3a76029b0895b1173ae9ad76
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 23 Aug 2014 00:23:34 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 23 Aug 2014 00:23:34 -0400
Add a note that some options can be specified multiple times to select
multiple objects to restore. This replaces the somewhat confusing use
of plurals in the option descriptions themselves.
Fix outdated comment
commit : 25eda23679433ee35972f9e4411a628e19b8cd57
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 22 Aug 2014 13:55:34 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 22 Aug 2014 13:55:34 -0400
Fix corner-case behaviors in JSON/JSONB field extraction operators.
commit : 15247948cc19e74b20af15020b48bee4aec771e9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Aug 2014 13:18:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Aug 2014 13:18:00 -0400
Cause the path extraction operators to return their lefthand input,
not NULL, if the path array has no elements. This seems more consistent
since the case ought to correspond to applying the simple extraction
operator (->) zero times.
Cause other corner cases in field/element/path extraction to return NULL
rather than failing. This behavior is arguably more useful than throwing
an error, since it allows an expression index using these operators to be
built even when not all values in the column are suitable for the
extraction being indexed. Moreover, we already had multiple
inconsistencies between the path extraction operators and the simple
extraction operators, as well as inconsistencies between the JSON and
JSONB code paths. Adopt a uniform rule of returning NULL rather than
throwing an error when the JSON input does not have a structure that
permits the request to be satisfied.
Back-patch to 9.4. Update the release notes to list this as a behavior
change since 9.3.
Fix comment in pg_basebackup.
commit : 32d93e8c2da5387a8d5efdd4df1e5fb9bcfa9bb2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Aug 2014 13:45:38 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Aug 2014 13:45:38 +0300
The option is called --tablespace-mapping, not --tablespace.
Amit Kapila
Change the way pg_basebackup’s tablespace mapping is implemented.
commit : 8a22633f52f2399118d6ad3c2c4da6a31f07e907
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Aug 2014 10:16:26 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Aug 2014 10:16:26 +0300
Previously, we would first create the symlinks the way they are in the
original system, and at the end replace them with the mapped symlinks.
That never really made much sense, so now we create the symlink pointing
to the correct location to begin with, so that there's no need to fix
them at the end.
The old coding didn't work correctly on Windows, because Windows junction
points look more like directories than files, and ought to be removed with
rmdir rather than unlink. Also, it incorrectly used "%d" rather than "%u"
to print an Oid, but that's gone now.
Report and patch by Amit Kapila, with minor changes by me. Reviewed by
MauMau. Backpatch to 9.4, where the --tablespace feature was added.
Rework ‘MOVE ALL’ to ‘ALTER .. ALL IN TABLESPACE’
commit : d9b2bc45cf75f913490f1b3ce9b9263509b26704
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 21 Aug 2014 19:06:17 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 21 Aug 2014 19:06:17 -0400
As 'ALTER TABLESPACE .. MOVE ALL' really didn't change the tablespace
but instead changed objects inside tablespaces, it made sense to
rework the syntax and supporting functions to operate under the
'ALTER (TABLE|INDEX|MATERIALIZED VIEW)' syntax and to be in
tablecmds.c.
Pointed out by Alvaro, who also suggested the new syntax.
Back-patch to 9.4.
More regression test cases for json/jsonb extraction operators.
commit : 9243417801be3f1cfaa3a3c33d5a003f382bd7a4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Aug 2014 19:05:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Aug 2014 19:05:09 -0400
Cover some cases I omitted before, such as null and empty-string
elements in the path array. This exposes another inconsistency:
json_extract_path complains about empty path elements but
jsonb_extract_path does not.
Fix core dump in jsonb #> operator, and add regression test cases.
commit : 04db8747840f581177c6622008d2e42d3528f7fe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Aug 2014 16:48:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Aug 2014 16:48:37 -0400
jsonb's #> operator segfaulted (dereferencing a null pointer) if the RHS
was a zero-length array, as reported in bug #11207 from Justin Van Winkle.
json's #> operator returns NULL in such cases, so for the moment let's
make jsonb act likewise.
Also add a bunch of regression test queries memorializing the -> and #>
operators' behavior for this and other corner cases.
There is a good argument for changing some of these behaviors, as they
are not very consistent with each other, and throwing an error isn't
necessarily a desirable behavior for operators that are likely to be
used in indexes. However, everybody can agree that a core dump is the
Wrong Thing, and we need test cases even if we decide to change their
expected output later.
Revert “Fix bug in checking of IDENTIFY_SYSTEM result.”
commit : e0d010f64ca2b3b7d41ca961549388cf4fbe8aed
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 19 Aug 2014 18:30:38 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 19 Aug 2014 18:30:38 +0900
This reverts commit 083d29c65b7897f90c70e6dc0a4240a5fa75c8f2.
The commit changed the code so that it causes an errors when
IDENTIFY_SYSTEM returns three columns. But which prevents us
from using the replication-related utilities against the server
with older version. This is not what we want. For that
compatibility, we allow the utilities to receive three columns
as the result of IDENTIFY_SYSTEM eventhough it actually returns
four columns in 9.4 or later.
Pointed out by Andres Freund.
Fix bug in checking of IDENTIFY_SYSTEM result.
commit : c41996b18c0bb1cbf7bdcdf6a01da8e3cbce9fc8
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 19 Aug 2014 17:26:07 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 19 Aug 2014 17:26:07 +0900
5a991ef8692ed0d170b44958a81a6bd70e90585 added new column into
the result of IDENTIFY_SYSTEM command. But it was not reflected into
several codes checking that result. Specifically though the number of
columns in the result was increased to 4, it was still compared with 3
in some replication codes.
Back-patch to 9.4 where the number of columns in IDENTIFY_SYSTEM
result was increased.
Report from Michael Paquier
Install libpq DLL with $(INSTALL_SHLIB).
commit : 151ce45825b317a9e06c40ddb48917bde9dc94fa
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 23:00:38 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 23:00:38 -0400
Programs need execute permission on a DLL file to load it. MSYS
"install" ignores the mode argument, and our Cygwin build statically
links libpq into programs. That explains the lack of buildfarm trouble.
Back-patch to 9.0 (all supported versions).
Make pg_service.conf sample LDIF more portable.
commit : 48e0b5ff3795a827c558a9ca7863fbfdbff6d683
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 22:58:57 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 22:58:57 -0400
The aboriginal sample placed connection parameters in
groupOfUniqueNames/uniqueMember. OpenLDAP, at least as early as version
2.4.23, rejects uniqueMember entries that do not conform to the syntax
for a distinguished name. Use device/description, which is free-form.
Back-patch to 9.4 for web site visibility.
Document new trigger-related forms of ALTER FOREIGN TABLE.
commit : a611d2afb0f2ea1de8262dc132aaa0d5aaa3dbf2
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 22:58:25 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 22:58:25 -0400
Oversight in commit 7cbe57c34dec4860243e6d0f81738cfbb6e5d069.
Back-patch to 9.4, where that commit first appeared. In passing,
release-note the FDW API postcondition change from the same commit.
Adjust Release Notes to reflect holding off wrapped expanded mode until 9.5 (thanks Michael Paquier)
commit : 61947069ffb27a7eb8037cbd7756dbcbb06ebd4a
author : Greg Stark <stark@mit.edu>
date : Mon, 18 Aug 2014 13:59:41 +0100
committer: Greg Stark <stark@mit.edu>
date : Mon, 18 Aug 2014 13:59:41 +0100
Revert psql changes to support wrapped expanded mode. That feature is nice and we’ll keep it in 9.5 but it’ll take more time to iron out the collateral damage on other queries and also on tools like check_postgres.
commit : 7e81c4b2901d8a692cc4e8c839a5a6490fc345e4
author : Greg Stark <stark@mit.edu>
date : Mon, 18 Aug 2014 11:28:57 +0100
committer: Greg Stark <stark@mit.edu>
date : Mon, 18 Aug 2014 11:28:57 +0100
Fix obsolete mention of non-int64 support in CREATE SEQUENCE documentation.
commit : f304ddc5cefff167e702c044269d75df2d5b4508
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Aug 2014 01:17:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Aug 2014 01:17:49 -0400
The old text explained what happened if we didn't have working int64
arithmetic. Since that case has been explicitly rejected by configure
since 8.4.3, documenting it in the 9.x branches can only produce confusion.
Use ISO 8601 format for dates converted to JSON, too.
commit : 560e2300b2ab395a367153e37d445fd584281cf7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Aug 2014 22:57:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Aug 2014 22:57:20 -0400
Commit f30015b6d794c15d52abbb3df3a65081fbefb1ed made this happen for
timestamp and timestamptz, but it seems pretty inconsistent to not
do it for simple dates as well.
(In passing, I re-pgindent'd json.c.)
Add missing index terms for replication commands in the document.
commit : 3b2f4aa0f0fe23b0cac753f91833df353994d298
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 18 Aug 2014 11:18:53 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 18 Aug 2014 11:18:53 +0900
Previously only CREATE_REPLICATION_SLOT was exposed as an index term.
That's odd and there is no reason not to add index terms for other
replication commands.
Back-patch to 9.4.
Make an editorial pass over the 9.4 release notes.
commit : 912c70bb8db05a4a7599e43e3a79599957daa301
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Aug 2014 22:26:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Aug 2014 22:26:49 -0400
Update the notes to include commits through today, and do a lot of
wordsmithing and markup adjustment. Notably, don't use <link> where <xref>
will do; since we got rid of the text-format HISTORY file, there is no
longer a reason to avoid <xref>.
Improve DISCARD documentation.
commit : 1071ba183a2181f109cbd5b2a597637b3b145a8c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Aug 2014 15:59:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 17 Aug 2014 15:59:06 -0400
The new DISCARD SEQUENCES option was inadequately described, and hadn't
been mentioned at all in the initial Description paragraph. Rather than
rectifying the latter the hard way, it seemed better to rewrite the
description as a summary, instead of having it basically duplicate
statements made under Parameters. Be more consistent about the ordering
of the options, too.
doc: Work around stylesheet bug for man build
commit : 3d5ba5395aa0437c45441d2ca7b0973cbd060305
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 17 Aug 2014 09:10:28 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 17 Aug 2014 09:10:28 -0400
The upstream stylesheets for man output insert a *roff comment for an
occurrence of an indexterm, for reasons that have apparently been lost
in history. This, however, is done incorrectly and causes some
formatting problems. This hasn't been an issue until now, but the
reorganization of indexterm elements inside variablelists has triggered
this issue.
The upstream fix (http://sourceforge.net/p/docbook/bugs/1340/) is to
drop indexterms altogether in man output, and so we'll do the same here.
Fix bogus return macros in range_overright_internal().
commit : 364f7cd4b6d2bb89be55c8915fcd08b69b5eb84e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Aug 2014 13:48:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Aug 2014 13:48:43 -0400
PG_RETURN_BOOL() should only be used in functions following the V1 SQL
function API. This coding accidentally fails to fail since letting the
compiler coerce the Datum representation of bool back to plain bool
does give the right answer; but that doesn't make it a good idea.
Back-patch to older branches just to avoid unnecessary code divergence.
Fix bogus commutator/negator links for JSONB containment operators.
commit : 30c05261ae842e2475fb06c7746de8623bcca731
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Aug 2014 12:53:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Aug 2014 12:53:57 -0400
<@ and @> are each other's commutators, but they were incorrectly marked
as being each other's negators instead. (This was actually questioned
in a comment in the original commit, but nobody followed through :-(.)
Per bug #11178 from Christian Pronovost.
In passing, fix some JSONB operator descriptions that were randomly
different from the phrasing of every other similar description.
catversion bump for pg_catalog contents change.
Remove remnants of a JENTRY_ISFIRST flag bit.
commit : a4eaa07bd011cba36921757489ab941f0b652587
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 15 Aug 2014 09:39:38 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 15 Aug 2014 09:39:38 +0300
I removed the flag earlier, but missed a few references in jsonb.h.
Set shared library path for in-tree TAP tests
commit : 0964db851d8bb6805d41f66a663bd129fa3cbea0
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 15 Aug 2014 00:01:14 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 15 Aug 2014 00:01:14 -0400
When the TAP tests are run in-tree (make check), set the shared library
path using the appropriate environment variable, using a logic similar
to pg_regress, so that the right libraries are used.
Update SysV parameter configuration documentation for FreeBSD.
commit : 5086be023ac4205fe1003079a99803112cbaffa5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Aug 2014 16:05:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Aug 2014 16:05:49 -0400
FreeBSD hasn't made any use of kern.ipc.semmap since 1.1, and newer
releases reject attempts to set it altogether; so stop recommending
that it be adjusted. Per bug #11161.
Back-patch to all supported branches. Before 9.3, also incorporate
commit 7a42dff47, which touches the same text and for some reason
was not back-patched at the time.
Fix help message in pg_ctl.
commit : f3ab265052429793acf7a838a565b6d63b093914
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 14 Aug 2014 13:57:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 14 Aug 2014 13:57:52 +0900
Previously the help message described that -m is an option for
"stop", "restart" and "promote" commands in pg_ctl. But actually
that's not an option for "promote". So this commit fixes that
incorrect description in the help message.
Back-patch to 9.3 where the incorrect description was added.
Expose -S option in pg_receivexlog.
commit : 7c77ba8577d52b142997303f14c1e01abdb2d104
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 13 Aug 2014 10:45:28 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 13 Aug 2014 10:45:28 +0900
This option is equivalent to --slot option which pg_receivexlog has
already supported, which specifies the replication slot to use for
WAL streaming. pg_recvlogical has already supported both options,
and this commit makes pg_receivexlog consistent with pg_recvlogical
regarding the slot option.
Back-patch to 9.4 where the slot option was added.
Michael Paquier
pg_recvlogical message and code improvements.
commit : 876f1e6805c34bb87525583e524e3445a33c215b
author : Andres Freund <andres@anarazel.de>
date : Tue, 12 Aug 2014 11:12:16 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 12 Aug 2014 11:12:16 +0200
Some error messages complained about --init and --stop being used
whereas the --create and --drop are the correct verbs. Fix that.
Also a XLogRecPtr was tested in a boolean fashion instead of being
compared to InvalidXLogRecPtr.
Backpatch to 9.4 where pg_recvlogical was introduced.
Michael Paquier
Be less aggressive in asking for feedback of logical walsender clients.
commit : 423f73df9dcb9fd5b05fb1ed17bd636245bb90f3
author : Andres Freund <andres@anarazel.de>
date : Tue, 12 Aug 2014 11:04:50 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 12 Aug 2014 11:04:50 +0200
When doing logical decoding using START_LOGICAL_REPLICATION in a
walsender process the walsender sometimes was sending out keepalive
messages too frequently. Asking for feedback every time.
WalSndWaitForWal() sends out keepalive messages when it's waiting for
new WAL to be generated locally when it sees that the remote side
hasn't yet flushed WAL up to the local position. That generally is
good but causes problems if the remote side only writes but doesn't
flush changes yet. So check for both remote write and flush position.
Additionally we've asked for feedback to the keepalive message which
isn't warranted when waiting for WAL in contrast to preventing
timeouts because of wal_sender_timeout.
Complaint and patch by Steve Singer.
Change first call of ProcessConfigFile so as to process only data_directory.
commit : 700f060528b1485970e6414fbf96aa1f87766a40
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 12 Aug 2014 16:50:09 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 12 Aug 2014 16:50:09 +0900
When both postgresql.conf and postgresql.auto.conf have their own entry of
the same parameter, PostgreSQL uses the entry in postgresql.auto.conf because
it appears last in the configuration scan. IOW, the other entries which appear
earlier are ignored. But, previously, ProcessConfigFile() detected the invalid
settings of even those unused entries and emitted the error messages
complaining about them, at postmaster startup. Complaining about the entries
to ignore is basically useless.
This problem happened because ProcessConfigFile() was called twice at
postmaster startup and the first call read only postgresql.conf. That is, the
first call could check the entry which might be ignored eventually by
the second call which read both postgresql.conf and postgresql.auto.conf.
To work around the problem, this commit changes ProcessConfigFile so that
its first call processes only data_directory and the second one does all the
entries. It's OK to process data_directory in the first call because it's
ensured that data_directory doesn't exist in postgresql.auto.conf.
Back-patch to 9.4 where postgresql.auto.conf was added.
Patch by me. Review by Amit Kapila
Fix documentation oversights about pageinspect and initialization fork.
commit : 44ea72d28066103b3d1df9a3e9476f52c56e06cc
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 11 Aug 2014 22:52:16 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 11 Aug 2014 22:52:16 +0900
The initialization fork was added in 9.1, but has not been taken into
consideration in documents of get_raw_page function in pageinspect and
storage layout. This commit fixes those oversights.
get_raw_page can read not only a table but also an index, etc. So it
should be documented that the function can read any relation. This commit
also fixes the document of pageinspect that way.
Back-patch to 9.1 where those oversights existed.
Vik Fearing, review by MauMau
Clarify type resolution behavior for domain types.
commit : 5d20643532cafd719482119d250c919edcac93b7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Aug 2014 16:13:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Aug 2014 16:13:16 -0400
The user documentation was vague and not entirely accurate about how
we treat domain inputs for ambiguous operators/functions. Clarify
that, and add an example and some commentary. Per a recent question
from Adam Mackler.
It's acted like this ever since we added domains, so back-patch
to all supported branches.
Clean up handling of unknown-type inputs in json_build_object and friends.
commit : 2591e623f5fc80a49347fb5e106aa1e03f713429
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 17:31:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 17:31:16 -0400
There's actually no need for any special case for unknown-type literals,
since we only need to push the value through its output function and
unknownout() works fine. The code that was here was completely bizarre
anyway, and would fail outright in cases that should work, not to mention
suffering from some copy-and-paste bugs.
Further cleanup of JSON-specific error messages.
commit : 84dd042a51e702a3761250e2ce801b3fb2b879c3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 16:35:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 16:35:32 -0400
Fix an obvious typo in json_build_object()'s complaint about invalid
number of arguments, and make the errhint a bit more sensible too.
Per discussion about how to word the improved hint, change the few places
in the documentation that refer to JSON object field names as "names" to
say "keys" instead, since that's what we've said in the vast majority of
places in the docs. Arguably "name" is more correct, since that's the
terminology used in RFC 7159; but we're stuck with "key" in view of the
naming of json_object_keys() so let's at least be self-consistent.
I adjusted a few code comments to match this as well, and failed to
resist the temptation to clean up some odd whitespace choices in the
same area, as well as a useless duplicate PG_ARGISNULL() check. There's
still quite a bit of code that uses the phrase "field name" in non-user-
visible ways, so I left those usages alone.
Reject duplicate column names in foreign key referenced-columns lists.
commit : 2f9912335c198f7ee8ec8c46a72f947c9c1c2257
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 13:46:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 13:46:38 -0400
Such cases are disallowed by the SQL spec, and even if we wanted to allow
them, the semantics seem ambiguous: how should the FK columns be matched up
with the columns of a unique index? (The matching could be significant in
the presence of opclasses with different notions of equality, so this issue
isn't just academic.) However, our code did not previously reject such
cases, but instead would either fail to match to any unique index, or
generate a bizarre opclass-lookup error because of sloppy thinking in the
index-matching code.
David Rowley
Small message fixes
commit : 213f0ff938949df3dd64cddd8c71f2da59812216
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 9 Aug 2014 00:07:00 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 9 Aug 2014 00:07:00 -0400
commit : 6749cd4e41ef68ba2ffe368487ec1b98fb0a974f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Aug 2014 20:46:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Aug 2014 20:46:44 -0400
s/XIDs XIDs/XIDs/ in one place in maintenance.sgml.
Guillaume Lelarge
pg_upgrade: prevent oid conflicts with new-cluster TOAST tables
commit : f445b368d357332fb8392384ee4d75f21f07c5bb
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 7 Aug 2014 14:56:13 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 7 Aug 2014 14:56:13 -0400
Previously, TOAST tables only required in the new cluster could cause
oid conflicts if they were auto-numbered and a later conflicting oid had
to be assigned.
Backpatch through 9.3
Fix alternate regression test output file.
commit : dc431f41672611d5575e330209784adad73b4f0d
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 6 Aug 2014 11:18:38 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 6 Aug 2014 11:18:38 -0400
When more than one setting entries of same parameter exist in the
configuration file, PostgreSQL uses only entry appearing last in
configuration file scan. Since the other entries are not used,
ParseConfigFp() doesn't need to process them, but previously it did
that. This problematic behavior caused the configuration file scan
to detect invalid settings of unused entries (e.g., existence of
multiple entries of PGC_POSTMASTER parameter) and log the messages
complaining about them.
This commit changes the configuration file scan so that it processes
only last entry of each parameter.
Note that when multiple entries of same parameter exist both in
postgresql.conf and postgresql.auto.conf, unused entries in
postgresql.conf are still processed only at postmaster startup.
The problem has existed since old version, but a user is more likely
to encounter it since 9.4 where ALTER SYSTEM command was introduced.
So back-patch to 9.4.
Amit Kapila, slightly modified by me. Per report from Christoph Berg.
Improve some JSON error messages.
commit : 930e8ad738f5c78abd667626ca86f2553f36356f
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 5 Aug 2014 12:26:25 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 5 Aug 2014 12:26:25 -0400
These messages are new in 9.4, which hasn't been released yet, so
back-patch to REL9_4_STABLE.
Daniele Varrazzo
pg_upgrade: remove reference to autovacuum_multixact_freeze_max_age
commit : 1337b3bbc2d821837e580fa232b714270e7ccd90
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 4 Aug 2014 11:45:45 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 4 Aug 2014 11:45:45 -0400
autovacuum_multixact_freeze_max_age was added as a pg_ctl start
parameter in 9.3.X to prevent autovacuum from running. However, only
some 9.3.X releases have autovacuum_multixact_freeze_max_age as it was
added in a minor PG 9.3 release. It also isn't needed because -b turns
off autovacuum in 9.1+.
Without this fix, trying to upgrade from an early 9.3 release to 9.4
would fail.
Report by EDB
Backpatch through 9.3
Add missing PQclear() calls into pg_receivexlog.
commit : 7cf7dc759c5c23703c1ac9e2808a2a059b0b02dc
author : Fujii Masao <fujii@postgresql.org>
date : Sat, 2 Aug 2014 15:18:09 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Sat, 2 Aug 2014 15:18:09 +0900
In 9.2, pg_receivexlog with verbose option has emitted the messages
at the end of each WAL file. But the commit 0b63291 suppressed such
messages by mistake. This commit fixes the bug so that pg_receivexlog
--verbose outputs such messages again.
Back-patch to 9.3 where the bug was added.
Fix typo in user manual
commit : d5186cf270c0860932bd8a03897eb78f43dc88fe
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 1 Aug 2014 21:13:17 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 1 Aug 2014 21:13:17 +0300
Avoid wholesale autovacuuming when autovacuum is nominally off.
commit : a95f7fb761eea4b323973671f86dc406612a5d11
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Jul 2014 14:41:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Jul 2014 14:41:35 -0400
When autovacuum is nominally off, we will still launch autovac workers
to vacuum tables that are at risk of XID wraparound. But after we'd done
that, an autovac worker would proceed to autovacuum every table in the
targeted database, if they meet the usual thresholds for autovacuuming.
This is at best pretty unexpected; at worst it delays response to the
wraparound threat. Fix it so that if autovacuum is nominally off, we
*only* do forced vacuums and not any other work.
Per gripe from Andrey Zhidenkov. This has been like this all along,
so back-patch to all supported branches.
Fix mishandling of background worker PGPROCs in EXEC_BACKEND builds.
commit : aeebacff114634ffa07b5299ee6c41b219717bc3
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Jul 2014 11:25:58 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Jul 2014 11:25:58 -0400
InitProcess() relies on IsBackgroundWorker to decide whether the PGPROC
for a new backend should be taken from ProcGlobal's freeProcs or from
bgworkerFreeProcs. In EXEC_BACKEND builds, InitProcess() is called
sooner than in non-EXEC_BACKEND builds, and IsBackgroundWorker wasn't
getting initialized soon enough.
Report by Noah Misch. Diagnosis and fix by me.
doc: Clean up some recently added PL/pgSQL documentation
commit : 98c5fe5d0df8549972f46c324d9c6b18b4c4ecc0
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 29 Jul 2014 23:47:16 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 29 Jul 2014 23:47:16 -0400
- Capitalize titles consistently.
- Fix some grammar.
- Group "Obtaining Information About an Error" under "Trapping Errors",
but make "Obtaining the Call Stack Context Information" its own
section, since it's not about errors.
Oops, fix recoveryStopsBefore functions for regular commits.
commit : 5b7f1f52107941a819cdf587216b86081cd967e2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 29 Jul 2014 17:16:59 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 29 Jul 2014 17:16:59 +0300
There were several oversights in recovery code where COMMIT/ABORT PREPARED
records were ignored:
* pg_last_xact_replay_timestamp() (wasn't updated for 2PC commits)
* recovery_min_apply_delay (2PC commits were applied immediately)
* recovery_target_xid (recovery would not stop if the XID used 2PC)
The first of those was reported by Sergiy Zuban in bug #11032, analyzed by
Tom Lane and Andres Freund. The bug was always there, but was masked before
commit d19bd29f07aef9e508ff047d128a4046cc8bc1e2, because COMMIT PREPARED
always created an extra regular transaction that was WAL-logged.
Backpatch to all supported versions (older versions didn't have all the
features and therefore didn't have all of the above bugs).
Reword the sentence for pg_logical_slot_peek_changes function.
Previously the duplicated paragraphs were used next to each other
in the document to demonstrate that the changes in the stream
were not consumed by pg_logical_slot_peek_changes function.
But some users misunderstood that the duplication of the same
paragraph was just typo. So this commit rewords the sentence in
the latter paragraph for less confusing.
Christoph Moench-Tegeder
Fix obsolete statement in smgr/README.
commit : 5307c993637674692ef71bcd41ff2412b03de914
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Jul 2014 16:30:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Jul 2014 16:30:14 -0400
The documentation of ALTER TABLESPACE ... MOVE was added without any
markup, not even paragraph breaks. Fix that, and clarify the text in a
few places.
Fix a performance problem in pg_dump’s dump order selection logic.
commit : a8dddcaf758159059a83e147a960b369e9e3ab96
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Jul 2014 19:48:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Jul 2014 19:48:45 -0400
findDependencyLoops() was not bright about cases where there are multiple
dependency paths between the same two dumpable objects. In most scenarios
this did not hurt us too badly; but since the introduction of section
boundary pseudo-objects in commit a1ef01fe163b304760088e3e30eb22036910a495,
it was possible for this code to take unreasonable amounts of time (tens
of seconds on a database with a couple thousand objects), as reported in
bug #11033 from Joe Van Dyk. Joe's particular problem scenario involved
"pg_dump -a" mode with long chains of foreign key constraints, but I think
that similar problems could arise with other situations as long as there
were enough objects. To fix, add a flag array that lets us notice when we
arrive at the same object again while searching from a given start object.
This simple change seems to be enough to eliminate the performance problem.
Back-patch to 9.1, like the patch that introduced section boundary objects.
Prevent shm_mq_send from reading uninitialized memory.
commit : df58a17df29f7ec0ffc8389deee46e81a2a58a60
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Jul 2014 09:19:50 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Jul 2014 09:19:50 -0400
shm_mq_send_bytes didn't invariably initialize *bytes_written before
returning, which would cause shm_mq_send to read from uninitialized
memory and add the value it found there to mqh->mqh_partial_bytes.
This could cause the next attempt to send a message via the queue to
fail an assertion (if the queue was detached) or copy data from a
garbage pointer value into the queue (if non-blocking mode was in use).
Fix checkpointer crash in EXEC_BACKEND builds.
commit : 3372f1adad12bc70321fdf22f3c11ac67e429f63
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Jul 2014 09:04:59 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Jul 2014 09:04:59 -0400
Nothing in the checkpointer calls InitXLOGAccess(), so WALInsertLocks
never got initialized there. Without EXEC_BACKEND, it works anyway
because the correct value is inherited from the postmaster, but
with EXEC_BACKEND we've got a problem. The problem appears to have
been introduced by commit 68a2e52bbaf98f136a96b3a0d734ca52ca440a95.
To fix, move the relevant initialization steps from InitXLOGAccess()
to XLOGShmemInit(), making this more parallel to what we do
elsewhere.
Amit Kapila
Properly remove ephemeral replication slots after a crash restart.
commit : fece13d7477720bcbf02af795bed695c54d1250c
author : Andres Freund <andres@anarazel.de>
date : Thu, 24 Jul 2014 14:32:34 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 24 Jul 2014 14:32:34 +0200
Ephemeral slots - slots that shouldn't survive database restarts -
weren't properly cleaned up after a immediate/crash restart. They were
ignored in the sense that they weren't restored into memory and thus
didn't cause unwanted resource retention; but they prevented a new
slot with the same name from being created.
Now ephemeral slots are fully removed during startup.
Backpatch to 9.4 where replication slots where added.
Avoid access to already-released lock in LockRefindAndRelease.
commit : 8da262879ef5e53620b9e6a0da82510d09c105cb
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Jul 2014 08:19:19 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Jul 2014 08:19:19 -0400
commit : 7a8715b9886ef2970b89edb7e8ab2a195e0f1e0d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jul 2014 15:20:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jul 2014 15:20:34 -0400
Break the list of available options into an <itemizedlist> instead of
inline sentences. This is mostly motivated by wanting to ensure that the
cross-references to the FSM and VM docs don't cross page boundaries in PDF
format; but it seems to me to read more easily this way anyway. I took the
liberty of editorializing a bit further while at it.
Per complaint from Magnus about 9.0.18 docs not building in A4 format.
Patch all active branches so we don't get blind-sided by this particular
issue again in future.
Report success when Windows kill() emulation signals an exiting process.
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and log messages about kill() reporting "Invalid argument" will
cease to appear for this not-unexpected condition.
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
Re-enable error for “SELECT … OFFSET -1”.
commit : 30d6a9858cd8389e59d652d9919761dc095326c5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jul 2014 13:30:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jul 2014 13:30:01 -0400
The executor has thrown errors for negative OFFSET values since 8.4 (see
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain
fade I taught the planner that OFFSET with a constant negative value was a
no-op (commit 1a1832eb085e5bca198735e5d0e766a3cb61b8fc). Reinstate the
former behavior by only discarding OFFSET with a value of exactly 0. In
passing, adjust a planner comment that referenced the ancient behavior.
Back-patch to 9.3 where the mistake was introduced.
Check block number against the correct fork in get_raw_page().
commit : 1ea941450bca70ec9e30c2936e99835f9649f865
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jul 2014 11:45:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jul 2014 11:45:50 -0400
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was too weak (allowing a
lower-level error to be reported, but no real harm to be done).
However, very small tables could have an FSM larger than their heap,
in which case the mistake prevented access to some FSM pages.
Per report from Torsten Foertsch.
In passing, make the bad-block-number error into an ereport not elog
(since it's certainly not an internal error); and fix sloppily
maintained comment for RelationGetNumberOfBlocksInFork.
This has been wrong since we invented relation forks, so back-patch
to all supported branches.
Allow empty string object keys in json_object().
commit : a61f63df7d19006b36adf7ee402999aa5243097d
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 22 Jul 2014 11:22:47 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 22 Jul 2014 11:22:47 -0400
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite. Back-patch to 9.0 (all supported versions).
Unset some local environment variables in TAP tests
commit : 87c4232fd35fc3d1ff06189e886bffb382f6ca87
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 22 Jul 2014 00:42:36 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 22 Jul 2014 00:42:36 -0400
Unset environment variables that control message language, so that we
can compare some program output with expected strings. This is very
similar to what pg_regress does.
gitattributes: Ignore time zone data files for whitespace checks
commit : 2cf489301e0487ea7bedde488e1b52ede862d058
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Jul 2014 23:58:18 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Jul 2014 23:58:18 -0400
commit : ecb2d583ca6b248a94c8b53e74dac1ec863a4db7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 22:41:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 22:41:23 -0400
In commit 631dc390f49909a5c8ebd6002cfb2bcee5415a9d, we started to handle
simple numeric timezone offsets via the zic library instead of the old
CTimeZone/HasCTZSet kluge. However, we overlooked the fact that the zic
code will reject UTC offsets exceeding a week (which seems a bit arbitrary,
but not because it's too tight ...). This led to possibly setting
session_timezone to NULL, which results in crashes in most timezone-related
operations as of 9.4, and crashes in a small number of places even before
that. So check for NULL return from pg_tzset_offset() and report an
appropriate error message. Per bug #11014 from Duncan Gillis.
Back-patch to all supported branches, like the previous patch.
(Unfortunately, as of today that no longer includes 8.4.)
Stamp 9.4beta2.
commit : c85374626f680902c207285b986ac38a134535eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 15:07:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 15:07:50 -0400
Release notes for 9.3.5, 9.2.9, 9.1.14, 9.0.18, 8.4.22.
commit : ab2f504b2e8b4e90e44c9a20bb5d481794b39d1d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 14:59:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 14:59:25 -0400
commit : 3622b6be0fa8082f60eee2dd373f68911861118b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 12:58:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 12:58:44 -0400
Defend against bad relfrozenxid/relminmxid/datfrozenxid/datminmxid values.
commit : d122387d7d9149fdb9589ebdaf52c763464e4cd5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 11:41:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 11:41:30 -0400
In commit a61daa14d56867e90dc011bbba52ef771cea6770, we fixed pg_upgrade so
that it would install sane relminmxid and datminmxid values, but that does
not cure the problem for installations that were already pg_upgraded to
9.3; they'll initially have "1" in those fields. This is not a big problem
so long as 1 is "in the past" compared to the current nextMultiXact
counter. But if an installation were more than halfway to the MXID wrap
point at the time of upgrade, 1 would appear to be "in the future" and
that would effectively disable tracking of oldest MXIDs in those
tables/databases, until such time as the counter wrapped around.
While in itself this isn't worse than the situation pre-9.3, where we did
not manage MXID wraparound risk at all, the consequences of premature
truncation of pg_multixact are worse now; so we ought to make some effort
to cope with this. We discussed advising users to fix the tracking values
manually, but that seems both very tedious and very error-prone.
Instead, this patch adopts two amelioration rules. First, a relminmxid
value that is "in the future" is allowed to be overwritten with a
full-table VACUUM's actual freeze cutoff, ignoring the normal rule that
relminmxid should never go backwards. (This essentially assumes that we
have enough defenses in place that wraparound can never occur anymore,
and thus that a value "in the future" must be corrupt.) Second, if we see
any "in the future" values then we refrain from truncating pg_clog and
pg_multixact. This prevents loss of clog data until we have cleaned up
all the broken tracking data. In the worst case that could result in
considerable clog bloat, but in practice we expect that relfrozenxid-driven
freezing will happen soon enough to fix the problem before clog bloat
becomes intolerable. (Users could do manual VACUUM FREEZEs if not.)
Note that this mechanism cannot save us if there are already-wrapped or
already-truncated-away MXIDs in the table; it's only capable of dealing
with corrupt tracking values. But that's the situation we have with the
pg_upgrade bug.
For consistency, apply the same rules to relfrozenxid/datfrozenxid. There
are not known mechanisms for these to get messed up, but if they were, the
same tactics seem appropriate for fixing them.
Translation updates
commit : 4bcdfb930e0477def194a651f043eaf9c8b82818
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Jul 2014 01:07:36 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Jul 2014 01:07:36 -0400
commit : be72263635dc95b4ada1bda3494c815fbd8987c3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Jul 2014 22:20:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Jul 2014 22:20:38 -0400
Rather remarkable that this has been wrong since 9.1 and nobody noticed.
Update time zone data files to tzdata release 2014e.
commit : e5ea60e80bf0b2941c63c64d0a9de4f103ec8d58
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Jul 2014 15:00:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Jul 2014 15:00:50 -0400
DST law changes in Crimea, Egypt, Morocco. New zone Antarctica/Troll
for Norwegian base in Queen Maud Land.
Partial fix for dropped columns in functions returning composite.
commit : f0a497e4c499b3283b10d6092388413f9a565d65
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Jul 2014 14:28:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Jul 2014 14:28:25 -0400
When a view has a function-returning-composite in FROM, and there are
some dropped columns in the underlying composite type, ruleutils.c
printed junk in the column alias list for the reconstructed FROM entry.
Before 9.3, this was prevented by doing get_rte_attribute_is_dropped
tests while printing the column alias list; but that solution is not
currently available to us for reasons I'll explain below. Instead,
check for empty-string entries in the alias list, which can only exist
if that column position had been dropped at the time the view was made.
(The parser fills in empty strings to preserve the invariant that the
aliases correspond to physical column positions.)
While this is sufficient to handle the case of columns dropped before
the view was made, we have still got issues with columns dropped after
the view was made. In particular, the view could contain Vars that
explicitly reference such columns! The dependency machinery really
ought to refuse the column drop attempt in such cases, as it would do
when trying to drop a table column that's explicitly referenced in
views. However, we currently neglect to store dependencies on columns
of composite types, and fixing that is likely to be too big to be
back-patchable (not to mention that existing views in existing databases
would not have the needed pg_depend entries anyway). So I'll leave that
for a separate patch.
Pre-9.3, ruleutils would print such Vars normally (with their original
column names) even though it suppressed their entries in the RTE's
column alias list. This is certainly bogus, since the printed view
definition would fail to reload, but at least it didn't crash. However,
as of 9.3 the printed column alias list is tightly tied to the names
printed for Vars; so we can't treat columns as dropped for one purpose
and not dropped for the other. This is why we can't just put back the
get_rte_attribute_is_dropped test: it results in an assertion failure
if the view in fact contains any Vars referencing the dropped column.
Once we've got dependencies preventing such cases, we'll probably want
to do it that way instead of relying on the empty-string test used here.
This fix turned up a very ancient bug in outfuncs/readfuncs, namely
that T_String nodes containing empty strings were not dumped/reloaded
correctly: the node was printed as "<>" which is read as a string
value of <>. Since (per SQL) we disallow empty-string identifiers,
such nodes don't occur normally, which is why we'd not noticed.
(Such nodes aren't used for literal constants, just identifiers.)
Per report from Marc Schablewski. Back-patch to 9.3 which is where
the rule printing behavior changed. The dangling-variable case is
broken all the way back, but that's not what his complaint is about.
Limit pg_upgrade authentication advice to always-secure techniques.
~/.pgpass is a sound choice everywhere, and "peer" authentication is
safe on every platform it supports. Cease to recommend "trust"
authentication, the safety of which is deeply configuration-specific.
Back-patch to 9.0, where pg_upgrade was introduced.
Fix two low-probability memory leaks in regular expression parsing.
commit : 4a66f0f2d5a758f282549555feec4541c35588c4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Jul 2014 13:00:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Jul 2014 13:00:27 -0400
If pg_regcomp failed after having invoked markst/cleanst, it would leak any
"struct subre" nodes it had created. (We've already detected all regex
syntax errors at that point, so the only likely causes of later failure
would be query cancel or out-of-memory.) To fix, make sure freesrnode
knows the difference between the pre-cleanst and post-cleanst cleanup
procedures. Add some documentation of this less-than-obvious point.
Also, newlacon did the wrong thing with an out-of-memory failure from
realloc(), so that the previously allocated array would be leaked.
Both of these are pretty low-probability scenarios, but a bug is a bug,
so patch all the way back.
Per bug #10976 from Arthur O'Dwyer.
doc: Spell checking
commit : 9fb149573dee5dc0b2849b4cdee5d5ffe83313d9
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 16 Jul 2014 22:20:15 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 16 Jul 2014 22:20:15 -0400
The consistent function contained several bugs:
* The "if (which2) { ... }" block was broken. It compared the argument's
lower bound against centroid's upper bound, while it was supposed to compare
the argument's upper bound against the centroid's lower bound (the comment
was correct, code was wrong). Also, it cleared bits in the "which1"
variable, while it was supposed to clear bits in "which2".
* If the argument's upper bound was equal to the centroid's lower bound, we
descended to both halves (= all quadrants). That's unnecessary, searching
the right quadrants is sufficient. This didn't lead to incorrect query
results, but was clearly wrong, and slowed down queries unnecessarily.
* In the case that argument's lower bound is adjacent to the centroid's
upper bound, we also don't need to visit all quadrants. Per similar
reasoning as previous point.
* The code where we compare the previous centroid with the current centroid
should match the code where we compare the current centroid with the
argument. The point of that code is to redo the calculation done in the
previous level, to see if we were supposed to traverse left or right (or up
or down), and if we actually did. If we moved in the different direction,
then we know there are no matches for bound.
Refactor the code and adds comments to make it more readable and easier to
reason about.
Backpatch to 9.3 where SP-GiST support for range types was introduced.
Move check for SSL_get_current_compression to run on mingw
commit : 0e34d82538bd48fc537d512539cee014654a45e1
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 15 Jul 2014 22:00:56 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 15 Jul 2014 22:00:56 +0200
Trying to reassign objects owned by a user that had text search
dictionaries or configurations used to fail with:
ERROR: unexpected classid 3600
or
ERROR: unexpected classid 3602
Fix by adding cases for those object types in a switch in pg_shdepend.c.
Both REASSIGN OWNED and text search objects go back all the way to 8.1,
so backpatch to all supported branches. In 9.3 the alter-owner code was
made generic, so the required change in recent branches is pretty
simple; however, for 9.2 and older ones we need some additional
reshuffling to enable specifying objects by OID rather than name.
Text search templates and parsers are not owned objects, so there's no
change required for them.
Per bug #9749 reported by Michal Novotný
Detect presence of SSL_get_current_compression
commit : 5e4c9b37312e7d9dcb88e1e0a1fc279c780dd89e
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 15 Jul 2014 18:04:43 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 15 Jul 2014 18:04:43 +0200
Apparently we still build against OpenSSL so old that it doesn't
have this function, so add an autoconf check for it to make the
buildfarm happy. If the function doesn't exist, always return
that compression is disabled, since presumably the actual
compression functionality is always missing.
For now, hardcode the function as present on MSVC, since we should
hopefully be well beyond those old versions on that platform.
Add missing source files to nls.mk
commit : 77b41010dbb159b77b35aef02b517ce1a130f3b6
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 15 Jul 2014 10:00:53 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 15 Jul 2014 10:00:53 -0400
Both the psql banner and the connection logging already included
SSL status, cipher and bitlength, this adds the information about
compression being on or off.
Add missing serial commas
commit : 350651905decd60637e583837d3bb3aa5d9164b6
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 15 Jul 2014 08:25:27 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 15 Jul 2014 08:25:27 -0400
EXPLAIN ANALYZE shows the information of the numbers of exact/lossy blocks which
bitmap heap scan processes. But, previously, when those numbers were both zero,
it displayed only the prefix "Heap Blocks:" in TEXT output format. This is strange
and would confuse the users. So this commit suppresses such unnecessary information.
Backpatch to 9.4 where EXPLAIN ANALYZE was changed so that such information was
displayed.
Etsuro Fujita
Fix decoding of consecutive MULTI_INSERTs emitted by one heap_multi_insert().
commit : 22ccce5206717036a06aefdf3f9f78ed9ffaab2f
author : Andres Freund <andres@anarazel.de>
date : Sat, 12 Jul 2014 14:28:19 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 12 Jul 2014 14:28:19 +0200
Commit 1b86c81d2d fixed the decoding of toasted columns for the rows
contained in one xl_heap_multi_insert record. But that's not actually
enough, because heap_multi_insert() will actually first toast all
passed in rows and then emit several *_multi_insert records; one for
each page it fills with tuples.
Add a XLOG_HEAP_LAST_MULTI_INSERT flag which is set in
xl_heap_multi_insert->flag denoting that this multi_insert record is
the last emitted by one heap_multi_insert() call. Then use that flag
in decode.c to only set clear_toast_afterwards in the right situation.
Expand the number of rows inserted via COPY in the corresponding
regression test to make sure that more than one heap page is filled
with tuples by one heap_multi_insert() call.
Backpatch to 9.4 like the previous commit.
Add autocompletion of locale keywords for CREATE DATABASE
commit : bb4d05c026a7b811fa081d994bc02133fb6d13b1
author : Magnus Hagander <magnus@hagander.net>
date : Sat, 12 Jul 2014 14:19:57 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Sat, 12 Jul 2014 14:19:57 +0200
Adds support for autocomplete of LC_COLLATE and LC_CTYPE to
the CREATE DATABASE command in psql.
Fix bug with whole-row references to append subplans.
commit : f280eff94974d4f50a927120d45580bb14c27e87
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Jul 2014 19:12:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Jul 2014 19:12:38 -0400
ExecEvalWholeRowVar incorrectly supposed that it could "bless" the source
TupleTableSlot just once per query. But if the input is coming from an
Append (or, perhaps, other cases?) more than one slot might be returned
over the query run. This led to "record type has not been registered"
errors when a composite datum was extracted from a non-blessed slot.
This bug has been there a long time; I guess it escaped notice because when
dealing with subqueries the planner tends to expand whole-row Vars into
RowExprs, which don't have the same problem. It is possible to trigger
the problem in all active branches, though, as illustrated by the added
regression test.
Rename logical decoding’s pg_llog directory to pg_logical.
commit : 6fe24405fa2e79d653daaf5c078e2a9d0a4b2c0c
author : Andres Freund <andres@anarazel.de>
date : Wed, 2 Jul 2014 21:07:47 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 2 Jul 2014 21:07:47 +0200
The old name wasn't very descriptive as of actual contents of the
directory, which are historical snapshots in the snapshots/
subdirectory and mappingdata for rewritten tuples in
mappings/. There's been a fair amount of discussion what would be a
good name. I'm settling for pg_logical because it's likely that
further data around logical decoding and replication will need saving
in the future.
Also add the missing entry for the directory into storage.sgml's list
of PGDATA contents.
Bumps catversion as the data directories won't be compatible.
Backpatch to 9.4, which I missed to do as Michael Paquier luckily
noticed. As there already has been a catversion bump after 9.4beta1,
there's no reasons for having 9.4 diverge from master.
Fix whitespace
commit : 8adb4769954f072636a1c139517d08b6ba860779
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 8 Jul 2014 23:29:09 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 8 Jul 2014 23:29:09 -0400
Don’t assume a subquery’s output is unique if there’s a SRF in its tlist.
commit : ac45aa1dde2dd690682bf74f7535ba6d1a87bff8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Jul 2014 14:03:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Jul 2014 14:03:16 -0400
While the x output of "select x from t group by x" can be presumed unique,
this does not hold for "select x, generate_series(1,10) from t group by x",
because we may expand the set-returning function after the grouping step.
(Perhaps that should be re-thought; but considering all the other oddities
involved with SRFs in targetlists, it seems unlikely we'll change it.)
Put a check in query_is_distinct_for() so it's not fooled by such cases.
Back-patch to all supported branches.
David Rowley
doc: Fix spacing in verbatim environments
commit : 443dd97001c4cdb78ec388fffd5780ddccb3218f
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 8 Jul 2014 11:39:07 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 8 Jul 2014 11:39:07 -0400
Previously, when calculations on the need for toast tables changed,
pg_upgrade could not handle cases where the new cluster needed a TOAST
table and the old cluster did not. (It already handled the opposite
case.) This fixes the "OID mismatch" error typically generated in this
case.
Backpatch through 9.2
Fix decoding of MULTI_INSERTs when rows other than the last are toasted.
commit : d54712e7cf2e8925d1e04782a0aec88eae2be72c
author : Andres Freund <andres@anarazel.de>
date : Sun, 6 Jul 2014 15:58:01 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 6 Jul 2014 15:58:01 +0200
When decoding the results of a HEAP2_MULTI_INSERT (currently only
generated by COPY FROM) toast columns for all but the last tuple
weren't replaced by their actual contents before being handed to the
output plugin. The reassembled toast datums where disregarded after
every REORDER_BUFFER_CHANGE_(INSERT|UPDATE|DELETE) which is correct
for plain inserts, updates, deletes, but not multi inserts - there we
generate several REORDER_BUFFER_CHANGE_INSERTs for a single
xl_heap_multi_insert record.
To solve the problem add a clear_toast_afterwards boolean to
ReorderBufferChange's union member that's used by modifications. All
row changes but multi_inserts always set that to true, but
multi_insert sets it only for the last change generated.
Add a regression test covering decoding of multi_inserts - there was
none at all before.
Backpatch to 9.4 where logical decoding was introduced.
Bug found by Petr Jelinek.
Consistently pass an “unsigned char” to ctype.h functions.
The isxdigit() calls relied on undefined behavior. The isascii() call
was well-defined, but our prevailing style is to include the cast.
Back-patch to 9.4, where the isxdigit() calls were introduced.
Don’t cache per-group context across the whole query in orderedsetaggs.c.
commit : e44964c709b4a5f18d3f9a8fe6d5c259091315c1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Jul 2014 18:47:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Jul 2014 18:47:09 -0400
Although nodeAgg.c currently uses the same per-group memory context for
all groups of a query, that might change in future. Avoid assuming it.
This costs us an extra AggCheckCallContext() call per group, but that's
pretty cheap and is probably good from a safety standpoint anyway.
Back-patch to 9.4 in case any third-party code copies this logic.
Andrew Gierth
Redesign API presented by nodeAgg.c for ordered-set and similar aggregates.
commit : f688cf548b3e37991009b7a3607171242c796e62
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Jul 2014 18:25:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Jul 2014 18:25:37 -0400
The previous design exposed the input and output ExprContexts of the
Agg plan node, but work on grouping sets has suggested that we'll regret
doing that. Instead provide more narrowly-defined APIs that can be
implemented in multiple ways, namely a way to get a short-term memory
context and a way to register an aggregate shutdown callback.
Back-patch to 9.4 where the bad APIs were introduced, since we don't
want third-party code using these APIs and then having to change in 9.5.
Andrew Gierth
Use a separate temporary directory for the Unix-domain socket
commit : 6b56bc16cdf0c59e7d18ec046b2ed63bc82faf7b
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Jul 2014 21:44:02 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Jul 2014 21:44:02 -0400
Creating the Unix-domain socket in the build directory can run into
name-length limitations. Therefore, create the socket file in the
default temporary directory of the operating system. Keep the temporary
data directory etc. in the build tree.
Support vpath builds in TAP tests
commit : 04163ff1b98651ac2e04384ae8d84d8d1cb5dd60
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Jul 2014 21:47:07 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Jul 2014 21:47:07 -0400
If a connection committed or rolled back any transactions within a
PGSTAT_STAT_INTERVAL pacing interval without accessing any tables,
the reporting of those statistics would be held up until the
connection closed or until it ended a PGSTAT_STAT_INTERVAL interval
in which it had accessed a table. This could result in under-
reporting of transactions for an extended period, followed by a
spike in reported transactions.
While this is arguably a bug, the impact is minimal, primarily
affecting, and being affected by, monitoring software. It might
cause more confusion than benefit to change the existing behavior
in released stable branches, so apply only to master and the 9.4
beta.
Gurjeet Singh, with review and editing by Kevin Grittner,
incorporating suggested changes from Abhijit Menon-Sen and Tom
Lane.
pg_upgrade: preserve database and relation minmxid values
commit : b446a384b7c231e3fa10dfb0fbc9247a6b329348
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 2 Jul 2014 15:29:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 2 Jul 2014 15:29:38 -0400
commit : cec3be05f624bc32599c2a056ec1b47bec917510
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Jul 2014 12:31:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Jul 2014 12:31:27 -0400
This function wasn't originally thought to be really user-facing,
because converting a table to a view isn't something we expect people
to do manually. So not all that much effort was spent on the error
messages; in particular, while the code will complain that you got
the column types wrong it won't say exactly what they are. But since
we repurposed the code to also check compatibility of rule RETURNING
lists, it's definitely user-facing. It now seems worthwhile to add
errdetail messages showing exactly what the conflict is when there's
a mismatch of column names or types. This is prompted by bug #10836
from Matthias Raffelsieper, which might have been forestalled if the
error message had reported the wrong column type as being "record".
Back-patch to 9.4, but not into older branches where the set of
translatable error strings is supposed to be stable.
Prevent psql from issuing BEGIN before ALTER SYSTEM when AUTOCOMMIT is off.
The autocommit-off mode works by issuing an implicit BEGIN just before
any command that is not already in a transaction block and is not itself
a BEGIN or other transaction-control command, nor a command that
cannot be executed inside a transaction block. This commit prevents psql
from issuing such an implicit BEGIN before ALTER SYSTEM because it's
not allowed inside a transaction block.
Backpatch to 9.4 where ALTER SYSTEM was added.
Report by Feike Steenbergen
Fix inadequately-sized output buffer in contrib/unaccent.
commit : 49bca9ea53f6428f7ac6372ad4dd47ecacfac395
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Jul 2014 11:22:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Jul 2014 11:22:46 -0400
The output buffer size in unaccent_lexize() was calculated as input string
length times pg_database_encoding_max_length(), which effectively assumes
that replacement strings aren't more than one character. While that was
all that we previously documented it to support, the code actually has
always allowed replacement strings of arbitrary length; so if you tried
to make use of longer strings, you were at risk of buffer overrun. To fix,
use an expansible StringInfo buffer instead of trying to determine the
maximum space needed a-priori.
This would be a security issue if unaccent rules files could be installed
by unprivileged users; but fortunately they can't, so in the back branches
the problem can be labeled as improper configuration by a superuser.
Nonetheless, a memory stomp isn't a nice way of reacting to improper
configuration, so let's back-patch the fix.
pg_upgrade: update C comments about pg_dumpall
commit : 4dc3df9d193838060ec97dd29899e33676796ab5
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 30 Jun 2014 19:57:47 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 30 Jun 2014 19:57:47 -0400
There were some C comments that hadn't been updated from the switch of
using only pg_dumpall to using pg_dump and pg_dumpall, so update them.
Also, don't bother using --schema-only for pg_dumpall --globals-only.
Backpatch through 9.4
Don’t prematurely free the BufferAccessStrategy in pgstat_heap().
commit : 37a4d3d70617f574b9a3dd5af079430b24817333
author : Noah Misch <noah@leadboat.com>
date : Mon, 30 Jun 2014 16:59:19 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 30 Jun 2014 16:59:19 -0400
This function continued to use it after heap_endscan() freed it. In
passing, don't explicit create a strategy here. Instead, use the one
created by heap_beginscan_strat(), if any. Back-patch to 9.2, where use
of a BufferAccessStrategy here was introduced.
Check interrupts during logical decoding more frequently.
commit : 6ad903d70a440eb0fbe0b33ceb87a8b0a81cb240
author : Andres Freund <andres@anarazel.de>
date : Sun, 29 Jun 2014 17:08:04 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 29 Jun 2014 17:08:04 +0200
When reading large amounts of preexisting WAL during logical decoding
using the SQL interface we possibly could fail to check interrupts in
due time. Similarly the same could happen on systems with a very high
WAL volume while creating a new logical replication slot, independent
of the used interface.
Previously these checks where only performed in xlogreader's read_page
callbacks, while waiting for new WAL to be produced. That's not
sufficient though, if there's never a need to wait. Walsender's send
loop already contains a interrupt check.
Backpatch to 9.4 where the logical decoding feature was introduced.
Revert the assertion of no palloc’s in critical section.
commit : d27d493a4e465c7b3a9e2749e0b69d51aa1e3133
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 30 Jun 2014 10:23:18 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 30 Jun 2014 10:23:18 +0300
Per discussion, it still fires too often to be safe to enable in
production. Keep it in master, so that we find the issues, but disable it
in the stable branch.
Remove use_json_as_text options from json_to_record/json_populate_record.
commit : 3130b8505ffcc3dae053939824c72291f6cdff3b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 Jun 2014 13:51:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 Jun 2014 13:51:02 -0400
The "false" case was really quite useless since all it did was to throw
an error; a definition not helped in the least by making it the default.
Instead let's just have the "true" case, which emits nested objects and
arrays in JSON syntax. We might later want to provide the ability to
emit sub-objects in Postgres record or array syntax, but we'd be best off
to drive that off a check of the target field datatype, not a separate
argument.
For the functions newly added in 9.4, we can just remove the flag arguments
outright. We can't do that for json_populate_record[set], which already
existed in 9.3, but we can ignore the argument and always behave as if it
were "true". It helps that the flag arguments were optional and not
documented in any useful fashion anyway.
Have multixact be truncated by checkpoint, not vacuum
commit : 56f86bb764bb99a32810c52976926f85cc3bf3b1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Jun 2014 14:43:52 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Jun 2014 14:43:52 -0400
Instead of truncating pg_multixact at vacuum time, do it only at
checkpoint time. The reason for doing it this way is twofold: first, we
want it to delete only segments that we're certain will not be required
if there's a crash immediately after the removal; and second, we want to
do it relatively often so that older files are not left behind if
there's an untimely crash.
Per my proposal in
http://www.postgresql.org/message-id/20140626044519.GJ7340@eldon.alvh.no-ip.org
we now execute the truncation in the checkpointer process rather than as
part of vacuum. Vacuum is in only charge of maintaining in shared
memory the value to which it's possible to truncate the files; that
value is stored as part of checkpoints also, and so upon recovery we can
reuse the same value to re-execute truncate and reset the
oldest-value-still-safe-to-use to one known to remain after truncation.
Per bug reported by Jeff Janes in the course of his tests involving
bug #8673.
While at it, update some comments that hadn't been updated since
multixacts were changed.
Backpatch to 9.3, where persistency of pg_multixact files was
introduced by commit 0ac5ad5134f2.
Don’t allow relminmxid to go backwards during VACUUM FULL
commit : 9eecc8a7cafa2be356a859f74c5db5961e190579
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Jun 2014 14:43:46 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Jun 2014 14:43:46 -0400
We were allowing a table's pg_class.relminmxid value to move backwards
when heaps were swapped by VACUUM FULL or CLUSTER. There is a
similar protection against relfrozenxid going backwards, which we
neglected to clone when the multixact stuff was rejiggered by commit
0ac5ad5134f276.
Backpatch to 9.3, where relminmxid was introduced.
As reported by Heikki in
http://www.postgresql.org/message-id/52401AEA.9000608@vmware.com
Fix broken Assert() introduced by 8e9a16ab8f7f0e58
commit : 4c888a6290add7ab86078c8759f0de1bd74c7377
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Jun 2014 14:43:39 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 27 Jun 2014 14:43:39 -0400
Don't assert MultiXactIdIsRunning if the multi came from a tuple that
had been share-locked and later copied over to the new cluster by
pg_upgrade. Doing that causes an error to be raised unnecessarily:
MultiXactIdIsRunning is not open to the possibility that its argument
came from a pg_upgraded tuple, and all its other callers are already
checking; but such multis cannot, obviously, have transactions still
running, so the assert is pointless.
Noticed while investigating the bogus pg_multixact/offsets/0000 file
left over by pg_upgrade, as reported by Andres Freund in
http://www.postgresql.org/message-id/20140530121631.GE25431@alap3.anarazel.de
Backpatch to 9.3, as the commit that introduced the buglet.
Disallow pushing volatile qual expressions down into DISTINCT subqueries.
commit : 6327f25dddba0c359f8be8395e1b2d99dfe0d30c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Jun 2014 11:08:51 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Jun 2014 11:08:51 -0700
A WHERE clause applied to the output of a subquery with DISTINCT should
theoretically be applied only once per distinct row; but if we push it
into the subquery then it will be evaluated at each row before duplicate
elimination occurs. If the qual is volatile this can give rise to
observably wrong results, so don't do that.
While at it, refactor a little bit to allow subquery_is_pushdown_safe
to report more than one kind of restrictive condition without indefinitely
expanding its argument list.
Although this is a bug fix, it seems unwise to back-patch it into released
branches, since it might de-optimize plans for queries that aren't giving
any trouble in practice. So apply to 9.4 but not further back.
Get rid of bogus separate pg_proc entries for json_extract_path operators.
commit : c3096d57c8faa24aa5ff4cc7e87d989ce42ad05d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Jun 2014 16:22:18 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Jun 2014 16:22:18 -0700
These should not have existed to begin with, but there was apparently some
misunderstanding of the purpose of the opr_sanity regression test item
that checks for operator implementation functions with their own comments.
The idea there is to check for unintentional violations of the rule that
operator implementation functions shouldn't be documented separately
.... but for these functions, that is in fact what we want, since the
variadic option is useful and not accessible via the operator syntax.
Get rid of the extra pg_proc entries and fix the regression test and
documentation to be explicit about what we're doing here.
Forward-patch regression test for “could not find pathkey item to sort”.
commit : 973837450c764b585321c965179eb8a57380ab5c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Jun 2014 10:40:55 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Jun 2014 10:40:55 -0700
Commit a87c729153e372f3731689a7be007bc2b53f1410 already fixed the bug this
is checking for, but the regression test case it added didn't cover this
scenario. Since we managed to miss the fact that there was a bug at all,
it seems like a good idea to propagate the extra test case forward to HEAD.
Remove obsolete example of CSV log file name from log_filename document.
commit : 2a741ca7658167c9061f9d0095992b326d6ffdbb
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 26 Jun 2014 14:27:27 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 26 Jun 2014 14:27:27 +0900
7380b63 changed log_filename so that epoch was not appended to it
when no format specifier is given. But the example of CSV log file name
with epoch still left in log_filename document. This commit removes
such obsolete example.
This commit also documents the defaults of log_directory and
log_filename.
Backpatch to all supported versions.
Christoph Berg
Rationalize error messages within jsonfuncs.c.
commit : 119fed85f5f68e8fb146549e3267026c9fdc8640
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Jun 2014 15:25:26 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Jun 2014 15:25:26 -0700
I noticed that the functions in jsonfuncs.c sometimes printed error
messages that claimed I'd called some other function. Investigation showed
that this was from repurposing code into "worker" functions without taking
much care as to whether it would mention the right SQL-level function if it
threw an error. Moreover, there was a weird mismash of messages that
contained a fixed function name, messages that used %s for a function name,
and messages that constructed a function name out of spare parts, like
"json%s_populate_record" (which, quite aside from being ugly as sin, wasn't
even sufficient to cover all the cases). This would put an undue burden on
our long-suffering translators. Standardize on inserting the SQL function
name with %s so as to reduce the number of translatable strings, and pass
function names around as needed to make sure we can report the right one.
Fix up some gratuitous variations in wording, too.
Cosmetic improvements in jsonfuncs.c.
commit : 199aa7108794db50c64b55327e4c81d1c2f414a5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Jun 2014 11:22:21 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Jun 2014 11:22:21 -0700
Re-pgindent, remove a lot of random vertical whitespace, remove useless
(if not counterproductive) inline markings, get rid of unnecessary
zero-padding of strings for hashtable searches. No functional changes.
Fix handling of nested JSON objects in json_populate_recordset and friends.
commit : a331512dec25807c4c93e3d537ac7734ee901641
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 Jun 2014 21:22:43 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 Jun 2014 21:22:43 -0700
populate_recordset_object_start() improperly created a new hash table
(overwriting the link to the existing one) if called at nest levels
greater than one. This resulted in previous fields not appearing in
the final output, as reported by Matti Hameister in bug #10728.
In 9.4 the problem also affects json_to_recordset.
This perhaps missed detection earlier because the default behavior is to
throw an error for nested objects: you have to pass use_json_as_text = true
to see the problem.
In addition, fix query-lifespan leakage of the hashtable created by
json_populate_record(). This is pretty much the same problem recently
fixed in dblink: creating an intended-to-be-temporary context underneath
the executor's per-tuple context isn't enough to make it go away at the
end of the tuple cycle, because MemoryContextReset is not
MemoryContextResetAndDeleteChildren.
Michael Paquier and Tom Lane
pg_upgrade: remove pg_multixact files left by initdb
commit : dd5369047fc3400f4b5d1d61d85b040a8eef8d1b
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 24 Jun 2014 16:11:06 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 24 Jun 2014 16:11:06 -0400
This fixes a bug that caused vacuum to fail when the '0000' files left
by initdb were accessed as part of vacuum's cleanup of old pg_multixact
files.
Backpatch through 9.3
Don’t allow foreign tables with OIDs.
commit : 1818ae0a789ec360d8641c98520f832b9fd9c0ef
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 24 Jun 2014 12:31:36 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 24 Jun 2014 12:31:36 +0300
The syntax doesn't let you specify "WITH OIDS" for foreign tables, but it
was still possible with default_with_oids=true. But the rest of the system,
including pg_dump, isn't prepared to handle foreign tables with OIDs
properly.
Backpatch down to 9.1, where foreign tables were introduced. It's possible
that there are databases out there that already have foreign tables with
OIDs. There isn't much we can do about that, but at least we can prevent
them from being created in the future.
Patch by Etsuro Fujita, reviewed by Hadi Moshayedi.
Fix typo in replication slot function doc.
commit : e9b182404b67eef9a263c3d07b89cb60b26bed7b
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 24 Jun 2014 03:51:51 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 24 Jun 2014 03:51:51 +0900
commit : a2586dece1953e7c395b533bf52b54b5e7bb3a3c
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 21 Jun 2014 15:33:22 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 21 Jun 2014 15:33:22 -0400
commit : 750c0351ea9c07e2398a2e116ed7d48dbc42b489
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 21 Jun 2014 10:56:37 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 21 Jun 2014 10:56:37 -0400
commit : bcd67a2fe97eaf3f83b5ddb72aaffff34f4d441f
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 21 Jun 2014 09:17:14 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 21 Jun 2014 09:17:14 -0500
By using curly braces, the template had specified that one of
"NOT DEFERRABLE", "INITIALLY IMMEDIATE", or "INITIALLY DEFERRED"
was required on any CREATE TRIGGER statement, which is not
accurate. Change to square brackets makes that optional.
Backpatch to 9.1, where the error was introduced.
Clean up data conversion short-lived memory context.
commit : 9d884a34c343641f7ab3c24377d7ec0970df4eea
author : Joe Conway <mail@joeconway.com>
date : Fri, 20 Jun 2014 12:22:34 -0700
committer: Joe Conway <mail@joeconway.com>
date : Fri, 20 Jun 2014 12:22:34 -0700
dblink uses a short-lived data conversion memory context. However it
was not deleted when no longer needed, leading to a noticeable memory
leak under some circumstances. Plug the hole, along with minor
refactoring. Backpatch to 9.2 where the leak was introduced.
Report and initial patch by MauMau. Reviewed/modified slightly by
Tom Lane and me.
Do all-visible handling in lazy_vacuum_page() outside its critical section.
commit : 4bc0a13a8a6af0320923a89238b7ab3f27c28d56
author : Andres Freund <andres@anarazel.de>
date : Fri, 20 Jun 2014 11:06:48 +0200
committer: Andres Freund <andres@anarazel.de>
date : Fri, 20 Jun 2014 11:06:48 +0200
Since fdf9e21196a lazy_vacuum_page() rechecks the all-visible status
of pages in the second pass over the heap. It does so inside a
critical section, but both visibilitymap_test() and
heap_page_is_all_visible() perform operations that should not happen
inside one. The former potentially performs IO and both potentially do
memory allocations.
To fix, simply move all the all-visible handling outside the critical
section. Doing so means that the PD_ALL_VISIBLE on the page won't be
included in the full page image of the HEAP2_CLEAN record anymore. But
that's fine, the flag will be set by the HEAP2_VISIBLE logged later.
Backpatch to 9.3 where the problem was introduced. The bug only came
to light due to the assertion added in 4a170ee9 and isn't likely to
cause problems in production scenarios. The worst outcome is a
avoidable PANIC restart.
This also gets rid of the difference in the order of operations
between master and standby mentioned in 2a8e1ac5.
Per reports from David Leverton and Keith Fiske in bug #10533.
Avoid leaking memory while evaluating arguments for a table function.
commit : 1044e79a0b7b21ddedd9e093394a34e8cc2d42bc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jun 2014 22:13:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jun 2014 22:13:44 -0400
ExecMakeTableFunctionResult evaluated the arguments for a function-in-FROM
in the query-lifespan memory context. This is insignificant in simple
cases where the function relation is scanned only once; but if the function
is in a sub-SELECT or is on the inside of a nested loop, any memory
consumed during argument evaluation can add up quickly. (The potential for
trouble here had been foreseen long ago, per existing comments; but we'd
not previously seen a complaint from the field about it.) To fix, create
an additional temporary context just for this purpose.
Per an example from MauMau. Back-patch to all active branches.
Document SQL functions’ behavior of parsing the whole function at once.
commit : b488daf0d59614e801059e3558f73b65b0cf7e06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jun 2014 12:33:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jun 2014 12:33:56 -0400
Fix calculation of PREDICATELOCK_MANAGER_LWLOCK_OFFSET.
commit : 909cab83058b12cabec6fb10c945f67ef09de5ec
author : Kevin Grittner <kgrittn@postgresql.org>
date : Thu, 19 Jun 2014 08:51:54 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Thu, 19 Jun 2014 08:51:54 -0500
Commit ea9df812d8502fff74e7bc37d61bdc7d66d77a7f failed to include
NUM_BUFFER_PARTITIONS in this offset, resulting in a bad offset.
Ultimately this threw off NUM_FIXED_LWLOCKS which is based on
earlier offsets, leading to memory allocation problems. It seems
likely to have also caused increased LWLOCK contention when
serializable transactions were used, because lightweight locks used
for that overlapped others.
Reported by Amit Kapila with analysis and fix.
Backpatch to 9.4, where the bug was introduced.
Don’t allow data_directory to be set in postgresql.auto.conf by ALTER SYSTEM.
commit : fc5cf383d9ae894e3c9e94701ce5dc468d334433
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 19 Jun 2014 20:31:20 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 19 Jun 2014 20:31:20 +0900
data_directory could be set both in postgresql.conf and postgresql.auto.conf so far.
This could cause some problematic situations like circular definition. To avoid such
situations, this commit forbids a user to set data_directory in postgresql.auto.conf.
Backpatch this to 9.4 where ALTER SYSTEM command was introduced.
Amit Kapila, reviewed by Abhijit Menon-Sen, with minor adjustments by me.
Remove unnecessary check for jbvBinary in convertJsonbValue.
commit : a6896e00058c55692347f898a9bc2a2974520df8
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Jun 2014 19:28:20 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Jun 2014 19:28:20 -0400
The check was confusing and is a condition that should never in fact
happen.
Per gripe from Dmitry Dolgov.
Fix weird spacing in error message.
commit : fd1afbbedc55014783b9730385967d73c31a1f37
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Jun 2014 15:44:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Jun 2014 15:44:15 -0400
Seems to have been introduced in 1a3458b6d8d202715a83c88474a1b63726d0929e.
Document that jsonb has all the standard comparison operators.
commit : 8b4067e6ec051b5b50b9e8ae981708ce7c4bcf02
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Jun 2014 15:16:48 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Jun 2014 15:16:48 -0400
Catch up with commit b8cc8f94730610c0189aa82dfec4ae6ce9b13e34's
introduction of the HAVE_UUID_OSSP symbol to the principal build
process. Back-patch to 9.4, where that commit appeared.
9.4 release notes: improve valgrind mention
commit : 9d90472a0ed4955678d7080ee6b2a53a7762f32b
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 17 Jun 2014 11:28:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 17 Jun 2014 11:28:34 -0400
Use type pgsocket for Windows pipe emulation socket calls
commit : 0ada6b84b058b76095ffffa69175e82b6f3e63ec
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 16 Jun 2014 15:33:19 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 16 Jun 2014 15:33:19 -0400
Any OS user able to access the socket can connect as the bootstrap
superuser and proceed to execute arbitrary code as the OS user running
the test. Protect against that by placing the socket in a temporary,
mode-0700 subdirectory of /tmp. The pg_regress-based test suites and
the pg_upgrade test suite were vulnerable; the $(prove_check)-based test
suites were already secure. Back-patch to 8.4 (all supported versions).
The hazard remains wherever the temporary cluster accepts TCP
connections, notably on Windows.
As a convenient side effect, this lets testing proceed smoothly in
builds that override DEFAULT_PGSOCKET_DIR. Popular non-default values
like /var/run/postgresql are often unwritable to the build user.
Security: CVE-2014-0067
Add mkdtemp() to libpgport.
commit : 598efaa37f4e223491cf326f2ab44414a934c014
author : Noah Misch <noah@leadboat.com>
date : Sat, 14 Jun 2014 09:41:13 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sat, 14 Jun 2014 09:41:13 -0400
This function is pervasive on free software operating systems; import
NetBSD's implementation. Back-patch to 8.4, like the commit that will
harness it.
Harden pg_filenode_relation test against concurrent DROP TABLE.
commit : cc3e1553fa6786b3a8c673fc9d8ce0a258ba8809
author : Noah Misch <noah@leadboat.com>
date : Fri, 13 Jun 2014 19:57:59 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 13 Jun 2014 19:57:59 -0400
Back-patch to 9.4, where .dir-locals.el was introduced.
Fix pg_restore’s processing of old-style BLOB COMMENTS data.
commit : c3c1401ca23a6a990989da777c78f7c8a19ca282
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 20:14:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 20:14:36 -0400
Prior to 9.0, pg_dump handled comments on large objects by dumping a bunch
of COMMENT commands into a single BLOB COMMENTS archive object. With
sufficiently many such comments, some of the commands would likely get
split across bufferloads when restoring, causing failures in
direct-to-database restores (though no problem would be evident in text
output). This is the same type of issue we have with table data dumped as
INSERT commands, and it can be fixed in the same way, by using a mini SQL
lexer to figure out where the command boundaries are. Fortunately, the
COMMENT commands are no more complex to lex than INSERTs, so we can just
re-use the existing lexer for INSERTs.
Per bug #10611 from Jacek Zalewski. Back-patch to all active branches.
Improve tuplestore’s error messages for I/O failures.
commit : 3ba1776c568e36423ee66892481b6d1703f4fbd8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 18:59:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 18:59:06 -0400
We should report the errno when we get a failure from functions like
BufFileWrite. "ERROR: write failed" is unreasonably taciturn for a
case that's well within the realm of possibility; I've seen it a
couple times in the buildfarm recently, in situations that were
probably out-of-disk-space, but it'd be good to see the errno
to confirm it.
I think this code was originally written without assuming that
the buffile.c functions would return useful errno; but most other
callers *are* assuming that, and a quick look at the buffile code
gives no reason to suppose otherwise.
Also, a couple of the old messages were phrased on the assumption
that a short read might indicate a logic bug in tuplestore itself;
but that code's pretty well tested by now, so a filesystem-level
problem seems much more likely.
Adjust largeobject regression test to leave a couple of LOs behind.
commit : b37e574865f8b465a1c99a29dcdfcecf6eca32f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 17:51:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 17:51:47 -0400
Since we commonly test pg_dump/pg_restore by seeing whether they can dump
and restore the regression test database, it behooves us to include some
large objects in that test scenario.
I tried to include a comment on one of these large objects to improve
the test scenario further ... but it turns out that pg_upgrade fails to
preserve comments on large objects, and its regression test notices
the discrepancy. So uncommenting that COMMENT is a TODO for later.
Remove inadvertent copyright violation in largeobject regression test.
commit : 7e00e09872f194c3dc30faca6aff7c2a32b608f6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 16:51:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 16:51:05 -0400
Robert Frost is no longer with us, but his copyrights still are, so
let's stop using "Stopping by Woods on a Snowy Evening" as test data
before somebody decides to sue us. Wordsworth is more safely dead.
Add regression test to prevent future breakage of legacy query in libpq.
commit : e6f6db300fef2e53080209ae00f19408203e5686
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 15:54:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 15:54:13 -0400
Memorialize the expected output of the query that libpq has been using for
many years to get the OIDs of large-object support functions. Although
we really ought to change the way libpq does this, we must expect that
this query will remain in use in the field for the foreseeable future,
so until we're ready to break compatibility with old libpq versions
we'd better check the results stay the same. See the recent lo_create()
fiasco.
Rename lo_create(oid, bytea) to lo_from_bytea().
commit : e3489847d08beaa4b9dc2a84011719f0b848f3e1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 15:39:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Jun 2014 15:39:09 -0400
The previous naming broke the query that libpq's lo_initialize() uses
to collect the OIDs of the server-side functions it requires, because
that query effectively assumes that there is only one function named
lo_create in the pg_catalog schema (and likewise only one lo_open, etc).
While we should certainly make libpq more robust about this, the naive
query will remain in use in the field for the foreseeable future, so it
seems the only workable choice is to use a different name for the new
function. lo_from_bytea() won a small straw poll.
Back-patch into 9.4 where the new function was introduced.
Consistency improvements for slot and decoding code.
commit : d52a6c4944c1d83cfaae53e20561c53220e7968b
author : Andres Freund <andres@anarazel.de>
date : Thu, 12 Jun 2014 13:23:46 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 12 Jun 2014 13:23:46 +0200
Change the order of checks in similar functions to be the same; remove
a parameter that's not needed anymore; rename a memory context and
expand a couple of comments.
Per review comments from Amit Kapila
Fix ancient encoding error in hungarian.stop.
commit : 7f9fbb842b09da851e003a70c6c53fd8ca6c6f82
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Jun 2014 22:48:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Jun 2014 22:48:16 -0400
When we grabbed this file off the Snowball project's website, we mistakenly
supposed that it was in LATIN1 encoding, but evidently it was actually in
LATIN2. This resulted in ő (o-double-acute, U+0151, which is code 0xF5 in
LATIN2) being misconverted into õ (o-tilde, U+00F5), as complained of in
bug #10589 from Zoltán Sörös. We'd have messed up u-double-acute too,
but there aren't any of those in the file. Other characters used in the
file have the same codes in LATIN1 and LATIN2, which no doubt helped hide
the problem for so long.
The error is not only ours: the Snowball project also was confused about
which encoding is required for Hungarian. But dealing with that will
require source-code changes that I'm not at all sure we'll wish to
back-patch. Fixing the stopword file seems reasonably safe to back-patch
however.
Forward-port regression test for bug #10587 into 9.3 and HEAD.
commit : ab76208e3df6841b3770edeece57d0f048392237
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Jun 2014 21:37:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Jun 2014 21:37:18 -0400
Although this bug is already fixed in post-9.2 branches, the case
triggering it is quite different from what was under consideration
at the time. It seems worth memorializing this example in HEAD
just to make sure it doesn't get broken again in future.
Extracted from commit 187ae17300776f48b2bd9d0737923b1bf70f606e.
Fix infinite loop when splitting inner tuples in SPGiST text indexes.
commit : c170655cc81fd5e3c152e951c52247171bb57611
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Jun 2014 16:30:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Jun 2014 16:30:40 -0400
Previously, the code used a node label of zero both for strings that
contain no bytes beyond the inner tuple's prefix, and for cases where an
"allTheSame" inner tuple has to be split to allow a string with a different
next byte to be inserted into it. Failing to distinguish these cases meant
that if a string ending with the current prefix needed to be inserted into
an allTheSame tuple, we got into an infinite loop, because after splitting
the tuple we'd descend into the child allTheSame tuple and then find we
need to split again.
To fix, instead use -1 and -2 as the node labels for these two cases.
This requires widening the node label type from "char" to int2, but
fortunately SPGiST stores all pass-by-value node label types in their
Datum representation, which means that this change is transparently upward
compatible so far as the on-disk representation goes. We continue to
recognize zero as a dummy node label for reading purposes, but will not
attempt to push new index entries down into such a label, so that the loop
won't occur even when dealing with an existing index.
Per report from Teodor Sigaev. Back-patch to 9.2 where the faulty
code was introduced.
Wrap multixact/members correctly during extension, take 2
commit : b0b263baab3e927fe4b4f35755b91ac8d1db8fe0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 9 Jun 2014 15:17:23 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 9 Jun 2014 15:17:23 -0400
In a50d97625497b7 I already changed this, but got it wrong for the case
where the number of members is larger than the number of entries that
fit in the last page of the last segment.
As reported by Serge Negodyuck in a followup to bug #8673.
Fix off-by-one in decoding causing one-record events to be skipped.
commit : fe7337f2dc3177da19b647fcda3a33b73da82e14
author : Andres Freund <andres@anarazel.de>
date : Thu, 5 Jun 2014 18:27:11 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 5 Jun 2014 18:27:11 +0200
A ReorderBufferTransaction's end_lsn, the sentPtr advocated by
walsender keepalive messages, and the end location remembered by the
decoding get_*changes* SQL functions all use the location of the last
read record + 1. I.e. the LSN points to the beginning of the next
record. That cannot realistically be changed without changing the
replication protocol because that's how keepalive messages have worked
since 9.0.
The bug is that the logic inside the snapshot builder, which decides
whether a transaction's contents should be decoded, assumed the start
location would point towards the last byte of the last record. The
reason this didn't actually cause visible problems is that currently
that decision is only made for commit records. Since interesting
transactions always have at least one additional record - containing
actual data - we'd never skip a transaction.
But if there ever were transactions, or other events, with just one
record containing important information, we'd skip them after stopping
and restarting logical decoding.
Add defenses against running with a wrong selection of LOBLKSIZE.
commit : 5f93c37805e7485488480916b4585e098d3cc883
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jun 2014 11:31:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jun 2014 11:31:06 -0400
It's critical that the backend's idea of LOBLKSIZE match the way data has
actually been divided up in pg_largeobject. While we don't provide any
direct way to adjust that value, doing so is a one-line source code change
and various people have expressed interest recently in changing it. So,
just as with TOAST_MAX_CHUNK_SIZE, it seems prudent to record the value in
pg_control and cross-check that the backend's compiled-in setting matches
the on-disk data.
Also tweak the code in inv_api.c so that fetches from pg_largeobject
explicitly verify that the length of the data field is not more than
LOBLKSIZE. Formerly we just had Asserts() for that, which is no protection
at all in production builds. In some of the call sites an overlength data
value would translate directly to a security-relevant stack clobber, so it
seems worth one extra runtime comparison to be sure.
In the back branches, we can't change the contents of pg_control; but we
can still make the extra checks in inv_api.c, which will offer some amount
of protection against running with the wrong value of LOBLKSIZE.
Consistently spell a replication slot’s name as slot_name.
commit : f0c108560bce3a5481db57ffc3743e71b5f7b2d1
author : Andres Freund <andres@anarazel.de>
date : Thu, 5 Jun 2014 16:29:20 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 5 Jun 2014 16:29:20 +0200
Previously there's been a mix between 'slotname' and 'slot_name'. It's
not nice to be unneccessarily inconsistent in a new feature. As a post
beta1 initdb now is required in the wake of eeca4cd35e, fix the
inconsistencies.
Most the changes won't affect usage of replication slots because the
majority of changes is around function parameter names. The prominent
exception to that is that the recovery.conf parameter
'primary_slotname' is now named 'primary_slot_name'.
Move regression test listing of builtin leakproof functions to opr_sanity.sql.
commit : e0cb4aa89dd61cb1a76d348ced634681255b6a07
author : Andres Freund <andres@anarazel.de>
date : Thu, 5 Jun 2014 13:54:16 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 5 Jun 2014 13:54:16 +0200
The original location in create_function_3.sql didn't invite the close
structinity warranted for adding new leakproof functions. Add comments
to the test explaining that functions should only be added after
careful consideration and understanding what a leakproof function is.
Per complaint from Tom Lane after 5eebb8d954ad.
Adjust SP-GiST WAL record formats to reduce alignment padding.
commit : 8776faa81cb651322b8993422bdd4633f1f6a487
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 5 Jun 2014 12:55:35 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 5 Jun 2014 12:55:35 +0300
The way the code was written, the padding was copied from uninitialized
memory areas.. Because the structs are local variables in the code where
the WAL records are constructed, making them larger and zeroing the padding
bytes would not make the code very pretty, so rather than fixing this
directly by zeroing out the padding bytes, it seems more clear to not try to
align the tuples in the WAL records. The redo functions are taught to copy
the tuple header to a local variable to avoid unaligned access.
Stable-branches have the same problem, but we can't change the WAL format
there, so fix in master only. Reading a few random extra bytes at the stack
is harmless in practice, so it's not worth crafting a different
back-patchable fix.
Per reports from Kevin Grittner and Andres Freund, using clang static
analyzer and Valgrind, respectively.
Tweak new regression test case for better portability.
commit : d4d48a5edd9eb28a7f2ee2e4cbe20d984274982e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jun 2014 21:31:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jun 2014 21:31:41 -0400
Buildfarm says we get different plans on 32-bit and 64-bit platforms,
probably because of MAXALIGN-related differences in memory-consumption
calculations. Add some dummy WHERE clauses so that the planner estimates
different sizes for the three generate_series() relations; that should
stabilize the choice of join order.
Add btree and hash opclasses for pg_lsn.
commit : 4c8ab1b91d2bd154031f7bc8529b9e6e2f1cc443
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jun 2014 20:45:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jun 2014 20:45:56 -0400
This is needed to allow ORDER BY, DISTINCT, etc to work as expected for
pg_lsn values.
We had previously decided to put this off for 9.5, but in view of commit
eeca4cd35e284c72b2ea1b4494e64e7738896e81 there's no reason to avoid a
catversion bump for 9.4beta2, and this does make a pretty significant
usability difference for pg_lsn.
Michael Paquier, with fixes from Andres Freund and Tom Lane
Bump PG_CONTROL_VERSION for previous 9.4 changes.
commit : eeca4cd35e284c72b2ea1b4494e64e7738896e81
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jun 2014 18:16:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jun 2014 18:16:17 -0400
This should have been done in 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c
and/or 50e547096c4858a68abf09894667a542cc418315, but better late than
never. If we don't change this then we risk 9.3 pg_controldata or
pg_resetxlog being inappropriately used against a 9.4 pg_control file,
or vice versa.
Fix longstanding bug in HeapTupleSatisfiesVacuum().
commit : 621a99a666ba1a27b852dc5ddc0e1b224c388f53
author : Andres Freund <andres@anarazel.de>
date : Wed, 4 Jun 2014 21:36:19 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 4 Jun 2014 21:36:19 +0200
HeapTupleSatisfiesVacuum() didn't properly discern between
DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been
inserted in the current transaction and deleted in a aborted
subtransaction of the current backend. At the very least that caused
problems for CLUSTER and CREATE INDEX in transactions that had
aborting subtransactions producing rows, leading to warnings like:
WARNING: concurrent delete in progress within table "..."
possibly in an endless, uninterruptible, loop.
Instead of treating *InProgress xmins the same as *IsCurrent ones,
treat them as being distinct like the other visibility routines. As
implemented this separatation can cause a behaviour change for rows
that have been inserted and deleted in another, still running,
transaction. HTSV will now return INSERT_IN_PROGRESS instead of
DELETE_IN_PROGRESS for those. That's both, more in line with the other
visibility routines and arguably more correct. The latter because a
INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of
xmax.
The only current caller where that's possibly worse than the old
behaviour is heap_prune_chain() which now won't mark the page as
prunable if a row has concurrently been inserted and deleted. That's
harmless enough.
As a cautionary measure also insert a interrupt check before the gotos
in IndexBuildHeapScan() that lead to the uninterruptible loop. There
are other possible causes, like a row that several sessions try to
update and all fail, for repeated loops and the cost of doing so in
the retry case is low.
As this bug goes back all the way to the introduction of
subtransactions in 573a71a5da backpatch to all supported releases.
Reported-By: Sandro Santilli
Add description of pg_stat directory into doc.
commit : c8c9c1f5a3fcd2db0f94d3126e142dee91c53632
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 5 Jun 2014 01:43:17 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 5 Jun 2014 01:43:17 +0900
187492b6c2e8cafc5b39063ca3b67846e8155d24 changed pgstat.c so that
the stats files were saved into $PGDATA/pg_stat directory when the server
was shutdowned. But it accidentally forgot to change the location of
pg_stat_statements permanent stats file. This commit fixes pg_stat_statements
so that its stats file is also saved into $PGDATA/pg_stat at shutdown.
Since this fix changes the file layout, we don't back-patch it to 9.3
where this oversight was introduced.
Silence Bison deprecation warnings
commit : 55fb759ab3e7543a6be72a35e6b6961455c5b393
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 3 Jun 2014 22:36:35 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 3 Jun 2014 22:36:35 -0400
Bison >=3.0 issues warnings about
%name-prefix="base_yy"
instead of the now preferred
%name-prefix "base_yy"
but the latter doesn't work with Bison 2.3 or less. So for now we
silence the deprecation warnings.
Use EncodeDateTime instead of to_char to render JSON timestamps.
commit : ab14a73a6ca5cc4750f0e00a48bdc25a2293034a
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 3 Jun 2014 18:26:47 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 3 Jun 2014 18:26:47 -0400
Per gripe from Peter Eisentraut and Tom Lane.
The output is slightly different, but still ISO 8601 compliant: to_char
doesn't output the minutes when time zone offset is an integer number of
hours, while EncodeDateTime outputs ":00".
The code is slightly adapted from code in xml.c
Do not escape a unicode sequence when escaping JSON text.
commit : 0ad1a816320a2b539a51628e2a0b1e83ff096b1d
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 3 Jun 2014 16:11:31 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 3 Jun 2014 16:11:31 -0400
Previously, any backslash in text being escaped for JSON was doubled so
that the result was still valid JSON. However, this led to some perverse
results in the case of Unicode sequences, These are now detected and the
initial backslash is no longer escaped. All other backslashes are
still escaped. No validity check is performed, all that is looked for is
\uXXXX where X is a hexidecimal digit.
This is a change from the 9.2 and 9.3 behaviour as noted in the Release
notes.
Per complaint from Teodor Sigaev.
Output timestamps in ISO 8601 format when rendering JSON.
commit : f30015b6d794c15d52abbb3df3a65081fbefb1ed
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 3 Jun 2014 13:56:53 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 3 Jun 2014 13:56:53 -0400
Many JSON processors require timestamp strings in ISO 8601 format in
order to convert the strings. When converting a timestamp, with or
without timezone, to a JSON datum we therefore now use such a format
rather than the type's default text output, in functions such as
to_json().
This is a change in behaviour from 9.2 and 9.3, as noted in the release
notes.
Make plpython_unicode regression test work in more database encodings.
commit : 2dfa15de5510b3c19ffb92b512c39d5440a07b1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Jun 2014 12:01:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Jun 2014 12:01:27 -0400
This test previously used a data value containing U+0080, and would
therefore fail if the database encoding didn't have an equivalent to
that; which only about half of our supported server encodings do.
We could fall back to using some plain-ASCII character, but that seems
like it's losing most of the point of the test. Instead switch to using
U+00A0 (no-break space), which translates into all our supported encodings
except the four in the EUC_xx family.
Per buildfarm testing. Back-patch to 9.1, which is as far back as this
test is expected to succeed everywhere. (9.0 has the test, but without
back-patching some 9.1 code changes we could not expect to get consistent
results across platforms anyway.)
Set the process latch when processing recovery conflict interrupts.
commit : 44445b28d265fe91fea3da47bd3a8c4007ce87e5
author : Andres Freund <andres@anarazel.de>
date : Tue, 3 Jun 2014 14:02:54 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 3 Jun 2014 14:02:54 +0200
Because RecoveryConflictInterrupt() didn't set the process latch
anything using the latter to wait for events didn't get notified about
recovery conflicts. Most latch users are never the target of recovery
conflicts, which explains the lack of reports about this until
now.
Since 9.3 two possible affected users exist though: The sql callable
pg_sleep() now uses latches to wait and background workers are
expected to use latches in their main loop. Both would currently wait
until the end of WaitLatch's timeout.
Fix by adding a SetLatch() to RecoveryConflictInterrupt(). It'd also
be possible to fix the issue by having each latch user set
set_latch_on_sigusr1. That seems failure prone and though, as most of
these callsites won't often receive recovery conflicts and thus will
likely only be tested against normal query cancels et al. It'd also be
unnecessarily verbose.
Backpatch to 9.1 where latches were introduced. Arguably 9.3 would be
sufficient, because that's where pg_sleep() was converted to waiting
on the latch and background workers got introduced; but there could be
user level code making use of the latch pre 9.3.
Use unaligned output in another regression test query to reduce diff noise.
commit : 5eebb8d954adf9d600b1a157682539db1e8a3ada
author : Andres Freund <andres@anarazel.de>
date : Tue, 3 Jun 2014 12:19:18 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 3 Jun 2014 12:19:18 +0200
Use the unaligned/no rowcount output mode in a regression tests that
shows all built-in leakproof functions. Currently a new leakproof
function will often change the alignment of all existing functions,
making it hard to see the actual difference and creating unnecessary
patch conflicts.
Noticed while looking over a patch introducing new leakproof functions.
doc: fix JSON function prototype variable label
commit : 19c9da1d9654cbfd95bae26caff497d78277fb6e
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jun 2014 16:18:45 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jun 2014 16:18:45 -0400
from_jsonb -> from_json, for consistency
Patch by rudolf (private report)
Improve the efficiency of certain jsonb get operations.
commit : 1a4174a498a15a848d4c4c50a3a9ef500926e4bd
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 1 Jun 2014 19:04:02 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 1 Jun 2014 19:04:02 -0400
Instead of iterating over jsonb structures, use the inbuilt functions
findJsonbValueFromContainerLen() and getIthJsonbValueFromContainer() to
extract values directly. These functions use algorithms that are O(n log
n) and O(1) respectively, whereas iterating is O(n), so we should see
considerable speedup here.
Teodor Sigaev.
Improvements to the replication protocol documentation.
commit : a57509821c3147b2bf57560e3bce1641d78a7519
author : Andres Freund <andres@anarazel.de>
date : Sat, 31 May 2014 15:58:04 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 31 May 2014 15:58:04 +0200
Document the CREATE_REPLICATION_SLOT's output_plugin parameter; that
START_REPLICATION ... LOGICAL takes parameters; that START_REPLICATION
... LOGICAL uses the same messages as ... PHYSICAL; and be more
consistent with the usage of <literal/>.
Michael Paquier, with some additional changes by me.
On OS X, link libpython normally, ignoring the “framework” framework.
commit : 20561acf93d32b7d7fdd59d054344b2e341d6aa0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 May 2014 18:18:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 May 2014 18:18:11 -0400
As of Xcode 5.0, Apple isn't including the Python framework as part of the
SDK-level files, which means that linking to it might fail depending on
whether Xcode thinks you've selected a specific SDK version. According to
their Tech Note 2328, they've basically deprecated the framework method of
linking to libpython and are telling people to link to the shared library
normally. (I'm pretty sure this is in direct contradiction to the advice
they were giving a few years ago, but whatever.) Testing says that this
approach works fine at least as far back as OS X 10.4.11, so let's just
rip out the framework special case entirely. We do still need a special
case to decide that OS X provides a shared library at all, unfortunately
(I wonder why the distutils check doesn't work ...). But this is still
less of a special case than before, so it's fine.
Back-patch to all supported branches, since we'll doubtless be hearing
about this more as more people update to recent Xcode.
Fix typos in MSVC solution file.
commit : 512f3b03e3cddf7dc1901c0e062500133e534c1d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 30 May 2014 10:27:40 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 30 May 2014 10:27:40 +0300
In release notes, mention the need to initialize bgw_notify_pid.
commit : 42be7d6923e52a8c1ceb549c0931ac43a4954b86
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 29 May 2014 23:33:49 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 29 May 2014 23:33:49 -0400
When using the OSSP UUID library, cache its uuid_t state object.
commit : c941aed96b482e32dc3a8eba66b298824e7adc39
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 May 2014 13:51:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 May 2014 13:51:02 -0400
The original coding in contrib/uuid-ossp created and destroyed a uuid_t
object (or, in some cases, even two of them) each time it was called.
This is not the intended usage: you're supposed to keep the uuid_t object
around so that the library can cache its state across uses. (Other UUID
libraries seem to keep equivalent state behind-the-scenes in static
variables, but OSSP chose differently.) Aside from being quite inefficient,
creating a new uuid_t loses knowledge of the previously generated UUID,
which in theory could result in duplicate V1-style UUIDs being created
on sufficiently fast machines.
On at least some platforms, creating a new uuid_t also draws some entropy
from /dev/urandom, leaving less for the rest of the system. This seems
sufficiently unpleasant to justify back-patching this change.
Fix uuid-ossp regression tests based on buildfarm feedback.
commit : 25dd07e0f6ba1aef0a6802474112b5bcce621ea4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 23:15:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 23:15:51 -0400
The previous version of these tests expected uuid_generate_v1() to always
emit MAC addresses with the local-admin and multicast address bits zero.
However, several of the buildfarm critters are reporting values with the
local-admin bit set. (Perhaps they're running inside VMs or jails.)
And a couple are reporting values with the multicast bit set, probably
meaning that the UUID library couldn't read the system MAC address.
Also, it emerges that if OSSP UUID can't read the system MAC address, it
falls back to V1MC behavior wherein the whole node field gets randomized
each time, breaking the test that expected the node field to remain stable
in V1 output. (It looks like e2fs doesn't behave that way, though.)
It's not entirely clear why we can't get a system MAC address, since the
buildfarm scripts would not work without internet access. Nonetheless,
the regression tests had better cope with the case, so adjust the tests
to expect these behaviors.
Revert “Fix bogus %name-prefix option syntax in all our Bison files.”
commit : 71ed8b3ca76cd720f4013c3c20f0d2706583ab9a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 19:21:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 19:21:01 -0400
This reverts commit 45b7abe59e9485657ac9380f35d2d917dd0da25b.
It turns out that the %name-prefix syntax without "=" does not work
at all in pre-2.4 Bison. We are not prepared to make such a large
jump in minimum required Bison version just to suppress a warning
message in a version hardly any developers are using yet.
When 3.0 gets more popular, we'll figure out a way to deal with this.
In the meantime, BISONFLAGS=-Wno-deprecated is recommendable for
anyone using 3.0 who doesn't want to see the warning.
Don’t pay heed to wal_sender_timeout while creating a decoding slot.
commit : 21d48d66c8be053ef5ce0474bb30f8a91b7c3dd6
author : Andres Freund <andres@anarazel.de>
date : Thu, 29 May 2014 00:32:09 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 29 May 2014 00:32:09 +0200
Sometimes CREATE_REPLICATION_SLOT ... LOGICAL ... needs to wait for
further WAL using WalSndWaitForWal(). That used to always respect
wal_sender_timeout and kill the session when waiting long enough
because no feedback/ping messages can be sent while the slot is still
being created.
Introduce the notion that last_reply_timestamp = 0 means that the
walsender currently doesn't need timeout processing to avoid that
problem. Use that notion for CREATE_REPLICATION_SLOT ... LOGICAL.
Bugreport and initial patch by Steve Singer, revised by me.
Minor refactoring of jsonb_util.c
commit : d1d50bff247f189a6a1477596cdbd52d097089a0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 28 May 2014 23:44:31 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 28 May 2014 23:44:31 +0300
The only caller of compareJsonbScalarValue that needed locale-sensitive
comparison of strings was also the only caller that didn't just check for
equality. Separate the two cases for clarity: compareJsonbScalarValue now
does locale-sensitive comparison, and a new function,
equalsJsonbScalarValue, just checks for equality.
Jsonb comparison bug fixes.
commit : b3e5cfd5f979054e31d60adafd9e75bf9c38549a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 28 May 2014 22:47:04 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 28 May 2014 22:47:04 +0300
Fix an over-zealous assertion, which didn't take into account that sometimes
a scalar element can be compared against an array/object element.
Avoid comparing possibly-uninitialized local variables when end-of-array or
end-of-object is reached. Also fix and enhance comments a bit.
Peter Geoghegan, per reports by Pavel Stehule and me.
Fix bogus %name-prefix option syntax in all our Bison files.
commit : 45b7abe59e9485657ac9380f35d2d917dd0da25b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 15:41:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 15:41:53 -0400
%name-prefix doesn't use an "=" sign according to the Bison docs, but it
silently accepted one anyway, until Bison 3.0. This was originally a
typo of mine in commit 012abebab1bc72043f3f670bf32e91ae4ee04bd2, and we
seem to have slavishly copied the error into all the other grammar files.
Per report from Vik Fearing; analysis by Peter Eisentraut.
Back-patch to all active branches, since somebody might try to build
a back branch with up-to-date tools.
Improve regression tests for uuid-ossp.
commit : c0f27628d2fb53e8e5d190da2132739a2bb2f500
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 14:21:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 14:21:17 -0400
On reflection, the timestamp-advances test might fail if we're unlucky
enough for the time_mid field to change between two calls, since uuid_cmp
is just bytewise comparison and the field ordering has more significant
fields later. Build some field extraction functions so we can do a more
honest test of that. Also check that the version and reserved fields
contain what they should.
Fix stack clobber in new uuid-ossp code.
commit : 2103218dd4a0c6a44d05c09c066da20e1c2360fb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 11:50:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 11:50:41 -0400
The V5 (SHA1 hashing) code wrote 20 bytes into a 16-byte local variable.
This had accidentally failed to fail in my testing and Matteo's, but
buildfarm results exposed the problem.
Ensure cleanup in case of early errors in streaming base backups
commit : 8232d6df4c943a30c08e65d7ea893cb762bc5612
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 28 May 2014 12:40:45 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 28 May 2014 12:40:45 +0200
Move the code that sends the initial status information as well as the
calculation of paths inside the ENSURE_ERROR_CLEANUP block. If this code
failed, we would "leak" a counter of number of concurrent backups, thereby
making the system always believe it was in backup mode. This could happen
if the sending failed (which it probably never did given that the small
amount of data to send would never cause a flush) or if the psprintf calls
ran out of memory. Both are very low risk, but all operations after
do_pg_start_backup should be protected.
doc: improve markup of ssl_ecdh_curve commit
commit : c676315658973390c5550d73d3bb1fb7b92720b5
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 28 May 2014 06:27:01 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 28 May 2014 06:27:01 -0400
commit : ec3357a3bc37d9108b2cf2db96499f83f1a93df1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 00:26:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 28 May 2014 00:26:46 -0400
In general it's not a good idea for built-in types in the 'U' category
to be marked preferred; they could draw behavior away from user-defined
types with similarly-named operators. pg_lsn is probably at low risk
of that right now given the lack of casts between it and other types,
but that doesn't make this marking OK.
Ordinarily we'd bump catversion when changing any predefined catalog
contents like this, but since we're past beta1, the costs of a forced
initdb seem to outweigh the benefits of guaranteed behavioral consistency.
There's not any known behavioral impact today anyway --- this is more
in the nature of being sure there's not problems in future.
Per an off-list complaint from Thomas Fanghaenel.
Fix obsolete config-module-exclusion logic in vcregress.pl.
commit : 8600031147cee7845e1ad9e64304e1f5fe585515
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 May 2014 22:31:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 May 2014 22:31:21 -0400
The recent addition of regression tests to uuid-ossp exposed the fact
that the MSVC build system wasn't being consistent about whether it was
building/testing that contrib module, ie, it would try to test the module
even when it hadn't built it. The same hazard was latent for sslinfo.
For the moment I just copied the more up-to-date logic from point A to
point B, but this is screaming for refactoring.
Per buildfarm results.
Propagate system identifier generation improvement into pg_resetxlog.
commit : 4bcb3946249cbeed157ffd545a804913cfce749b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 May 2014 22:01:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 May 2014 22:01:13 -0400
Commit 5035701e07e8bd395aa878465a102afd7b74e8c3 improved xlog.c's method
for creating a database system identifier, but I neglected to fix the
copy of that code appearing in pg_resetxlog.c. Spotted by Andres Freund.
doc: improve ssl_ecdh_curve descriptions
commit : 49cf2cd815d61e1399fe46f9532347f09c3ed2f9
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 27 May 2014 21:30:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 27 May 2014 21:30:20 -0400
Support BSD and e2fsprogs UUID libraries alongside OSSP UUID library.
commit : b8cc8f94730610c0189aa82dfec4ae6ce9b13e34
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 May 2014 19:42:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 May 2014 19:42:08 -0400
Allow the contrib/uuid-ossp extension to be built atop any one of these
three popular UUID libraries. (The extension's name is now arguably a
misnomer, but we'll keep it the same so as not to cause unnecessary
compatibility issues for users.)
We would not normally consider a change like this post-beta1, but the issue
has been forced by our upgrade to autoconf 2.69, whose more rigorous header
checks are causing OSSP's header files to be rejected on some platforms.
It's been foreseen for some time that we'd have to move away from depending
on OSSP UUID due to lack of upstream maintenance, so this is a down payment
on that problem.
While at it, add some simple regression tests, in hopes of catching any
major incompatibilities between the three implementations.
Matteo Beccati, with some further hacking by me
worker_spi: Initialize bgw_notify_pid in all cases.
commit : 616afee14d7e8d6690286aaf8a2a0a01168c378a
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 26 May 2014 22:56:28 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 26 May 2014 22:56:28 -0400
Commit 090d0f2050647958865cb495dff74af7257d2bb4 added new code showing
how it can be useful to set bgw_notify_pid to a non-zero value, but it
failed to make sure that the existing call to RegisterBackgroundWorker
initialized the new field at all.
Report and patch by Shigeru Hanada.
Avoid unportable usage of sscanf(UINT64_FORMAT).
commit : 9d7ded0f4277f5c0063eca8e871a34e2355a8371
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 May 2014 22:23:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 May 2014 22:23:29 -0400
On Mingw, it seems that scanf() doesn't necessarily accept the same format
codes that printf() does, and in particular it may fail to recognize %llu
even though printf() does. Since configure only probes printf() behavior
while setting up the INT64_FORMAT macros, this means it's unsafe to use
those macros with scanf(). We had only one instance of such a coding
pattern, in contrib/pg_stat_statements, so change that code to avoid
the problem.
Per buildfarm warnings. Back-patch to 9.0 where the troublesome code
was introduced.
Michael Paquier
Fix pg_recvlogical to accept the documented -I instead only –startpos.
commit : bf2e70ba6c0175e5a676b6aa37e49915d8918a63
author : Andres Freund <andres@anarazel.de>
date : Sun, 25 May 2014 18:47:05 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 25 May 2014 18:47:05 +0200
The bug was caused by omitting 'I:' from the short argument list to
getopt_long(). To make similar bugs in the future less likely reorder
options in --help, long and short option lists to be in the same,
alphabetical within groups, order.
Report and fix by Michael Paquier, some additional reordering by me.
Small typo and formatting fixes in postgresql.conf.sample
commit : 0a5faaa90718b0ce259f43bfae8d629cc040a67c
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 25 May 2014 23:20:15 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 25 May 2014 23:20:15 -0400
Fix error when trying to delete page with half-dead left sibling.
commit : 8da31837803e95f26642019d859c3309d1c125fa
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 25 May 2014 18:15:04 -0400
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 25 May 2014 18:15:04 -0400
The new page deletion code didn't cope with the case the target page's
right sibling was marked half-dead. It failed a sanity check which checked
that the downlinks in the parent page match the lower level, because a
half-dead page has no downlink. To cope, check for that condition, and
just give up on the deletion if it happens. The vacuum will finish the
deletion of the half-dead page when it gets there, and on the next vacuum
after that the empty can be deleted.
Reported by Jeff Janes.
Allow total number of transactions in pgbench to exceed INT_MAX.
commit : 9a65fb350717360c505de9df411024d47e55710b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 May 2014 16:33:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 May 2014 16:33:29 -0400
Change the total-transactions counters from int32 to int64 to accommodate
cases where we do more than 2^31 transactions during a run. This patch
does not change the INT_MAX limit on explicit "-t" parameters, but it
does allow the product of the -t and -c parameters to exceed INT_MAX, or
allow a -T limit that is large enough that more than 2^31 transactions
can be completed. While pgbench did not actually fail in such cases,
it did print an incorrect total-transactions count, and some of the
derived numbers such as TPS would have been wrong as well.
Tomas Vondra
Don’t allocate memory inside an Assert() iff in a critical section.
commit : 9fa93530c878a0e23147a65f7d9a62802b22a995
author : Andres Freund <andres@anarazel.de>
date : Sun, 25 May 2014 01:37:52 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 25 May 2014 01:37:52 +0200
HeapTupleHeaderGetCmax() asserts that it is only used if the tuple has
been updated by the current transaction. That check is correct and
sensible but requires allocating memory if xmax is a multixact. When
wal_level is set to logical cmax needs to be included in a wal record
, generated inside a critical section, which can trigger the assertion
added in 4a170ee9e.
Reported-By: Steve Singer
Silence a couple of spurious valgrind warnings in inval.c.
commit : 0564bbe7a1690f025f4424d5a12cb6af9d428c48
author : Andres Freund <andres@anarazel.de>
date : Wed, 7 May 2014 22:30:05 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 7 May 2014 22:30:05 +0200
Define padding bytes in SharedInvalidationMessage structs to be
defined. Otherwise the sinvaladt.c ringbuffer, which is accessed by
multiple processes, will cause spurious valgrind warnings about
undefined memory being used. That's because valgrind remembers the
undefined bytes from the last local process's store, not realizing
that another process has written since, filling the previously
uninitialized bytes.
doc: link/caps fixes for 9.4 release notes
commit : 37828e87aec2eb0c15655d4ad753644be851e59f
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 23 May 2014 15:05:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 23 May 2014 15:05:31 -0400
commit : 57b7e83b0d5e192c01e261b76ff0ed0ccd73c37c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 23 May 2014 08:16:09 -0400
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 23 May 2014 08:16:09 -0400
commit : 11ad3b35c25de6edcaa8a7695cb1d58650c546d3
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 22 May 2014 10:40:00 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 22 May 2014 10:40:00 -0400
commit : 51f41e8c0a0b9ce00734ed4702d16601cc55c280
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 21 May 2014 23:18:38 -0400
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 21 May 2014 23:18:38 -0400
doc: add ALTER TABLE lock level item as major 9.4 item
commit : 2e1b5d3f014206f6bdf3dc48d50ecec9dee10fd6
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 21 May 2014 15:49:44 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 21 May 2014 15:49:44 -0400
commit : e12d7320ca494fd05134847e300feedb2d4a5969
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 21 May 2014 08:00:39 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 21 May 2014 08:00:39 -0400
doc: 9.4 release notes update for pg_bench line limit item
commit : 6a61308fba6f474c840192052bca8c86df95927c
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 20 May 2014 14:10:09 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 20 May 2014 14:10:09 -0400
Prevent auto_explain from changing the output of a user’s EXPLAIN.
commit : e416830a296f440acd67afd8599dde5411021fc4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 May 2014 12:20:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 May 2014 12:20:47 -0400
Commit af7914c6627bcf0b0ca614e9ce95d3f8056602bf, which introduced the
EXPLAIN (TIMING) option, for some reason coded explain.c to look at
planstate->instrument->need_timer rather than es->timing to decide
whether to print timing info. However, the former flag might get set
as a result of contrib/auto_explain wanting timing information. We
certainly don't want activation of auto_explain to change user-visible
statement behavior, so fix that.
Also fix an independent bug introduced in the same patch: in the code
path for a never-executed node with a machine-friendly output format,
if timing was selected, it would fail to print the Actual Rows and Actual
Loops items.
Per bug #10404 from Tomonari Katsumata. Back-patch to 9.2 where the
faulty code was introduced.
Update obsolete comment.
commit : a0841ecd2518d4505b96132b764b918ab5d21ad4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 May 2014 16:38:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 May 2014 16:38:49 -0400
commit : 4e92f780123ca862970816d3fa70d3baf2fcbea4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 19 May 2014 14:15:21 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 19 May 2014 14:15:21 +0300
Lowercase help statements. Use an existing message to reduce the number
of strings to be translated.
Euler Taveira
Fix backup-block numbering in redo of b-tree split.
commit : c91a9b5a285e20e54cf90f3660ce51ce3a5c2ef4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 19 May 2014 13:16:24 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 19 May 2014 13:16:24 +0300
I got the backup block numbers off-by-one in the commit that changed the
way incomplete-splits are handled. I blame the comments, which said
"backup block 1" and "backup block 2", even though the backup blocks
are numbered starting from 0, in the macros and functions used in replay.
Fix the comments and the code.
Per Jeff Janes' bug report about corruption caused by torn page writes.
The incorrect code is new in git master, but backpatch the comment change
down to 9.0, where the numbering in the redo-side macros was changed.
Fix incorrect column name in pg_stat_replication document.
commit : eb56812144bb310f7cb2f63e53d6d58f30df95b5
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 19 May 2014 17:03:30 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 19 May 2014 17:03:30 +0900
commit : 009ca5e7821d742ed118a87c756c857895f3ffdd
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 19 May 2014 00:47:45 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 19 May 2014 00:47:45 -0400
commit : b05d1e3c0b2477797cd04b1e8dd1d3b91306e671
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 19 May 2014 00:35:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 19 May 2014 00:35:02 -0400
commit : e41cc470bb57a0f3a765fa44b77ef104b5a5a01e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 May 2014 00:06:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 May 2014 00:06:26 -0400
C89 says that compound initializers may only contain constant expressions;
a restriction violated by commit 89d00cbe. While we've had no actual field
complaints about this, C89 is still the project standard, and it's not
saving all that much code to break compatibility here. So let's adhere to
the old restriction.
In passing, replace a bunch of hardwired constants "256" with
sizeof(target-variable), just because the latter is more readable and
less breakable. And const-ify where possible.
Back-patch to 9.3 where the nonportable code was added.
Andres Freund and Tom Lane
doc: improve 9.4 release notes
commit : 4d30d4b9d725211859c63a18e458015636d24b94
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 18 May 2014 23:59:23 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 18 May 2014 23:59:23 -0400
commit : 0c19aaba22c4d904f7259ef11f7d6db7b5dd36a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 18 May 2014 18:17:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 18 May 2014 18:17:55 -0400
That's what I get for not fully retesting the final version of the patch.
The replace_allowed cross-check needs an additional special case for
bootstrapping.
Fix two ancient memory-leak bugs in relcache.c.
commit : 078b2ed291c758e7125d72c3a235f128d40a232b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 18 May 2014 16:51:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 18 May 2014 16:51:46 -0400
RelationCacheInsert() ignored the possibility that hash_search(HASH_ENTER)
might find a hashtable entry already present for the same OID. However,
that can in fact occur during recursive relcache load scenarios. When it
did happen, we overwrote the pointer to the pre-existing Relation, causing
a session-lifespan leakage of that entire structure. As far as is known,
the pre-existing Relation would always have reference count zero by the
time we arrive back at the outer insertion, so add code that deletes the
pre-existing Relation if so. If by some chance its refcount is positive,
elog a WARNING and allow the pre-existing Relation to be leaked as before.
Also, AttrDefaultFetch() was sloppy about leaking the cstring form of the
pg_attrdef.adbin value it's copying into the relcache structure. This is
only a query-lifespan leakage, and normally not very significant, but it
adds up during CLOBBER_CACHE testing.
These bugs are of very ancient vintage, but I'll refrain from back-patching
since there's no evidence that these leaks amount to anything in ordinary
usage.
Make fallback implementation of pg_memory_barrier() work.
commit : 44cd47c1d49655c5dd9648bde8e267617c3735b4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 May 2014 18:29:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 May 2014 18:29:46 -0400
The fallback implementation involves acquiring and releasing a spinlock
variable that is otherwise unreferenced --- not even to the extent of
initializing it. This accidentally fails to fail on platforms where
spinlocks should be initialized to zeroes, but elsewhere it results in
a "stuck spinlock" failure during startup.
I griped about this last July, and put in a hack that worked for gcc
on HPPA, but didn't get around to fixing the general case. Per the
discussion back then, the best thing to do seems to be to initialize
dummy_spinlock in main.c.
Fix a bunch of functions that were declared static then defined not-static.
commit : c1907f0cc49e38df9853b7547c9afce5204e4784
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 May 2014 17:57:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 May 2014 17:57:53 -0400
Per testing with a compiler that whines about this.
Fix unaligned accesses in DecodeUpdate().
commit : 6c42b2b10af3f717030966b9f05867f3e065becc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 May 2014 15:53:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 May 2014 15:53:21 -0400
The xl_heap_header_len structures in an XLOG_HEAP_UPDATE record aren't
necessarily aligned adequately. The regular replay function for these
records is aware of that, but decode.c didn't get the memo. I'm not
sure why the buildfarm failed to catch this; the test_decoding test
certainly blows up real good on my old HPPA box.
Also, I'm pretty sure that the address arithmetic was wrong for the
case of XLOG_HEAP_CONTAINS_OLD and not XLOG_HEAP_CONTAINS_NEW_TUPLE,
though this apparently can't happen when logical decoding is active.
Update README, we don’t do post-recovery cleanup actions anymore.
commit : a3655dd4a5cee3917a7d1766e07e36013e7e8835
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 17 May 2014 13:48:52 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 17 May 2014 13:48:52 +0300
transam/README explained how B-tree incomplete splits were tracked and
fixed after recovery, as an example of handling complex actions that need
multiple WAL records, but that's not how it works anymore. Explain the new
paradigm.
Make sure chr(int) can’t create invalid UTF8 sequences.
commit : 7894ac5004d5ec158f46296540d3cf49386d30e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 16:51:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 16:51:28 -0400
Several years ago we changed chr(int) so that if the database encoding is
UTF8, it would interpret its argument as a Unicode code point and expand it
into the appropriate multibyte sequence. However, we weren't sufficiently
careful about checking validity of the input. According to RFC3629, UTF8
disallows code points above U+10FFFF (note that the predecessor standard
RFC2279 was more liberal). Also, both versions of the UTF8 spec agree
that Unicode surrogate-pair codes should never appear in UTF8. Because
our encoding validity checks follow RFC3629, our failure to enforce these
restrictions in chr() means it could be used to produce text strings that
will be rejected when the database is dumped and reloaded. To ensure
consistency with the input functions, let's actually apply
pg_utf8_islegal() to the proposed output of chr().
Per discussion, this seems like too much of a behavioral change to
back-patch, but it's not too late to squeeze it into 9.4.
Suppress some more valgrind whining about btree_gist.
commit : af215d8190e6ab170c02c24afd1be81f5a147481
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 15:29:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 15:29:02 -0400
A couple of functions didn't bother to zero out pad bytes in datums that
would ultimately go to disk. Harmless, but valgrind doesn't know that.
Fix a second cause of undersized pallocs for btree_gist indexes on macaddr.
commit : 39586bc1e971c136c4487b26eb7334dbbe23b102
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 15:18:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 15:18:09 -0400
gbt_macad_union also allocated 12-byte structs where we really need 16.
Per report from Andres Freund. No back-patch since there's no current
risk of a real problem.
Fix valgrind warning for btree_gist indexes on macaddr.
commit : 82bbb60c30dbff0633da34387ccab58d843379b5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 15:11:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 May 2014 15:11:51 -0400
The macaddr opclass stores two macaddr structs (each of size 6) in an
index column that's declared as being of type gbtreekey16, ie 16 bytes.
In the original coding this led to passing a palloc'd value of size 12
to the index insertion code, so that data would be fetched past the
end of the allocated value during index tuple construction. This makes
valgrind unhappy. In principle it could result in a SIGSEGV, though
with the current implementation of palloc there's no risk since
the 12-byte request size would be rounded up to 16 bytes anyway.
To fix, add a field to struct gbtree_ninfo showing the declared size of
the index datums, and use that in the palloc requests; and use palloc0
to be sure that any wasted bytes are cleanly initialized.
Per report from Andres Freund. No back-patch since there's no current
risk of a real problem.
Add test case for logical decoding of prepared transactions.
commit : d900e192a3ef2dd73fae4522c35aadce6d72a534
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 11:33:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 11:33:49 +0300
Fix test_decoding test case’s check that slot has been dropped.
commit : afd0fcbc5d421454e7d55d949cca0721c9c135c3
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 11:23:17 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 11:23:17 +0300
pg_stat_replication shows connected replication clients. The ddl test case
never has any replication clients connected, so querying pg_stat_replication
is pointless. To check that a slot has been dropped correctly, query
pg_replication_slots instead.
Andres Freund
Fix thinko in logical decoding of commit-prepared records.
commit : 03e2b1017c0d360cae0b4d0a8bf5d6924536c834
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 10:53:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 10:53:10 +0300
The decoding of prepared transaction commits accidentally used the XID of
the transaction performing the COMMIT PREPARED, not the XID of the prepared
transaction. Before bb38fb0d43c8d that lead to those transactions not being
decoded, afterwards to a assertion failure.
Open output file before sleeping in pg_recvlogical.
commit : e7873b74d9c1bb7a325960f52043db6de88e6e66
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 10:10:45 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 10:10:45 +0300
Let's complain about e.g an invalid path or permission problem sooner rather
than later. Before this patch, we would only try to open the output file
after receiving the first decoded message from the server.
Initialize tsId and dbId fields in WAL record of COMMIT PREPARED.
commit : 07a4a93a0e35a778c77ffbbbc18de29e859e18f0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 09:47:50 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 May 2014 09:47:50 +0300
Commit dd428c79 added dbId and tsId to the xl_xact_commit struct but missed
that prepared transaction commits reuse that struct. Fix that.
Because those fields were left unitialized, replaying a commit prepared WAL
record in a hot standby node would fail to remove the relcache init file.
That can lead to "could not open file" errors on the standby. Relcache init
file only needs to be removed when a system table/index is rewritten in the
transaction using two phase commit, so that should be rare in practice. In
HEAD, the incorrect dbId/tsId values are also used for filtering in logical
replication code, causing the transaction to always be filtered out.
Analysis and fix by Andres Freund. Backpatch to 9.0 where hot standby was
introduced.
Fix unportable setvbuf() usage in initdb.
commit : f62d417825d6a8e26768a130a5f4c9e454d9dbe4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 May 2014 15:57:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 May 2014 15:57:54 -0400
In yesterday's commit 2dc4f011fd61501cce507be78c39a2677690d44b, I tried
to force buffering of stdout/stderr in initdb to be what it is by
default when the program is run interactively on Unix (since that's how
most manual testing is done). This tripped over the fact that Windows
doesn't support _IOLBF mode. We dealt with that a long time ago in
syslogger.c by falling back to unbuffered mode on Windows. Export that
solution in port.h and use it in initdb.
Back-patch to 8.4, like the previous commit.
Fix whitespace
commit : 2f8e68bd7ea3523977567369056c4b3e67e44fdc
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 15 May 2014 13:23:31 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 15 May 2014 13:23:31 -0400
Fix a couple of bugs in pg_recvlogical output to stdout.
commit : 00c26b6a60e7ceed29ddae34b0a69fe945c08f81
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 19:43:37 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 19:43:37 +0300
Don't close stdout on SIGHUP. Also, when a SIGHUP is received, close the
file immediately, rather than only after receiving some more data from
the server. Rename a variable, to avoid mentally dealing with double
negatives (not unsynced means synced).
Handle duplicate XIDs in txid_snapshot.
commit : 8f9b9590d79fc1fc1ad08b207401acfdbb0bfac7
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 18:29:20 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 18:29:20 +0300
The proc array can contain duplicate XIDs, when a transaction is just being
prepared for two-phase commit. To cope, remove any duplicates in
txid_current_snapshot(). Also ignore duplicates in the input functions, so
that if e.g. you have an old pg_dump file that already contains duplicates,
it will be accepted.
Report and fix by Jan Wieck. Backpatch to all supported versions.
Fix race condition in preparing a transaction for two-phase commit.
commit : bb38fb0d43c8d7ff54072bfd8bd63154e536b384
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 16:37:50 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 16:37:50 +0300
To lock a prepared transaction's shared memory entry, we used to mark it
with the XID of the backend. When the XID was no longer active according
to the proc array, the entry was implicitly considered as not locked
anymore. However, when preparing a transaction, the backend's proc array
entry was cleared before transfering the locks (and some other state) to
the prepared transaction's dummy PGPROC entry, so there was a window where
another backend could finish the transaction before it was in fact fully
prepared.
To fix, rewrite the locking mechanism of global transaction entries. Instead
of an XID, just have simple locked-or-not flag in each entry (we store the
locking backend's backend id rather than a simple boolean, but that's just
for debugging purposes). The backend is responsible for explicitly unlocking
the entry, and to make sure that that happens, install a callback to unlock
it on abort or process exit.
Backpatch to all supported versions.
Misc message style and doc fixes.
commit : ff810b4928882bfdc4ebe1ce603c47830aba3132
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 14:49:11 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 14:49:11 +0300
Silence warnings about redefining popen on Mingw-w64.
commit : a82a17475d8a8a91df5fd1448b0f93772f590ecd
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 12:18:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 May 2014 12:18:49 +0300
Mingw-w64 headers map popen/pclose to _popen and _pclose, but we want to use
our popen wrapper rather than the Mingw-w64. #undef the Mingw's version.
doc: Clarify what files pg_basebackup omits from data directory
commit : 4773c70aa4c938c367ee179f7301f70a4efabc0e
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 14 May 2014 22:26:49 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 14 May 2014 22:26:49 -0400
commit : c424c049189f758920b1a3bb961bc05c93a900df
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 14 May 2014 22:19:18 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 14 May 2014 22:19:18 -0400
In initdb, ensure stdout/stderr buffering behavior is what we expect.
commit : 2dc4f011fd61501cce507be78c39a2677690d44b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 21:13:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 21:13:54 -0400
Since this program may print to either stdout or stderr, the relative
ordering of its messages depends on the buffering behavior of those files.
Force stdout to be line-buffered and stderr to be unbuffered, ensuring
that the behavior will match standard Unix interactive behavior, even
when stdout and stderr are rerouted to a file.
Per complaint from Tomas Vondra. The particular case he pointed out is
new in HEAD, but issues of the same sort could arise in any branch with
other error messages, so back-patch to all branches.
I'm unsure whether we might not want to do this in other client programs
as well. For the moment, just fix initdb.
pg_update: slight major version adjustment
commit : 2e6602dfc25d1f8e8a2e1df48c96440b02aa19c1
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 21:13:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 21:13:59 -0400
Fix version check for pg_upgrade line type crosscheck.
commit : 4456763c78d2a94c42e67ce788fbe94a07aa12dc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 20:23:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 20:23:32 -0400
commit : bb797b640449d67f722d27660c718b68a692f8f9
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 16:26:06 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 16:26:06 -0400
The data type internal format changed in 9.4. Also mention this in the
9.4 release notes.
Code review for recent changes in relcache.c.
commit : b23b0f5588d2e2f15edff66e072e339a8c9616a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 14:55:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 14:55:48 -0400
rd_replidindex should be managed the same as rd_oidindex, and rd_keyattr
and rd_idattr should be managed like rd_indexattr. Omissions in this area
meant that the bitmapsets computed for rd_keyattr and rd_idattr would be
leaked during any relcache flush, resulting in a slow but permanent leak in
CacheMemoryContext. There was also a tiny probability of relcache entry
corruption if we ran out of memory at just the wrong point in
RelationGetIndexAttrBitmap. Otherwise, the fields were not zeroed where
expected, which would not bother the code any AFAICS but could greatly
confuse anyone examining the relcache entry while debugging.
Also, create an API function RelationGetReplicaIndex rather than letting
non-relcache code be intimate with the mechanisms underlying caching of
that value (we won't even mention the memory leak there).
Also, fix a relcache flush hazard identified by Andres Freund:
RelationGetIndexAttrBitmap must not assume that rd_replidindex stays valid
across index_open.
The aspects of this involving rd_keyattr date back to 9.3, so back-patch
those changes.
doc: fix 9.4 release notes typo
commit : ac53295d667e7727d7b70ddf11d82c067870501f
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 14:13:19 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 14:13:19 -0400
commit : eefd90c4a95449f02b568d5370cfe6bcd1bf13e9
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 12:21:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 12:21:03 -0400
commit : 31a263237fa3eb6f36d58335fbdb82bab3136db3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 11:51:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 May 2014 11:51:10 -0400
Historically we've printed a complaint for a bad locale setting, but then
fallen back to the environment default. Per discussion, this is not such
a great idea, because rectifying an erroneous locale choice post-initdb
(perhaps long after data has been loaded) could be enormously expensive.
Better to complain and give the user a chance to double-check things.
The behavior was particularly bad if the bad setting came from environment
variables rather than a bogus command-line switch: in that case not only
was there a fallback to C/SQL_ASCII, but the printed complaint was quite
unhelpful. It's hard to be entirely sure what variables setlocale looked
at, but we can at least give a hint where the problem might be.
Per a complaint from Tomas Vondra.
docs: mention windows quoting change in 9.4 release notes
commit : eb6144bb447ecbb036bfa08da85940cd50d49410
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 11:02:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 11:02:03 -0400
doc: auto-updatable view adjustments for 9.4 release notes
commit : e513087f6401a64b0d9f0b20cd2a51a7938ac645
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 10:07:24 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 14 May 2014 10:07:24 -0400
commit : 062f53518927f9bfe1820578ce79d3180b1aa2ca
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 13 May 2014 15:12:54 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 13 May 2014 15:12:54 -0400
commit : f35aef415aa755c4e99f8c0ef83f9d14dbc48bb4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 13 May 2014 19:17:28 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 13 May 2014 19:17:28 +0300
When cache invalidations arrive while ri_LoadConstraintInfo() is busy
filling a new cache entry, InvalidateConstraintCacheCallBack() compares
the - not yet initialized - oidHashValue field with the to-be-invalidated
hash value. To fix, check whether the entry is already marked as invalid.
Andres Freund
Initialize padding bytes in btree_gist varbit support.
commit : 540ac7cea919623f691b20892ccc50e5e33b5009
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 13 May 2014 14:16:28 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 13 May 2014 14:16:28 +0300
The code expands a varbit gist leaf key to a node key by copying the bit
data twice in a varlen datum, as both the lower and upper key. The lower key
was expanded to INTALIGN size, but the padding bytes were not initialized.
That's a problem because when the lower/upper keys are compared, the padding
bytes are used compared too, when the values are otherwise equal. That could
lead to incorrect query results.
REINDEX is advised for any btree_gist indexes on bit or bit varying data
type, to fix any garbage padding bytes on disk.
Per Valgrind, reported by Andres Freund. Backpatch to all supported
versions.
Add Valgrind suppression for reorderbuffer padding bytes.
commit : 5a90ac29c44f0dabf1e3a7b0443ba772cf206e2e
author : Noah Misch <noah@leadboat.com>
date : Mon, 12 May 2014 23:03:49 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 12 May 2014 23:03:49 -0400
docs: use structfield instead of structname in 9.4 release notes
commit : 9af8bd51a10edaf454c6b5246d79eded73528fd2
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 12 May 2014 21:37:49 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 12 May 2014 21:37:49 -0400
commit : 6de9a6c015d543c41933171cd6cf5d357597f19f
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 12 May 2014 21:30:58 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 12 May 2014 21:30:58 -0400
Be more wary in choice of timezone names to test make_timestamptz with.
commit : 66b737cd9a72e10df4de1867ae7b675bc48d478c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 May 2014 20:21:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 May 2014 20:21:16 -0400
America/Metlakatla hasn't been in the IANA database all that long, so
some installations might not have it. It does seem worthwhile to test
with a fractional-minute GMT offset, but we can get that from almost
any pre-1900 date; I chose Europe/Paris, whose LMT offset from Greenwich
should be pretty darn well established.
Also, assuming that Mars/Mons_Olympus will never be in the IANA database
seems less than future-proof, so let's use a more fanciful location for
the bad-zone-name check.
Per complaint from Christoph Berg.
Ignore config.pl and buildenv.pl in src/tools/msvc.
commit : 73011f35eca7f4a3973289d5813648abbc1074a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 May 2014 14:24:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 May 2014 14:24:18 -0400
config.pl and buildenv.pl can be used to customize build settings when
using MSVC. They should never get committed into the common source tree.
Back-patch to 9.0; it looks like the rules were different in 8.4.
Michael Paquier
Fix typo in test_shm_mq document.
commit : a3632771bb66eec74c7e73c0d7a5f8cdd6719be2
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 13 May 2014 01:41:54 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 13 May 2014 01:41:54 +0900
commit : c890b488063e23f12b5ab01c9a6d254a034fcea2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 12 May 2014 10:17:40 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 12 May 2014 10:17:40 +0300
The leak is fairly small and rare, but a leak nevertheless.
Per Coverity report. Backpatch to 9.2, where pg_receivexlog was added.
pg_basebackup shares the code, but it always exits on error, so there is
no real leak.
Stamp 9.4beta1.
commit : e6df2e1be6330660ba4d81daa726ae4a71535aa9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 May 2014 17:16:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 May 2014 17:16:48 -0400
Find postgresql.auto.conf in PGDATA even when postgresql.conf is elsewhere.
commit : 195e81aff5d63da1e1f9dd0314a13859ec15c7c0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 May 2014 15:13:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 May 2014 15:13:30 -0400
The original coding for ALTER SYSTEM made a fundamentally bogus assumption
that postgresql.auto.conf could be sought relative to the main config file
if we hadn't yet determined the value of data_directory. This fails for
common arrangements with the config file elsewhere, as reported by
Christoph Berg.
The simplest fix is to not try to read postgresql.auto.conf until after
SelectConfigFiles has chosen (and locked down) the data_directory setting.
Because of the logic in ProcessConfigFile for handling resetting of GUCs
that've been removed from the config file, we cannot easily read the main
and auto config files separately; so this patch adopts a brute force
approach of reading the main config file twice during postmaster startup.
That's a tad ugly, but the actual time cost is likely to be negligible,
and there's no time for a more invasive redesign before beta.
With this patch, any attempt to set data_directory via ALTER SYSTEM
will be silently ignored. It would probably be better to throw an
error, but that can be dealt with later. This bug, however, would
prevent any testing of ALTER SYSTEM by a significant fraction of the
userbase, so it seems important to get it fixed before beta.
Rename jsonb_hash_ops to jsonb_path_ops.
commit : 12e611d43e6efbf0e36014a3055ed47366facee7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 May 2014 12:06:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 May 2014 12:06:04 -0400
There's no longer much pressure to switch the default GIN opclass for
jsonb, but there was still some unhappiness with the name "jsonb_hash_ops",
since hashing is no longer a distinguishing property of that opclass,
and anyway it seems like a relatively minor detail. At the suggestion of
Heikki Linnakangas, we'll use "jsonb_path_ops" instead; that captures the
important characteristic that each index entry depends on the entire path
from the document root to the indexed value.
Also add a user-facing explanation of the implementation properties of
these two opclasses.
Translation updates
commit : e136271a947d142eaa7093a789e6fa9ceda18c17
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 10 May 2014 21:53:11 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 10 May 2014 21:53:11 -0400
docs: Mark 9.4 release notes as current as of today
commit : ea78ce1d457d8e0fef01328219a1dfd89aeba7ae
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 10 May 2014 22:03:24 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 10 May 2014 22:03:24 -0400
Rename min_recovery_apply_delay to recovery_min_apply_delay.
commit : 0d0b2bf175a53dfedcc0cb69eaba7576b0c286f2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 19:46:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 19:46:19 -0400
Per discussion, this seems like a more consistent choice of name.
Fabrízio de Royes Mello, after a suggestion by Peter Eisentraut;
some additional documentation wordsmithing by me
More work on the JSON/JSONB user documentation.
commit : f825c7c850dbe683d62defd7e5bd31664ee3302c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 18:56:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 18:56:52 -0400
Document existence operator adequately; fix obsolete claim that no
Unicode-escape semantic checks happen on input (it's still true for
json, but not for jsonb); improve examples; assorted wordsmithing.
Fix bug in lossy-page handling in GIN
commit : 866e6e1d04d4ae9615bd1899a757dae0191e9c77
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 10 May 2014 23:24:23 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 10 May 2014 23:24:23 +0300
When returning rows from a bitmap, as done with partial match queries, we
would get stuck in an infinite loop if the bitmap contained a lossy page
reference.
This bug is new in master, it was introduced by the patch to allow skipping
items refuted by other entries in GIN scans.
Report and fix by Alexander Korotkov
Accept tcl 8.6 in configure’s probe for tclsh.
commit : eaba54c20c5ab2cb6aaffa574444fd4990dfe2c7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 10:48:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 10:48:01 -0400
Usually the search would find plain "tclsh" without any trouble,
but some installations might only have the version-numbered flavor
of that program.
No compatibility problems have been reported with 8.6, so we might
as well back-patch this to all active branches.
Christoph Berg
Update config.guess and config.sub
commit : 7fa5bc43aaaf01e23c3a6ab59a57c19273f6f7f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 10:33:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 May 2014 10:33:34 -0400
commit : 17e4082b6312383075e397b4b2ae324c90716c5b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 20:25:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 20:25:42 -0400
Fix broken allocation logic in recently-rewritten jsonb_util.c.
commit : 3d8c2b496fc1fed2b8ff8a403d3a17329325466e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 18:24:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 18:24:17 -0400
reserveFromBuffer() failed to consider the possibility that it needs to
more-than-double the current buffer size. Beyond that, it seems likely
that we'd someday need to worry about integer overflow of the buffer
length variable. Rather than reinvent the logic that's already been
debugged in stringinfo.c, let's go back to using that logic. We can
still have the same targeted API, but we'll rely on stringinfo.c to
manage reallocation.
Per report from Alexander Korotkov.
Improve user-facing JSON documentation.
commit : 0b92a77c17ebe8bec08e250e1a929b07efef1008
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 16:33:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 16:33:25 -0400
I started out with the intention of just fixing the info about the jsonb
operator classes, but soon found myself copy-editing most of the JSON
material. Hopefully it's more readable now.
Get rid of bogus dependency on typcategory in to_json() and friends.
commit : 0ca6bda8e7501947c05f30c127f6d12ff90b5a64
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 12:55:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 12:55:00 -0400
These functions were relying on typcategory to identify arrays and
composites, which is not reliable and not the normal way to do it.
Using typcategory to identify boolean, numeric types, and json itself is
also pretty questionable, though the code in those cases didn't seem to be
at risk of anything worse than wrong output. Instead, use the standard
lsyscache functions to identify arrays and composites, and rely on a direct
check of the type OID for the other cases.
In HEAD, also be sure to look through domains so that a domain is treated
the same as its base type for conversions to JSON. However, this is a
small behavioral change; given the lack of field complaints, we won't
back-patch it.
In passing, refactor so that there's only one copy of the code that decides
which conversion strategy to apply, not multiple copies that could (and
have) gotten out of sync.
Code review for logical decoding patch.
commit : f1d8dd3647fd0c87f0fb238f7cfc45c1ce282a55
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 9 May 2014 10:44:04 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 9 May 2014 10:44:04 -0400
Post-commit review identified a number of places where addition was
used instead of multiplication or memory wasn't zeroed where it should
have been. This commit also fixes one case where a structure member
was mis-initialized, and moves another memory allocation closer to
the place where the allocated storage is used for clarity.
Andres Freund
Remove overeager assertion in logical_heap_begin_rewrite.
commit : b2dada8f5f90ab015ca8a62b46261ef01a7c781f
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 9 May 2014 10:33:40 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 9 May 2014 10:33:40 -0400
It's legal to configure wal_level=logical and max_replication_slots=0
simultaneously.
Andres Freund
Teach add_json() that jsonb is of TYPCATEGORY_JSON.
commit : 62e57ff040e5d0acd303b94e86fff689effc5957
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 09:44:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 09:44:11 -0400
This code really needs to be refactored so that there aren't so many copies
that can diverge. Not to mention that this whole approach is probably
wrong. But for the moment I'll just stick my finger in the dike.
Per report from Michael Paquier.
Fix typcategory labeling of jsonb.
commit : bdf9dd4db78a5f23e863f2d4d8500969dc261fd0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 09:25:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 09:25:58 -0400
Dunno who had the cute idea of labeling jsonb as typcategory 'C',
but it is not a composite type. Label it 'U', since that's what
json is using.
More jsonb cleanup.
commit : d9daff0e0cb15221789e6c50d9733c8754c054fb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 9 May 2014 15:55:56 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 9 May 2014 15:55:56 +0300
Fix JSONB_MAX_ELEMS and JSONB_MAX_PAIRS macros to use CB_MASK in the
calculation. JENTRY_POSMASK happens to have the same value at the moment,
but that's just coincidental.
Refactor jsonb iterator functions, for readability.
Get rid of the JENTRY_ISFIRST flag. Whenever we handle JEntrys, we have
access to the whole array and have enough context information to know
which entry is the first. This frees up one bit in the JEntry header for
future use. While we're at it, shuffle the JEntry bits so that boolean
true and false go together, for aesthetic reasons.
Bump catalog version as this changes the on-disk format slightly.
Improve key representation for GIN jsonb_ops, and fix existence-search bug.
commit : 46dddf7673c5820be7c78a8b0e098fdbc65d003d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 08:41:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 May 2014 08:41:26 -0400
Change the key representation so that values that would exceed 127 bytes
are hashed into short strings, and so that the original JSON datatype of
each value is recorded in the index. The hashing rule eliminates the major
objection to having this opclass be the default for jsonb, namely that it
could fail for plausible input data (due to GIN's restrictions on maximum
key length). Preserving datatype information doesn't really buy us much
right now, but it requires no extra space compared to the previous way,
and it might be useful later.
Also, change the consistency-checking functions to request recheck for
exists (jsonb ? text) and related operators. The original analysis that
this is an exactly checkable query was incorrect, since the index does
not preserve information about whether a key appears at top level in
the indexed JSON object. Add a test case demonstrating the problem.
Make some other, mostly cosmetic improvements to the code in jsonb_gin.c
as well.
catversion bump due to on-disk data format change in jsonb_ops indexes.
Minor cleanup of jsonb_util.c
commit : ff7bbb0176a667aeb0577e4d48d651ffdb6afd50
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 9 May 2014 13:09:59 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 9 May 2014 13:09:59 +0300
Move the functions around to group related functions together. Remove
binequal argument from lengthCompareJsonbStringValue, moving that
responsibility to lengthCompareJsonbPair. Fix typo in comment.
Avoid some pnstrdup()s when constructing jsonb
commit : d3c72e23df6ef1fde8122db589d12d49c8495535
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 9 May 2014 11:32:28 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 9 May 2014 11:32:28 +0300
This speeds up text to jsonb parsing and hstore to jsonb conversions
somewhat.
Fix missing dependencies in ecpg’s test Makefiles.
commit : 14d309cc55d88b73d4c9d1fa51b535ae491405fd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 22:34:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 22:34:51 -0400
Ensure that ecpg preprocessor output files are rebuilt when re-testing
after a change in the ecpg preprocessor itself, or a change in any of
several include files that get copied verbatim into the output files.
The lack of these dependencies was what created problems for Kevin Grittner
after the recent pgindent run. There's no way for --enable-depend to
discover these dependencies automatically, so we've gotta put them into
the Makefiles by hand.
While at it, reduce the amount of duplication in the ecpg invocations.
Document permissions needed for pg_database_size and pg_tablespace_size.
commit : fb1974cc6b58cd21a269dd7ab8aea0120906ec3b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 21:45:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 21:45:02 -0400
Back in 8.3, we installed permissions checks in these functions (see
commits 8bc225e7990a and cc26599b7206). But we forgot to document that
anywhere in the user-facing docs; it did get mentioned in the 8.3 release
notes, but nobody's looking at that any more. Per gripe from Suya Huang.
Increase the default value of effective_cache_size to 4GB.
commit : b910d7ea358b0134d170ebf4002248df25a5f244
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 21:11:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 21:11:47 -0400
Per discussion, the old value of 128MB is ridiculously small on modern
machines; in fact, it's not even any larger than the default value of
shared_buffers, which it certainly should be. Increase to 4GB, which
is unlikely to be any worse than the old default for anyone, and should
be noticeably better for most. Eventually we might have an autotuning
scheme for this setting, but the recent attempt crashed and burned,
so for now just do this.
Revert “Auto-tune effective_cache size to be 4x shared buffers”
commit : a16d421ca4fc639929bc964b2585e8382cf16e33
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 20:49:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 20:49:38 -0400
This reverts commit ee1e5662d8d8330726eaef7d3110cb7add24d058, as well as
a remarkably large number of followup commits, which were mostly concerned
with the fact that the implementation didn't work terribly well. It still
doesn't: we probably need some rather basic work in the GUC infrastructure
if we want to fully support GUCs whose default varies depending on the
value of another GUC. Meanwhile, it also emerged that there wasn't really
consensus in favor of the definition the patch tried to implement (ie,
effective_cache_size should default to 4 times shared_buffers). So whack
it all back to where it was. In a followup commit, I'll do what was
recently agreed to, which is to simply change the default to a higher
value.
Un-break ecpg test suite under –disable-integer-datetimes.
commit : 08c8e8962f56c23c6799178d52d3b31350a0708f
author : Noah Misch <noah@leadboat.com>
date : Thu, 8 May 2014 19:29:02 -0400
committer: Noah Misch <noah@leadboat.com>
date : Thu, 8 May 2014 19:29:02 -0400
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b broke it. The change in
sub-second precision at extreme dates is normal. The inconsistent
truncation vs. rounding is essentially a bug, albeit a longstanding one.
Back-patch to 8.4, like the causative commit.
Fix comment.
commit : 1e81f8462aceb07d520daaabdc999b879381bd12
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 12:42:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 12:42:56 -0400
Previous commit was confused about the case we're handling: actually,
what the patch is dealing with is platforms that have optreset, *and*
have <getopt.h>, but the latter fails to declare the former. Because
we use a linking probe to set HAVE_INT_OPTRESET, we need to be sure we
have a declaration even if <getopt.h> doesn't think it exists.
Allow for platforms that have optreset but not .
commit : 0c15a524c532c1006a7bd36d3a680f8e8b8db9fc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 12:33:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 8 May 2014 12:33:29 -0400
Reportedly, some versions of mingw are like that, and it seems plausible
in general that older platforms might be that way. However, we'd
determined experimentally that just doing "extern int" conflicts with
the way Cygwin declares these variables, so explicitly exclude Cygwin.
Michael Paquier, tweaked by me to hopefully not break Cygwin
Protect against torn pages when deleting GIN list pages.
commit : 4f7bb4b2a36facc94a1d6b821ec6733093aa9bc6
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 8 May 2014 14:43:04 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 8 May 2014 14:43:04 +0300
To-be-deleted list pages contain no useful information, as they are being
deleted, but we must still protect the writes from being torn by a crash
after a partial write. To do that, re-initialize the pages on WAL replay.
Jeff Janes caught this with a test program to test partial writes.
Backpatch to all supported versions.
Include files copied from libpqport in .gitignore
commit : 02c9a938057ecb811c65999577d32c5f5e9c99dc
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 8 May 2014 10:56:57 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 8 May 2014 10:56:57 +0300
Avoid buffer bloat in libpq when server is consistently faster than client.
commit : 2f557167b19af79ffecb8faedf8b7bce4d48f3e1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 May 2014 21:38:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 May 2014 21:38:36 -0400
If the server sends a long stream of data, and the server + network are
consistently fast enough to force the recv() loop in pqReadData() to
iterate until libpq's input buffer is full, then upon processing the last
incomplete message in each bufferload we'd usually double the buffer size,
due to supposing that we didn't have enough room in the buffer to finish
collecting that message. After filling the newly-enlarged buffer, the
cycle repeats, eventually resulting in an out-of-memory situation (which
would be reported misleadingly as "lost synchronization with server").
Of course, we should not enlarge the buffer unless we still need room
after discarding already-processed messages.
This bug dates back quite a long time: pqParseInput3 has had the behavior
since perhaps 2003, getCopyDataMessage at least since commit 70066eb1a1ad
in 2008. Probably the reason it's not been isolated before is that in
common environments the recv() loop would always be faster than the server
(if on the same machine) or faster than the network (if not); or at least
it wouldn't be slower consistently enough to let the buffer ramp up to a
problematic size. The reported cases involve Windows, which perhaps has
different timing behavior than other platforms.
Per bug #7914 from Shin-ichi Morita, though this is different from his
proposed solution. Back-patch to all supported branches.
When a background worker exists with code 0, unregister it.
commit : be7558162acc5578d0b2cf0c8d4c76b6076ce352
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 17:43:39 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 17:43:39 -0400
The previous behavior was to restart immediately, which was generally
viewed as less useful.
Petr Jelinek, with some adjustments by me.
Fix build after removing JsonbValue.estSize field.
commit : 7572b7735971cd7a5ef289e133eedf7d82f79c42
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 8 May 2014 00:05:43 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 8 May 2014 00:05:43 +0300
Oops, I didn't realize that contrib/hstore refers to jsonb stuff.
When a bgworker exits, always call ReleasePostmasterChildSlot.
commit : eee6cf1f337aa488a20e9111df446cdad770e645
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 16:30:23 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 16:30:23 -0400
Commit e2ce9aa27bf20eff2d991d0267a15ea5f7024cd7 was insufficiently
well thought out. Repair.
Restart bgworkers immediately after a crash-and-restart cycle.
commit : 970d1f76d1600dfbdbd9cd88a9e2af113e253798
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 16:04:47 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 16:04:47 -0400
Just as we would start bgworkers immediately after an initial startup
of the server, we should restart them immediately when reinitializing.
Petr Jelinek and Robert Haas
Clean up jsonb code.
commit : 364ddc3e5cbd01c93a39896b5260509129a9883e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 7 May 2014 23:16:19 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 7 May 2014 23:16:19 +0300
The main target of this cleanup is the convertJsonb() function, but I also
touched a lot of other things that I spotted into in the process.
The new convertToJsonb() function uses an output buffer that's resized on
demand, so the code to estimate of the size of JsonbValue is removed.
The on-disk format was not changed, even though I refactored the structs
used to handle it. The term "superheader" is replaced with "container".
The jsonb_exists_any and jsonb_exists_all functions no longer sort the input
array. That was a premature optimization, the idea being that if there are
duplicates in the input array, you only need to check them once. Also,
sorting the array saves some effort in the binary search used to find a key
within an object. But there were drawbacks too: the sorting and
deduplicating obviously isn't free, and in the typical case there are no
duplicates to remove, and the gain in the binary search was minimal. Remove
all that, which makes the code simpler too.
This includes a bug-fix; the total length of the elements in a jsonb array
or object mustn't exceed 2^28. That is now checked.
Detach shared memory from bgworkers without shmem access.
commit : 4d155d8b08fe08c1a1649fdbad61c6dcf4a8671f
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 14:54:43 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 14:54:43 -0400
Since the postmaster won't perform a crash-and-restart sequence
for background workers which don't request shared memory access,
we'd better make sure that they can't corrupt shared memory.
Patch by me, review by Tom Lane.
Fix failure to set ActiveSnapshot while rewinding a cursor.
commit : 04e5025be8bbe572e12b19c4ba9e2a8360b8ffe5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 May 2014 14:25:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 May 2014 14:25:11 -0400
ActiveSnapshot needs to be set when we call ExecutorRewind because some
plan node types may execute user-defined functions during their ReScan
calls (nodeLimit.c does so, at least). The wisdom of that is somewhat
debatable, perhaps, but for now the simplest fix is to make sure the
required context is valid. Failure to do this typically led to a
null-pointer-dereference core dump, though it's possible that in more
complex cases a function could be executed with the wrong snapshot
leading to very subtle misbehavior.
Per report from Leif Jensen. It's been broken for a long time, so
back-patch to all active branches.
Never crash-and-restart for bgworkers without shared memory access.
commit : e2ce9aa27bf20eff2d991d0267a15ea5f7024cd7
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 13:19:02 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 7 May 2014 13:19:02 -0400
The motivation for a crash and restart cycle when a backend dies is
that it might have corrupted shared memory on the way down; and we
can't recover reliably except by reinitializing everything. But that
doesn't apply to processes that don't touch shared memory. Currently,
there's nothing to prevent a background worker that doesn't request
shared memory access from touching shared memory anyway, but that's a
separate bug.
Previous to this commit, the coding in postmaster.c was inconsistent:
an exit status other than 0 or 1 didn't provoke a crash-and-restart,
but failure to release the postmaster child slot did. This change
makes those cases consistent.
Fix some more confusion between uint32 and Datum.
commit : 1891b415f0cf45d56f29af423598f8518754d675
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 May 2014 23:52:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 May 2014 23:52:30 -0400
Fix interval test, which was broken for floating-point timestamps.
commit : 348aa75a678069569923c501206d5a1ca03654e3
author : Jeff Davis <jdavis@postgresql.org>
date : Tue, 6 May 2014 19:35:24 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Tue, 6 May 2014 19:35:24 -0700
Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that
couldn't be made consistent between integer and floating-point
timestamps.
It was designed to test the longest possible interval output length,
so removing four zeros from the number of hours, as this patch does,
is not ideal. But the test still has some utility for its original
purpose, and there aren't a lot of other good options.
Noah Misch suggested a different approach where we test that the
output either matches what we expect from integer timestamps or what
we expect from floating-point timestamps. That seemed to obscure an
otherwise simple test, however.
Reviewed by Tom Lane and Noah Misch.
hash_any returns Datum, not uint32 (and definitely not “int”).
commit : 2c22afaa4e29cbd773bae3f043a941f82ff30e2d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 May 2014 22:49:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 May 2014 22:49:32 -0400
The coding in JsonbHashScalarValue might have accidentally failed to fail
given current representational choices, but the key word there would be
"accidental". Insert the appropriate datatype conversion macro. And
use the right conversion macro for hash_numeric's result, too.
In passing make the code a bit cleaner and less repetitive by factoring
out the xor step from the switch.
Improve comment for tricky aspect of index-only scans.
commit : 35c0cd3b05b0be18dc2d049c33b38a2d13993ffe
author : Jeff Davis <jdavis@postgresql.org>
date : Sun, 4 May 2014 13:18:55 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Sun, 4 May 2014 13:18:55 -0700
Index-only scans avoid taking a lock on the VM buffer, which would
cause a lot of contention. To be correct, that requires some intricate
assumptions that weren't completely documented in the previous
comment.
Reviewed by Robert Haas.
doc: Fix DocBook XML validity
commit : 3a9d430af515e9dd8a9d34a4011367e667a66521
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 6 May 2014 21:28:58 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 6 May 2014 21:28:58 -0400
The main problem is that DocBook SGML allows indexterm elements just
about everywhere, but DocBook XML is stricter. For example, this common
pattern
<varlistentry>
<indexterm>...</indexterm>
<term>...</term>
...
</varlistentry>
needs to be changed to something like
<varlistentry>
<term>...<indexterm>...</indexterm></term>
...
</varlistentry>
See also bb4eefe7bf518e42c73797ea37b033a5d8a8e70a.
There is currently nothing in the build system that enforces that things
stay valid, because that requires additional tools and will receive
separate consideration.
With ecpg exclusion removed, re-run pgindent for 9.4
commit : 84288a86ac74dbeae486b6ff699c017f7d9517bb
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 20:39:28 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 20:39:28 -0400
commit : 9516668e48abcc5c036ecb199acf15e5bcc4b008
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 20:09:00 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 20:09:00 -0400
commit : 250f259a44411d341e75928401503a681844c59d
author : Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 6 May 2014 22:50:06 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 6 May 2014 22:50:06 +0100
Allow for translatable string, rather than use "or"
Improve pgindent test instructions
commit : 7c7b1f4ae5ea3b1b113682d4d4e5af4356b053bc
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 15:33:25 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 15:33:25 -0400
commit : e0124230ba2b6778671f26b06af0d8d04bcb4d1c
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 6 May 2014 13:37:46 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 6 May 2014 13:37:46 -0400
The previous coding would potentially cause attaching to segment A to
fail if segment B was at the same time in the process of going away.
Andres Freund, with a comment tweak by me
Fix improperly passed file descriptors
commit : 4335c958154c39ef99a38dc953b3f803b13a1048
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 12:20:51 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 12:20:51 -0400
Fix for commit 14ea89366fe321609afc5838ff9fe2ded1cd707d
Report by Andres Freund
pgindent run for 9.4
commit : 0a7832005792fa6dad171f9cadb8d587fe0dd800
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 12:12:18 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 12:12:18 -0400
This includes removing tabs after periods in C comments, which was
applied to back branches, so this change should not effect backpatching.
Adjust pgindent to remove tabs after periods in C comments.
commit : fb85cd4320414c3f6e9c8bc69ec944200ae1e493
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 10:57:15 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 10:57:15 -0400
Fix detection of short tar files, broken by commit 14ea89366fe321609afc5838ff9fe2ded1cd707d
commit : 55d5ff825fae0ee9a1114a17fcd97a3e360a23b0
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 10:00:57 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 10:00:57 -0400
commit : 2e54d88af137da5c1cf4749e2b9d4371224bbd47
author : Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 6 May 2014 14:44:18 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 6 May 2014 14:44:18 +0100
Logic is correct, matching handling of LP_DEAD elsewhere.
Update typedef list in preparation for pgindent run
commit : 284c464b9f7a47e3c4559a1ced75ff3dcb697e36
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 09:08:14 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 09:08:14 -0400
More rewording of pg_stat_statements for 9.4 release notes
commit : 47faae931686536cfbd5dd70f347e4e658c5ebcc
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 08:52:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 May 2014 08:52:16 -0400
commit : 08317edc2d4200e3716deaf585925069601c8965
author : Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 6 May 2014 13:44:15 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 6 May 2014 13:44:15 +0100
Commit d298b50a3b469c088bb40a4d36d38111b4cd574d by Heikki Linnakangas
requested that the version check message be updated at next release, suggesting
that the appropriate text would be “9.3 or later”. The logic used for the check
indicates that the correct text for 9.4 is “9.3 or 9.4”, since the logic would
cause this to fail for later releases.
Fix use of free in walsender error handling after a sysid mismatch.
commit : 3a8e9e977fa642433986e5cd145e3a6f86601c2c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 6 May 2014 15:14:51 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 6 May 2014 15:14:51 +0300
Found via valgrind. The bug exists since the introduction of the walsender,
so backpatch to 9.0.
Andres Freund
Fix handling of array of char pointers in ecpglib.
commit : 8d6a07fa01cece1bd3508a81e59c0c0cbc0bb867
author : Michael Meskes <meskes@postgresql.org>
date : Tue, 6 May 2014 13:04:30 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Tue, 6 May 2014 13:04:30 +0200
When array of char * was used as target for a FETCH statement returning more
than one row, it tried to store all the result in the first element. Instead it
should dump array of char pointers with right offset, use the address instead
of the value of the C variable while reading the array and treat such variable
as char **, instead of char * for pointer arithmetic.
Patch by Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Properly detect read and write errors in pg_dump/dumpall, and pg_restore
commit : 14ea89366fe321609afc5838ff9fe2ded1cd707d
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 20:27:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 20:27:16 -0400
commit : 768fb0032655e37810ab37a22f870af85ab1108c
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 20:24:50 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 20:24:50 -0400
Run autoconf in wake of commit a692ee5870f0f442565b4c4bff367094599e9bdf.
commit : 9252b8eec27bbefbeae9d60d8cd4f6b8be80b861
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 20:24:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 20:24:38 -0400
Heikki updated configure.in but evidently forgot to include the updated
configure script in the commit. Per buildfarm.
Move pg_stat_statements into its on 9.4 release note section
commit : a1c287a3836ff47e7ea01c82aceba75f15ba7c91
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 20:03:12 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 20:03:12 -0400
In 9.4 release notes, add detail to pg_stat_statements items
commit : 60832ea39d670cb6c39081e31ad175e0e1c555f8
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 19:58:58 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 19:58:58 -0400
commit : 49c683bafda8659b885b2b119042e16cba1f702a
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 19:16:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 19:16:34 -0400
Add doc links to 9.4 release notes, and add major features list
commit : a64560d994faab23b76848b4e95027b7b11ad9a7
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 16:26:27 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 16:26:27 -0400
Fix possible cache invalidation failure in ReceiveSharedInvalidMessages.
commit : 0f928a85ecd509b165bfb9acd71b18c40063a7a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 14:43:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 14:43:39 -0400
Commit fad153ec45299bd4d4f29dec8d9e04e2f1c08148 modified sinval.c to reduce
the number of calls into sinvaladt.c (which require taking a shared lock)
by keeping a local buffer of collected-but-not-yet-processed messages.
However, if processing of the last message in a batch resulted in a
recursive call to ReceiveSharedInvalidMessages, we could overwrite that
message with a new one while the outer invalidation function was still
working on it. This would be likely to lead to invalidation of the wrong
cache entry, allowing subsequent processing to use stale cache data.
The fix is just to make a local copy of each message while we're processing
it.
Spotted by Andres Freund. Back-patch to 8.4 where the bug was introduced.
Fix pg_type.typlen for newly-revived line type.
commit : 3727afafeef69088456acc3f6257360315220a20
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 13:37:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 13:37:54 -0400
Commit 261c7d4b653bc3e44c31fd456d94f292caa50d8f removed the "m" field
from struct LINE, but neglected to make pg_type.h's idea of the type's
size match. This resulted in reading past the end of palloc'd LINE
values when inserting them into tuples etc. In principle that could
cause a SIGSEGV, though the odds of detectable problems seem low.
Bump catversion since this makes an incompatible on-disk format change.
Note that if the line type had been in use in the field, this would
break pg_upgrade'ability of databases containing line values; but
it seems unlikely that there are any (they'd have had to be compiled
with -DENABLE_LINE_TYPE).
Spotted by Andres Freund.
Add SGML markup tags to 9.4 release notes
commit : b2f7bd72c4d3e80065725c72e85778d5f4bdfd4a
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 12:38:09 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 12:38:09 -0400
Fix case of pg_dump -Fc to an unseekable file (such as a pipe).
commit : e03485ae8a2025d5deea291ebb24412229cc2fe5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 11:26:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 May 2014 11:26:41 -0400
This was accidentally broken in commits cfa1b4a711/5e8e794e3b.
It saves a line or so to call ftello unconditionally in _CloseArchive,
but we have to expect that it might fail if we're not in hasSeek mode.
Per report from Bernd Helmle.
In passing, improve _getFilePos to print an appropriate message if
ftello fails unexpectedly, rather than just a vague complaint about
"ftell mismatch".
Update “huge pages” description in the 9.4 release notes
commit : f8db074049be74fa100b4f97d09ee76222660e7c
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 10:30:45 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 10:30:45 -0400
Update 9.4 release notes with feedback from the hackers list
commit : 5b8de6d4676ed9eb6df4685deb601be3db4eaa24
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 10:06:26 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 May 2014 10:06:26 -0400
doc: In FDW handler docs, mark up scan_clauses with .
commit : c70cc9afb3c561addeab805b15352d5ffb6d8f38
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 5 May 2014 10:04:02 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 5 May 2014 10:04:02 -0400
Pass sensible value to memset() when randomizing reorderbuffer’s tuple slab.
commit : 377790fbd707b41bdf2264fe6c217e903e241f7c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:21:46 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:21:46 +0300
This is entirely harmless, but still wrong. Noticed by coverity.
Andres Freund
Don’t leak memory after connection aborts in pg_recvlogical.
commit : 329de9fa983debc941ebd79f335f2574b72a3694
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:20:12 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:20:12 +0300
Use Size instead of uint32 to store result of sizeof()
commit : c83457683968e2263d7e6bcdcdd52d472f9b0f8d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:17:16 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:17:16 +0300
Silences coverity and is more consistent with other functions in the
same file.
Andres Freund
Assert that pre/post-fix updated tuples are on the same page during replay.
commit : 1460b199e6e748712253fa130d1c3368ba6ac861
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:14:41 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:14:41 +0300
If they were not 'oldtup.t_data' would be dereferenced while set to NULL
in case of a full page image for block 0.
Do so primarily to silence coverity; but also to make sure this prerequisite
isn't changed without adapting the replay routine as that would appear to
work in many cases.
Andres Freund
Replace SYSTEMQUOTEs with Windows-specific wrapper functions.
commit : a692ee5870f0f442565b4c4bff367094599e9bdf
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:07:40 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 5 May 2014 16:07:40 +0300
It's easy to forget using SYSTEMQUOTEs when constructing command strings
for system() or popen(). Even if we fix all the places missing it now, it is
bound to be forgotten again in the future. Introduce wrapper functions that
do the the extra quoting for you, and get rid of SYSTEMQUOTEs in all the
callers.
We previosly used SYSTEMQUOTEs in all the hard-coded command strings, and
this doesn't change the behavior of those. But user-supplied commands, like
archive_command, restore_command, COPY TO/FROM PROGRAM calls, as well as
pgbench's \shell, will now gain an extra pair of quotes. That is desirable,
but if you have existing scripts or config files that include an extra
pair of quotes, those might need to be adjusted.
Reviewed by Amit Kapila and Tom Lane
Add missing 9.4 release file.
commit : d69ffd6f035fe24483247bf9b2335d7474eaf31a
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 4 May 2014 07:12:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 4 May 2014 07:12:48 -0400
commit : 21223c24c2c4694efea3d9b4b29dfe45fda71f2a
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 3 May 2014 23:16:24 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 3 May 2014 23:16:24 -0400
doc: Update pg_basebackup version compatibility claim for 9.4
commit : 0717748c904719af8689c04dc610a937de6d9a0e
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 1 May 2014 22:08:22 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 1 May 2014 22:08:22 -0400
Fix yet another corner case in dumping rules/views with USING clauses.
commit : 91e16b980612d80de1017e97e9f206239afb9026
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 May 2014 20:22:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 May 2014 20:22:37 -0400
ruleutils.c tries to cope with additions/deletions/renamings of columns in
tables referenced by views, by means of adding machine-generated aliases to
the printed form of a view when needed to preserve the original semantics.
A recent blog post by Marko Tiikkaja pointed out a case I'd missed though:
if one input of a join with USING is itself a join, there is nothing to
stop the user from adding a column of the same name as the USING column to
whichever side of the sub-join didn't provide the USING column. And then
there'll be an error when the view is re-parsed, since now the sub-join
exposes two columns matching the USING specification. We were catching a
lot of related cases, but not this one, so add some logic to cope with it.
Back-patch to 9.3, which is the first release that makes any serious
attempt to cope with such cases (cf commit 2ffa740be and follow-ons).
Fix “quiet inline” configure test for newer clang compilers.
commit : 4c8aa8b5aea1e032f569222d4b6c1019e84622dc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 May 2014 16:16:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 May 2014 16:16:36 -0400
This test used to just define an unused static inline function and check
whether that causes a warning. But newer clang versions warn about
unused static inline functions when defined inside a .c file, but not
when defined in an included header, which is the case we care about.
Change the test to cope.
Andres Freund
Fix failure to detoast fields in composite elements of structured types.
commit : 3f8c8e3c61cef5729980ee4372ec159862a979f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 May 2014 15:19:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 May 2014 15:19:06 -0400
If we have an array of records stored on disk, the individual record fields
cannot contain out-of-line TOAST pointers: the tuptoaster.c mechanisms are
only prepared to deal with TOAST pointers appearing in top-level fields of
a stored row. The same applies for ranges over composite types, nested
composites, etc. However, the existing code only took care of expanding
sub-field TOAST pointers for the case of nested composites, not for other
structured types containing composites. For example, given a command such
as
UPDATE tab SET arraycol = ARRAY[(ROW(x,42)::mycompositetype] ...
where x is a direct reference to a field of an on-disk tuple, if that field
is long enough to be toasted out-of-line then the TOAST pointer would be
inserted as-is into the array column. If the source record for x is later
deleted, the array field value would become a dangling pointer, leading
to errors along the line of "missing chunk number 0 for toast value ..."
when the value is referenced. A reproducible test case for this was
provided by Jan Pecek, but it seems likely that some of the "missing chunk
number" reports we've heard in the past were caused by similar issues.
Code-wise, the problem is that PG_DETOAST_DATUM() is not adequate to
produce a self-contained Datum value if the Datum is of composite type.
Seen in this light, the problem is not just confined to arrays and ranges,
but could also affect some other places where detoasting is done in that
way, for example form_index_tuple().
I tried teaching the array code to apply toast_flatten_tuple_attribute()
along with PG_DETOAST_DATUM() when the array element type is composite,
but this was messy and imposed extra cache lookup costs whether or not any
TOAST pointers were present, indeed sometimes when the array element type
isn't even composite (since sometimes it takes a typcache lookup to find
that out). The idea of extending that approach to all the places that
currently use PG_DETOAST_DATUM() wasn't attractive at all.
This patch instead solves the problem by decreeing that composite Datum
values must not contain any out-of-line TOAST pointers in the first place;
that is, we expand out-of-line fields at the point of constructing a
composite Datum, not at the point where we're about to insert it into a
larger tuple. This rule is applied only to true composite Datums, not
to tuples that are being passed around the system as tuples, so it's not
as invasive as it might sound at first. With this approach, the amount
of code that has to be touched for a full solution is greatly reduced,
and added cache lookup costs are avoided except when there actually is
a TOAST pointer that needs to be inlined.
The main drawback of this approach is that we might sometimes dereference
a TOAST pointer that will never actually be used by the query, imposing a
rather large cost that wasn't there before. On the other side of the coin,
if the field value is used multiple times then we'll come out ahead by
avoiding repeat detoastings. Experimentation suggests that common SQL
coding patterns are unaffected either way, though. Applications that are
very negatively affected could be advised to modify their code to not fetch
columns they won't be using.
In future, we might consider reverting this solution in favor of detoasting
only at the point where data is about to be stored to disk, using some
method that can drill down into multiple levels of nested structured types.
That will require defining new APIs for structured types, though, so it
doesn't seem feasible as a back-patchable fix.
Note that this patch changes HeapTupleGetDatum() from a macro to a function
call; this means that any third-party code using that macro will not get
protection against creating TOAST-pointer-containing Datums until it's
recompiled. The same applies to any uses of PG_RETURN_HEAPTUPLEHEADER().
It seems likely that this is not a big problem in practice: most of the
tuple-returning functions in core and contrib produce outputs that could
not possibly be toasted anyway, and the same probably holds for third-party
extensions.
This bug has existed since TOAST was invented, so back-patch to all
supported branches.
Documentation corrections for pg_replication_slots.
commit : 65fb5ff13009ef34ff95300d3e03540cf872e494
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Apr 2014 22:55:16 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Apr 2014 22:55:16 -0400
Thomas Reiss, with changes to the catalog_xmin language by me.
Improve error messages in reorderbuffer.c.
commit : 203b0d132fe9038061b5bab70f1362440ae94aa8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 18:16:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 18:16:53 -0400
Be more clear about failure cases in relfilenode->relation lookup,
and fix some other places that were inconsistent or not per our
message style guidelines.
Andres Freund and Tom Lane
Consistently allow reading of messages from a detached shm_mq.
commit : 5ec45bb7fa0a1495a360165a12ba5d6b4587bb4a
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Apr 2014 17:38:18 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Apr 2014 17:38:18 -0400
This was intended to work always, but the previous code only allowed
it if at least one message was successfully read by the receiver
before the sender detached the queue.
Report by Petr Jelinek. Patch by me.
Rationalize common/relpath.[hc].
commit : 2d00190495b22e0d0ba351b2cda9c95fb2e3d083
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 17:30:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 17:30:50 -0400
Commit a73018392636ce832b09b5c31f6ad1f18a4643ea created rather a mess by
putting dependencies on backend-only include files into include/common.
We really shouldn't do that. To clean it up:
* Move TABLESPACE_VERSION_DIRECTORY back to its longtime home in
catalog/catalog.h. We won't consider this symbol part of the FE/BE API.
* Push enum ForkNumber from relfilenode.h into relpath.h. We'll consider
relpath.h as the source of truth for fork numbers, since relpath.c was
already partially serving that function, and anyway relfilenode.h was
kind of a random place for that enum.
* So, relfilenode.h now includes relpath.h rather than vice-versa. This
direction of dependency is fine. (That allows most, but not quite all,
of the existing explicit #includes of relpath.h to go away again.)
* Push forkname_to_number from catalog.c to relpath.c, just to centralize
fork number stuff a bit better.
* Push GetDatabasePath from catalog.c to relpath.c; it was rather odd
that the previous commit didn't keep this together with relpath().
* To avoid needing relfilenode.h in common/, redefine the underlying
function (now called GetRelationPath) as taking separate OID arguments,
and make the APIs using RelFileNode or RelFileNodeBackend into macro
wrappers. (The macros have a potential multiple-eval risk, but none of
the existing call sites have an issue with that; one of them had such a
risk already anyway.)
* Fix failure to follow the directions when "init" fork type was added;
specifically, the errhint in forkname_to_number wasn't updated, and neither
was the SGML documentation for pg_relation_size().
* Fix tablespace-path-too-long check in CreateTableSpace() to account for
fork-name component of maximum-length pathnames. This requires putting
FORKNAMECHARS into a header file, but it was rather useless (and
actually unreferenced) where it was.
The last couple of items are potentially back-patchable bug fixes,
if anyone is sufficiently excited about them; but personally I'm not.
Per a gripe from Christoph Berg about how include/common wasn't
self-contained.
Check for interrupts and stack overflow during rule/view dumps.
commit : 0bff398761b5e6119b40550bbe3751f4194dc7a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 13:46:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 13:46:13 -0400
Since ruleutils.c recurses, it could be driven to stack overflow by
deeply nested constructs. Very large queries might also take long
enough to deparse that a check for interrupts seems like a good idea.
Stick appropriate tests into a couple of key places.
Noted by Greg Stark. Back-patch to all supported branches.
Reduce indentation/parenthesization of set operations in rule/view dumps.
commit : 41de93c53aa941167d445ecb7d91d58829adcc92
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 13:26:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 13:26:26 -0400
A query such as "SELECT x UNION SELECT y UNION SELECT z UNION ..."
produces a left-deep nested parse tree, which we formerly showed in its
full nested glory and with all the possible parentheses. This does little
for readability, though, and long UNION lists resulting in excessive
indentation are common. Instead, let's omit parentheses and indent all
the subqueries at the same level in such cases.
This patch skips indentation/parenthesization whenever the lefthand input
of a SetOperationStmt is another SetOperationStmt of the same kind and
ALL/DISTINCT property. We could teach the code the exact syntactic
precedence of set operations and thereby avoid parenthesization in some
more cases, but it's not clear that that'd be a readability win: it seems
better to parenthesize if the set operation changes. (As an example,
if there's one UNION in a long list of UNION ALL, it now stands out like
a sore thumb, which seems like a good thing.)
Back-patch to 9.3. This completes our response to a complaint from Greg
Stark that since commit 62e666400d there's a performance problem in pg_dump
for views containing long UNION sequences (or other types of deeply nested
constructs). The previous commit 0601cb54dac14d979d726ab2ebeda251ae36e857
handles the general problem, but this one makes the specific case of UNION
lists look a lot nicer.
Limit overall indentation in rule/view dumps.
commit : 0601cb54dac14d979d726ab2ebeda251ae36e857
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 12:48:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 12:48:12 -0400
Continuing to indent no matter how deeply nested we get doesn't really
do anything for readability; what's worse, it results in O(N^2) total
whitespace, which can become a performance and memory-consumption issue.
To address this, once we get past 40 characters of indentation, reduce
the indentation step distance 4x, and also limit the maximum indentation
by reducing it modulo 40. This latter choice is a bit weird at first
glance, but it seems to preserve readability better than a simple cap
would do.
Back-patch to 9.3, because since commit 62e666400d the performance issue
is a hazard for pg_dump.
Greg Stark and Tom Lane
Fix indentation of JOIN clauses in rule/view dumps.
commit : d166eed302400a71eed1aaa301d30be3af7b5715
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 12:01:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 12:01:19 -0400
The code attempted to outdent JOIN clauses further left than the parent
FROM keyword, which was odd in any case, and led to inconsistent formatting
since in simple cases the clauses couldn't be moved any further left than
that. And it left a permanent decrement of the indentation level, causing
subsequent lines to be much further left than they should be (again, this
couldn't be seen in simple cases for lack of indentation to give up).
After a little experimentation I chose to make it indent JOIN keywords
two spaces from the parent FROM, which is one space more than the join's
lefthand input in cases where that appears on a different line from FROM.
Back-patch to 9.3. This is a purely cosmetic change, and the bug is quite
old, so that may seem arbitrary; but we are going to be making some other
changes to the indentation behavior in both HEAD and 9.3, so it seems
reasonable to include this in 9.3 too. I committed this one first because
its effects are more visible in the regression test results as they
currently stand than they will be later.
Fix uninitialized-variable warnings induced by recent commit.
commit : 5358bfdc98a47d26649ae094dab88842a0603968
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 11:15:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Apr 2014 11:15:15 -0400
Some popen() calls were missing SYSTEMQUOTEs, which caused initdb and
pg_upgrade to fail on Windows, if the installation path contained both
spaces and @ signs.
Patch by Nikhil Deshpande. Backpatch to all supported versions.
PL/Python: Adjust the regression tests for Python 3.4
commit : d0765d50f429472d00554701ac6531c84d324811
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 29 Apr 2014 22:16:16 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 29 Apr 2014 22:16:16 -0400
The error test case in the plpython_do test resulted in a slightly
different error message with Python 3.4. So pick a different way to
test it that avoids that and is perhaps also a bit clearer.
Fix whitespace
commit : 322173eb0a6c2f43394645f8ae33eedd70bab432
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 29 Apr 2014 21:35:07 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 29 Apr 2014 21:35:07 -0400
Improve planner to drop constant-NULL inputs of AND/OR where it’s legal.
commit : 95811032d782049642a672e3db0a5382616ab084
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Apr 2014 13:12:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Apr 2014 13:12:26 -0400
In general we can't discard constant-NULL inputs, since they could change
the result of the AND/OR to be NULL. But at top level of WHERE, we do not
need to distinguish a NULL result from a FALSE result, so it's okay to
treat NULL as FALSE and then simplify AND/OR accordingly.
This is a very ancient oversight, but in 9.2 and later it can lead to
failure to optimize queries that previous releases did optimize, as a
result of more aggressive parameter substitution rules making it possible
to reduce more subexpressions to NULL constants. This is the root cause of
bug #10171 from Arnold Scheffler. We could alternatively have fixed that
by teaching orclauses.c to ignore constant-NULL OR arms, but it seems
better to get rid of them globally.
I resisted the temptation to back-patch this change into all active
branches, but it seems appropriate to back-patch as far as 9.2 so that
there will not be performance regressions of the kind shown in this bug.
Remove unnecessary cast causing a warning
commit : dbe31616c9be7380b8a88cdfbeaa68dbdcdebc36
author : Greg Stark <stark@mit.edu>
date : Tue, 29 Apr 2014 12:43:03 +0100
committer: Greg Stark <stark@mit.edu>
date : Tue, 29 Apr 2014 12:43:03 +0100
Incidentally, I reversed the two names in the earlier commit. The
original author was Sergey Muraviov and the reviewer was Emre
Hasegeli.
Add support for wrapping to psql’s “extended” mode. This makes it very feasible to display tables that have both many columns and some large data in some columns (such as pg_stats).
commit : 6513633b94173fc1d9e2b213c43f9422ddbf5faa
author : Greg Stark <stark@mit.edu>
date : Mon, 28 Apr 2014 18:41:36 +0100
committer: Greg Stark <stark@mit.edu>
date : Mon, 28 Apr 2014 18:41:36 +0100
In writeListPage, never take a full-page image of the page, because we
have all the information required to re-initialize in the WAL record
anyway. Before this fix, a full-page image was always generated, unless
full_page_writes=off, because when the page is initialized its LSN is
always 0. In stable-branches, keep the code to restore the backup blocks
if they exist, in case that the WAL is generated with an older minor
version, but in master Assert that there are no full-page images.
In the redo routine, add missing "off++". Otherwise the tuples are added
to the page in reverse order. That happens to be harmless because we
always scan and remove all the tuples together, but it was clearly wrong.
Also, it was masked by the first bug unless full_page_writes=off, because
the page was always restored from a full-page image.
Backpatch to all supported versions.
Minor fixes for ALTER TABLE documentation.
commit : 728c06f17f68f4f80b61808b491b1c7b065a3d27
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 28 Apr 2014 10:10:51 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 28 Apr 2014 10:10:51 -0400
Can’t completely get rid of #ifndef FRONTEND in palloc.h :-(
commit : a9baeb361d635963a19a0268a7d60636c813d2ee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Apr 2014 21:24:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Apr 2014 21:24:19 -0400
pg_controldata includes postgres.h not postgres_fe.h, so utils/palloc.h
must be able to compile in a "#define FRONTEND" context. It appears that
Solaris Studio is smart enough to persuade us to define PG_USE_INLINE,
but not smart enough to not make a copy of unreferenced static functions;
which leads to an unsatisfied reference to CurrentMemoryContext. So we
need an #ifndef FRONTEND around that declaration. Per buildfarm.
Improve generation algorithm for database system identifier.
commit : 5035701e07e8bd395aa878465a102afd7b74e8c3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Apr 2014 15:11:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Apr 2014 15:11:10 -0400
As noted some time ago, the original coding had a typo ("|" for "^")
that made the result less unique than intended. Even the intended
behavior is obsolete since it was based on wanting to produce a
usable value even if we didn't have int64 arithmetic --- a limitation
we stopped supporting years ago. Instead, let's redefine the system
identifier as tv_sec in the upper 32 bits (same as before), tv_usec
in the next 20 bits, and the low 12 bits of getpid() in the remaining
bits. This is still hardly guaranteed-universally-unique, but it's
noticeably better than before. Per my proposal at
<29019.1374535940@sss.pgh.pa.us>
Don’t #include utils/palloc.h in common/fe_memutils.h.
commit : 528c454b2ada89ca0f0cd9a64f939e775b55b879
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Apr 2014 14:14:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Apr 2014 14:14:28 -0400
This breaks the principle that common/ ought not depend on anything in the
server, not only code-wise but in the headers. The only arguable advantage
is avoidance of duplication of half a dozen extern declarations, and even
that is rather dubious, considering that the previous coding was wrong
about which declarations to duplicate: it exposed pnstrdup() to frontend
code even though no such function is provided in fe_memutils.c.
On the same principle, don't #include utils/memutils.h in the frontend
build of psprintf.c. This requires duplicating the definition of
MaxAllocSize, but that seems fine to me: there's no a-priori reason why
frontend code should use the same size limit as the backend anyway.
In passing, clean up some rather odd layout and ordering choices that
were imposed on palloc.h to reduce the number of #ifdefs required by
the previous approach.
Per gripe from Christoph Berg. There's still more work to do to make
include/common/ clean, but this part seems reasonably noncontroversial.
Record the proper typmod for an index expression column.
commit : 39b0c7681e465f3e486ca2a5d13fbbafbe25cb1a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Apr 2014 12:22:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Apr 2014 12:22:09 -0400
We should use exprTypmod() to extract the typmod of the expression,
instead of just blindly storing -1. This seems to have been an aboriginal
oversight in commit fc8d970cbcdd6f025475822a4cf01dfda0873226 which
introduced general-expression indexes. The consequences are only cosmetic
at present, since the index machinery doesn't really look at typmod for
index columns; but still it seems best to describe the column type as
precisely as we can. Per off-list complaint from Thomas Fanghaenel.
Fix off-by-one bug in LWLockRegisterTranche().
commit : 4bfc5f1396b18da3a0db73e4406badc4ce793a1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Apr 2014 15:59:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Apr 2014 15:59:57 -0400
Original coding failed to enlarge the array as required if
the requested tranche_id was equal to LWLockTranchesAllocated.
In passing, fix poor style of not casting the result of (re)palloc.
Clean up temp installations after client program tests.
commit : 49137ec9d469f744289d0dfa2487a7fc1ef217cb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Apr 2014 15:40:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Apr 2014 15:40:35 -0400
Commit 7d0f493f19607774fdccb1a1ea06fdd96a3d9698 added infrastructure
to perform tests in assorted src/bin/ subdirectories, but forgot to
teach "make clean" to clean up the detritus the tests leave behind.
Fix race when updating a tuple concurrently locked by another process
If a tuple is locked, and this lock is later upgraded either to an
update or to a stronger lock, and in the meantime some other process
tries to lock, update or delete the same tuple, it (the tuple) could end
up being updated twice, or having conflicting locks held.
The reason for this is that the second updater checks for a change in
Xmax value, or in the HEAP_XMAX_IS_MULTI infomask bit, after noticing
the first lock; and if there's a change, it restarts and re-evaluates
its ability to update the tuple. But it neglected to check for changes
in lock strength or in lock-vs-update status when those two properties
stayed the same. This would lead it to take the wrong decision and
continue with its own update, when in reality it shouldn't do so but
instead restart from the top.
This could lead to either an assertion failure much later (when a
multixact containing multiple updates is detected), or duplicate copies
of tuples.
To fix, make sure to compare the other relevant infomask bits alongside
the Xmax value and HEAP_XMAX_IS_MULTI bit, and restart from the top if
necessary.
Also, in the belt-and-suspenders spirit, add a check to
MultiXactCreateFromMembers that a multixact being created does not have
two or more members that are claimed to be updates. This should protect
against other bugs that might cause similar bogus situations.
Backpatch to 9.3, where the possibility of multixacts containing updates
was introduced. (In prior versions it was possible to have the tuple
lock upgraded from shared to exclusive, and an update would not restart
from the top; yet we're protected against a bug there because there's
always a sleep to wait for the locking transaction to complete before
continuing to do anything. Really, the fact that tuple locks always
conflicted with concurrent updates is what protected against bugs here.)
Per report from Andrew Dunstan and Josh Berkus in thread at
http://www.postgresql.org/message-id/534C8B33.9050807@pgexperts.com
Bug analysis by Andres Freund.
Reset pg_stat_activity.xact_start during PREPARE TRANSACTION.
commit : d19bd29f07aef9e508ff047d128a4046cc8bc1e2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Apr 2014 13:29:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Apr 2014 13:29:48 -0400
Once we've completed a PREPARE, our session is not running a transaction,
so its entry in pg_stat_activity should show xact_start as null, rather
than leaving the value as the start time of the now-prepared transaction.
I think possibly this oversight was triggered by faulty extrapolation
from the adjacent comment that says PrepareTransaction should not call
AtEOXact_PgStat, so tweak the wording of that comment.
Noted by Andres Freund while considering bug #10123 from Maxim Boguk,
although this error doesn't seem to explain that report.
Back-patch to all active branches.
Properly build pg_recvlogical in the msvc build system
commit : b2c9b161b8ae36dd9972e77297274afb9a675782
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 24 Apr 2014 09:30:44 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Thu, 24 Apr 2014 09:30:44 +0200
Fix incorrect pg_proc.proallargtypes entries for two built-in functions.
commit : a0f9358149b78c62871a0b7d3c167b78f9b2c77e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Apr 2014 21:21:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Apr 2014 21:21:05 -0400
pg_sequence_parameters() and pg_identify_object() have had incorrect
proallargtypes entries since 9.1 and 9.3 respectively. This was mostly
masked by the correct information in proargtypes, but a few operations
such as pg_get_function_arguments() (and thus psql's \df display) would
show the wrong data types for these functions' input parameters.
In HEAD, fix the wrong info, bump catversion, and add an opr_sanity
regression test to catch future mistakes of this sort.
In the back branches, just fix the wrong info so that installations
initdb'd with future minor releases will have the right data. We
can't force an initdb, and it doesn't seem like a good idea to add
a regression test that will fail on existing installations.
Andres Freund
Allow polymorphic aggregates to have non-polymorphic state data types.
commit : f0fedfe82c8adea78354652d67c027a1a8fbce88
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Apr 2014 19:17:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Apr 2014 19:17:31 -0400
Before 9.4, such an aggregate couldn't be declared, because its final
function would have to have polymorphic result type but no polymorphic
argument, which CREATE FUNCTION would quite properly reject. The
ordered-set-aggregate patch found a workaround: allow the final function
to be declared as accepting additional dummy arguments that have types
matching the aggregate's regular input arguments. However, we failed
to notice that this problem applies just as much to regular aggregates,
despite the fact that we had a built-in regular aggregate array_agg()
that was known to be undeclarable in SQL because its final function
had an illegal signature. So what we should have done, and what this
patch does, is to decouple the extra-dummy-arguments behavior from
ordered-set aggregates and make it generally available for all aggregate
declarations. We have to put this into 9.4 rather than waiting till
later because it slightly alters the rules for declaring ordered-set
aggregates.
The patch turned out a bit bigger than I'd hoped because it proved
necessary to record the extra-arguments option in a new pg_aggregate
column. I'd thought we could just look at the final function's pronargs
at runtime, but that didn't work well for variadic final functions.
It's probably just as well though, because it simplifies life for pg_dump
to record the option explicitly.
While at it, fix array_agg() to have a valid final-function signature,
and add an opr_sanity test to notice future deviations from polymorphic
consistency. I also marked the percentile_cont() aggregates as not
needing extra arguments, since they don't.
doc: Fix DocBook table column count declaration
commit : 125ba2945aacde7713f3767b012c429c384f3b62
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 23 Apr 2014 16:14:14 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 23 Apr 2014 16:14:14 -0400
When marking a branch as half-dead, a pointer to the top of the branch is
stored in the leaf block's hi-key. During normal operation, the high key
was left in place, and the block number was just stored in the ctid field
of the high key tuple, but in WAL replay, the high key was recreated as a
truncated tuple with zero columns. For the sake of easier debugging, also
truncate the tuple in normal operation, so that the page is identical
after WAL replay. Also, rename the 'downlink' field in the WAL record to
'topparent', as that seems like a more descriptive name. And make sure
it's set to invalid when unlinking the leaf page.
Fix documentation of FmgrInfo.fn_nargs.
commit : d26b042ce577a4012b9798528f0b1bcfa6e502eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Apr 2014 23:22:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Apr 2014 23:22:12 -0400
Some ancient comments claimed that fn_nargs could be -1 to indicate a
variable number of input arguments; but this was never implemented, and
is at variance with what we ultimately did with "variadic" functions.
Update the comments.
Fix broken logic in logical_heap_rewrite_flush_mappings().
commit : c6a4ace5bf839b2480e8bb4c36bd3ec850c55c65
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Apr 2014 22:33:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Apr 2014 22:33:35 -0400
Forgot to update LSN of left sibling's page, when creating a new root.
I fixed this for regular insertions and page splits earlier, but missed
new root creation.
Fix Gin README.
commit : 45e67a2ad7fcc1389cf897e308a75c3cb9f88c3f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 22 Apr 2014 22:36:32 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 22 Apr 2014 22:36:32 +0300
The README incorrectly claimed that GIN posting tree pages contain an array
of uncompressed items in addition to compressed posting lists. Earlier
versions of the GIN posting list compression patch worked that way, but not
the one that was committed.
doc: Improve “replication slot” index entries
commit : 80ce90b9c40d10dc3acaf10ac0975c3b8d1e3289
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 22 Apr 2014 15:22:10 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 22 Apr 2014 15:22:10 -0400
Don't use simple_heap_insert to insert the tuple to a sequence relation.
simple_heap_insert creates a heap insertion WAL record, and replaying that
will create a regular heap page without the special area containing the
sequence magic constant, which is wrong for a sequence. That was not a bug
because we always created a sequence WAL record after that, and replaying
that overwrote the bogus heap page, and the transient state could never be
seen by another backend because it was only done when creating a new
sequence relation. But it's simpler and cleaner to avoid that in the first
place.
pg_stat_statements forgot to let previous occupant of hook get control too.
commit : 78a3c9b6a5f6cc84abaf4e13deb58c620eb2161b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Apr 2014 13:28:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Apr 2014 13:28:07 -0400
pgss_post_parse_analyze() neglected to pass the call on to any earlier
occupant of the post_parse_analyze_hook. There are no other users of that
hook in contrib/, and most likely none in the wild either, so this is
probably just a latent bug. But it's a bug nonetheless, so back-patch
to 9.2 where this code was introduced.
Fix another typo.
commit : 602b27ab8e45fbb07cf5b275b0593b38190232e4
author : Robert Haas <rhaas@postgresql.org>
date : Sun, 20 Apr 2014 16:32:57 +0200
committer: Robert Haas <rhaas@postgresql.org>
date : Sun, 20 Apr 2014 16:32:57 +0200
Mention impossibility of moving tablespaces, backing them up
independently, or the inadvisability of placing them on temporary
file systems.
Patch by Craig Ringer, adjustments by Ian Lawrence Warwick and me
libpq: have PQconnectdbParams() and PQpingParams accept “” as default
commit : 13ecb822e8da5668133b706474c25bc908ae370a
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 19 Apr 2014 08:41:51 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 19 Apr 2014 08:41:51 -0400
Previously, these functions treated "" optin values as defaults in some
ways, but not in others, like when comparing to .pgpass. Also, add
documentation to clarify that now "" and NULL use defaults, like
PQsetdbLogin() has always done.
BACKWARD INCOMPATIBILITY
Patch by Adrian Vondendriesch, docs by me
Report by Jeff Janes
Fix typo
commit : 66b1084e2ccf1f5b8cb57ebb41f54f76850a2b5d
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 18 Apr 2014 12:49:54 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 18 Apr 2014 12:49:54 +0200
Because of gcc -Wmissing-prototypes, all functions in dynamically
loadable modules must have a separate prototype declaration. This is
meant to detect global functions that are not declared in header files,
but in cases where the function is called via dfmgr, this is redundant.
Besides filling up space with boilerplate, this is a frequent source of
compiler warnings in extension modules.
We can fix that by creating the function prototype as part of the
PG_FUNCTION_INFO_V1 macro, which such modules have to use anyway. That
makes the code of modules cleaner, because there is one less place where
the entry points have to be listed, and creates an additional check that
functions have the right prototype.
Remove now redundant prototypes from contrib and other modules.
Fix unused-variable warning on Windows.
commit : 01563158235f5650743fd9b1dfa80c3d8faf89bb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Apr 2014 16:12:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Apr 2014 16:12:24 -0400
Introduced in 585bca39: msgid is not used in the Windows code path.
Also adjust comments a tad (mostly to keep pgindent from messing it up).
David Rowley
pgcrypto: fix memset() calls that might be optimized away
commit : 9fe55259fd61fd9199907623f974caa7af66e780
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 17 Apr 2014 12:37:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 17 Apr 2014 12:37:53 -0400
Specifically, on-stack memset() might be removed, so:
* Replace memset() with px_memset()
* Add px_memset to copy_crlf()
* Add px_memset to pgp-s2k.c
Patch by Marko Kreen
Report by PVS-Studio
Backpatch through 8.4.
report stat() error in trigger file check
commit : 83defef8c794e7772e4099a7efa2ebac3c62742c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 17 Apr 2014 11:55:57 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 17 Apr 2014 11:55:57 -0400
Non-existent tablespace directory references can occur if user
tablespaces are created inside data directories and the data directory
is renamed in preparation for running pg_upgrade, and the symbolic links
are not updated.
Backpatch to 9.3.
docs: adjustments for streaming standbys that disconnect frequently
commit : 52e757420fa98a76015c2c88432db94269f3e8f4
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 17 Apr 2014 10:52:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 17 Apr 2014 10:52:32 -0400
Document problems when disconnection causes loss of hot_standby_feedback
and suggest adjusting max_standby_archive_delay and
max_standby_streaming_delay.
Initial patch by Marko Tiikkaja, adjustments by me
Set the all-visible flag on heap page before writing WAL record, not after.
commit : 2a8e1ac598c864ac2775f33da21a117c363c6c7f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 17 Apr 2014 17:47:50 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 17 Apr 2014 17:47:50 +0300
If we set the all-visible flag after writing WAL record, and XLogInsert
takes a full-page image of the page, the image would not include the flag.
We will then proceed to set the VM bit, which would then be set without the
corresponding all-visible flag on the heap page.
Found by comparing page images on master and standby, after writing/replaying
each WAL record. (There is still a discrepancy: the all-visible flag won't
be set after replaying the HEAP_CLEAN record, even though it is set in the
master. However, it will be set when replaying the HEAP2_VISIBLE record and
setting the VM bit, so the all-visible flag and VM bit are always consistent
on the standby, even though they are momentarily out-of-sync with master)
Backpatch to 9.3 where this code was introduced.
Rename EXPLAIN ANALYZE’s “total runtime” output to “execution time”.
commit : 5f86cbd714c9d43c0fbb43a7b172f77ebf429548
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 20:48:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 20:48:51 -0400
Now that EXPLAIN also outputs a "planning time" measurement, the use of
"total" here seems rather confusing: it sounds like it might include the
planning time which of course it doesn't. Majority opinion was that
"execution time" is a better label, so we'll call it that.
This should be noted as a backwards incompatibility for tools that examine
EXPLAIN ANALYZE output.
In passing, I failed to resist the temptation to do a little editing on the
materialized-view example affected by this change.
docs: properly document psql auto encoding mode
commit : e183d11262f4e04ce7f191a9655aeeaa4682a7f5
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 19:53:42 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 19:53:42 -0400
Previously, 'int' was used for socket values in libpq, but socket values
are unsigned on Windows. This is a style correction.
Initial patch and previous PGINVALID_SOCKET initial patch by Joel
Jacobson, modified by me
Report from PVS-Studio
doc: move min_recovery_apply_delay into the right section
commit : be5f7fff470066dc3ee655b25840733eb9006426
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 19:15:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 19:15:16 -0400
Previously it wasn't clear from --help that -F, -R, -z, -0 only
controlled psql unaligned output.
Initial patch from Jov <amutu@amutu.com>, adjustments by me
We were neglecting to schema-qualify them.
Backpatch to 9.3, where object identities were introduced as a concept
by commit f8348ea32ec8.
Fix contrib/postgres_fdw’s remote-estimate representation of array Params.
commit : 5b68d81697bcb0d16136bd037e454ee53c521185
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 17:21:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 17:21:57 -0400
We were emitting "(SELECT null::typename)", which is usually interpreted
as a scalar subselect, but not so much in the context "x = ANY(...)".
This led to remote-side parsing failures when remote_estimate is enabled.
A quick and ugly fix is to stick in an extra cast step,
"((SELECT null::typename)::typename)". The cast will be thrown away as
redundant by parse analysis, but not before it's done its job of making
sure the grammar sees the ANY argument as an a_expr rather than a
select_with_parens. Per an example from Hannu Krosing.
docs: make max_wal_senders higher to handle disconnects
commit : 9c5334650085d441324e0f4fd9f8db12657b25c7
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 15:06:17 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 15:06:17 -0400
Document abrupt streaming client disconnection might leave slots in use,
so max_wal_senders should be slightly higher than needed to allow for
immediate reconnection.
Per mention by Magnus
Update oidjoins regression test for 9.4.
commit : cbb5e23bfa92973bddf11935448a9d42c32f7d42
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 14:28:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 14:28:59 -0400
Now that we're pretty much feature-frozen, it's time to update the checks
on system catalog foreign-key references.
(It looks like we missed doing this altogether for 9.3. Sigh.)
Attempt to get plpython regression tests working again for MSVC builds.
commit : ef158312e96960bfbc802ceda58f432f6fd845eb
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 16 Apr 2014 13:35:46 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 16 Apr 2014 13:35:46 -0400
This has probably been broken for quite a long time. Buildfarm member
currawong's current results suggest that it's been broken since 9.1, so
backpatch this to that branch.
This only supports Python 2 - I will handle Python 3 separately, but
this is a fairly simple fix.
pg_upgrade: remove redundant include files
commit : 95cb917297ebe77add3cef4f01cca1004031fa9a
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 13:27:00 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 13:27:00 -0400
commit : cad4fe6455bdc9ef1026b4a247eeb588ab3a8bd6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 13:20:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Apr 2014 13:20:54 -0400
According to the Single Unix Spec and assorted man pages, you're supposed
to use the constants named AF_xxx when setting ai_family for a getaddrinfo
call. In a few places we were using PF_xxx instead. Use of PF_xxx
appears to be an ancient BSD convention that was not adopted by later
standardization. On BSD and most later Unixen, it doesn't matter much
because those constants have equivalent values anyway; but nonetheless
this code is not per spec.
In the same vein, replace PF_INET by AF_INET in one socket() call, which
wasn't even consistent with the other socket() call in the same function
let alone the remainder of our code.
Per investigation of a Cygwin trouble report from Marco Atzeri. It's
probably a long shot that this will fix his issue, but it's wrong in
any case.
Fix timeout in LDAP lookup of libpq connection parameters
commit : 585bca393640b609c54159e1bedd30a89fec5ea8
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 16 Apr 2014 17:18:02 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 16 Apr 2014 17:18:02 +0200
Bind attempts to an LDAP server should time out after two seconds,
allowing additional lines in the service control file to be parsed
(which provide a fall back to a secondary LDAP server or default options).
The existing code failed to enforce that timeout during TCP connect,
resulting in a hang far longer than two seconds if the LDAP server
does not respond.
Laurenz Albe
Add to_regprocedure() and to_regoperator().
commit : dfc0219f649d5450a5e4d491dab1eeb23ac5530a
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 16 Apr 2014 12:21:43 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 16 Apr 2014 12:21:43 -0400
These are natural complements to the functions added by commit
0886fc6a5c75b294544263ea979b9cf6195407d9, but they weren't included
in the original patch for some reason. Add them.
Patch by me, per a complaint by Tom Lane. Review by Tatsuo
Ishii.
Try to fix spurious DSM failures on Windows.
commit : 1a81daab8be9a0b3769a2660db44a56a6035e34a
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 16 Apr 2014 12:04:44 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 16 Apr 2014 12:04:44 -0400
Apparently, Windows can sometimes return an error code even when the
operation actually worked just fine. Rearrange the order of checks
according to what appear to be the best practices in this area.
Amit Kapila
doc: fix json_extract_path_text() typo by adding jsonb
commit : ed4a26260c6ebd7948eacc42eddae1e898239f6e
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 11:24:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 16 Apr 2014 11:24:38 -0400
Previously, in some places, socket creation errors were checked for
negative values, which is not true for Windows because sockets are
unsigned. This masked socket creation errors on Windows.
Backpatch through 9.0. 8.4 doesn't have the infrastructure to fix this.
Use correctly-sized buffer when zero-filling a WAL file.
commit : 848b9f05ab283724dd063d936a92568c1fdf422b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 16 Apr 2014 10:21:09 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 16 Apr 2014 10:21:09 +0300
I mixed up BLCKSZ and XLOG_BLCKSZ when I changed the way the buffer is
allocated a couple of weeks ago. With the default settings, they are both
8k, but they can be changed at compile-time.
contrib/test_decoding: fix regression test for psql oid display changes
commit : ab76d8e9d672c661fe8ce4d9405dc8956b8ece9d
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 15 Apr 2014 14:45:10 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 15 Apr 2014 14:45:10 -0400
In psql \d+, display oids only when they exist, and display replication
identity only when it is non-default. Also document the defaults for
replication identity for system and non-system tables. Update
regression output.
vacuumdb: Add option –analyze-in-stages
commit : c92c3d50d7fbe7391b5fc864b444346b2db29ffe
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 14 Apr 2014 23:15:05 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 14 Apr 2014 23:15:05 -0400
Add vacuumdb option --analyze-in-stages which runs ANALYZE three times
with different configuration settings, adopting the logic from the
analyze_new_cluster.sh script that pg_upgrade generates. That way,
users of pg_dump/pg_restore can also use that functionality.
Change pg_upgrade to create the script so that it calls vacuumdb instead
of implementing the logic itself.
Have lcov call the right gcov
commit : 0d3b2b80aa6aee753f372bb0300a131691e9f55c
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 14 Apr 2014 21:52:03 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 14 Apr 2014 21:52:03 -0400
By default, lcov will call whatever gcov it can find in the path. But
if the user has specified a different gcov to configure, this could be
incompatible. So tell lcov explicitly with an option which gcov program
to call.
Add @configure_input@ marker to Makefile.global.in
commit : e3fd9327384abc1cd252ddd8ce9429ab7bef48b5
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 14 Apr 2014 21:49:57 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 14 Apr 2014 21:49:57 -0400
This allows squeezing out the unused space in full-page writes. And more
importantly, it can be a useful debugging aid.
In hindsight we should've done this back when GIN was added - we wouldn't
need the 'maxoff' field in the page opaque struct if we had used pd_lower
and pd_upper like on normal pages. But as long as there can be pages in the
index that have been binary-upgraded from pre-9.4 versions, we can't rely
on that, and have to continue using 'maxoff'.
Most of the code churn comes from renaming some macros, now that they're
used on internal pages, too.
This change is completely backwards-compatible, no effect on pg_upgrade.
doc: Suggesting clearing pg_replslot from a hot filesystem backup.
commit : 69671ab548459814d489315bf5cd421f84e984a4
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 14 Apr 2014 13:00:04 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 14 Apr 2014 13:00:04 -0400
Fix bogus handling of bad strategy number in GIST consistent() functions.
commit : 4dfb065b3ab662dcc96d07ee7fc9dadf6975a0cb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Apr 2014 11:10:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Apr 2014 11:10:32 -0400
Make sure we throw an error instead of silently doing the wrong thing when
fed a strategy number we don't recognize. Also, in the places that did
already throw an error, spell the error message in a way more consistent
with our message style guidelines.
Per report from Paul Jones. Although this is a bug, it won't occur unless
a superuser tries to do something he shouldn't, so it doesn't seem worth
back-patching.
Correct description of constraint_name in ALTER TABLE documentation.
commit : f0aa6c06d4e114ecb7ed81a2168238bbcfd54878
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 14 Apr 2014 10:52:07 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 14 Apr 2014 10:52:07 -0400
Apparently, the old text was written at a time when the only use of
constraint_name here was for a constraint to be dropped, but that's
no longer true.
Etsuro Fujita
Update list of relation types on which ALTER TABLE RENAME/OWNER work.
commit : 0c953540d285a94684b0c0dc7a2c338cb1d65ef0
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 14 Apr 2014 10:43:53 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 14 Apr 2014 10:43:53 -0400
The entry B-tree pages all follow the standard page layout. The 9.3 code has
this right. I inadvertently changed this at some point during the big
refactorings in git master.
Improve some O(N^2) behavior in window function evaluation.
commit : e0c91a7ff015fab0ccbb0f75b6819f29ae00295e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Apr 2014 13:59:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Apr 2014 13:59:17 -0400
Repositioning the tuplestore seek pointer in window_gettupleslot() turns
out to be a very significant expense when the window frame is sizable and
the frame end can move. To fix, introduce a tuplestore function for
skipping an arbitrary number of tuples in one call, parallel to the one we
introduced for tuplesort objects in commit 8d65da1f. This reduces the cost
of window_gettupleslot() to O(1) if the tuplestore has not spilled to disk.
As in the previous commit, I didn't try to do any real optimization of
tuplestore_skiptuples for the case where the tuplestore has spilled to
disk. There is probably no practical way to get the cost to less than O(N)
anyway, but perhaps someone can think of something later.
Also fix PersistHoldablePortal() to make use of this API now that we have
it.
Based on a suggestion by Dean Rasheed, though this turns out not to look
much like his patch.
Suppress compiler warning in new contrib/pg_trgm code.
commit : 46a60abfe9fa13087dbbe15953c20df35f006968
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Apr 2014 11:00:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Apr 2014 11:00:11 -0400
Given that ALTER TABLESPACE has moved on from just existing for
general purpose rename/owner changes, it deserves its own top-level
production in the grammar. This also cleans up the RenameStmt to
only ever be used for actual RENAMEs again- it really wasn't
appropriate to hide non-RENAME productions under there.
Noted by Alvaro.
Add ANALYZE into regression tests
commit : b3e6593716efef901fcc847f33256c6b49958898
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 13 Apr 2014 00:41:33 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 13 Apr 2014 00:41:33 -0400
Looks like we can end up with different plans happening on the
buildfarm, which breaks the regression tests when we include
EXPLAIN output (which is done in the regression tests for
updatable security views, to ensure that the user-defined
function isn't pushed down to a level where it could view the
rows before the security quals are applied).
This adds in ANALYZE to hopefully make the plans consistent.
The ANALYZE ends up changing the original plan too, so the
update looks bigger than it really is. The new plan looks
perfectly valid, of course.
Provide moving-aggregate support for boolean aggregates.
commit : d95425c8b9d3ea1681bd91b76ce73be95ca5ee21
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Apr 2014 00:01:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Apr 2014 00:01:46 -0400
Views which are marked as security_barrier must have their quals
applied before any user-defined quals are called, to prevent
user-defined functions from being able to see rows which the
security barrier view is intended to prevent them from seeing.
Remove the restriction on security barrier views being automatically
updatable by adding a new securityQuals list to the RTE structure
which keeps track of the quals from security barrier views at each
level, independently of the user-supplied quals. When RTEs are
later discovered which have securityQuals populated, they are turned
into subquery RTEs which are marked as security_barrier to prevent
any user-supplied quals being pushed down (modulo LEAKPROOF quals).
Dean Rasheed, reviewed by Craig Ringer, Simon Riggs, KaiGai Kohei
Provide moving-aggregate support for a bunch of numerical aggregates.
commit : 9d229f399e87d2ae7132c2e8feef317ce1479728
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Apr 2014 20:33:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Apr 2014 20:33:09 -0400
First installment of the promised moving-aggregate support in built-in
aggregates: count(), sum(), avg(), stddev() and variance() for
assorted datatypes, though not for float4/float8.
In passing, remove a 2001-vintage kluge in interval_accum(): interval
array elements have been properly aligned since around 2003, but
nobody remembered to take out this workaround. Also, fix a thinko
in the opr_sanity tests for moving-aggregate catalog entries.
David Rowley and Florian Pflug, reviewed by Dean Rasheed
Create infrastructure for moving-aggregate optimization.
commit : a9d9acbf219b9e96585779cd5f99d674d4ccba74
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Apr 2014 11:58:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Apr 2014 11:58:53 -0400
Until now, when executing an aggregate function as a window function
within a window with moving frame start (that is, any frame start mode
except UNBOUNDED PRECEDING), we had to recalculate the aggregate from
scratch each time the frame head moved. This patch allows an aggregate
definition to include an alternate "moving aggregate" implementation
that includes an inverse transition function for removing rows from
the aggregate's running state. As long as this can be done successfully,
runtime is proportional to the total number of input rows, rather than
to the number of input rows times the average frame length.
This commit includes the core infrastructure, documentation, and regression
tests using user-defined aggregates. Follow-on commits will update some
of the built-in aggregates to use this feature.
David Rowley and Florian Pflug, reviewed by Dean Rasheed; additional
hacking by me
docs: psql ‘–’ comments are not passed to the server
commit : 3c41b812c5578fd7bd5c2de42941012d7d56dde2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 10 Apr 2014 17:16:22 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 10 Apr 2014 17:16:22 -0400
There were a couple of bugs here. First, if the fuzzy limit was exceeded,
the loop in entryGetItem might drop out too soon if a whole block needs to
be skipped because it's < advancePast ("continue" in a while-loop checks the
loop condition too). Secondly, the loop checked when stepping to a new page
that there is at least one offset on the page < advancePast, but we cannot
rely on that on subsequent calls of entryGetItem, because advancePast might
change in between. That caused the skipping loop to read bogus items in the
TbmIterateResult's offset array.
First item and fix by Alexander Korotkov, second bug pointed out by Fabrízio
de Royes Mello, by a small variation of Alexander's test query.
The new pointer_to_struct test needs a special command line parameter to ecpg. Hopefully this will fix the buildfarm failures on Windows.
commit : ef29a884575f233e6cd382dcfb42af602fa78cd6
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 10 Apr 2014 20:37:00 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 10 Apr 2014 20:37:00 +0200
I'm not sure if this is what's causing the Windows buildfarm members
to get unhappy, but I don't think it can be helping anything...
Add an in-core GiST index opclass for inet/cidr types.
commit : f23a5630ebc797219b62797f566dec9f65090e03
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Apr 2014 15:46:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Apr 2014 15:46:14 -0400
This operator class can accelerate subnet/supernet tests as well as
btree-equivalent ordered comparisons. It also handles a new network
operator inet && inet (overlaps, a/k/a "is supernet or subnet of"),
which is expected to be useful in exclusion constraints.
Ideally this opclass would be the default for GiST with inet/cidr data,
but we can't mark it that way until we figure out how to do a more or
less graceful transition from the current situation, in which the
really-completely-bogus inet/cidr opclasses in contrib/btree_gist are
marked as default. Having the opclass in core and not default is better
than not having it at all, though.
While at it, add new documentation sections to allow us to officially
document GiST/GIN/SP-GiST opclasses, something there was never a clear
place to do before. I filled these in with some simple tables listing
the existing opclasses and the operators they support, but there's
certainly scope to put more information there.
Emre Hasegeli, reviewed by Andreas Karlsson, further hacking by me
doc: Fix typo.
commit : 02f65617eab3deb715428a3ed62ca4e7f56ceda3
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 8 Apr 2014 11:47:29 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 8 Apr 2014 11:47:29 -0400
Instead of storing the ID of the dynamic shared memory control
segment in a file within the data directory, store it in the main
control segment. This avoids a number of nasty corner cases,
most seriously that doing an online backup and then using it on
the same machine (e.g. to fire up a standby) would result in the
standby clobbering all of the master's dynamic shared memory
segments.
Per complaints from Heikki Linnakangas, Fujii Masao, and Tom
Lane.
Add new to_reg* functions for error-free OID lookups.
commit : 0886fc6a5c75b294544263ea979b9cf6195407d9
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 8 Apr 2014 10:27:56 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 8 Apr 2014 10:27:56 -0400
These functions won't throw an error if the object doesn't exist,
or if (for functions and operators) there's more than one matching
object.
Yugo Nagata and Nozomi Anzai, reviewed by Amit Khandekar, Marti
Raudsepp, Amit Kapila, and me.
Fix hot standby bug with GiST scans.
commit : 7ca32e255ba4f7e55bbdbcf0df996ac62798672b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 8 Apr 2014 14:47:24 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 8 Apr 2014 14:47:24 +0300
Don't reset the rightlink of a page when replaying a page update record.
This was a leftover from pre-hot standby days, when it was not possible to
have scans concurrent with WAL replay. Resetting the right-link was not
necessary back then either, but it was done for the sake of tidiness. But
with hot standby, it's wrong, because a concurrent scan might still need it.
Backpatch all versions with hot standby, 9.0 and above.
Zero padding byte at end of GIN posting list.
commit : 38a2b95c342c0d3d261d525a74943a977725483e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 7 Apr 2014 19:48:03 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 7 Apr 2014 19:48:03 +0300
The one existing assertion of this type has tripped a few times in the
buildfarm lately, but it's not clear whether the problem is really
originating there or whether it's leftovers from a trip through one
of the other two paths that lack a matching assertion. So add one.
Since the same bug(s) most likely exist(s) in the back-branches also,
back-patch to 9.2, where the fast-path lock mechanism was added.
Remove ipc_test.
commit : b8a721149b190dc09c00620f65cb85b190b83d45
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 7 Apr 2014 10:40:47 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 7 Apr 2014 10:40:47 -0400
This doesn't seem to be useful any more, and it's not really worth the
effort to keep updating it every time relevant dependencies or calling
signatures in the shared memory or semaphore code change.
Fix WAL replay bug in the new GIN incomplete-split code.
commit : 594bac42728fed67e05458633f35c2b1d7b38f1e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 7 Apr 2014 14:34:31 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 7 Apr 2014 14:34:31 +0300
Forgot to set the incomplete-split flag on the left page half, in redo of a
page split.
Spotted this by comparing the page contents on master and standby, after
inserting/applying each WAL record.
Extra warnings and errors for PL/pgSQL
commit : 7d8f1de1bc04bf8ddda6548156ef32f46e13dd50
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sun, 6 Apr 2014 12:21:51 -0400
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sun, 6 Apr 2014 12:21:51 -0400
Infrastructure to allow
plpgsql.extra_warnings
plpgsql.extra_errors
Initial extra checks only for shadowed_variables
Marko Tiikkaja and Petr Jelinek
Reviewed by Simon Riggs and Pavel Stěhule
Isolation test files for ALTER TABLE patch
commit : f14a6bbedb79adce2298d0d4f5e2abe8563e0eca
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sun, 6 Apr 2014 11:44:24 -0400
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sun, 6 Apr 2014 11:44:24 -0400
VALIDATE CONSTRAINT
CLUSTER ON
SET WITHOUT CLUSTER
ALTER COLUMN SET STATISTICS
ALTER COLUMN SET ()
ALTER COLUMN RESET ()
All other sub-commands use AccessExclusiveLock
Simon Riggs and Noah Misch
Reviews by Robert Haas and Andres Freund
Improve contrib/pg_trgm’s heuristics for regexp index searches.
commit : 80a5cf643adb496abe577a1ca6dc0c476d849c19
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 20:48:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 20:48:47 -0400
When extracting trigrams from a regular expression for search of a GIN or
GIST trigram index, it's useful to penalize (preferentially discard)
trigrams that contain whitespace, since those are typically far more common
in the index than trigrams not containing whitespace. Of course, this
should only be a preference not a hard rule, since we might otherwise end
up with no trigrams to search for. The previous coding tended to produce
fairly inefficient trigram search sets for anchored regexp patterns, as
reported by Erik Rijkers. This patch penalizes whitespace-containing
trigrams, and also reduces the target number of extracted trigrams, since
experience suggests that the original coding tended to select too many
trigrams to search for.
Alexander Korotkov, reviewed by Tom Lane
Block signals earlier during postmaster startup.
commit : 5d8117e1f38d7240e99d57e624a9d880872c7e98
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 18:16:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 18:16:08 -0400
Formerly, we set up the postmaster's signal handling only when we were
about to start launching subprocesses. This is a bad idea though, as
it means that for example a SIGINT arriving before that will kill the
postmaster instantly, perhaps leaving lockfiles, socket files, shared
memory, etc laying about. We'd rather that such a signal caused orderly
postmaster termination including releasing of those resources. A simple
fix is to move the PostmasterMain stanza that initializes signal handling
to an earlier point, before we've created any such resources. Then, an
early-arriving signal will be blocked until we're ready to deal with it
in the usual way. (The only part that really needs to be moved up is
blocking of signals, but it seems best to keep the signal handler
installation calls together with that; for one thing this ensures the
kernel won't drop any signals we wished to get. The handlers won't get
invoked in any case until we unblock signals in ServerLoop.)
Per a report from MauMau. He proposed changing the way "pg_ctl stop"
works to deal with this, but that'd just be masking one symptom not
fixing the core issue.
It's been like this since forever, so back-patch to all supported branches.
Fix another palloc in critical section.
commit : ffbba6ee1244901b492fe268ea94f72e35aedf38
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 5 Apr 2014 22:02:28 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 5 Apr 2014 22:02:28 +0300
Also add a regression test for a GIN index with enough items with the same
key, so that a GIN posting tree gets created. Apparently none of the
existing GIN tests were large enough for that.
This code is new, no backpatching required.
Fix processing of PGC_BACKEND GUC parameters on Windows.
commit : 6862ca6970d11c47996d99e49a1cf8b55ef9b40d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 12:41:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 12:41:25 -0400
EXEC_BACKEND builds (i.e., Windows) failed to absorb values of PGC_BACKEND
parameters if they'd been changed post-startup via the config file. This
for example prevented log_connections from working if it were turned on
post-startup. The mechanism for handling this case has always been a bit
of a kluge, and it wasn't revisited when we implemented EXEC_BACKEND.
While in a normal forking environment new backends will inherit the
postmaster's value of such settings, EXEC_BACKEND backends have to read
the settings from the CONFIG_EXEC_PARAMS file, and they were mistakenly
rejecting them. So this case has always been broken in the Windows port;
so back-patch to all supported branches.
Amit Kapila
ecpg/ecpglib must build the src/port files it uses with -DFRONTEND.
commit : 44c5d387eafb4ba1a032f8d7b13d85c553d69181
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 02:20:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Apr 2014 02:20:25 -0400
Remarkably, this hasn't been noticed before, though it surely should
have been happening since around the fall of the Byzantine empire.
Commit 438b529604 changed path.c to depend on FRONTEND, and that exposed
the omission, per buildfarm reports.
I'm suspicious that some other subdirectories are missing this too,
but this one change is enough to make ecpg tests pass for me.
Fix tablespace creation WAL replay to work on Windows.
commit : abe075dfffe2ef7e76ebbf5717fa3823f9a70a1f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 23:09:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 23:09:35 -0400
The code segment that removes the old symlink (if present) wasn't clued
into the fact that on Windows, symlinks are junction points which have
to be removed with rmdir().
Backpatch to 9.0, where the failing code was introduced.
MauMau, reviewed by Muhammad Asif Naeem and Amit Kapila
Allow “-C variable” and “–describe-config” even to root users.
commit : b203c57bb778d90bb8728be19e78825134d5820f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 22:03:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 22:03:35 -0400
There's no really compelling reason to refuse to do these read-only,
non-server-starting options as root, and there's at least one good
reason to allow -C: pg_ctl uses -C to find out the true data directory
location when pointed at a config-only directory. On Windows, this is
done before dropping administrator privileges, which means that pg_ctl
fails for administrators if and only if a config-only layout is used.
Since the root-privilege check is done so early in startup, it's a bit
awkward to check for these switches. Make the somewhat arbitrary
decision that we'll only skip the root check if -C is the first switch.
This is not just to make the code a bit simpler: it also guarantees that
we can't misinterpret a --boot mode switch. (While AuxiliaryProcessMain
doesn't currently recognize any such switch, it might have one in the
future.) This is no particular problem for pg_ctl, and since the whole
behavior is undocumented anyhow, it's not a documentation issue either.
(--describe-config only works as the first switch anyway, so this is
no restriction for that case either.)
Back-patch to 9.2 where pg_ctl first began to use -C.
MauMau, heavily edited by me
Preserve errno across free().
commit : 2209c0f8618bbed257975055e017efab139e3fa3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 19:07:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 19:07:37 -0400
Dept. of second thoughts: free() isn't guaranteed not to change errno.
Make sure we report the right error if getcwd() fails.
Make sure -D is an absolute path when starting server on Windows.
commit : 9aca51250681d2e8d18ed1d73e7cd1283d1cf303
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 18:42:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 18:42:13 -0400
This is needed because Windows services may get started with a different
current directory than where pg_ctl is executed. We want relative -D
paths to be interpreted relative to pg_ctl's CWD, similarly to what
happens on other platforms.
In support of this, move the backend's make_absolute_path() function
into src/port/path.c (where it probably should have been long since)
and get rid of the rather inferior version in pg_regress.
Kumar Rajeev Rastogi, reviewed by MauMau
Fix bogus time printout in walreceiver’s debug log messages.
commit : 8120c7452a51a773ad7a249b55557439f39d41ef
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 11:43:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Apr 2014 11:43:34 -0400
The displayed sendtime and receipttime were always exactly equal, because
somebody forgot that timestamptz_to_str returns a static buffer (thereby
simplifying life for most callers, at the cost of complicating it for those
who need two results concurrently). Apply the same pstrdup solution used
by the other call sites with this issue. Back-patch to 9.2 where the
faulty code was introduced. Per bug #9849 from Haruka Takatsuka, though
this is not exactly his patch.
Possibly we should change timestamptz_to_str's API, but I wouldn't want
to do so in the back branches.
Fix some compiler warnings that clang emits with -pedantic.
commit : 59202fae0434c98beb4994c5fe4df354a6af31e6
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 4 Apr 2014 11:26:01 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 4 Apr 2014 11:26:01 -0400
GetVirtualXIDsDelayingChkpt calls palloc, which isn't safe in a critical
section. I thought I covered this case with the exemption for the
checkpointer, but CreateCheckPoint is also called from the startup process.
Add an Assertion that you don’t palloc within a critical section.
commit : 4a170ee9e0ebd7021cb1190fabd5b0cbe2effb8e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 4 Apr 2014 14:27:18 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 4 Apr 2014 14:27:18 +0300
If a palloc in a critical section fails, it becomes a PANIC.
Fix non-equivalence of VARIADIC and non-VARIADIC function call formats.
commit : c7b353959931ae8e95177fe0a138b8119db9b802
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 22:02:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 22:02:24 -0400
For variadic functions (other than VARIADIC ANY), the syntaxes foo(x,y,...)
and foo(VARIADIC ARRAY[x,y,...]) should be considered equivalent, since the
former is converted to the latter at parse time. They have indeed been
equivalent, in all releases before 9.3. However, commit 75b39e790 made an
ill-considered decision to record which syntax had been used in FuncExpr
nodes, and then to make equal() test that in checking node equality ---
which caused the syntaxes to not be seen as equivalent by the planner.
This is the underlying cause of bug #9817 from Dmitry Ryabov.
It might seem that a quick fix would be to make equal() disregard
FuncExpr.funcvariadic, but the same commit made that untenable, because
the field actually *is* semantically significant for some VARIADIC ANY
functions. This patch instead adopts the approach of redefining
funcvariadic (and aggvariadic, in HEAD) as meaning that the last argument
is a variadic array, whether it got that way by parser intervention or was
supplied explicitly by the user. Therefore the value will always be true
for non-ANY variadic functions, restoring the principle of equivalence.
(However, the planner will continue to consider use of VARIADIC as a
meaningful difference for VARIADIC ANY functions, even though some such
functions might disregard it.)
In HEAD, this change lets us simplify the decompilation logic in
ruleutils.c, since the funcvariadic/aggvariadic flag tells directly whether
to print VARIADIC. However, in 9.3 we have to continue to cope with
existing stored rules/views that might contain the previous definition.
Fortunately, this just means no change in ruleutils.c, since its existing
behavior effectively ignores funcvariadic for all cases other than VARIADIC
ANY functions.
In HEAD, bump catversion to reflect the fact that FuncExpr.funcvariadic
changed meanings; this is sort of pro forma, since I don't believe any
built-in views are affected.
Unfortunately, this patch doesn't magically fix everything for affected
9.3 users. After installing 9.3.5, they might need to recreate their
rules/views/indexes containing variadic function calls in order to get
everything consistent with the new definition. As in the cited bug,
the symptom of a problem would be failure to use a nominally matching
index that has a variadic function call in its definition. We'll need
to mention this in the 9.3.5 release notes.
Code review for commit d26888bc4d1e539a82f21382b0000fe5bbf889d9.
commit : 741364bf5caeeae79b83bbdba778805d286622ba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 16:57:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 16:57:45 -0400
Mostly, copy-edit the comments; but also fix it to not reject domains over
arrays.
Fix documentation about joining pg_locks to other views.
commit : 42c6236f37988b4cb067f3fc908b247e70177496
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 14:18:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 14:18:25 -0400
The advice to join to pg_prepared_xacts via the transaction column was not
updated when the transaction column was replaced by virtualtransaction.
Since it's not quite obvious how to do that join, give an explicit example.
For consistency also give an example for the adjacent case of joining to
pg_stat_activity. And link-ify the view references too, just because we
can. Per bug #9840 from Alexey Bashtanov.
Michael Paquier and Tom Lane
Avoid promising that “ADD COLUMN … DEFAULT NULL” is free.
commit : 879808e5197c374e431e81fb5599dfea533bb9aa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 12:38:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Apr 2014 12:38:00 -0400
The system realizes that DEFAULT NULL is dummy in simple cases, but not if
a cast function (such as a length coercion) needs to be applied. It's
dubious that suppressing that function call would be appropriate, anyway.
For the moment, let's just adjust the docs to say that you should omit the
DEFAULT clause if you don't want a rewrite to happen. Per gripe from Amit
Langote.
Avoid palloc in critical section in GiST WAL-logging.
commit : 04e298b826d452ceb838d9fda884a29f229d484d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 3 Apr 2014 15:09:37 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 3 Apr 2014 15:09:37 +0300
Memory allocation can fail if you run out of memory, and inside a critical
section that will lead to a PANIC. Use conservatively-sized arrays in stack
instead.
There was previously no explicit limit on the number of pages a GiST split
can produce, it was only limited by the number of LWLocks that can be held
simultaneously (100 at the moment). This patch adds an explicit limit of 75
pages. That should be plenty, a typical split shouldn't produce more than
2-3 page halves.
The bug has been there forever, but only backpatch down to 9.1. The code
was changed significantly in 9.1, and it doesn't seem worth the risk or
trouble to adapt this for 9.0 and 8.4.
Fix assorted issues in client host name lookup.
commit : fc752505a99a4e2c781a070d3d42a25289c22e3c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Apr 2014 17:11:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Apr 2014 17:11:24 -0400
The code for matching clients to pg_hba.conf lines that specify host names
(instead of IP address ranges) failed to complain if reverse DNS lookup
failed; instead it silently didn't match, so that you might end up getting
a surprising "no pg_hba.conf entry for ..." error, as seen in bug #9518
from Mike Blackwell. Since we don't want to make this a fatal error in
situations where pg_hba.conf contains a mixture of host names and IP
addresses (clients matching one of the numeric entries should not have to
have rDNS data), remember the lookup failure and mention it as DETAIL if
we get to "no pg_hba.conf entry". Apply the same approach to forward-DNS
lookup failures, too, rather than treating them as immediate hard errors.
Along the way, fix a couple of bugs that prevented us from detecting an
rDNS lookup error reliably, and make sure that we make only one rDNS lookup
attempt; formerly, if the lookup attempt failed, the code would try again
for each host name entry in pg_hba.conf. Since more or less the whole
point of this design is to ensure there's only one lookup attempt not one
per entry, the latter point represents a performance bug that seems
sufficient justification for back-patching.
Also, adjust src/port/getaddrinfo.c so that it plays as well as it can
with this code. Which is not all that well, since it does not have actual
support for rDNS lookup, but at least it should return the expected (and
required by spec) error codes so that the main code correctly perceives the
lack of functionality as a lookup failure. It's unlikely that PG is still
being used in production on any machines that require our getaddrinfo.c,
so I'm not excited about working harder than this.
To keep the code in the various branches similar, this includes
back-patching commits c424d0d1052cb4053c8712ac44123f9b9a9aa3f2 and
1997f34db4687e671690ed054c8f30bb501b1168 into 9.2 and earlier.
Back-patch to 9.1 where the facility for hostnames in pg_hba.conf was
introduced.
De-anonymize the union in JsonbValue.
commit : f33a71a7865a1dd54f04b370e2637f88665f8db8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Apr 2014 14:30:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Apr 2014 14:30:08 -0400
Fix bugs in manipulation of PgBackendStatus.st_clienthostname.
commit : 682c5bbec5d9533d2d654d6a096c36bbae9f5bd0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Apr 2014 21:30:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Apr 2014 21:30:08 -0400
Initialization of this field was not being done according to the
st_changecount protocol (it has to be done within the changecount increment
range, not outside). And the test to see if the value should be reported
as null was wrong. Noted while perusing uses of Port.remote_hostname.
This was wrong from the introduction of this code (commit 4a25bc145),
so back-patch to 9.1.
Fix bug in the new GIN incomplete-split code.
commit : 8bbbcb91bae1489471d11fef269533bc4df2f766
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 1 Apr 2014 22:45:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 1 Apr 2014 22:45:10 +0300
Inserting a downlink to an internal page clears the incomplete-split flag
of the child's left sibling, so the left sibling's LSN also needs to be
updated and it needs to be marked dirty. The codepath for an insertion got
this right, but the case where the internal node is split because of
inserting the new downlink missed that.
Doc: improve discussion of reverse+forward host name lookup in pg_hba.conf.
commit : 6eff0accfe6b6170d10b91df769ea523b50927b8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Apr 2014 15:20:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Apr 2014 15:20:30 -0400
Inserting a downlink to an internal page clears the incomplete-split flag
of the child's left sibling, so the left sibling's LSN also needs to be
updated.
Move SizeOfHeapNewCid next to xl_heap_new_cid struct.
commit : f7534296b484fa73b064c87cc3a5062ba3803f3b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 1 Apr 2014 16:23:16 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 1 Apr 2014 16:23:16 +0300
commit : 4bc15a8bfbc7856bc3426dc9ab99567eebbb64d3
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 14:32:12 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 14:32:12 -0400
Otherwise, the compiler might decide to move modifications to data
within this structure outside the enclosing SpinLockAcquire /
SpinLockRelease pair, leading to shared memory corruption.
This may or may not explain a recent lmgr-related buildfarm failure
on prairiedog, but it needs to be fixed either way.
test_decoding: Update .gitignore
commit : 0f95b723eb207ca8fe2a0391b444db23b386617b
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 14:18:35 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 14:18:35 -0400
Commit 7317d8d961f210c3a6b20972cd605bcd9bffb06e changed the set of
things that need to be ignored, but neglected to update .gitignore.
Count buffers dirtied due to hints in pgBufferUsage.shared_blks_dirtied.
commit : 066254cea117a5a40d21401f754c83cc163378ae
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 13:06:26 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 13:06:26 -0400
Previously, such buffers weren't counted, with the possible result that
EXPLAIN (BUFFERS) and pg_stat_statements would understate the true
number of blocks dirtied by an SQL statement.
Back-patch to 9.2, where this counter was introduced.
Amit Kapila
Fix thinko in logical decoding code.
commit : 3f0e4be453ffd27b5f5e6c115172091abda3a38f
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 13:03:18 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 31 Mar 2014 13:03:18 -0400
Rewrite the way GIN posting lists are packed on a page, to reduce WAL volume.
commit : 14d02f0bb352d70d50106e153aca4af9c4b0b842
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 31 Mar 2014 15:15:19 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 31 Mar 2014 15:15:19 +0300
Inserting (in retail) into the new 9.4 format GIN posting tree created much
larger WAL records than in 9.3. The previous strategy to WAL logging was
basically to log the whole page on each change, with the exception of
completely unmodified segments up to the first modified one. That was not
too bad when appending to the end of the page, as only the last segment had
to be WAL-logged, but per Fujii Masao's testing, even that produced 2x the
WAL volume that 9.3 did.
The new strategy is to keep track of changes to the posting lists in a more
fine-grained fashion, and also make the repacking" code smarter to avoid
decoding and re-encoding segments unnecessarily.
Rename GinLogicValue to GinTernaryValue.
commit : 0cfa34c25a7c8e7017cac346d954016fad0dfc16
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 31 Mar 2014 10:26:38 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 31 Mar 2014 10:26:38 +0300
It's more descriptive. Also, get rid of the enum, and use #defines instead,
per Greg Stark's suggestion.
Use separate output dirs for test_decoding’s two runs.
commit : 7317d8d961f210c3a6b20972cd605bcd9bffb06e
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 30 Mar 2014 18:30:59 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 30 Mar 2014 18:30:59 -0400
contrib/test_decoding's "make check" runs two sets of tests. Unless we
specify separate output directories for each set the isolation tests
will overwrite the output from the normal regression set. Doing this
will help the buildfarm collect complete logs.
psql: display “Replica Identity” only for FULL and NOTHING
commit : 9d66116444b9763bc09defb688fb09343420e040
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 29 Mar 2014 19:00:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 29 Mar 2014 19:00:11 -0400
INDEX is already displayed on the index, and we now exclude pg_catalog.
DEFAULT is not displayed.
Fix dumping of a materialized view that depends on a table’s primary key.
commit : 62215de2925705bc607635e45ff800364456b1a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Mar 2014 17:34:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Mar 2014 17:34:00 -0400
It is possible for a view or materialized view to depend on a table's
primary key, if the view query relies on functional dependency to
abbreviate a GROUP BY list. This is problematic for pg_dump since we
ordinarily want to dump view definitions in the pre-data section but
indexes in post-data. pg_dump knows how to deal with this situation for
regular views, by breaking the view's ON SELECT rule apart from the view
proper. But it had not been taught what to do about materialized views,
and in fact mistakenly dumped them as regular views in such cases, as
seen in bug #9616 from Jesse Denardo.
If we had CREATE OR REPLACE MATERIALIZED VIEW, we could fix this in a
manner analogous to what's done for regular views; but we don't yet,
and we'd not back-patch such a thing into 9.3 anyway. As a hopefully-
temporary workaround, break the circularity by postponing the matview
into post-data altogether when this case occurs.
Revert “Secure Unix-domain sockets of “make check” temporary clusters.”
commit : 8f5578d0f9681ef81bc71a3762a191d66a29c8b1
author : Noah Misch <noah@leadboat.com>
date : Sat, 29 Mar 2014 03:12:00 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sat, 29 Mar 2014 03:12:00 -0400
Any OS user able to access the socket can connect as the bootstrap
superuser and in turn execute arbitrary code as the OS user running the
test. Protect against that by placing the socket in the temporary data
directory, which has mode 0700 thanks to initdb. Back-patch to 8.4 (all
supported versions). The hazard remains wherever the temporary cluster
accepts TCP connections, notably on Windows.
Attempts to run "make check" from a directory with a long name will now
fail. An alternative not sharing that problem was to place the socket
in a subdirectory of /tmp, but that is only secure if /tmp is sticky.
The PG_REGRESS_SOCK_DIR environment variable is available as a
workaround when testing from long directory paths.
As a convenient side effect, this lets testing proceed smoothly in
builds that override DEFAULT_PGSOCKET_DIR. Popular non-default values
like /var/run/postgresql are often unwritable to the build user.
Security: CVE-2014-0067
Document platform-specificity of unix_socket_permissions.
commit : fbd32b0cab806a2244bd5171e4b60e53f4a9dfe7
author : Noah Misch <noah@leadboat.com>
date : Sat, 29 Mar 2014 00:52:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sat, 29 Mar 2014 00:52:31 -0400
Improve regression test for pg_filenode_relation().
commit : 9613a1d98e5f940d8124850e61b0a950157c8863
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Mar 2014 16:58:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Mar 2014 16:58:09 -0400
Make it print the details in case there's a failure.
Andres Freund, slightly modified by me
Adjust getpwuid() fix commit to display errno string on failure
commit : e1827012ed4119150e29c3afcf462d3353f3a405
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 28 Mar 2014 12:50:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 28 Mar 2014 12:50:11 -0400
This adjusts patch 613c6d26bd42dd8c2dd0664315be9551475b8864.
Fix EquivalenceClass processing for nested append relations.
commit : a87c729153e372f3731689a7be007bc2b53f1410
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Mar 2014 11:50:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Mar 2014 11:50:01 -0400
The original coding of EquivalenceClasses didn't foresee that appendrel
child relations might themselves be appendrels; but this is possible for
example when a UNION ALL subquery scans a table with inheritance children.
The oversight led to failure to optimize ordering-related issues very well
for the grandchild tables. After some false starts involving explicitly
flattening the appendrel representation, we found that this could be fixed
easily by removing a few implicit assumptions about appendrel parent rels
not being children themselves.
Kyotaro Horiguchi and Tom Lane, reviewed by Noah Misch
Un-break peer authentication.
commit : b777be0d48a042f500cac72140ffb50392973aa2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Mar 2014 10:30:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Mar 2014 10:30:37 -0400
Commit 613c6d26bd42dd8c2dd0664315be9551475b8864 sloppily replaced a
lookup of the UID obtained from getpeereid() with a lookup of the
server's own user name, thus totally destroying peer authentication.
Revert. Per report from Christoph Berg.
In passing, make sure get_user_name() zeroes *errstr on success on
Windows as well as non-Windows. I don't think any callers actually
depend on this ATM, but we should be consistent across platforms.
Improve documentation note about Python 2.3 and cdecimal.
commit : e5a452b3a4600dfc9c045e1591c25e6a567d8d73
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Mar 2014 17:15:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Mar 2014 17:15:45 -0400
Explain exactly what fails (ie, function arguments of type numeric)
if you don't have it.
contrib/test_decoding: adjust expected output
commit : 5906e10a2aecf472c41b2cb5a2a923c7bbabdce2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 27 Mar 2014 10:47:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 27 Mar 2014 10:47:48 -0400
Expected output has changed because of psql replica identity output
changes.
Reported by Christoph Berg
Silence compiler warnings in new jsonb code.
commit : e709ced1536d1ed34d96633ea7c319a3a2a2751c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 27 Mar 2014 08:53:44 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 27 Mar 2014 08:53:44 +0200
Document that Python 2.3 requires cdecimal module for full functionality.
commit : f3cfc23195e3363ceab49449ed851944bcaf0849
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Mar 2014 22:43:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Mar 2014 22:43:22 -0400
This has been true for some time, but we were leaving users to discover it
the hard way.
Back-patch to 9.2. It might've been true before that, but we were claiming
Python 2.2 compatibility before that, so I won't guess at the exact
requirements back then.
Fix uninitialized variables in json’s populate_record_worker().
commit : 7e4d1600a621ee4e786e715bc82eaad1113dba0e
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 26 Mar 2014 18:20:56 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 26 Mar 2014 18:20:56 -0400
commit : 2d5e0f07de0119045fb889f9c11de0e486ce4ac5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Mar 2014 16:41:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Mar 2014 16:41:32 -0400
We must increment the refcount on "plntup" as soon as we have the
reference, not sometime later. Otherwise, if an error is thrown in
between, the Py_XDECREF(plntup) call in the PG_CATCH block removes a
refcount we didn't add, allowing the object to be freed even though
it's still part of the plpython function's parsetree.
This appears to be the cause of crashes seen on buildfarm member
prairiedog. It's a bit surprising that we've not seen it fail repeatably
before, considering that the regression tests have been exercising the
faulty code path since 2009.
The real-world impact is probably minimal, since it's unlikely anyone would
be provoking the "TD["new"] is not a dictionary" error in production, and
that's the only case that is actually wrong. Still, it's a bug affecting
the regression tests, so patch all supported branches.
In passing, remove dead variable "plstr", and demote "platt" to a local
variable inside the PG_TRY block, since we don't need to clean it up
in the PG_CATCH path.
Pass more than the first XLogRecData entry to rm_desc, with WAL_DEBUG.
commit : c2a6724823c14fd442c5441eb169b2581781fef0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 18:04:57 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 18:04:57 +0200
If you compile with WAL_DEBUG and enable it with wal_debug=on, we used to
only pass the first XLogRecData entry to the rm_desc routine. I think the
original assumprion was that the first XLogRecData entry contains all the
necessary information for the rm_desc routine, but that's a pretty shaky
assumption. At least standby_redo didn't get the memo.
To fix, piece together all the data in a temporary buffer, and pass that to
the rm_desc routine.
It's been like this forever, but the patch didn't apply cleanly to
back-branches. Probably wouldn't be hard to fix the conflicts, but it's
not worth the trouble.
psql: update “replica identity” display for \d+
commit : b69c4e65bea92ef617581365c365d2f43aa9e1fa
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Mar 2014 11:13:17 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Mar 2014 11:13:17 -0400
Display "replica identity" only for \d plus mode, exclude system schema
objects, and display all possible values, not just non-default,
non-index ones.
pg_upgrade: use pg_usleep(); remove Windows workaround
commit : ba08155bd5e6dffe5cd4bda9e7d6616b5e20d564
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Mar 2014 10:22:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Mar 2014 10:22:16 -0400
commit : f9c6d72cbf49257fea4265d994b96e66f25b2474
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 26 Mar 2014 10:18:24 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 26 Mar 2014 10:18:24 -0400
Set function parameter names and defaults. Add jsonb versions (which the
code already provided for so the actual new code is trivial). Add jsonb
regression tests and docs.
Bump catalog version (which I apparently forgot to do when jsonb was
committed).
Use pg_usleep() instead of plain sleep(), to fix Windows build
commit : 28475f8e58bd5da2b44a42203665a543f335c6a3
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 15:25:39 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 15:25:39 +0200
commit : ce9bb92f8fb8d25cf00ec939797ffdb5930fb792
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 13:48:20 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 13:48:20 +0200
This is useful for seeing what WAL records are inserted in real-time, by
pointing pg_xlogdump to a live server.
Fix ‘recheck’ flag in tsquery’s GIN tri-consistent function.
commit : 86cf41ed27f6e822a99998505ecffb42f2662662
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 10:13:44 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Mar 2014 10:13:44 +0200
It needs to be initialized, like in the boolean gin_tsquery_consistent
version.
Peter Geoghegan.
Tidy up the populate/to_record{set} code for json a bit.
commit : fbc3def8620953cf124aac65e7be4821f138c37f
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 25 Mar 2014 21:20:54 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 25 Mar 2014 21:20:54 -0400
Backpatch to 9.0 where XLOG_PARAMETER_CHANGE record was instroduced.
Fix typos in pg_basebackup documentation
commit : 36f7c3a1e019d16a83a363958c3f3927692821d9
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 25 Mar 2014 11:16:57 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 25 Mar 2014 11:16:57 +0100
commit : 6c5ced1526b189ed98baa0d195a7078d1afd112e
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 22:04:44 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 22:04:44 -0400
Remove wchar.c Asserts that were stricter than the main code
commit : 5db55c6bbca28b8be4d68d2fa0e22465cfe8e755
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 15:59:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 15:59:38 -0400
Assert errors were thrown for functions being passed invalid encodings,
while the main code handled it just fine.
Also document that libpq's PQclientEncoding() returns -1 for an encoding
lookup failure.
Per report from Peter Geoghegan
docs: Add short “cover density” description
commit : 0b5c0f3bc78d72b753387f84b9188709af3ef8fb
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 15:46:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 15:46:59 -0400
Also, previous commit 1420f3a9827a39e5c6c998f6fa35a6fc97903145 to fix
ts_rank_cd() for stripped lexemes was from a patch created by Alex Hill.
Fix ts_rank_cd() to ignore stripped lexemes
commit : 1420f3a9827a39e5c6c998f6fa35a6fc97903145
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 14:36:36 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 24 Mar 2014 14:36:36 -0400
Previously, stripped lexemes got a default location and could be
considered if mixed with non-stripped lexemes.
BACKWARD INCOMPATIBILITY CHANGE
Change ginMergeItemPointers to return a palloc’d array.
commit : bb42e21be274a71f6868ce2fc8fae2c15c3ecf66
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 24 Mar 2014 18:40:26 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 24 Mar 2014 18:40:26 +0200
Enclose "TIMELINE tli" part with brackets because it's optional.
Backport to 9.3 where TIMELINE option was introduced.
Noted by Marko Tiikkaja
Remove dead code and add comments.
commit : 2f3afc09793da3a30f2878f34eda30a71060da7e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 24 Mar 2014 11:02:23 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 24 Mar 2014 11:02:23 +0200
'cbuffer' variable was left over from an earlier version of the patch to
rewrite the incomplete split handling.
Fix “the the” typos.
commit : 3ed249b74133bc567a4efcfb90eb69d445097c1b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 24 Mar 2014 08:42:13 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 24 Mar 2014 08:42:13 +0200
Do jsonb regression test input in the conventional way.
commit : ab22b149c60a10b842e3ec7fe3eb3b0b66c6611a
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 23 Mar 2014 20:18:06 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 23 Mar 2014 20:18:06 -0400
commit : ca07cd59b24e00e428ed26716754244cec7f56b7
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 23 Mar 2014 18:25:16 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 23 Mar 2014 18:25:16 -0400
Introduce jsonb, a structured format for storing json.
commit : d9134d0a355cfa447adc80db4505d5931084278a
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 23 Mar 2014 16:40:19 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 23 Mar 2014 16:40:19 -0400
The new format accepts exactly the same data as the json type. However, it is
stored in a format that does not require reparsing the orgiginal text in order
to process it, making it much more suitable for indexing and other operations.
Insignificant whitespace is discarded, and the order of object keys is not
preserved. Neither are duplicate object keys kept - the later value for a given
key is the only one stored.
The new type has all the functions and operators that the json type has,
with the exception of the json generation functions (to_json, json_agg etc.)
and with identical semantics. In addition, there are operator classes for
hash and btree indexing, and two classes for GIN indexing, that have no
equivalent in the json type.
This feature grew out of previous work by Oleg Bartunov and Teodor Sigaev, which
was intended to provide similar facilities to a nested hstore type, but which
in the end proved to have some significant compatibility issues.
Authors: Oleg Bartunov, Teodor Sigaev, Peter Geoghegan and Andrew Dunstan.
Review: Andres Freund
Don’t test xmin/xmax columns of a postgres_fdw foreign table.
commit : b2b2491b06074e68fc7c96148cb0fdf0c8eb0469
author : Noah Misch <noah@leadboat.com>
date : Sun, 23 Mar 2014 03:48:17 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 23 Mar 2014 03:48:17 -0400
This covers all the SQL-standard trigger types supported for regular
tables; it does not cover constraint triggers. The approach for
acquiring the old row mirrors that for view INSTEAD OF triggers. For
AFTER ROW triggers, we spool the foreign tuples to a tuplestore.
This changes the FDW API contract; when deciding which columns to
populate in the slot returned from data modification callbacks, writable
FDWs will need to check for AFTER ROW triggers in addition to checking
for a RETURNING clause.
In support of the feature addition, refactor the TriggerFlags bits and
the assembly of old tuples in ModifyTable.
Ronan Dunklau, reviewed by KaiGai Kohei; some additional hacking by me.
Improve comments about AfterTriggerBeginQuery() query level usage.
commit : 6115480c543c0141011a99db78987ad13540be59
author : Noah Misch <noah@leadboat.com>
date : Sun, 23 Mar 2014 02:15:52 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 23 Mar 2014 02:15:52 -0400
equalTupleDescs() neglected both of these ConstrCheck fields, and
CreateTupleDescCopyConstr() neglected ccnoinherit. At this time, the
only known behavior defect resulting from these omissions is constraint
exclusion disregarding a CHECK constraint validated by an ALTER TABLE
VALIDATE CONSTRAINT statement issued earlier in the same transaction.
Back-patch to 9.2, where these fields were introduced.
Fix thinkos in GinLogicValue enum.
commit : 4c0e97c2d58f1cec9fc24237342962811de3cfee
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 21 Mar 2014 23:41:37 +0100
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 21 Mar 2014 23:41:37 +0100
It was incorrectly declared as global variable, not an enum type, and
the comments for GIN_FALSE and GIN_TRUE were backwards.
Fix build with LWLOCK_STATS or dtrace.
commit : dea6ed2c980286e89caf4166ad329f506abbff29
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 21 Mar 2014 23:11:24 +0100
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 21 Mar 2014 23:11:24 +0100
Also fix the name of the dtrace probe for LWLockAcquireOrWait(). The
function was renamed from LWLockWaitUntilFree to LWLockAqcuireOrWait, but
the dtrace probe was neglected.
Pointed out by Andres Freund and the buildfarm.
Remove MinGW readdir/errno bug workaround fixed on 2003-10-10
commit : 1494931d7375ccdc6afd34f135bc708f8954eecc
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 21 Mar 2014 13:47:37 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 21 Mar 2014 13:47:37 -0400
commit : 6f03927fce038096f53ca67eeab9adb24938f8a6
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 21 Mar 2014 13:45:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 21 Mar 2014 13:45:11 -0400
Clear errno before calling readdir() and handle old MinGW errno bug
while adding full test coverage for readdir/closedir failures.
Backpatch through 8.4.
Replace the XLogInsert slots with regular LWLocks.
commit : 68a2e52bbaf98f136a96b3a0d734ca52ca440a95
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 21 Mar 2014 15:06:08 +0100
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 21 Mar 2014 15:06:08 +0100
The special feature the XLogInsert slots had over regular LWLocks is the
insertingAt value that was updated atomically with releasing backends
waiting on it. Add new functions to the LWLock API to do that, and replace
the slots with LWLocks. This reduces the amount of duplicated code.
(There's still some duplication, but at least it's all in lwlock.c now.)
Reviewed by Andres Freund.
Again fix initialization of auto-tuned effective_cache_size.
commit : af930e606a3217db3909029c6c3f8d003ba70920
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Mar 2014 12:58:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Mar 2014 12:58:13 -0400
The previous method was overly complex and underly correct; in particular,
by assigning the default value with PGC_S_OVERRIDE, it prevented later
attempts to change the setting in postgresql.conf, as noted by Jeff Janes.
We should just assign the default value with source PGC_S_DYNAMIC_DEFAULT,
which will have the desired priority relative to the boot_val as well as
user-set values.
There is still a gap in this method: if there's an explicit assignment of
effective_cache_size = -1 in the postgresql.conf file, and that assignment
appears before shared_buffers is assigned, the code will substitute 4 times
the bootstrap default for shared_buffers, and that value will then persist
(since it will have source PGC_S_FILE). I don't see any very nice way
to avoid that though, and it's not a case to be expected in practice.
The existing comments in guc-file.l look forward to a redesign of the
DYNAMIC_DEFAULT mechanism; if that ever happens, we should consider this
case as one of the things we'd like to improve.
libpq: pass a memory allocation failure error up to PQconndefaults()
commit : a4c8f14364c27508233f8a31ac4b10a4c90235a9
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 20 Mar 2014 11:48:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 20 Mar 2014 11:48:31 -0400
Previously user name memory allocation failures were ignored and the
default user name set to NULL.
test_shm_mq: Improve regression tests.
commit : d1bdab2fa39f9a29fc806e1f2b6b5428b88d7cc5
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 20 Mar 2014 08:42:53 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 20 Mar 2014 08:42:53 -0400
With this in place, a session blocking behind another one because of
tuple locks will get a context line mentioning the relation name, tuple
TID, and operation being done on tuple. For example:
LOG: process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
DETAIL: Process holding the lock: 11366. Wait queue: 11367.
CONTEXT: while updating tuple (0,2) in relation "foo"
STATEMENT: UPDATE foo SET value = 3;
Most usefully, the new line is displayed by log entries due to
log_lock_waits, although of course it will be printed by any other log
message as well.
Author: Christian Kruse, some tweaks by Álvaro Herrera
Reviewed-by: Amit Kapila, Andres Freund, Tom Lane, Robert Haas
Fix memory leak during regular expression execution.
commit : ea8c7e9054abf23fa3de2f8e4414f60ac8a8b620
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Mar 2014 11:09:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Mar 2014 11:09:24 -0400
For a regex containing backrefs, pg_regexec() might fail to free all the
sub-DFAs that were created during execution, resulting in a permanent
(session lifespan) memory leak. Problem was introduced by me in commit
587359479acbbdc95c8e37da40707e37097423f5. Per report from Sandro Santilli;
diagnosis by Greg Stark.
Some minor improvements to logical decoding document.
commit : fb1d92a9fa0226c435daf16d08e5d05d6986fc54
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 19 Mar 2014 22:13:05 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 19 Mar 2014 22:13:05 +0900
Fix compilation of pg_xlogdump, now that rm_safe_restartpoint is no more.
commit : 033dc1c92cf018d396e983d425b821dda420cfff
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 22:23:00 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 22:23:00 +0200
commit : 59a5ab3f426e74e3f901dc2cf533726bcea08ed2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 22:06:59 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 22:06:59 +0200
It is no longer used, none of the resource managers have multi-record
actions that would make it unsafe to perform a restartpoint.
Also don't allow rm_cleanup to write WAL records, it's also no longer
required. Move the call to rm_cleanup routines to make it more symmetric
with rm_startup.
Fix misc typos in comments.
commit : 1d3b258cbe4aedfb49c92c28b9cbd7c18d277e04
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 21:03:17 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 21:03:17 +0200
commit : 3ee4fcfc63452a1ab5586b2d4cb4b6908d1badff
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 18 Mar 2014 14:57:49 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 18 Mar 2014 14:57:49 -0400
commit : a3b30d4cfe5f3ae718fd2cc6aa05b7707cac88dd
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 18 Mar 2014 14:54:00 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 18 Mar 2014 14:54:00 -0400
Make the handling of interrupted B-tree page splits more robust.
commit : 40dae7ec537c5619fc93ad602c62f37be786d161
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 20:12:58 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 18 Mar 2014 20:12:58 +0200
Splitting a page consists of two separate steps: splitting the child page,
and inserting the downlink for the new right page to the parent. Previously,
we handled the case that you crash in between those steps with a cleanup
routine after the WAL recovery had finished, which finished the incomplete
split. However, that doesn't help if the page split is interrupted but the
database doesn't crash, so that you don't perform WAL recovery. That could
happen for example if y