Stamp 9.5.0.
commit : cdd4ed5449bf317cc71b45a8deee0173822e7592
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 16:29:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 16:29:34 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
Docs: provide a concrete discussion and example for RLS race conditions.
commit : d878b115c350c18c0c9836c7652d5a179b5f9a33
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 15:11:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 15:11:44 -0500
Commit 43cd468cf01007f3 added some wording to create_policy.sgml purporting
to warn users against a race condition of the sort that had been noted some
time ago by Peter Geoghegan. However, that warning was far too vague to be
useful (or at least, I completely failed to grasp what it was on about).
Since the problem case occurs with a security design pattern that lots of
people are likely to try to use, we need to be as clear as possible about
it. Provide a concrete example in the main-line docs in place of the
original warning.
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_policy.sgml
Adjust behavior of row_security GUC to match the docs.
commit : 6a77404f5cd9380ccae24414d3f178e79011e96d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 12:21:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 12:21:31 -0500
Some time back we agreed that row_security=off should not be a way to
bypass RLS entirely, but only a way to get an error if it was being
applied. However, the code failed to act that way for table owners.
Per discussion, this is a must-fix bug for 9.5.0.
Adjust the logic in rls.c to behave as expected; also, modify the
error message to be more consistent with the new interpretation.
The regression tests need minor corrections as well. Also update
the comments about row_security in ddl.sgml to be correct. (The
official description of the GUC in config.sgml is already correct.)
I failed to resist the temptation to do some other very minor
cleanup as well, such as getting rid of a duplicate extern declaration.
M doc/src/sgml/ddl.sgml
M src/backend/utils/misc/rls.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Fix typo in comment.
commit : fa39e891b08a5cb283a721592d0fa2c19b4c7176
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 4 Jan 2016 10:12:37 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 4 Jan 2016 10:12:37 -0500
Masahiko Sawada
M src/bin/pg_rewind/RewindTest.pm
Translation updates
commit : 00dfd5c94c41685e867e3a686900cc2f9e4dd829
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 4 Jan 2016 08:18:48 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 4 Jan 2016 08:18:48 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 3b0ccc27cf917446ea0a6c680b70534cfcaba81e
M src/backend/po/de.po
M src/backend/po/id.po
M src/backend/po/pl.po
M src/backend/po/ru.po
M src/backend/po/zh_CN.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/zh_CN.po
M src/bin/pg_basebackup/po/pl.po
M src/bin/pg_basebackup/po/zh_CN.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/pl.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_controldata/po/zh_CN.po
M src/bin/pg_ctl/po/pl.po
M src/bin/pg_ctl/po/zh_CN.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/pl.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/zh_CN.po
M src/bin/pg_resetxlog/po/de.po
M src/bin/pg_resetxlog/po/pl.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/pg_resetxlog/po/zh_CN.po
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/po/pl.po
A src/bin/pg_rewind/po/zh_CN.po
M src/bin/psql/nls.mk
M src/bin/psql/po/de.po
A src/bin/psql/po/ko.po
M src/bin/psql/po/pl.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/zh_CN.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/pl.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/zh_CN.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/zh_CN.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/zh_CN.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/zh_CN.po
M src/pl/plpython/nls.mk
A src/pl/plpython/po/ko.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/zh_CN.po
M src/pl/tcl/po/pl.po
M src/pl/tcl/po/zh_CN.po
Fix regrole and regnamespace output functions to do quoting, too.
commit : de93252386e25b78400228b08326a50c43dd232b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 01:53:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 01:53:24 -0500
We discussed this but somehow failed to implement it...
M src/backend/utils/adt/regproc.c
Fix regrole and regnamespace types to honor quoting like other reg* types.
commit : fa038f830b64779475b746a6840db9bdd0298d80
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 01:03:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Jan 2016 01:03:53 -0500
Aside from any consistency arguments, this is logically necessary because
the I/O functions for these types also handle numeric OID values. Without
a quoting rule it is impossible to distinguish numeric OIDs from role or
namespace names that happen to contain only digits.
Also change the to_regrole and to_regnamespace functions to dequote their
arguments. While not logically essential, this seems like a good idea
since the other to_reg* functions do it. Anyone who really wants raw
lookup of an uninterpreted name can fall back on the time-honored solution
of (SELECT oid FROM pg_namespace WHERE nspname = whatever).
Report and patch by Jim Nasby, reviewed by Michael Paquier
M src/backend/utils/adt/regproc.c
M src/test/regress/expected/regproc.out
M src/test/regress/sql/regproc.sql
Fix bogus lock release in RemovePolicyById and RemoveRoleFromObjectPolicy.
commit : c244a511ba7f40dd43516eb025b1b299f2978f23
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 20:53:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 20:53:35 -0500
Can't release the AccessExclusiveLock on the target table until commit.
Otherwise there is a race condition whereby other backends might service
our cache invalidation signals before they can actually see the updated
catalog rows.
Just to add insult to injury, RemovePolicyById was closing the rel (with
incorrect lock drop) and then passing the now-dangling rel pointer to
CacheInvalidateRelcache. Probably the reason this doesn't fall over on
CLOBBER_CACHE buildfarm members is that some outer level of the DROP logic
is still holding the rel open ... but it'd have bit us on the arse
eventually, no doubt.
M src/backend/commands/policy.c
Do some copy-editing on the docs for row-level security.
commit : 35adf6e44cb65111f7caf5a9988c0738790ef02d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 20:04:11 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 20:04:11 -0500
Clarifications, markup improvements, corrections of misleading or
outright wrong statements.
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/alter_policy.sgml
M doc/src/sgml/ref/create_policy.sgml
M doc/src/sgml/ref/drop_policy.sgml
Guard against null arguments in binary_upgrade_create_empty_extension().
commit : ab1f08a3a4a855cb9245456866918706ca2fdf06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 16:26:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 16:26:38 -0500
The CHECK_IS_BINARY_UPGRADE macro is not sufficient security protection
if we're going to dereference pass-by-reference arguments before it.
But in any case we really need to explicitly check PG_ARGISNULL for all
the arguments of a non-strict function, not only the ones we expect null
values for.
Oversight in commits 30982be4e5019684e1772dd9170aaa53f5a8e894 and
f92fc4c95ddcc25978354a8248d3df22269201bc. Found by Andreas Seltenreich.
(The other usages in pg_upgrade_support.c seem safe.)
M src/backend/utils/adt/pg_upgrade_support.c
Do some copy-editing on the docs for replication origins.
commit : 2e5c9284f688d124b0169ff5b86003ca86842666
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 16:03:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 16:03:42 -0500
Minor grammar and markup improvements.
M doc/src/sgml/func.sgml
M doc/src/sgml/replication-origins.sgml
Do a final round of copy-editing on the 9.5 release notes.
commit : 78d0e582ab1087d0cde9d00d8c8994591ae3c955
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 15:33:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 15:33:12 -0500
M doc/src/sgml/release-9.5.sgml
Fix treatment of *lpNumberOfBytesRecvd == 0: that's a completion condition.
commit : 29692bdbb1dffed0eda38ad8268655425a7dcdf5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 13:56:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jan 2016 13:56:29 -0500
pgwin32_recv() has treated a non-error return of zero bytes from WSARecv()
as being a reason to block ever since the current implementation was
introduced in commit a4c40f140d23cefb. However, so far as one can tell
from Microsoft's documentation, that is just wrong: what it means is
graceful connection closure (in stream protocols) or receipt of a
zero-length message (in message protocols), and neither case should result
in blocking here. The only reason the code worked at all was that control
then fell into the retry loop, which did *not* treat zero bytes specially,
so we'd get out after only wasting some cycles. But as of 9.5 we do not
normally reach the retry loop and so the bug is exposed, as reported by
Shay Rojansky and diagnosed by Andres Freund.
Remove the unnecessary test on the byte count, and rearrange the code
in the retry loop so that it looks identical to the initial sequence.
Back-patch to 9.5. The code is wrong all the way back, AFAICS, but
since it's relatively harmless in earlier branches we'll leave it alone.
M src/backend/port/win32/socket.c
Teach pg_dump to quote reloption values safely.
commit : b01828e97df66b7ae5e1f8a583e2dc509e13a365
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Jan 2016 19:04:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Jan 2016 19:04:45 -0500
Commit c7e27becd2e6eb93 fixed this on the backend side, but we neglected
the fact that several code paths in pg_dump were printing reloptions
values that had not gotten massaged by ruleutils. Apply essentially the
same quoting logic in those places, too.
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
Fix overly-strict assertions in spgtextproc.c.
commit : 701303590053e100aa3a4ea87ac498d7fe00243f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Jan 2016 16:24:50 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Jan 2016 16:24:50 -0500
spg_text_inner_consistent is capable of reconstructing an empty string
to pass down to the next index level; this happens if we have an empty
string coming in, no prefix, and a dummy node label. (In practice, what
is needed to trigger that is insertion of a whole bunch of empty-string
values.) Then, we will arrive at the next level with in->level == 0
and a non-NULL (but zero length) in->reconstructedValue, which is valid
but the Assert tests weren't expecting it.
Per report from Andreas Seltenreich. This has no impact in non-Assert
builds, so should not be a problem in production, but back-patch to
all affected branches anyway.
In passing, remove a couple of useless variable initializations and
shorten the code by not duplicating DatumGetPointer() calls.
M src/backend/access/spgist/spgtextproc.c
Adjust back-branch release note description of commits a2a718b22 et al.
commit : 9200e5664405600ab0bf588a8ff48621682b9fa2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Jan 2016 15:29:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Jan 2016 15:29:03 -0500
As pointed out by Michael Paquier, recovery_min_apply_delay didn't exist
in 9.0-9.3, making the release note text not very useful. Instead make it
talk about recovery_target_xid, which did exist then.
9.0 is already out of support, but we can fix the text in the newer
branches' copies of its release notes.
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
Update copyright for 2016
commit : d47bc474b325099da381aa52a3a2a95354a2c80e
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 2 Jan 2016 13:33:39 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 2 Jan 2016 13:33:39 -0500
Backpatch certain files through 9.1
M COPYRIGHT
M doc/src/sgml/legal.sgml
Teach flatten_reloptions() to quote option values safely.
commit : 404c45bac64d312033dcf0373f7b1c0133b03afc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Jan 2016 15:27:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Jan 2016 15:27:53 -0500
flatten_reloptions() supposed that it didn't really need to do anything
beyond inserting commas between reloption array elements. However, in
principle the value of a reloption could be nearly anything, since the
grammar allows a quoted string there. Any restrictions on it would come
from validity checking appropriate to the particular option, if any.
A reloption value that isn't a simple identifier or number could thus lead
to dump/reload failures due to syntax errors in CREATE statements issued
by pg_dump. We've gotten away with not worrying about this so far with
the core-supported reloptions, but extensions might allow reloption values
that cause trouble, as in bug #13840 from Kouhei Sutou.
To fix, split the reloption array elements explicitly, and then convert
any value that doesn't look like a safe identifier to a string literal.
(The details of the quoting rule could be debated, but this way is safe
and requires little code.) While we're at it, also quote reloption names
if they're not safe identifiers; that may not be a likely problem in the
field, but we might as well try to be bulletproof here.
It's been like this for a long time, so back-patch to all supported
branches.
Kouhei Sutou, adjusted some by me
M src/backend/utils/adt/ruleutils.c
Add some more defenses against silly estimates to gincostestimate().
commit : d932391fd832aa62c5f86ddf7012622bb01bde9a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Jan 2016 13:42:21 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Jan 2016 13:42:21 -0500
A report from Andy Colson showed that gincostestimate() was not being
nearly paranoid enough about whether to believe the statistics it finds in
the index metapage. The problem is that the metapage stats (other than the
pending-pages count) are only updated by VACUUM, and in the worst case
could still reflect the index's original empty state even when it has grown
to many entries. We attempted to deal with that by scaling up the stats to
match the current index size, but if nEntries is zero then scaling it up
still gives zero. Moreover, the proportion of pages that are entry pages
vs. data pages vs. pending pages is unlikely to be estimated very well by
scaling if the index is now orders of magnitude larger than before.
We can improve matters by expanding the use of the rule-of-thumb estimates
I introduced in commit 7fb008c5ee59b040: if the index has grown by more
than a cutoff amount (here set at 4X growth) since VACUUM, then use the
rule-of-thumb numbers instead of scaling. This might not be exactly right
but it seems much less likely to produce insane estimates.
I also improved both the scaling estimate and the rule-of-thumb estimate
to account for numPendingPages, since it's reasonable to expect that that
is accurate in any case, and certainly pages that are in the pending list
are not either entry or data pages.
As a somewhat separate issue, adjust the estimation equations that are
concerned with extra fetches for partial-match searches. These equations
suppose that a fraction partialEntries / numEntries of the entry and data
pages will be visited as a consequence of a partial-match search. Now,
it's physically impossible for that fraction to exceed one, but our
estimate of partialEntries is mostly bunk, and our estimate of numEntries
isn't exactly gospel either, so we could arrive at a silly value. In the
example presented by Andy we were coming out with a value of 100, leading
to insane cost estimates. Clamp the fraction to one to avoid that.
Like the previous patch, back-patch to all supported branches; this
problem can be demonstrated in one form or another in all of them.
M src/backend/utils/adt/selfuncs.c
Split out pg_operator.h function declarations to new file pg_operator_fn.h.
commit : 2d774aaf1801b0338241cca9409803451ef28a6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Jan 2016 13:00:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Jan 2016 13:00:13 -0500
Commit a2e35b53c39b2a27 added an #include of catalog/objectaddress.h to
pg_operator.h, making it impossible for client-side code to #include
pg_operator.h. It's not entirely clear whether any client-side code needs
to include pg_operator.h, but it seems prudent to assume that there is some
such code somewhere. Therefore, split off the function definitions into a
new file pg_operator_fn.h, similarly to what we've done for some other
catalog header files.
Back-patch of part of commit 0dab5ef39b3d9d86.
M src/backend/catalog/pg_operator.c
M src/backend/commands/operatorcmds.c
M src/include/catalog/pg_operator.h
A src/include/catalog/pg_operator_fn.h
Add a comment noting that FDWs don't have to implement EXCEPT or LIMIT TO.
commit : 69892d58c9881acac934629187c7301f8e296eb4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Dec 2015 17:59:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Dec 2015 17:59:10 -0500
postgresImportForeignSchema pays attention to IMPORT's EXCEPT and LIMIT TO
options, but only as an efficiency hack, not for correctness' sake. The
FDW documentation does explain that, but someone using postgres_fdw.c
as a coding guide might not remember it, so let's add a comment here.
Per question from Regina Obe.
M contrib/postgres_fdw/postgres_fdw.c
Put back one copyObject() in rewriteTargetView().
commit : 30858be2f83b57517f84ce2e149f2d1c536c0252
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Dec 2015 16:45:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Dec 2015 16:45:47 -0500
Commit 6f8cb1e23485bd6d tried to centralize rewriteTargetView's copying
of a target view's Query struct. However, it ignored the fact that the
jointree->quals field was used twice. This only accidentally failed to
fail immediately because the same ChangeVarNodes mutation is applied in
both cases, so that we end up with logically identical expression trees
for both uses (and, as the code stands, the second ChangeVarNodes call
actually does nothing). However, we end up linking *physically*
identical expression trees into both an RTE's securityQuals list and
the WithCheckOption list. That's pretty dangerous, mainly because
prepsecurity.c is utterly cavalier about further munging such structures
without copying them first.
There may be no live bug in HEAD as a consequence of the fact that we apply
preprocess_expression in between here and prepsecurity.c, and that will
make a copy of the tree anyway. Or it may just be that the regression
tests happen to not trip over it. (I noticed this only because things
fell over pretty badly when I tried to relocate the planner's call of
expand_security_quals to before expression preprocessing.) In any case
it's very fragile because if anyone tried to make the securityQuals and
WithCheckOption trees diverge before we reach preprocess_expression, it
would not work. The fact that the current code will preprocess
securityQuals and WithCheckOptions lists at completely different times in
different query levels does nothing to increase my trust that that can't
happen.
In view of the fact that 9.5.0 is almost upon us and the aforesaid commit
has seen exactly zero field testing, the prudent course is to make an extra
copy of the quals so that the behavior is not different from what has been
in the field during beta.
M src/backend/rewrite/rewriteHandler.c
Rename (new|old)estCommitTs to (new|old)estCommitTsXid
commit : 282fdfcdc8a8f987c06e839d581b94bf196def8a
author : Joe Conway <mail@joeconway.com>
date : Mon, 28 Dec 2015 12:35:16 -0800
committer: Joe Conway <mail@joeconway.com>
date : Mon, 28 Dec 2015 12:35:16 -0800
The variables newestCommitTs and oldestCommitTs sound as if they are
timestamps, but in fact they are the transaction Ids that correspond
to the newest and oldest timestamps rather than the actual timestamps.
Rename these variables to reflect that they are actually xids: to wit
newestCommitTsXid and oldestCommitTsXid respectively. Also modify
related code in a similar fashion, particularly the user facing output
emitted by pg_controldata and pg_resetxlog.
Complaint and patch by me, review by Tom Lane and Alvaro Herrera.
Backpatch to 9.5 where these variables were first introduced.
M src/backend/access/rmgrdesc/xlogdesc.c
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/xlog.c
M src/backend/commands/vacuum.c
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_resetxlog/pg_resetxlog.c
M src/include/access/commit_ts.h
M src/include/access/transam.h
M src/include/catalog/pg_control.h
Document brin_summarize_new_pages
commit : 5bf939411ce7a4ae87cee65daca2e4add44b2b46
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Dec 2015 15:28:19 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Dec 2015 15:28:19 -0300
Pointer out by Jeff Janes
M doc/src/sgml/brin.sgml
M doc/src/sgml/func.sgml
Document the exponentiation operator as associating left to right.
commit : 508a26e2468fc4bb35f4b002552c304d51d97890
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Dec 2015 12:09:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Dec 2015 12:09:00 -0500
Common mathematical convention is that exponentiation associates right to
left. We aren't going to change the parser for this, but we could note
it in the operator's description. (It's already noted in the operator
precedence/associativity table, but users might not look there.)
Per bug #13829 from Henrik Pauli.
M doc/src/sgml/func.sgml
doc: pg_committs -> pg_commit_ts
commit : 3479b7984b01058993276d3d26ef47ec298ee219
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Dec 2015 13:45:03 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Dec 2015 13:45:03 -0300
Reported by: Alain Laporte (#13836)
M doc/src/sgml/ref/pg_resetxlog.sgml
Update documentation about pseudo-types.
commit : ea786b278c2471c69602c4b268be1ce90340e408
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Dec 2015 11:04:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Dec 2015 11:04:42 -0500
Tone down an overly strong statement about which pseudo-types PLs are
likely to allow. Add "event_trigger" to the list, as well as
"pg_ddl_command" in 9.5/HEAD. Back-patch to 9.3 where event_trigger
was added.
M doc/src/sgml/datatype.sgml
Fix translation domain in pg_basebackup
commit : c3e068b26185e6c667dbb45f05bb2466ed11cfea
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Dec 2015 10:50:35 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Dec 2015 10:50:35 -0300
For some reason, we've been overlooking the fact that pg_receivexlog
and pg_recvlogical are using wrong translation domains all along,
so their output hasn't ever been translated. The right domain is
pg_basebackup, not their own executable names.
Noticed by Ioseph Kim, who's been working on the Korean translation.
Backpatch pg_receivexlog to 9.2 and pg_recvlogical to 9.4.
M src/bin/pg_basebackup/pg_receivexlog.c
M src/bin/pg_basebackup/pg_recvlogical.c
Add forgotten CHECK_FOR_INTERRUPT calls in pgcrypto's crypt()
commit : c886c30cc8731a3fab989a2b361fd38c5bb1ad53
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 27 Dec 2015 13:03:19 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 27 Dec 2015 13:03:19 -0300
Both Blowfish and DES implementations of crypt() can take arbitrarily
long time, depending on the number of rounds specified by the caller;
make sure they can be interrupted.
Author: Andreas Karlsson
Reviewer: Jeff Janes
Backpatch to 9.1.
M contrib/pgcrypto/crypt-blowfish.c
M contrib/pgcrypto/crypt-des.c
Fix brin_summarize_new_values() to check index type and ownership.
commit : e10838026b373f01d1de0f4f7ea80a60c30565da
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Dec 2015 12:56:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Dec 2015 12:56:09 -0500
brin_summarize_new_values() did not check that the passed OID was for
an index at all, much less that it was a BRIN index, and would fail in
obscure ways if it wasn't (possibly damaging data first?). It also
lacked any permissions test; by analogy to VACUUM, we should only allow
the table's owner to summarize.
Noted by Jeff Janes, fix by Michael Paquier and me
M src/backend/access/brin/brin.c
M src/test/regress/expected/brin.out
M src/test/regress/sql/brin.sql
Remove unnecessary row ordering dependency in pg_rewind test suite.
commit : 2e947ba977eba1c0c31a2981d090b7b1897c49c2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Dec 2015 11:38:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Dec 2015 11:38:31 -0500
t/002_databases.pl was expecting to see a specific physical order of the
rows in pg_database. I broke that in HEAD with commit 01e386a325549b77,
but I'd say it's a pretty fragile test methodology in any case, so fix
it in 9.5 as well.
M src/bin/pg_rewind/t/002_databases.pl
Docs: fix erroneously-given function name.
commit : 0bdcb04c7d9c72bf9071b4a3d4ffc3d37ddad89e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Dec 2015 10:50:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Dec 2015 10:50:03 -0500
pg_replication_session_is_setup() exists nowhere; apparently this is
meant to refer to pg_replication_origin_session_is_setup().
Adrien Nayrat
M doc/src/sgml/func.sgml
Fix factual and grammatical errors in comments for struct _tableInfo.
commit : 84b363fb3476f5c5b3bb159d457aaf9966ba6b2d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Dec 2015 10:42:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Dec 2015 10:42:58 -0500
Amit Langote, further adjusted by me
M src/bin/pg_dump/pg_dump.h
Improve handling of password reuse in src/bin/scripts programs.
commit : 3945b6193240cd7fcb5ad3c67e9dca7f12d68b7e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Dec 2015 15:45:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Dec 2015 15:45:43 -0500
This reverts most of commit 83dec5a71 in favor of having connectDatabase()
store the possibly-reusable password in a static variable, similar to the
coding we've had for a long time in pg_dump's version of that function.
To avoid possible problems with unwanted password reuse, make callers
specify whether it's reasonable to attempt to re-use the password.
This is a wash for cases where re-use isn't needed, but it is far simpler
for callers that do want that. Functionally there should be no difference.
Even though we're past RC1, it seems like a good idea to back-patch this
into 9.5, like the prior commit. Otherwise, if there are any third-party
users of connectDatabase(), they'll have to deal with an API change in
9.5 and then another one in 9.6.
Michael Paquier
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.c
M src/bin/scripts/common.h
M src/bin/scripts/createlang.c
M src/bin/scripts/createuser.c
M src/bin/scripts/droplang.c
M src/bin/scripts/dropuser.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
In pg_dump, remember connection passwords no matter how we got them.
commit : a21994c1bf9e61d263a870c98ba1e5f559107b4e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Dec 2015 14:25:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Dec 2015 14:25:31 -0500
When pg_dump prompts the user for a password, it remembers the password
for possible re-use by parallel worker processes. However, libpq might
have extracted the password from a connection string originally passed
as "dbname". Since we don't record the original form of dbname but
break it down to host/port/etc, the password gets lost. Fix that by
retrieving the actual password from the PGconn.
(It strikes me that this whole approach is rather broken, as it will also
lose other information such as options that might have been present in
the connection string. But we'll leave that problem for another day.)
In passing, get rid of rather silly use of malloc() for small fixed-size
arrays.
Back-patch to 9.3 where parallel pg_dump was introduced.
Report and fix by Zeus Kronion, adjusted a bit by Michael Paquier and me
M src/bin/pg_dump/pg_backup_db.c
Comment improvements for abbreviated keys.
commit : 120b31dc5406cf004b99150b84b48dc312577eca
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 22 Dec 2015 13:57:18 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 22 Dec 2015 13:57:18 -0500
Peter Geoghegan and Robert Haas
M src/backend/utils/sort/tuplesort.c
M src/include/utils/sortsupport.h
Make viewquery a copy in rewriteTargetView()
commit : 496943ec2b6de0f22cd9e18f673e13635b5972ef
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 21 Dec 2015 10:34:20 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 21 Dec 2015 10:34:20 -0500
Rather than expect the Query returned by get_view_query() to be
read-only and then copy bits and pieces of it out, simply copy the
entire structure when we get it. This addresses an issue where
AcquireRewriteLocks, which is called by acquireLocksOnSubLinks(),
scribbles on the parsetree passed in, which was actually an entry
in relcache, leading to segfaults with certain view definitions.
This also future-proofs us a bit for anyone adding more code to this
path.
The acquireLocksOnSubLinks() was added in commit c3e0ddd40.
Back-patch to 9.3 as that commit was.
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Remove silly completion for "DELETE FROM tabname ...".
commit : 0c28e767c612c9e90ae8ab188cf9b21114a34ddc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Dec 2015 18:29:51 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Dec 2015 18:29:51 -0500
psql offered USING, WHERE, and SET in this context, but SET is not a valid
possibility here. Seems to have been a thinko in commit f5ab0a14ea83eb6c
which added DELETE's USING option.
M src/bin/psql/tab-complete.c
psql: Review of new help output strings
commit : 9ade78c65e1b98d2a8336be37d0442a53233c3b1
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 20 Dec 2015 11:50:04 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 20 Dec 2015 11:50:04 -0500
M src/bin/psql/describe.c
M src/bin/psql/help.c
Add missing COSTS OFF to EXPLAIN commands in rowsecurity.sql.
commit : 3ef762e7d806f18db743fd10bbf75a9b2631033c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Dec 2015 16:55:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Dec 2015 16:55:14 -0500
Commit e5e11c8cc added a bunch of EXPLAIN statements without COSTS OFF
to the regression tests. This is contrary to project policy since it
results in unnecessary platform dependencies in the output (it's just
luck that we didn't get buildfarm failures from it). Per gripe from
Mike Wilson.
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Fix tab completion for ALTER ... TABLESPACE ... OWNED BY.
commit : 8ae22e7d36e349d7d8fd616fbf7f78cc03e301e0
author : Andres Freund <andres@anarazel.de>
date : Sat, 19 Dec 2015 17:37:11 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sat, 19 Dec 2015 17:37:11 +0100
Previously the completion used the wrong word to match 'BY'. This was
introduced brokenly, in b2de2a. While at it, also add completion of
IN TABLESPACE ... OWNED BY and fix comments referencing nonexistent
syntax.
Reported-By: Michael Paquier
Author: Michael Paquier and Andres Freund
Discussion: CAB7nPqSHDdSwsJqX0d2XzjqOHr==HdWiubCi4L=Zs7YFTUne8w@mail.gmail.com
Backpatch: 9.4, like the commit introducing the bug
M src/bin/psql/tab-complete.c
pgbench: Change terminology from "threshold" to "parameter".
commit : 2c5b57ec7f0155eef7bd8d152e546ee96b2feb5e
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 18 Dec 2015 13:24:51 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 18 Dec 2015 13:24:51 -0500
Per a recommendation from Tomas Vondra, it's more helpful to refer to
the value that determines how skewed a Gaussian or exponential
distribution is as a parameter rather than a threshold.
Since it's not quite too late to get this right in 9.5, where it was
introduced, back-patch this. Most of the patch changes only comments
and documentation, but a few pgbench messages are altered to match.
Fabien Coelho, reviewed by Michael Paquier and by me.
M doc/src/sgml/ref/pgbench.sgml
M src/bin/pgbench/pgbench.c
Fix copy-and-paste error in logical decoding callback.
commit : 550e9c23053c2540620dd0f72525ce2e47fd40a5
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 18 Dec 2015 12:17:35 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 18 Dec 2015 12:17:35 -0500
This could result in the error context misidentifying where the error
actually occurred.
Craig Ringer
M src/backend/replication/logical/logical.c
Remove unreferenced function declarations.
commit : 30020c3fc3b6de5592978313df929d370f5770ce
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Dec 2015 20:21:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Dec 2015 20:21:42 -0500
datapagemap_create() and datapagemap_destroy() were declared extern,
but they don't actually exist anywhere. Per YUriy Zhuravlev and
Michael Paquier.
M src/bin/pg_rewind/datapagemap.h
Fix improper initialization order for readline.
commit : 5ec0aad018c3f36f9bd3e844f20562fb3c5d4590
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Dec 2015 16:55:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Dec 2015 16:55:23 -0500
Turns out we must set rl_basic_word_break_characters *before* we call
rl_initialize() the first time, because it will quietly copy that value
elsewhere --- but only on the first call. (Love these undocumented
dependencies.) I broke this yesterday in commit 2ec477dc8108339d;
like that commit, back-patch to all active branches. Per report from
Pavel Stehule.
M src/bin/psql/input.c
Rework internals of changing a type's ownership
commit : 0c6881fd142383845974ac836f3e6476cbe974ee
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 17 Dec 2015 14:25:41 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 17 Dec 2015 14:25:41 -0300
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
M src/backend/catalog/pg_shdepend.c
M src/backend/commands/tablecmds.c
M src/backend/commands/typecmds.c
M src/include/commands/typecmds.h
M src/test/regress/expected/dependency.out
M src/test/regress/sql/dependency.sql
Cope with Readline's failure to track SIGWINCH events outside of input.
commit : f1c152866c4a0786e4ec5504348c10735456f630
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Dec 2015 16:58:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Dec 2015 16:58:55 -0500
It emerges that libreadline doesn't notice terminal window size change
events unless they occur while collecting input. This is easy to stumble
over if you resize the window while using a pager to look at query output,
but it can be demonstrated without any pager involvement. The symptom is
that queries exceeding one line are misdisplayed during subsequent input
cycles, because libreadline has the wrong idea of the screen dimensions.
The safest, simplest way to fix this is to call rl_reset_screen_size()
just before calling readline(). That causes an extra ioctl(TIOCGWINSZ)
for every command; but since it only happens when reading from a tty, the
performance impact should be negligible. A more valid objection is that
this still leaves a tiny window during entry to readline() wherein delivery
of SIGWINCH will be missed; but the practical consequences of that are
probably negligible. In any case, there doesn't seem to be any good way to
avoid the race, since readline exposes no functions that seem safe to call
from a generic signal handler --- rl_reset_screen_size() certainly isn't.
It turns out that we also need an explicit rl_initialize() call, else
rl_reset_screen_size() dumps core when called before the first readline()
call.
rl_reset_screen_size() is not present in old versions of libreadline,
so we need a configure test for that. (rl_initialize() is present at
least back to readline 4.0, so we won't bother with a test for it.)
We would need a configure test anyway since libedit's emulation of
libreadline doesn't currently include such a function. Fortunately,
libedit seems not to have any corresponding bug.
Merlin Moncure, adjusted a bit by me
M configure
M configure.in
M src/bin/psql/input.c
M src/include/pg_config.h.in
Stamp 9.5rc1.
commit : 8abb52fa2971e16844d2a3e61b92fa347dc49d45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Dec 2015 17:25:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Dec 2015 17:25:44 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
Document use of Subject Alternative Names in SSL server certificates.
commit : 3ac806ccb5207810c7fe947ee44de4d242d42f97
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Dec 2015 16:57:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Dec 2015 16:57:23 -0500
Commit acd08d764 did not bother with updating the documentation.
M doc/src/sgml/libpq.sgml
Update 9.5 release notes through today.
commit : ddd78136764133b72bfe9102e60bbd49fa22b414
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Dec 2015 16:42:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Dec 2015 16:42:18 -0500
Also do another round of copy-editing, and fix up remaining FIXME items.
M doc/src/sgml/release-9.5.sgml
Improve CREATE POLICY documentation
commit : 46ae55c372761af5e02082ea934bebcba98040a4
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Dec 2015 10:08:14 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Dec 2015 10:08:14 -0500
Clarify that SELECT policies are now applied when SELECT rights
are required for a given query, even if the query is an UPDATE or
DELETE query. Pointed out by Noah.
Additionally, note the risk regarding concurrently open transactions
where a relation which controls access to the rows of another relation
are updated and the rows of the primary relation are also being
modified. Pointed out by Peter Geoghegan.
Back-patch to 9.5.
M doc/src/sgml/ref/create_policy.sgml
Collect the global OR of hasRowSecurity flags for plancache
commit : 651e2ba74af997c2952672397828636dc6c6d017
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 14 Dec 2015 20:05:55 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 14 Dec 2015 20:05:55 -0500
We carry around information about if a given query has row security or
not to allow the plancache to use that information to invalidate a
planned query in the event that the environment changes.
Previously, the flag of one of the subqueries was simply being copied
into place to indicate if the query overall included RLS components.
That's wrong as we need the global OR of all subqueries. Fix by
changing the code to match how fireRIRules works, which is results
in OR'ing all of the flags.
Noted by Tom.
Back-patch to 9.5 where RLS was introduced.
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/setrefs.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Add missing cleanup logic in pg_rewind/t/005_same_timeline.pl test.
commit : 2c24f0f092acb59184c3a3ace4b6cea4ff308328
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Dec 2015 19:22:50 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Dec 2015 19:22:50 -0500
Per Michael Paquier
M src/bin/pg_rewind/t/005_same_timeline.pl
pg_rewind: Don't error if the two clusters are already on the same timeline
commit : 4b021aa6103f49bece51d58fd5e307d4d03380bc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Dec 2015 18:21:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Dec 2015 18:21:42 -0500
This previously resulted in an error and a nonzero exit status, but
after discussion this should rather be a noop with a zero exit status.
This is a back-patch of commit 6b34e5563849edc12896bf5754e8fe7b88012697,
plus two changes from commit e50cda78404d6400b1326a996a4fabb144871151
that teach pg_rewind to allow the initial control file states to be
DB_SHUTDOWNED_IN_RECOVERY as well as DB_SHUTDOWNED. That's necessary
to get the additional regression test case to pass, and the old behavior
seems like rather a foot-gun anyway.
Peter Eisentraut and Tom Lane
M src/bin/pg_rewind/pg_rewind.c
A src/bin/pg_rewind/t/005_same_timeline.pl
Add missing CHECK_FOR_INTERRUPTS in lseg_inside_poly
commit : 188675256e15f7ad4d24ae976d1bb5fbb84f43e1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 14 Dec 2015 16:44:40 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 14 Dec 2015 16:44:40 -0300
Apparently, there are bugs in this code that cause it to loop endlessly.
That bug still needs more research, but in the meantime it's clear that
the loop is missing a check for interrupts so that it can be cancelled
timely.
Backpatch to 9.1 -- this has been missing since 49475aab8d0d.
M src/backend/utils/adt/geo_ops.c
Remove xmlparse(document '') test
commit : c6eced09b25d12d73b93a740f2d81c22bb7e3d1f
author : Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 14 Dec 2015 11:46:47 -0600
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 14 Dec 2015 11:46:47 -0600
This one test was behaving differently between the ubuntu fix for
CVE-2015-7499 and the base "expected" file. It's not worth having
yet another version of the expected file for this test, so drop it.
Perhaps at some point when all distros have settled down to the
same behavior on this test, it can be restored.
Problem found by me on libxml2 (2.9.1+dfsg1-3ubuntu4.6).
Solution suggested by Tom Lane.
Backpatch to 9.5, where the test was added.
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql
Fix out-of-memory error handling in ParameterDescription message processing.
commit : 34d136f92ac65c4ed8ede9459217ef900d603f97
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 14 Dec 2015 18:19:10 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 14 Dec 2015 18:19:10 +0200
If libpq ran out of memory while constructing the result set, it would hang,
waiting for more data from the server, which might never arrive. To fix,
distinguish between out-of-memory error and not-enough-data cases, and give
a proper error message back to the client on OOM.
There are still similar issues in handling COPY start messages, but let's
handle that as a separate patch.
Michael Paquier, Amit Kapila and me. Backpatch to all supported versions.
M src/interfaces/libpq/fe-protocol3.c
Fix bug in SetOffsetVacuumLimit() triggered by find_multixact_start() failure.
commit : ccde00b9b97ed8b7307e39f95bd48922bf955bb2
author : Andres Freund <andres@anarazel.de>
date : Mon, 14 Dec 2015 11:34:16 +0100
committer: Andres Freund <andres@anarazel.de>
date : Mon, 14 Dec 2015 11:34:16 +0100
Previously, if find_multixact_start() failed, SetOffsetVacuumLimit() would
install 0 into MultiXactState->offsetStopLimit if it previously succeeded.
Luckily, there are no known cases where find_multixact_start() will return
an error in 9.5 and above. But if it were to happen, for example due to
filesystem permission issues, it'd be somewhat bad: GetNewMultiXactId()
could continue allocating mxids even if close to a wraparound, or it could
erroneously stop allocating mxids, even if no wraparound is looming. The
wrong value would be corrected the next time SetOffsetVacuumLimit() is
called, or by a restart.
Reported-By: Noah Misch, although this is not his preferred fix
Discussion: 20151210140450.GA22278@alap3.anarazel.de
Backpatch: 9.5, where the bug was introduced as part of 4f627f
M src/backend/access/transam/multixact.c
Correct statement to actually be the intended assert statement.
commit : cb89644bb0df1921c6a15aa294903a9458c2a67d
author : Andres Freund <andres@anarazel.de>
date : Mon, 14 Dec 2015 11:25:04 +0100
committer: Andres Freund <andres@anarazel.de>
date : Mon, 14 Dec 2015 11:25:04 +0100
e3f4cfc7 introduced a LWLockHeldByMe() call, without the corresponding
Assert() surrounding it.
Spotted by Coverity.
Backpatch: 9.1+, like the previous commit
M src/backend/storage/buffer/bufmgr.c
Docs: document that psql's "\i -" means read from stdin.
commit : c9ed438817661238901f43ea10aab8f120ea837f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Dec 2015 23:42:54 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Dec 2015 23:42:54 -0500
This has worked that way for a long time, maybe always, but you would
not have known it from the documentation. Also back-patch the notes
I added to HEAD earlier today about behavior of the "-f -" switch,
which likewise have been valid for many releases.
M doc/src/sgml/ref/psql-ref.sgml
Consistently set all fields in pg_stat_replication to null instead of 0
commit : 28c366789e78af82dfd89ecb6cc32724f58d6a1b
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 13 Dec 2015 16:53:38 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 13 Dec 2015 16:53:38 +0100
Previously the "sent" field would be set to 0 and all other xlog
pointers be set to NULL if there were no valid values (such as when
in a backup sending walsender).
M src/backend/replication/walsender.c
Properly initialize write, flush and replay locations in walsender slots
commit : a9c56ff0e1f19fd6c2e48cfe44407c8cb8c4fbd5
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 13 Dec 2015 16:40:37 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 13 Dec 2015 16:40:37 +0100
These would leak random xlog positions if a walsender used for backup would
a walsender slot previously used by a replication walsender.
In passing also fix a couple of cases where the xlog pointer is directly
compared to zero instead of using XLogRecPtrIsInvalid, noted by
Michael Paquier.
M src/backend/replication/walsender.c
Doc: update external URLs for PostGIS project.
commit : 332be65b5e6a99420dd9b2762fe3e5602538053d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Dec 2015 20:02:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Dec 2015 20:02:09 -0500
Paul Ramsey
M doc/src/sgml/earthdistance.sgml
M doc/src/sgml/external-projects.sgml
M doc/src/sgml/release-8.4.sgml
Fix ALTER TABLE ... SET TABLESPACE for unlogged relations.
commit : ada9c09aebbe6c37d545fca29ac8c0e690158e80
author : Andres Freund <andres@anarazel.de>
date : Sat, 12 Dec 2015 14:19:19 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sat, 12 Dec 2015 14:19:19 +0100
Changing the tablespace of an unlogged relation did not WAL log the
creation and content of the init fork. Thus, after a standby is
promoted, unlogged relation cannot be accessed anymore, with errors
like:
ERROR: 58P01: could not open file "pg_tblspc/...": No such file or directory
Additionally the init fork was not synced to disk, independent of the
configured wal_level, a relatively small durability risk.
Investigation of that problem also brought to light that, even for
permanent relations, the creation of !main forks was not WAL logged,
i.e. no XLOG_SMGR_CREATE record were emitted. That mostly turns out not
to be a problem, because these files were created when the actual
relation data is copied; nonexistent files are not treated as an error
condition during replay. But that doesn't work for empty files, and
generally feels a bit haphazard. Luckily, outside init and main forks,
empty forks don't occur often or are not a problem.
Add the required WAL logging and syncing to disk.
Reported-By: Michael Paquier
Author: Michael Paquier and Andres Freund
Discussion: 20151210163230.GA11331@alap3.anarazel.de
Backpatch: 9.1, where unlogged relations were introduced
M src/backend/commands/tablecmds.c
Add an expected-file to match behavior of latest libxml2.
commit : ea7f7d8b322f0fd13419da1c0c46f7a9c74eef15
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 19:08:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 19:08:40 -0500
Recent releases of libxml2 do not provide error context reports for errors
detected at the very end of the input string. This appears to be a bug, or
at least an infelicity, introduced by the fix for libxml2's CVE-2015-7499.
We can hope that this behavioral change will get undone before too long;
but the security patch is likely to spread a lot faster/further than any
follow-on cleanup, which means this behavior is likely to be present in the
wild for some time to come. As a stopgap, add a variant regression test
expected-file that matches what you get with a libxml2 that acts this way.
A src/test/regress/expected/xml_2.out
For REASSIGN OWNED for foreign user mappings
commit : 31f88a12a0d9e340f7ccf49e5f133835499c981b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Dec 2015 18:39:09 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Dec 2015 18:39:09 -0300
As reported in bug #13809 by Alexander Ashurkov, the code for REASSIGN
OWNED hadn't gotten word about user mappings. Deal with them in the
same way default ACLs do, which is to ignore them altogether; they are
handled just fine by DROP OWNED. The other foreign object cases are
already handled correctly by both commands.
Also add a REASSIGN OWNED statement to foreign_data test to exercise the
foreign data objects. (The changes are just before the "cleanup" phase,
so it shouldn't remove any existing live test.)
Reported by Alexander Ashurkov, then independently by Jaime Casanova.
M src/backend/catalog/pg_shdepend.c
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql
Install our "missing" script where PGXS builds can find it.
commit : 6061aa8ed763f1d9d37d402a0e5769c823dd797c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 16:14:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 16:14:27 -0500
This allows sane behavior in a PGXS build done on a machine where build
tools such as bison are missing.
Jim Nasby
M config/Makefile
Handle policies during DROP OWNED BY
commit : fda18e46a65196b98d6ca4ce4911085b0d2f182f
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 11 Dec 2015 16:12:36 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 11 Dec 2015 16:12:36 -0500
DROP OWNED BY handled GRANT-based ACLs but was not removing roles from
policies. Fix that by having DROP OWNED BY remove the role specified
from the list of roles the policy (or policies) apply to, or the entire
policy (or policies) if it only applied to the role specified.
As with ACLs, the DROP OWNED BY caller must have permission to modify
the policy or a WARNING is thrown and no change is made to the policy.
M src/backend/catalog/pg_shdepend.c
M src/backend/commands/policy.c
M src/include/commands/policy.h
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Get rid of the planner's LateralJoinInfo data structure.
commit : dc4518814ecc2ae319c4d1679ee079e47dbd78e9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 15:52:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 15:52:16 -0500
I originally modeled this data structure on SpecialJoinInfo, but after
commit acfcd45cacb6df23 that looks like a pretty poor decision.
All we really need is relid sets identifying laterally-referenced rels;
and most of the time, what we want to know about includes indirect lateral
references, a case the LateralJoinInfo data was unsuited to compute with
any efficiency. The previous commit redefined RelOptInfo.lateral_relids
as the transitive closure of lateral references, so that it easily supports
checking indirect references. For the places where we really do want just
direct references, add a new RelOptInfo field direct_lateral_relids, which
is easily set up as a copy of lateral_relids before we perform the
transitive closure calculation. Then we can just drop lateral_info_list
and LateralJoinInfo and the supporting code. This makes the planner's
handling of lateral references noticeably more efficient, and shorter too.
Such a change can't be back-patched into stable branches for fear of
breaking extensions that might be looking at the planner's data structures;
but it seems not too late to push it into 9.5, so I've done so.
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/analyzejoins.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/plan/planagg.c
M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/prep/prepjointree.c
M src/backend/optimizer/prep/prepunion.c
M src/backend/optimizer/util/placeholder.c
M src/backend/optimizer/util/relnode.c
M src/backend/optimizer/util/var.c
M src/backend/rewrite/rewriteManip.c
M src/include/nodes/nodes.h
M src/include/nodes/relation.h
Handle dependencies properly in ALTER POLICY
commit : 12a54c888cf7bd9c37c4ce420e84cb52debe0184
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 11 Dec 2015 15:44:03 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 11 Dec 2015 15:44:03 -0500
ALTER POLICY hadn't fully considered partial policy alternation
(eg: change just the roles on the policy, or just change one of
the expressions) when rebuilding the dependencies. Instead, it
would happily remove all dependencies which existed for the
policy and then only recreate the dependencies for the objects
referred to in the specific ALTER POLICY command.
Correct that by extracting and building the dependencies for all
objects referenced by the policy, regardless of if they were
provided as part of the ALTER POLICY command or were already in
place as part of the pre-existing policy.
M src/backend/commands/policy.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Still more fixes for planner's handling of LATERAL references.
commit : 564c19e86eff3f2221471e60a963d55bd5f76954
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 14:22:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Dec 2015 14:22:20 -0500
More fuzz testing by Andreas Seltenreich exposed that the planner did not
cope well with chains of lateral references. If relation X references Y
laterally, and Y references Z laterally, then we will have to scan X on the
inside of a nestloop with Z, so for all intents and purposes X is laterally
dependent on Z too. The planner did not understand this and would generate
intermediate joins that could not be used. While that was usually harmless
except for wasting some planning cycles, under the right circumstances it
would lead to "failed to build any N-way joins" or "could not devise a
query plan" planner failures.
To fix that, convert the existing per-relation lateral_relids and
lateral_referencers relid sets into their transitive closures; that is,
they now show all relations on which a rel is directly or indirectly
laterally dependent. This not only fixes the chained-reference problem
but allows some of the relevant tests to be made substantially simpler
and faster, since they can be reduced to simple bitmap manipulations
instead of searches of the LateralJoinInfo list.
Also, when a PlaceHolderVar that is due to be evaluated at a join contains
lateral references, we should treat those references as indirect lateral
dependencies of each of the join's base relations. This prevents us from
trying to join any individual base relations to the lateral reference
source before the join is formed, which again cannot work.
Andreas' testing also exposed another oversight in the "dangerous
PlaceHolderVar" test added in commit 85e5e222b1dd02f1. Simply rejecting
unsafe join paths in joinpath.c is insufficient, because in some cases
we will end up rejecting *all* possible paths for a particular join, again
leading to "could not devise a query plan" failures. The restriction has
to be known also to join_is_legal and its cohort functions, so that they
will not select a join for which that will happen. I chose to move the
supporting logic into joinrels.c where the latter functions are.
Back-patch to 9.3 where LATERAL support was introduced.
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/util/relnode.c
M src/include/nodes/relation.h
M src/include/optimizer/pathnode.h
M src/include/optimizer/paths.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix commit timestamp initialization
commit : 0f2c089d3423bcf2bb11d1e5d2d38638cc31fec4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Dec 2015 14:30:43 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Dec 2015 14:30:43 -0300
This module needs explicit initialization in order to replay WAL records
in recovery, but we had broken this recently following changes to make
other (stranger) scenarios work correctly. To fix, rework the
initialization sequence so that it always takes place before WAL replay
commences for both master and standby.
I could have gone for a more localized fix that just added a "startup"
call for the master server, but it seemed better to restructure the
existing callers as well so that the whole thing made more sense. As a
drawback, there is more control logic in xlog.c now than previously, but
doing otherwise meant passing down the ControlFile flag, which seemed
uglier as a whole.
This also meant adding a check to not re-execute ActivateCommitTs if it
had already been called.
Reported by Fujii Masao.
Backpatch to 9.5.
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/xlog.c
M src/include/access/commit_ts.h
Improve some messages
commit : 0fc7c4a557752652ebddddb55ad11228129b530e
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 10 Dec 2015 22:05:27 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 10 Dec 2015 22:05:27 -0500
M src/backend/access/transam/commit_ts.c
M src/backend/catalog/objectaddress.c
M src/backend/commands/policy.c
M src/backend/commands/user.c
M src/backend/executor/nodeCustom.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/object_address.out
Improve ALTER POLICY tab completion.
commit : dcf5d7fb14b3ec59b436ce27d843574b6407e5b4
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 10 Dec 2015 12:28:46 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 10 Dec 2015 12:28:46 -0500
Complete "ALTER POLICY" with a policy name, as we do for DROP POLICY.
And, complete "ALTER POLICY polname ON" with a table name that has such
a policy, as we do for DROP POLICY, rather than with any table name
at all.
Masahiko Sawada
M src/bin/psql/tab-complete.c
Fix typo.
commit : b994acf705bea9840880b1860dca9ceb0f4785ee
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 10 Dec 2015 11:13:24 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 10 Dec 2015 11:13:24 -0500
Etsuro Fujita
M doc/src/sgml/fdwhandler.sgml
Fix ON CONFLICT UPDATE bug breaking AFTER UPDATE triggers.
commit : 34263e8e4a679ee785e601566bf144bf1f50a2b6
author : Andres Freund <andres@anarazel.de>
date : Thu, 10 Dec 2015 16:26:45 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 10 Dec 2015 16:26:45 +0100
ExecOnConflictUpdate() passed t_ctid of the to-be-updated tuple to
ExecUpdate(). That's problematic primarily because of two reason: First
and foremost t_ctid could point to a different tuple. Secondly, and
that's what triggered the complaint by Stanislav, t_ctid is changed by
heap_update() to point to the new tuple version. The behavior of AFTER
UPDATE triggers was therefore broken, with NEW.* and OLD.* tuples
spuriously identical within AFTER UPDATE triggers.
To fix both issues, pass a pointer to t_self of a on-stack HeapTuple
instead.
Fixing this bug lead to one change in regression tests, which previously
failed due to the first issue mentioned above. There's a reasonable
expectation that test fails, as it updates one row repeatedly within one
INSERT ... ON CONFLICT statement. That is only possible if the second
update is triggered via ON CONFLICT ... SET, ON CONFLICT ... WHERE, or
by a WITH CHECK expression, as those are executed after
ExecOnConflictUpdate() does a visibility check. That could easily be
prohibited, but given it's allowed for plain UPDATEs and a rare corner
case, it doesn't seem worthwhile.
Reported-By: Stanislav Grozev
Author: Andres Freund and Peter Geoghegan
Discussion: CAA78GVqy1+LisN-8DygekD_Ldfy=BJLarSpjGhytOsgkpMavfQ@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/triggers.out
M src/test/regress/expected/with.out
M src/test/regress/sql/triggers.sql
M src/test/regress/sql/with.sql
Fix bug leading to restoring unlogged relations from empty files.
commit : 5b51805fe4b9fec95274924c5733093a5f685a58
author : Andres Freund <andres@anarazel.de>
date : Thu, 10 Dec 2015 16:25:12 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 10 Dec 2015 16:25:12 +0100
At the end of crash recovery, unlogged relations are reset to the empty
state, using their init fork as the template. The init fork is copied to
the main fork without going through shared buffers. Unfortunately WAL
replay so far has not necessarily flushed writes from shared buffers to
disk at that point. In normal crash recovery, and before the
introduction of 'fast promotions' in fd4ced523 / 9.3, the
END_OF_RECOVERY checkpoint flushes the buffers out in time. But with
fast promotions that's not the case anymore.
To fix, force WAL writes targeting the init fork to be flushed
immediately (using the new FlushOneBuffer() function). In 9.5+ that
flush can centrally be triggered from the code dealing with restoring
full page writes (XLogReadBufferForRedoExtended), in earlier releases
that responsibility is in the hands of XLOG_HEAP_NEWPAGE's replay
function.
Backpatch to 9.1, even if this currently is only known to trigger in
9.3+. Flushing earlier is more robust, and it is advantageous to keep
the branches similar.
Typical symptoms of this bug are errors like
'ERROR: index "..." contains unexpected zero page at block 0'
shortly after promoting a node.
Reported-By: Thom Brown
Author: Andres Freund and Michael Paquier
Discussion: 20150326175024.GJ451@alap3.anarazel.de
Backpatch: 9.1-
M src/backend/access/transam/xlogutils.c
M src/backend/storage/buffer/bufmgr.c
M src/include/storage/bufmgr.h
Accept flex > 2.5.x on Windows, too.
commit : 2355faae010591febd2b39e74b209a5236f6682a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Dec 2015 10:19:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Dec 2015 10:19:13 -0500
Commit 32f15d05c fixed this in configure, but missed the similar check
in the MSVC scripts.
Michael Paquier, per report from Victor Wagner
M src/tools/msvc/pgflex.pl
Simplify LATERAL-related calculations within add_paths_to_joinrel().
commit : c3c5c02881d47b3bf8d9e1e1e3460ef348863035
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Dec 2015 18:54:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Dec 2015 18:54:25 -0500
While convincing myself that commit 7e19db0c09719d79 would solve both of
the problems recently reported by Andreas Seltenreich, I realized that
add_paths_to_joinrel's handling of LATERAL restrictions could be made
noticeably simpler and faster if we were to retain the minimum possible
parameterization for each joinrel (that is, the set of relids supplying
unsatisfied lateral references in it). We already retain that for
baserels, in RelOptInfo.lateral_relids, so we can use that field for
joinrels too.
This is a back-port of commit edca44b1525b3d591263d032dc4fe500ea771e0e.
I originally intended not to back-patch that, but additional hacking
in this area turns out to be needed, making it necessary not optional
to compute lateral_relids for joinrels. In preparation for those fixes,
sync the relevant code with HEAD as much as practical. (I did not risk
rearranging fields of RelOptInfo in released branches, however.)
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/util/relnode.c
M src/include/nodes/relation.h
Remove redundant sentence.
commit : 4acee11e660aa5dd22d81a1d1d4476e158c16a59
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 9 Dec 2015 14:11:58 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 9 Dec 2015 14:11:58 -0500
Peter Geoghegan
M doc/src/sgml/ref/insert.sgml
Make failure to open psql's --log-file fatal.
commit : e90371d1a79f4398867f4f3bb8547e94259b07b5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Dec 2015 17:14:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Dec 2015 17:14:46 -0500
Commit 344cdff2c made failure to open the target of --output fatal.
For consistency, the --log-file switch should behave similarly.
Like the previous commit, back-patch to 9.5 but no further.
Daniel Verite
M src/bin/psql/startup.c
Avoid odd portability problem in TestLib.pm's slurp_file function.
commit : 59f10ffa5bc1f39a5ce00806b394feb8f207bb33
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Dec 2015 16:58:05 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Dec 2015 16:58:05 -0500
For unclear reasons, this function doesn't always read the expected data
in some old Perl versions. Rewriting it to avoid use of ARGV seems to
dodge the problem, and this version is clearer anyway if you ask me.
In passing, also improve error message in adjacent append_to_file function.
M src/test/perl/TestLib.pm
Allow foreign and custom joins to handle EvalPlanQual rechecks.
commit : 325b357bc255149c5ace7d77f5c15c941bafef0a
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 8 Dec 2015 12:31:03 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 8 Dec 2015 12:31:03 -0500
Commit e7cb7ee14555cc9c5773e2c102efd6371f6f2005 provided basic
infrastructure for allowing a foreign data wrapper or custom scan
provider to replace a join of one or more tables with a scan.
However, this infrastructure failed to take into account the need
for possible EvalPlanQual rechecks, and ExecScanFetch would fail
an assertion (or just overwrite memory) if such a check was attempted
for a plan containing a pushed-down join. To fix, adjust the EPQ
machinery to skip some processing steps when scanrelid == 0, making
those the responsibility of scan's recheck method, which also has
the responsibility in this case of correctly populating the relevant
slot.
To allow foreign scans to gain control in the right place to make
use of this new facility, add a new, optional RecheckForeignScan
method. Also, allow a foreign scan to have a child plan, which can
be used to correctly populate the slot (or perhaps for something
else, but this is the only use currently envisioned).
KaiGai Kohei, reviewed by Robert Haas, Etsuro Fujita, and Kyotaro
Horiguchi.
M contrib/file_fdw/file_fdw.c
M contrib/postgres_fdw/postgres_fdw.c
M doc/src/sgml/fdwhandler.sgml
M src/backend/executor/execScan.c
M src/backend/executor/nodeForeignscan.c
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/pathnode.c
M src/include/foreign/fdwapi.h
M src/include/nodes/relation.h
M src/include/optimizer/pathnode.h
M src/include/optimizer/planmain.h
Fix another oversight in checking if a join with LATERAL refs is legal.
commit : 25517ee14c1a018876b64dce73e8f7fb7e937783
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Dec 2015 17:41:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Dec 2015 17:41:45 -0500
It was possible for the planner to decide to join a LATERAL subquery to
the outer side of an outer join before the outer join itself is completed.
Normally that's fine because of the associativity rules, but it doesn't
work if the subquery contains a lateral reference to the inner side of the
outer join. In such a situation the outer join *must* be done first.
join_is_legal() missed this consideration and would allow the join to be
attempted, but the actual path-building code correctly decided that no
valid join path could be made, sometimes leading to planner errors such as
"failed to build any N-way joins".
Per report from Andreas Seltenreich. Back-patch to 9.3 where LATERAL
support was added.
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/util/relnode.c
M src/include/optimizer/pathnode.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Update xindex.sgml for recent additions to GIST opclass API.
commit : 9d1839fad945cba7e23e645a3c212f34e56495f7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Dec 2015 12:42:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Dec 2015 12:42:32 -0500
Commit d04c8ed9044ec added another support function to the GIST API,
but overlooked mentioning it in xindex.sgml's summary of index support
functions.
Anastasia Lubennikova
M doc/src/sgml/xindex.sgml
Create TestLib.pm's tempdir underneath tmp_check/, not out in the open.
commit : 20c444f5b5ef155147b8f3ef115f6bc5382fd2c6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Dec 2015 13:23:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Dec 2015 13:23:48 -0500
This way, existing .gitignore entries and makefile clean actions will
automatically apply to the tempdir, should it survive a TAP test run
(which can happen if the user control-C's out of the run, for example).
Michael Paquier, per a complaint from me
M src/test/perl/TestLib.pm
Instruct Coverity using an assertion.
commit : 0d46bdde2b59e67446e10165e487935a54dfd225
author : Noah Misch <noah@leadboat.com>
date : Sat, 5 Dec 2015 03:04:17 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sat, 5 Dec 2015 03:04:17 -0500
This should make Coverity deduce that plperl_call_perl_func() does not
dereference NULL argtypes. Back-patch to 9.5, where the affected code
was introduced.
Michael Paquier
M src/pl/plperl/plperl.c
Further improve documentation of the role-dropping process.
commit : d3762fe6c208c4f5e66db24a10ddc549e9e08e0f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Dec 2015 14:44:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Dec 2015 14:44:13 -0500
In commit 1ea0c73c2 I added a section to user-manag.sgml about how to drop
roles that own objects; but as pointed out by Stephen Frost, I neglected
that shared objects (databases or tablespaces) may need special treatment.
Fix that. Back-patch to supported versions, like the previous patch.
M doc/src/sgml/user-manag.sgml
Further tweak commit_timestamp behavior
commit : 16e8e62d274a6026045bf809da38bc8ac33b9185
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 3 Dec 2015 19:22:31 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 3 Dec 2015 19:22:31 -0300
As pointed out by Fujii Masao, we weren't quite there on a standby
behaving sanely: first because we were failing to acquire the correct
state in the case where no XLOG_PARAMETER_CHANGE message was sent
(because a checkpoint had already happened after the setting was changed
in the master, and then the standby was restarted); and second because
promoting the standby with the feature enabled failed to activate it if
the master had the feature disabled.
This patch fixes both those misbehaviors hopefully without
re-introducing any old problems.
Also change the hint emitted in a standby together with the error
message about the feature being disabled, to make it point out that the
place to chance the setting is the master. Otherwise, if the setting is
already enabled in the standby, it is very confusing to have it say that
the setting must be enabled ...
Authors: Álvaro Herrera, Petr Jelínek.
Backpatch to 9.5.
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/xlog.c
M src/include/access/commit_ts.h
Clean up some psql issues around handling of the query output file.
commit : 07338cb7425ee661ea2b80c1a3826bee1bc1a1de
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Dec 2015 14:29:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Dec 2015 14:29:07 -0500
Formerly, if "psql -o foo" failed to open the output file "foo", it would
print an error message but then carry on as though -o had not been
specified at all. This seems contrary to expectation: a program that
cannot open its output file normally fails altogether. Make psql do
exit(1) after reporting the error.
If "\o foo" failed to open "foo", it would print an error message but then
reset the output file to stdout, as if the argument had been omitted.
This is likewise pretty surprising behavior. Make it keep the previous
output state, instead.
psql keeps SIGPIPE interrupts disabled when it is writing to a pipe, either
a pipe specified by -o/\o or a transient pipe opened for purposes such as
using a pager on query output. The logic for this was too simple and could
sometimes re-enable SIGPIPE when a -o pipe was still active, thus possibly
leading to an unexpected psql crash later.
Fixing the last point required getting rid of the kluge in PrintQueryTuples
and ExecQueryUsingCursor whereby they'd transiently change the global
queryFout state, but that seems like good cleanup anyway.
Back-patch to 9.5 but not further; these are minor-enough issues that
changing the behavior in stable branches doesn't seem appropriate.
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/common.h
M src/bin/psql/copy.c
M src/bin/psql/print.c
M src/bin/psql/print.h
M src/bin/psql/startup.c
psql: Improve spelling
commit : 28bfdc581a552e2a3b1f0faded352188559e5aca
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 3 Dec 2015 10:23:59 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 3 Dec 2015 10:23:59 -0500
M src/bin/psql/command.c
doc: Fix markup and improve placeholder names
commit : 0638a62dec88b148b560e5fb240087098fe58887
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 3 Dec 2015 10:20:54 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 3 Dec 2015 10:20:54 -0500
M doc/src/sgml/ref/insert.sgml
Fix behavior of printTable() and friends with externally-invoked pager.
commit : 375a3b3397487e46c9c607f23db4851eb5bb9ece
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Dec 2015 18:20:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Dec 2015 18:20:34 -0500
The formatting modes that depend on knowledge of the terminal window width
did not work right when printing a query result that's been fetched in
sections (as a result of FETCH_SIZE). ExecQueryUsingCursor() would force
use of the pager as soon as there's more than one result section, and then
print.c would see an output file pointer that's not stdout and incorrectly
conclude that the terminal window width isn't relevant.
This has been broken all along for non-expanded "wrapped" output format,
and as of 9.5 the issue affects expanded mode as well. The problem also
caused "\pset expanded auto" mode to invariably *not* switch to expanded
output in a segmented result, which seems to me to be exactly backwards.
To fix, we need to pass down an "is_pager" flag to inform the print.c
subroutines that some calling level has already replaced stdout with a
pager pipe, so they should (a) not do that again and (b) nonetheless honor
the window size. (Notably, this makes the first is_pager test in
print_aligned_text() not be dead code anymore.)
This patch is a bit invasive because there are so many existing calls of
printQuery()/printTable(), but fortunately all but a couple can just pass
"false" for the added parameter.
Back-patch to 9.5 but no further. Given the lack of field complaints,
it's not clear that we should change the behavior in stable branches.
Also, the API change for printQuery()/printTable() might possibly break
third-party code, again something we don't like to do in stable branches.
However, it's not quite too late to do this in 9.5, and with the larger
scope of the problem there, it seems worth doing.
M src/bin/psql/common.c
M src/bin/psql/describe.c
M src/bin/psql/large_obj.c
M src/bin/psql/print.c
M src/bin/psql/print.h
M src/bin/scripts/createlang.c
M src/bin/scripts/droplang.c
Make gincostestimate() cope with hypothetical GIN indexes.
commit : e9986a811cbed36915ce7a7bb76bca8df69ab1d5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 16:24:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 16:24:34 -0500
We tried to fetch statistics data from the index metapage, which does not
work if the index isn't actually present. If the index is hypothetical,
instead extrapolate some plausible internal statistics based on the index
page count provided by the index-advisor plugin.
There was already some code in gincostestimate() to invent internal stats
in this way, but since it was only meant as a stopgap for pre-9.1 GIN
indexes that hadn't been vacuumed since upgrading, it was pretty crude.
If we want it to support index advisors, we should try a little harder.
A small amount of testing says that it's better to estimate the entry pages
as 90% of the index, not 100%. Also, estimating the number of entries
(keys) as equal to the heap tuple count could be wildly wrong in either
direction. Instead, let's estimate 100 entries per entry page.
Perhaps someday somebody will want the index advisor to be able to provide
these numbers more directly, but for the moment this should serve.
Problem report and initial patch by Julien Rouhaud; modified by me to
invent less-bogus internal statistics. Back-patch to all supported
branches, since we've supported index advisors since 9.0.
M src/backend/utils/adt/selfuncs.c
Further tweaking of print_aligned_vertical().
commit : 181346cf9892820c94f51525d2c38684148812bf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 14:47:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 14:47:13 -0500
Don't force the data width to extend all the way to the right margin if it
doesn't need to. This reverts the behavior in non-wrapping cases to be
what it was in 9.4. Also, make the logic that ensures the data line width
is at least equal to the record-header line width a little less obscure.
In passing, avoid possible calculation of log10(0). Probably that's
harmless, given the lack of field complaints, but it seems risky:
conversion of NaN to an integer isn't well defined.
M src/bin/psql/print.c
M src/test/regress/expected/psql.out
Use "g" not "f" format in ecpg's PGTYPESnumeric_from_double().
commit : c79bdc9904afefeee495455be7dea737d714fbb4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 11:42:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 11:42:25 -0500
The previous coding could overrun the provided buffer size for a very large
input, or lose precision for a very small input. Adopt the methodology
that's been in use in the equivalent backend code for a long time.
Per private report from Bas van Schaik. Back-patch to all supported
branches.
M src/interfaces/ecpg/pgtypeslib/numeric.c
Further adjustment to psql's print_aligned_vertical() function.
commit : 6fe8ca0a2f8ac5ce2656addb0f6741b5315a8a23
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 11:07:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Dec 2015 11:07:29 -0500
We should ignore output_columns unless it's greater than zero.
A zero means we couldn't get any information from ioctl(TIOCGWINSZ);
in that case the expected behavior is to print the data at native width,
not to wrap it at the smallest possible value. print_aligned_text()
gets this consideration right, but print_aligned_vertical() lost track
of this detail somewhere along the line.
M src/bin/psql/print.c
Rework wrap-width calculation in psql's print_aligned_vertical() function.
commit : 4122ebcb1056655f23193e4632dccce68c524e43
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Nov 2015 17:53:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Nov 2015 17:53:32 -0500
This area was rather heavily whacked around in 6513633b9 and follow-on
commits, and it was showing it, because the logic to calculate the
allowable data width in wrapped expanded mode had only the vaguest
relationship to the logic that was actually printing the data. It was
not very close to being right about the conditions requiring overhead
columns to be added. Aside from being wrong, it was pretty unreadable
and under-commented. Rewrite it so it corresponds to what the printing
code actually does.
In passing, remove a couple of dead tests in the printing logic, too.
Per a complaint from Jeff Janes, though this doesn't look much like his
patch because it fixes a number of other corner-case bogosities too.
One such fix that's visible in the regression test results is that
although the code was attempting to enforce a minimum data width of
3 columns, it sometimes left less space than that available.
M src/bin/psql/print.c
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql
Avoid caching expression state trees for domain constraints across queries.
commit : e69d3a82e46461da4c3878487fb99c1294fb1d8f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 Nov 2015 18:18:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 29 Nov 2015 18:18:42 -0500
In commit 8abb3cda0ddc00a0ab98977a1633a95b97068d4e I attempted to cache
the expression state trees constructed for domain CHECK constraints for
the life of the backend (assuming the domain's constraints don't get
redefined). However, this turns out not to work very well, because
execQual.c will run those state trees with ecxt_per_query_memory pointing
to a query-lifespan context, and in some situations we'll end up with
pointers into that context getting stored into the state trees. This
happens in particular with SQL-language functions, as reported by
Emre Hasegeli, but there are many other cases.
To fix, keep only the expression plan trees for domain CHECK constraints
in the typcache's data structure, and revert to performing ExecInitExpr
(at least) once per query to set up expression state trees in the query's
context.
Eventually it'd be nice to undo this, but that will require some careful
thought about memory management for expression state trees, and it seems
far too late for any such redesign in 9.5. This way is still much more
efficient than what happened before 8abb3cda0.
M src/backend/utils/cache/typcache.c
M src/include/utils/typcache.h
M src/test/regress/expected/domain.out
M src/test/regress/sql/domain.sql
Fix failure to consider failure cases in GetComboCommandId().
commit : daefb9810807709d13ce42cc0e7220d77b368be9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Nov 2015 13:23:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Nov 2015 13:23:02 -0500
Failure to initially palloc the comboCids array, or to realloc it bigger
when needed, left combocid's data structures in an inconsistent state that
would cause trouble if the top transaction continues to execute. Noted
while examining a user complaint about the amount of memory used for this.
(There's not much we can do about that, but it does point up that repalloc
failure has a non-negligible chance of occurring here.)
In HEAD/9.5, also avoid possible invocation of memcpy() with a null pointer
in SerializeComboCIDState; cf commit 13bba0227.
M src/backend/utils/time/combocid.c
Be more paranoid about null return values from libpq status functions.
commit : 55a2cc844216838d743cae7d94bd4f38acc62d1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Nov 2015 17:31:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Nov 2015 17:31:53 -0500
PQhost() can return NULL in non-error situations, namely when a Unix-socket
connection has been selected by default. That behavior is a tad debatable
perhaps, but for the moment we should make sure that psql copes with it.
Unfortunately, do_connect() failed to: it could pass a NULL pointer to
strcmp(), resulting in crashes on most platforms. This was reported as a
security issue by ChenQin of Topsec Security Team, but the consensus of
the security list is that it's just a garden-variety bug with no security
implications.
For paranoia's sake, I made the keep_password test not trust PQuser or
PQport either, even though I believe those will never return NULL given
a valid PGconn.
Back-patch to all supported branches.
M src/bin/psql/command.c
pg_upgrade: fix CopyFile() on Windows to fail on file existence
commit : b17dbf26293e3805b5f7ab5a11a8e3f984c476ad
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 24 Nov 2015 17:18:28 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 24 Nov 2015 17:18:28 -0500
Also fix getErrorText() to return the right error string on failure.
This behavior now matches that of other operating systems.
Report by Noah Misch
Backpatch through 9.1
M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/exec.c
M src/bin/pg_upgrade/file.c
M src/bin/pg_upgrade/function.c
M src/bin/pg_upgrade/option.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/relfilenode.c
M src/bin/pg_upgrade/tablespace.c
M src/bin/pg_upgrade/util.c
M src/bin/pg_upgrade/version.c
doc: Some improvements on CREATE POLICY and ALTER POLICY documentation
commit : b542d940c308d35446e86c2bb273823303afb25c
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 23 Nov 2015 21:36:57 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 23 Nov 2015 21:36:57 -0500
M doc/src/sgml/ref/alter_policy.sgml
M doc/src/sgml/ref/create_policy.sgml
Clarify pg_rewind connection requirements.
commit : f01fcd0e41721510ca76906c670ddb051e628bc1
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 23 Nov 2015 19:30:36 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 23 Nov 2015 19:30:36 +0300
Per http://www.postgresql.org/message-id/flat/564C4CE6.9000509@postgrespro.ru
Pavel Luzanov <p.luzanov@postgrespro.ru>
M doc/src/sgml/ref/pg_rewind.sgml
doc: Add more documentation about wal_retrieve_retry_interval
commit : f1824e55137fc7a30d5ac11aafdaba533fc1a6b5
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 23 Nov 2015 09:13:44 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 23 Nov 2015 09:13:44 -0500
from Michael Paquier
M doc/src/sgml/config.sgml
Adopt the GNU convention for handling tar-archive members exceeding 8GB.
commit : 5f5e68b087e557fcddb7d28b096eead417623375
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Nov 2015 20:21:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Nov 2015 20:21:32 -0500
The POSIX standard for tar headers requires archive member sizes to be
printed in octal with at most 11 digits, limiting the representable file
size to 8GB. However, GNU tar and apparently most other modern tars
support a convention in which oversized values can be stored in base-256,
allowing any practical file to be a tar member. Adopt this convention
to remove two limitations:
* pg_dump with -Ft output format failed if the contents of any one table
exceeded 8GB.
* pg_basebackup failed if the data directory contained any file exceeding
8GB. (This would be a fatal problem for installations configured with a
table segment size of 8GB or more, and it has also been seen to fail when
large core dump files exist in the data directory.)
File sizes under 8GB are still printed in octal, so that no compatibility
issues are created except in cases that would have failed entirely before.
In addition, this patch fixes several bugs in the same area:
* In 9.3 and later, we'd defined tarCreateHeader's file-size argument as
size_t, which meant that on 32-bit machines it would write a corrupt tar
header for file sizes between 4GB and 8GB, even though no error was raised.
This broke both "pg_dump -Ft" and pg_basebackup for such cases.
* pg_restore from a tar archive would fail on tables of size between 4GB
and 8GB, on machines where either "size_t" or "unsigned long" is 32 bits.
This happened even with an archive file not affected by the previous bug.
* pg_basebackup would fail if there were files of size between 4GB and 8GB,
even on 64-bit machines.
* In 9.3 and later, "pg_basebackup -Ft" failed entirely, for any file size,
on 64-bit big-endian machines.
In view of these potential data-loss bugs, back-patch to all supported
branches, even though removal of the documented 8GB limit might otherwise
be considered a new feature rather than a bug fix.
M doc/src/sgml/ref/pg_dump.sgml
M src/backend/replication/basebackup.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_dump/pg_backup_tar.c
M src/include/pgtar.h
M src/port/tar.c
Fix handling of inherited check constraints in ALTER COLUMN TYPE (again).
commit : a35c5b7c1ffcde123b7b9b717608ed8357af870f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Nov 2015 14:55:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Nov 2015 14:55:28 -0500
The previous way of reconstructing check constraints was to do a separate
"ALTER TABLE ONLY tab ADD CONSTRAINT" for each table in an inheritance
hierarchy. However, that way has no hope of reconstructing the check
constraints' own inheritance properties correctly, as pointed out in
bug #13779 from Jan Dirk Zijlstra. What we should do instead is to do
a regular "ALTER TABLE", allowing recursion, at the topmost table that
has a particular constraint, and then suppress the work queue entries
for inherited instances of the constraint.
Annoyingly, we'd tried to fix this behavior before, in commit 5ed6546cf,
but we failed to notice that it wasn't reconstructing the pg_constraint
field values correctly.
As long as I'm touching pg_get_constraintdef_worker anyway, tweak it to
always schema-qualify the target table name; this seems like useful backup
to the protections installed by commit 5f173040.
In HEAD/9.5, get rid of get_constraint_relation_oids, which is now unused.
(I could alternatively have modified it to also return conislocal, but that
seemed like a pretty single-purpose API, so let's not pretend it has some
other use.) It's unused in the back branches as well, but I left it in
place just in case some third-party code has decided to use it.
In HEAD/9.5, also rename pg_get_constraintdef_string to
pg_get_constraintdef_command, as the previous name did nothing to explain
what that entry point did differently from others (and its comment was
equally useless). Again, that change doesn't seem like material for
back-patching.
I did a bit of re-pgindenting in tablecmds.c in HEAD/9.5, as well.
Otherwise, back-patch to all supported branches.
M src/backend/catalog/pg_constraint.c
M src/backend/commands/tablecmds.c
M src/backend/utils/adt/ruleutils.c
M src/include/catalog/pg_constraint.h
M src/include/utils/ruleutils.h
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Dodge a macro-name conflict with Perl.
commit : 8ee1a776a0c69cbd33b88f1210d1b94dfda18128
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Nov 2015 14:54:05 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Nov 2015 14:54:05 -0500
Some versions of Perl export a macro named HS_KEY. This creates a
conflict in contrib/hstore_plperl against hstore's macro of the same
name. The most future-proof solution seems to be to rename our macro;
I chose HSTORE_KEY. For consistency, rename HS_VAL and related macros
similarly.
Back-patch to 9.5. contrib/hstore_plperl doesn't exist before that
so there is no need to worry about the conflict in older releases.
Per reports from Marco Atzeri and Mike Blackwell.
M contrib/hstore/hstore.h
M contrib/hstore/hstore_compat.c
M contrib/hstore/hstore_gin.c
M contrib/hstore/hstore_gist.c
M contrib/hstore/hstore_io.c
M contrib/hstore/hstore_op.c
M contrib/hstore_plperl/hstore_plperl.c
M contrib/hstore_plpython/hstore_plpython.c
doc: Clarify some things on pg_receivexlog reference page
commit : 04f5622b63d6c368c10ea76b0187858e1468c693
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 19 Nov 2015 14:19:04 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 19 Nov 2015 14:19:04 -0500
M doc/src/sgml/ref/pg_receivexlog.sgml
Fix thinko: errmsg -> ereport.
commit : bb8b17960386e7026c4b5a63419752f310fa386a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Nov 2015 14:16:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Nov 2015 14:16:39 -0500
Silly mistake in my commit 09cecdf285ea9f51, reported by Erik Rijkers.
The fact that the buildfarm didn't find this implies that we are not
testing Perl builds that lack MULTIPLICITY, which is a bit disturbing
from a coverage standpoint. Until today I'd have said nobody cared
about such configurations anymore; but maybe not.
M src/pl/plperl/plperl.c
fix a perl typo
commit : 3f222b676d5c2fe2a7d869c80b8f840e2ae47b41
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 19 Nov 2015 02:42:02 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 19 Nov 2015 02:42:02 -0500
M src/tools/msvc/vcregress.pl
Update docs for vcregress.pl bincheck changes
commit : bfac7a69ba5d2dd9b77b9de5daa7de9920426377
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Nov 2015 23:32:16 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Nov 2015 23:32:16 -0500
M doc/src/sgml/install-windows.sgml
Improve vcregress.pl's handling of tap tests for client programs
commit : fed03032e57a3959524aaf22dd358a5cb4ad49e1
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Nov 2015 22:47:41 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 18 Nov 2015 22:47:41 -0500
The target is now named 'bincheck' rather than 'tapcheck' so that it
reflects what is checked instead of the test mechanism. Some of the
logic is improved, making it easier to add further sets of TAP based
tests in future. Also, the environment setting logic is imrpoved.
As discussed on -hackers a couple of months ago.
M src/tools/msvc/vcregress.pl
Fix incomplete set_foreignscan_references handling for fdw_recheck_quals
commit : 5021e3dac9878134ded01806807a9e17f9324425
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 18 Nov 2015 21:17:50 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 18 Nov 2015 21:17:50 -0500
KaiGai Kohei
M src/backend/optimizer/plan/setrefs.c
Improve ON CONFLICT documentation.
commit : af85779bf72e91ea43be3de8218e45d166dfe200
author : Andres Freund <andres@anarazel.de>
date : Tue, 10 Nov 2015 00:02:49 +0100
committer: Andres Freund <andres@anarazel.de>
date : Tue, 10 Nov 2015 00:02:49 +0100
Author: Peter Geoghegan and Andres Freund
Discussion: CAM3SWZScpWzQ-7EJC77vwqzZ1GO8GNmURQ1QqDQ3wRn7AbW1Cg@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced
M doc/src/sgml/ref/insert.sgml
Remove function names from some elog() calls in heapam.c.
commit : 6f8519d130e198c9e924caf678c47903ab0de8b6
author : Andres Freund <andres@anarazel.de>
date : Thu, 19 Nov 2015 01:25:58 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 19 Nov 2015 01:25:58 +0100
At least one of the names was, due to a function renaming late in the
development of ON CONFLICT, wrong. Since including function names in
error messages is against the message style guide anyway, remove them
from the messages.
Discussion: CAM3SWZT8paz=usgMVHm0XOETkQvzjRtAUthATnmaHQQY0obnGw@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced
M src/backend/access/heap/heapam.c
Accept flex > 2.5.x in configure.
commit : 659d472920e4cbc5f4c42912768e8301af036991
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Nov 2015 17:45:05 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Nov 2015 17:45:05 -0500
Per buildfarm member anchovy, 2.6.0 exists in the wild now.
Hopefully it works with Postgres; if not, we'll have to do something
about that, but in any case claiming it's "too old" is pretty silly.
M config/programs.m4
M configure
Fix possible internal overflow in numeric division.
commit : 80be41979e3ac2b17a4f985ee9249c78e3bafeb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Nov 2015 15:46:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Nov 2015 15:46:47 -0500
div_var_fast() postpones propagating carries in the same way as mul_var(),
so it has the same corner-case overflow risk we fixed in 246693e5ae8a36f0,
namely that the size of the carries has to be accounted for when setting
the threshold for executing a carry propagation step. We've not devised
a test case illustrating the brokenness, but the required fix seems clear
enough. Like the previous fix, back-patch to all active branches.
Dean Rasheed
M src/backend/utils/adt/numeric.c
Back-patch fixes to make TAP tests work on Windows.
commit : 331828b754378733cb5c2e49227603e7354e4e39
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Nov 2015 14:10:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Nov 2015 14:10:24 -0500
This back-ports commit 13d856e177e69083 and assorted followon patches
into 9.4 and 9.5. 9.5 and HEAD are now substantially identical in all
the files touched by this commit, except that 010_pg_basebackup.pl has
a few more tests related to the new --slot option. 9.4 has many fewer
TAP tests, but the test infrastructure files are substantially the same,
with the exception that 9.4 lacks the single-tmp-install infrastructure
introduced in 9.5 (commit dcae5faccab64776).
The primary motivation for this patch is to ensure that TAP test case
fixes can be back-patched without hazards of the kind seen in commits
34557f544/06dd4b44f. In principle it should also make the world safe
for running the TAP tests in the buildfarm in these branches; although
we might want to think about back-porting dcae5faccab64776 to 9.4 if
we're going to do that for real, because the TAP tests are quite disk
space hungry without it.
Michael Paquier did the back-porting work; original patches were by
him and assorted other people.
M doc/src/sgml/install-windows.sgml
M src/Makefile.global.in
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_ctl/t/002_status.pl
M src/bin/pg_rewind/RewindTest.pm
M src/bin/pg_rewind/t/004_pg_xlog_symlink.pl
M src/test/perl/SimpleTee.pm
M src/test/perl/TestLib.pm
M src/tools/msvc/clean.bat
M src/tools/msvc/vcregress.pl
Message style fix
commit : a408bd58a6746f919d96c840331707172cc2bf02
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 17 Nov 2015 06:53:07 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 17 Nov 2015 06:53:07 -0500
from Euler Taveira
M src/backend/commands/copy.c
M src/test/regress/expected/rowsecurity.out
Improve message
commit : b6a6340b170c31d4fd07d9ddae1cfac4e2200884
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 16 Nov 2015 22:26:32 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 16 Nov 2015 22:26:32 -0500
M src/bin/scripts/vacuumdb.c
Message improvements
commit : 689cabf402c33a69e595a0d25f61b1fb49fb1c78
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 16 Nov 2015 21:16:42 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 16 Nov 2015 21:16:42 -0500
M src/backend/access/transam/parallel.c
M src/backend/access/transam/xlog.c
M src/backend/catalog/objectaddress.c
M src/backend/commands/copy.c
M src/backend/commands/extension.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/libpq/auth.c
M src/backend/libpq/pqcomm.c
M src/backend/parser/parse_agg.c
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_relation.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/lmgr/lwlock.c
M src/backend/utils/adt/array_userfuncs.c
M src/backend/utils/adt/encode.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/rls.c
M src/port/win32error.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/insert_conflict.out
M src/test/regress/expected/join.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/object_address.out
M src/test/regress/expected/rowsecurity.out
doc: Fix commas and improve spacing
commit : 75c8af902e07a2090df429f410df1e753e3358f1
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 16 Nov 2015 18:59:55 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 16 Nov 2015 18:59:55 -0500
M doc/src/sgml/queries.sgml
Speed up ruleutils' name de-duplication code, and fix overlength-name case.
commit : 34d4f49bb9792c1dd3f73fcbab15df54c2402fe1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Nov 2015 13:45:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Nov 2015 13:45:17 -0500
Since commit 11e131854f8231a21613f834c40fe9d046926387, ruleutils.c has
attempted to ensure that each RTE in a query or plan tree has a unique
alias name. However, the code that was added for this could be quite slow,
even as bad as O(N^3) if N identical RTE names must be replaced, as noted
by Jeff Janes. Improve matters by building a transient hash table within
set_rtable_names. The hash table in itself reduces the cost of detecting a
duplicate from O(N) to O(1), and we can save another factor of N by storing
the number of de-duplicated names already created for each entry, so that
we don't have to re-try names already created. This way is probably a bit
slower overall for small range tables, but almost by definition, such cases
should not be a performance problem.
In principle the same problem applies to the column-name-de-duplication
code; but in practice that seems to be less of a problem, first because
N is limited since we don't support extremely wide tables, and second
because duplicate column names within an RTE are fairly rare, so that in
practice the cost is more like O(N^2) not O(N^3). It would be very much
messier to fix the column-name code, so for now I've left that alone.
An independent problem in the same area was that the de-duplication code
paid no attention to the identifier length limit, and would happily produce
identifiers that were longer than NAMEDATALEN and wouldn't be unique after
truncation to NAMEDATALEN. This could result in dump/reload failures, or
perhaps even views that silently behaved differently than before. We can
fix that by shortening the base name as needed. Fix it for both the
relation and column name cases.
In passing, check for interrupts in set_rtable_names, just in case it's
still slow enough to be an issue.
Back-patch to 9.3 where this code was introduced.
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Fix ruleutils.c's dumping of whole-row Vars in ROW() and VALUES() contexts.
commit : 0489a048d3914e4d5f89c91ac604350b9392e6fa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Nov 2015 14:41:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Nov 2015 14:41:09 -0500
Normally ruleutils prints a whole-row Var as "foo.*". We already knew that
that doesn't work at top level of a SELECT list, because the parser would
treat the "*" as a directive to expand the reference into separate columns,
not a whole-row Var. However, Joshua Yanovski points out in bug #13776
that the same thing happens at top level of a ROW() construct; and some
nosing around in the parser shows that the same is true in VALUES().
Hence, apply the same workaround already devised for the SELECT-list case,
namely to add a forced cast to the appropriate rowtype in these cases.
(The alternative of just printing "foo" was rejected because it is
difficult to avoid ambiguity against plain columns named "foo".)
Back-patch to all supported branches.
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
pg_upgrade: properly detect file copy failure on Windows
commit : fae58d5bede8b5bf3dd17381e7f6b73c1772577f
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 14 Nov 2015 11:47:11 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 14 Nov 2015 11:47:11 -0500
Previously, file copy failures were ignored on Windows due to an
incorrect return value check.
Report by Manu Joye
Backpatch through 9.1
M src/bin/pg_upgrade/file.c
M src/bin/pg_upgrade/pg_upgrade.h
Correct sepgsql docs with regard to RLS
commit : d324c7226104266bf9fd57380a0703e40ba24fd4
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 13 Nov 2015 11:06:42 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 13 Nov 2015 11:06:42 -0500
The sepgsql docs included a comment that PG doesn't support RLS. That
is only true for versions prior to 9.5.
Update the docs for 9.5 and master to say that PG supports RLS but that
sepgsql does not yet.
Pointed out by Heikki.
Back-patch to 9.5
M doc/src/sgml/sepgsql.sgml
vacuumdb: don't prompt for passwords over and over
commit : 5094da99b901df42580b6e7494d036ee4be9eb81
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 12 Nov 2015 18:05:23 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 12 Nov 2015 18:05:23 -0300
Having the script prompt for passwords over and over was a preexisting
problem when it processed multiple databases or when it processed
multiple analyze stages, but the parallel mode introduced in commit
a179232047 made it worse.
Fix the annoyance by keeping a copy of the password used by the first
connection that requires one. Since users can (currently) only have a
single password, there's no need for more complex arrangements (such as
remembering one password per database).
Per bug #13741 reported by Eric Brown. Patch authored and
cross-reviewed by Haribabu Kommi and Michael Paquier, slightly tweaked
by Álvaro Herrera.
Discussion: http://www.postgresql.org/message-id/20151027193919.931.54948@wrigleys.postgresql.org
Backpatch to 9.5, where parallel vacuumdb was introduced.
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.c
M src/bin/scripts/common.h
M src/bin/scripts/createlang.c
M src/bin/scripts/createuser.c
M src/bin/scripts/droplang.c
M src/bin/scripts/dropuser.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
commit : 747854f010b168c4f076cf44b61b100b0fe20866
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Nov 2015 13:03:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Nov 2015 13:03:52 -0500
In commit 210eb9b743c0645d I centralized libpq's logic for closing down
the backend communication socket, and made the new pqDropConnection
routine always reset the I/O buffers to empty. Many of the call sites
previously had not had such code, and while that amounted to an oversight
in some cases, there was one place where it was intentional and necessary
*not* to flush the input buffer: pqReadData should never cause that to
happen, since we probably still want to process whatever data we read.
This is the true cause of the problem Robert was attempting to fix in
c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final
ERROR message before reporting "server closed the connection unexpectedly".
But that only accidentally fixed it, by invoking parseInput before the
input buffer got flushed; and very likely there are timing scenarios
where we'd still lose the message before processing it.
To fix, pass a flag to pqDropConnection to tell it whether to flush the
input buffer or not. On review I think flushing is actually correct for
every other call site.
Back-patch to 9.3 where the problem was introduced. In HEAD, also improve
the comments added by c3e7c24a1d60dc6a.
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-protocol3.c
M src/interfaces/libpq/libpq-int.h
Do a round of copy-editing on the 9.5 release notes.
commit : a8c209fce10b5b3208451987782fd38e0a840624
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Nov 2015 19:19:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Nov 2015 19:19:14 -0500
Also fill in the previously empty "major enhancements" list. YMMV as to
which items should make the cut, but it's past time we had something more
than a placeholder here.
(I meant to get this done before beta2 was wrapped, but got distracted by
PDF build problems. Better late than never.)
M doc/src/sgml/release-9.5.sgml
Improve documentation around autovacuum-related storage parameters.
commit : bcb8f96e6775c649564ac0fb946ab6a1629ff969
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Nov 2015 17:13:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 11 Nov 2015 17:13:38 -0500
These were discussed in three different sections of the manual, which
unsurprisingly had diverged over time; and the descriptions of individual
variables lacked stylistic consistency even within each section (and
frequently weren't in very good English anyway). Clean up the mess, and
remove some of the redundant information in hopes that future additions
will be less likely to re-introduce inconsistency. For instance I see
no need for maintenance.sgml to include its very own list of all the
autovacuum storage parameters, especially since that list was already
incomplete.
M doc/src/sgml/config.sgml
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/ref/create_table.sgml
Docs: fix misleading example.
commit : 0819778c43e3bc19364c541c3ea099b5c3b7d224
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Nov 2015 22:11:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Nov 2015 22:11:39 -0500
Commit 8457d0beca731bf0 introduced an example which, while not incorrect,
failed to exhibit the behavior it meant to describe, as a result of omitting
an E'' prefix that needed to be there. Noticed and fixed by Peter Geoghegan.
I (tgl) failed to resist the temptation to wordsmith nearby text a bit
while at it.
M doc/src/sgml/datatype.sgml
Improve our workaround for 'TeX capacity exceeded' in building PDF files.
commit : 8d20eaa62b943bd155013aa01e0d6909bf520be0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Nov 2015 15:59:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Nov 2015 15:59:59 -0500
In commit a5ec86a7c787832d28d5e50400ec96a5190f2555 I wrote a quick hack
that reduced the number of TeX string pool entries created while converting
our documentation to PDF form. That held the fort for awhile, but as of
HEAD we're back up against the same limitation. It turns out that the
original coding of \FlowObjectSetup actually results in *three* string pool
entries being generated for every "flow object" (that is, potential
cross-reference target) in the documentation, and my previous hack only got
rid of one of them. With a little more care, we can reduce the string
count to one per flow object plus one per actually-cross-referenced flow
object (about 115000 + 5000 as of current HEAD); that should work until
the documentation volume roughly doubles from where it is today.
As a not-incidental side benefit, this change also causes pdfjadetex to
stop emitting unreferenced hyperlink anchors (bookmarks) into the PDF file.
It had been making one willy-nilly for every flow object; now it's just one
per actually-cross-referenced object. This results in close to a 2X
savings in PDF file size. We will still want to run the output through
"jpdftweak" to get it to be compressed; but we no longer need removal of
unreferenced bookmarks, so we might be able to find a quicker tool for
that step.
Although the failure only affects HEAD and US-format output at the moment,
9.5 cannot be more than a few pages short of failing likewise, so it
will inevitably fail after a few rounds of minor-version release notes.
I don't have a lot of faith that we'll never hit the limit in the older
branches; and anyway it would be nice to get rid of jpdftweak across the
board. Therefore, back-patch to all supported branches.
M doc/src/sgml/jadetex.cfg
Stamp 9.5beta2.
commit : eb66ee639e79b9ec85d877746aaca315ca82c2a4
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 9 Nov 2015 14:53:52 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 9 Nov 2015 14:53:52 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
Translation updates
commit : 289da0a7a59f60efa1baeadaca750ef2bdb97c78
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 9 Nov 2015 10:21:11 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 9 Nov 2015 10:21:11 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: cd263526676705b4a8a3a708c9842461c4a2bcc3
M src/backend/po/de.po
M src/backend/po/ru.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/de.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/preproc/po/pt_BR.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/ru.po
Add paragraph about ON CONFLICT interaction with partitioning.
commit : 90e074baec2f052120271437a72d2ef6d1de1696
author : Andres Freund <andres@anarazel.de>
date : Mon, 9 Nov 2015 05:08:56 +0100
committer: Andres Freund <andres@anarazel.de>
date : Mon, 9 Nov 2015 05:08:56 +0100
Author: Peter Geoghegan and Andres Freund
Discussion: CAM3SWZScpWzQ-7EJC77vwqzZ1GO8GNmURQ1QqDQ3wRn7AbW1Cg@mail.gmail.com,
CAHGQGwFUCWwSU7dtc2aRdRk73ztyr_jY5cPOyts+K8xKJ92X4Q@mail.gmail.com
Backpatch: 9.5, where UPSERT was introduced
M doc/src/sgml/ddl.sgml
Set replication origin when decoding commit records.
commit : 04c0b63365c7d4ee584300737afe6ef7df3b1253
author : Andres Freund <andres@anarazel.de>
date : Sun, 8 Nov 2015 23:01:53 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 8 Nov 2015 23:01:53 +0100
By accident the replication origin was not set properly in
DecodeCommit(). That's bad because the origin is passed to the output
plugins origin filter, and accessible from the output plugin via
ReorderBufferTXN->origin_id. Accessing the origin of individual changes
worked before the fix, which is why this wasn't notices earlier.
Reported-By: Craig Ringer
Author: Craig Ringer
Discussion: CAMsr+YFhBJLp=qfSz3-J+0P1zLkE8zNXM2otycn20QRMx380gw@mail.gmail.com
Backpatch: 9.5, where replication origins where introduced
M src/backend/replication/logical/decode.c
Fix 9.5 version of previous commit to match its log message.
commit : 40c28678aa65308f27347cd218a09fdc92c483ef
author : Noah Misch <noah@leadboat.com>
date : Sun, 8 Nov 2015 17:40:19 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 8 Nov 2015 17:40:19 -0500
M src/bin/pg_ctl/pg_ctl.c
Don't connect() to a wildcard address in test_postmaster_connection().
commit : bdb42bac3c96a5affe5e476a56b85562b2ed0da9
author : Noah Misch <noah@leadboat.com>
date : Sun, 8 Nov 2015 17:28:53 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 8 Nov 2015 17:28:53 -0500
At least OpenBSD, NetBSD, and Windows don't support it. This repairs
pg_ctl for listen_addresses='0.0.0.0' and listen_addresses='::'. Since
pg_ctl prefers to test a Unix-domain socket, Windows users are most
likely to need this change. Back-patch to 9.1 (all supported versions).
This could change pg_ctl interaction with loopback-interface firewall
rules. Therefore, in 9.4 and earlier (released branches), activate the
change only on known-affected platforms.
Reported (bug #13611) and designed by Kondo Yuta.
M src/bin/pg_ctl/pg_ctl.c
Update 9.5 release notes through today.
commit : 5daafafe74e23f9e6a8971820b4233565a837b77
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Nov 2015 17:09:04 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Nov 2015 17:09:04 -0500
M doc/src/sgml/release-9.5.sgml
Rename PQsslAttributes() to PQsslAttributeNames(), and const-ify fully.
commit : ab994cc00ec3e3700b2e62de9777d410fbb6ae84
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Nov 2015 16:13:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Nov 2015 16:13:49 -0500
Per discussion, the original name was a bit misleading, and
PQsslAttributeNames() seems more apropos. It's not quite too late to
change this in 9.5, so let's change it while we can.
Also, make sure that the pointer array is const, not only the pointed-to
strings.
Minor documentation wordsmithing while at it.
Lars Kanis, slight adjustments by me
M doc/src/sgml/libpq.sgml
M doc/src/sgml/release-9.5.sgml
M src/interfaces/libpq/exports.txt
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/fe-secure.c
M src/interfaces/libpq/libpq-fe.h
Fix enforcement of restrictions inside regexp lookaround constraints.
commit : 44fc25153681f0d3814275926f3c626a3f283cc2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Nov 2015 12:43:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Nov 2015 12:43:24 -0500
Lookahead and lookbehind constraints aren't allowed to contain backrefs,
and parentheses within them are always considered non-capturing. Or so
says the manual. But the regexp parser forgot about these rules once
inside a parenthesized subexpression, so that constructs like (\w)(?=(\1))
were accepted (but then not correctly executed --- a case like this acted
like (\w)(?=\w), without any enforcement that the two \w's match the same
text). And in (?=((foo))) the innermost parentheses would be counted as
capturing parentheses, though no text would ever be captured for them.
To fix, properly pass down the "type" argument to the recursive invocation
of parse().
Back-patch to all supported branches; it was agreed that silent
misexecution of such patterns is worse than throwing an error, even though
new errors in minor releases are generally not desirable.
M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Set include_realm=1 default in parse_hba_line
commit : 695012a0d585844130bf3d82ad0b4ebe0b7bf581
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 6 Nov 2015 11:18:33 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 6 Nov 2015 11:18:33 -0500
With include_realm=1 being set down in parse_hba_auth_opt, if multiple
options are passed on the pg_hba line, such as:
host all all 0.0.0.0/0 gss include_realm=0 krb_realm=XYZ.COM
We would mistakenly reset include_realm back to 1. Instead, we need to
set include_realm=1 up in parse_hba_line, prior to parsing any of the
additional options.
Discovered by Jeff McCormick during testing.
Bug introduced by 9a08841.
Back-patch to 9.5
M src/backend/libpq/hba.c
Fix erroneous hash calculations in gin_extract_jsonb_path().
commit : 4d867458fce3743adc95ad6513c9d2dea87cd7f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Nov 2015 18:15:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Nov 2015 18:15:48 -0500
The jsonb_path_ops code calculated hash values inconsistently in some cases
involving nested arrays and objects. This would result in queries possibly
not finding entries that they should find, when using a jsonb_path_ops GIN
index for the search. The problem cases involve JSONB values that contain
both scalars and sub-objects at the same nesting level, for example an
array containing both scalars and sub-arrays. To fix, reset the current
stack->hash after processing each value or sub-object, not before; and
don't try to be cute about the outermost level's initial hash.
Correcting this means that existing jsonb_path_ops indexes may now be
inconsistent with the new hash calculation code. The symptom is the same
--- searches not finding entries they should find --- but the specific
rows affected are likely to be different. Users will need to REINDEX
jsonb_path_ops indexes to make sure that all searches work as expected.
Per bug #13756 from Daniel Cheng. Back-patch to 9.4 where the faulty
logic was introduced.
M src/backend/utils/adt/jsonb_gin.c
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/jsonb.sql
Pass extra data to bgworkers, and use this to fix parallel contexts.
commit : c98605cc47fe42fac5f685d611db2a0c1afa2fcf
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 5 Nov 2015 12:05:38 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 5 Nov 2015 12:05:38 -0500
Up until now, the total amount of data that could be passed to a
background worker at startup was one datum, which can be a small as
4 bytes on some systems. That's enough to pass a dsm_handle or an
array index, but not much else. Add a bgw_extra flag to the
BackgroundWorker struct, allowing up to 128 bytes to be passed to
a new worker on any platform.
Use this to fix a problem I recently discovered with the parallel
context machinery added in 9.5: the master assigns each worker an
array index, and each worker subsequently assigns itself an array
index, and there's nothing to guarantee that the two sets of indexes
match, leading to chaos.
Normally, I would not back-patch the change to add bgw_extra, since it
is basically a feature addition. However, since 9.5 is still in beta
and there seems to be no other sensible way to repair the broken
parallel context machinery, back-patch to 9.5. Existing background
worker code can ignore the bgw_extra field without a problem, but
might need to be recompiled since the structure size has changed.
Report and patch by me. Review by Amit Kapila.
M doc/src/sgml/bgworker.sgml
M src/backend/access/transam/parallel.c
M src/backend/postmaster/bgworker.c
M src/include/postmaster/bgworker.h
Improve comments about abbreviation abort.
commit : 1d97b25501470716f5b93b1083d865bb5508b880
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Nov 2015 14:11:49 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Nov 2015 14:11:49 -0500
Peter Geoghegan
M src/backend/utils/sort/tuplesort.c
Remove obsolete advice about doubling backslashes in regex escapes.
commit : fdae4a93e9df6b9b0f0ef5b0ccff697e4859710f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Nov 2015 11:57:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Nov 2015 11:57:56 -0500
Standard-conforming literals have been the default for long enough that
it no longer seems necessary to go out of our way to tell people to write
regex escapes illegibly.
M doc/src/sgml/func.sgml
Code + docs review for unicode linestyle patch.
commit : f4057cdffc355f5d4a9d8411fb953069be6d72ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Nov 2015 11:49:21 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Nov 2015 11:49:21 -0500
Fix some brain fade in commit a2dabf0e1dda93c8: erroneous variable names
in docs, rearrangements that made sentences less clear not more so,
undocumented and poorly-chosen-anyway API behaviors of subroutines,
bad grammar in error messages, copy-and-paste faults.
Albe Laurenz and Tom Lane
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/release-9.5.sgml
M src/bin/psql/command.c
shm_mq: Third attempt at fixing nowait behavior in shm_mq_receive.
commit : fd5ce6b89b63bdb9632a925a80f6f7d4e7bd2e00
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Nov 2015 09:12:52 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Nov 2015 09:12:52 -0500
Commit a1480ec1d3bacb9acb08ec09f22bc25bc033115b purported to fix the
problems with commit b2ccb5f4e6c81305386edb34daf7d1d1e1ee112a, but it
didn't completely fix them. The problem is that the checks were
performed in the wrong order, leading to a race condition. If the
sender attached, sent a message, and detached after the receiver
called shm_mq_get_sender and before the receiver called
shm_mq_counterparty_gone, we'd incorrectly return SHM_MQ_DETACHED
before all messages were read. Repair by reversing the order of
operations, and add a long comment explaining why this new logic is
(hopefully) correct.
M src/backend/storage/ipc/shm_mq.c
Add RMV to list of commands taking AE lock.
commit : 67d4738d934e9df455d2f67b2617423319b377d5
author : Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 2 Nov 2015 06:26:28 -0600
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 2 Nov 2015 06:26:28 -0600
Backpatch to 9.3, where it was initially omitted.
Craig Ringer, with minor adjustment by Kevin Grittner
M doc/src/sgml/mvcc.sgml
Fix serialization anomalies due to race conditions on INSERT.
commit : 50ca917d911485aa696a30943fda98f41ff92206
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 31 Oct 2015 14:42:46 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 31 Oct 2015 14:42:46 -0500
On insert the CheckForSerializableConflictIn() test was performed
before the page(s) which were going to be modified had been locked
(with an exclusive buffer content lock). If another process
acquired a relation SIReadLock on the heap and scanned to a page on
which an insert was going to occur before the page was so locked,
a rw-conflict would be missed, which could allow a serialization
anomaly to be missed. The window between the check and the page
lock was small, so the bug was generally not noticed unless there
was high concurrency with multiple processes inserting into the
same table.
This was reported by Peter Bailis as bug #11732, by Sean Chittenden
as bug #13667, and by others.
The race condition was eliminated in heap_insert() by moving the
check down below the acquisition of the buffer lock, which had been
the very next statement. Because of the loop locking and unlocking
multiple buffers in heap_multi_insert() a check was added after all
inserts were completed. The check before the start of the inserts
was left because it might avoid a large amount of work to detect a
serialization anomaly before performing the all of the inserts and
the related WAL logging.
While investigating this bug, other SSI bugs which were even harder
to hit in practice were noticed and fixed, an unnecessary check
(covered by another check, so redundant) was removed from
heap_update(), and comments were improved.
Back-patch to all supported branches.
Kevin Grittner and Thomas Munro
M src/backend/access/heap/heapam.c
M src/backend/storage/lmgr/predicate.c
doc: security_barrier option is a Boolean, not a string.
commit : 21e634e4b23309ec33dfa27854c0b9901859dda3
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 30 Oct 2015 12:18:55 +0100
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 30 Oct 2015 12:18:55 +0100
Mistake introduced by commit 5bd91e3a835b5d5499fee5f49fc7c0c776fe63dd.
Hari Babu
M doc/src/sgml/ref/create_view.sgml
Fix typo in bgworker.c
commit : 7852f73bdfe6022c9b23abc950fec63d0d1f4582
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 30 Oct 2015 10:35:33 +0100
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 30 Oct 2015 10:35:33 +0100
M src/backend/postmaster/bgworker.c
Docs: add example clarifying use of nested JSON containment.
commit : 9a1a22980d3650e6e232bc4423ec74bfc6d0e7be
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Oct 2015 18:54:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Oct 2015 18:54:35 -0400
Show how this can be used in practice to make queries simpler and more
flexible. Also, draw an explicit contrast to the existence operator,
which doesn't work that way.
Peter Geoghegan and Tom Lane
M doc/src/sgml/json.sgml
Message style improvements
commit : 0bc3071796b33288cd912db196b90c76fa394c21
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 28 Oct 2015 20:23:53 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 28 Oct 2015 20:23:53 -0400
Message style, plurals, quoting, spelling, consistency with similar
messages
M contrib/test_decoding/expected/binary.out
M src/backend/access/transam/multixact.c
M src/backend/catalog/dependency.c
M src/backend/catalog/objectaddress.c
M src/backend/commands/copy.c
M src/backend/commands/matview.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/vacuumlazy.c
M src/backend/executor/execMain.c
M src/backend/parser/parse_clause.c
M src/backend/replication/logical/logicalfuncs.c
M src/backend/replication/logical/origin.c
M src/backend/replication/logical/snapbuild.c
M src/backend/replication/slot.c
M src/backend/tcop/postgres.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/misc.c
M src/bin/psql/command.c
M src/test/modules/test_rls_hooks/expected/test_rls_hooks.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/matview.out
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/updatable_views.out
Add missing serial comma, for consistency.
commit : d17d5125f68da155e3a8e555c0699b7679b06e3b
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 28 Oct 2015 12:19:14 +0100
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 28 Oct 2015 12:19:14 +0100
Amit Langote, per Etsuro Fujita
M src/backend/commands/tablecmds.c
Fix incorrect message in ATWrongRelkindError.
commit : e53e2a196887a60481bd0bb1b316062027c5f24d
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 28 Oct 2015 11:44:47 +0100
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 28 Oct 2015 11:44:47 +0100
Mistake introduced by commit 3bf3ab8c563699138be02f9dc305b7b77a724307.
Etsuro Fujita
M src/backend/commands/tablecmds.c
Fix secondary expected output for commit_ts test
commit : c56949168cc0aeac703865c3239f7bc7ca670402
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 23:02:04 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 23:02:04 -0300
Per red wall in buildfarm
M src/test/modules/commit_ts/expected/commit_timestamp_1.out
Document BRIN's inclusion opclass framework
commit : 3e9e03353966efa5cae5f927a77ba64a93f1ee8c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 19:03:15 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 19:03:15 -0300
Backpatch to 9.5 -- this should have been part of b0b7be61337, but we
didn't have 38b03caebc5de either at the time.
Author: Emre Hasegeli
Revised by: Ian Barwick
Discussion:
http://www.postgresql.org/message-id/CAE2gYzyB39Q9up_-TO6FKhH44pcAM1x6n_Cuj15qKoLoFihUVg@mail.gmail.com
http://www.postgresql.org/message-id/562DA711.3020305@2ndquadrant.com
M doc/src/sgml/brin.sgml
Fix BRIN free space computations
commit : cf42abcc653817849398b62c321de654ea2b28cc
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 18:17:55 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 18:17:55 -0300
A bug in the original free space computation made it possible to
return a page which wasn't actually able to fit the item. Since the
insertion code isn't prepared to deal with PageAddItem failing, a PANIC
resulted ("failed to add BRIN tuple [to new page]"). Add a macro to
encapsulate the correct computation, and use it in
brin_getinsertbuffer's callers before calling that routine, to raise an
early error.
I became aware of the possiblity of a problem in this area while working
on ccc4c074994d734. There's no archived discussion about it, but it's
easy to reproduce a problem in the unpatched code with something like
CREATE TABLE t (a text);
CREATE INDEX ti ON t USING brin (a) WITH (pages_per_range=1);
for length in `seq 8000 8196`
do
psql -f - <<EOF
TRUNCATE TABLE t;
INSERT INTO t VALUES ('z'), (repeat('a', $length));
EOF
done
Backpatch to 9.5, where BRIN was introduced.
M src/backend/access/brin/brin_pageops.c
Cleanup commit timestamp module activaction, again
commit : 68cc162e454a166a2a6ca992aeb759edcc56adc3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 15:06:50 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 15:06:50 -0300
Further tweak commit_ts.c so that on a standby the state is completely
consistent with what that in the master, rather than behaving
differently in the cases that the settings differ. Now in standby and
master the module should always be active or inactive in lockstep.
Author: Petr Jelínek, with some further tweaks by Álvaro Herrera.
Backpatch to 9.5, where commit timestamps were introduced.
Discussion: http://www.postgresql.org/message-id/5622BF9D.2010409@2ndquadrant.com
M src/backend/access/transam/commit_ts.c
M src/backend/commands/vacuum.c
M src/include/access/commit_ts.h
Measure string lengths only once
commit : 80ae841f2f0c51ea766a75f4abe73c0c48e4ab0c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 13:20:40 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Oct 2015 13:20:40 -0300
Bernd Helmle complained that CreateReplicationSlot() was assigning the
same value to the same variable twice, so we could remove one of them.
Code inspection reveals that we can actually remove both assignments:
according to the author the assignment was there for beauty of the
strlen line only, and another possible fix to that is to put the strlen
in its own line, so do that.
To be consistent within the file, refactor all duplicated strlen()
calls, which is what we do elsewhere in the backend anyway. In
basebackup.c, snprintf already returns the right length; no need for
strlen afterwards.
Backpatch to 9.4, where replication slots were introduced, to keep code
identical. Some of this is older, but the patch doesn't apply cleanly
and it's only of cosmetic value anyway.
Discussion: http://www.postgresql.org/message-id/BE2FD71DEA35A2287EA5F018@eje.credativ.lan
M src/backend/replication/basebackup.c
M src/backend/replication/walsender.c
shm_mq: Repair breakage from previous commit.
commit : 44390e30f8531906ed142336f84f172b93073038
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Oct 2015 22:01:11 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Oct 2015 22:01:11 -0400
If the counterparty writes some data into the queue and then detaches,
it's wrong to return SHM_MQ_DETACHED right away. If we do that, we
fail to read whatever was written.
M src/backend/storage/ipc/shm_mq.c
Add two missing cases to ATWrongRelkindError.
commit : 17b07afae341c05f2dae1b6c588df6b267e699f2
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Oct 2015 17:00:53 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Oct 2015 17:00:53 -0400
This way, we produce a better error message if someone tries to do
something like ALTER INDEX .. ALTER COLUMN .. SET STORAGE.
Amit Langote
M src/backend/commands/tablecmds.c
shm_mq: Fix failure to notice a dead counterparty when nowait is used.
commit : ac9a01615c5d45eb08e5b78c3d0155214e0ab498
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Oct 2015 16:33:30 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Oct 2015 16:33:30 -0400
The shm_mq mechanism was intended to optionally notice when the process
on the other end of the queue fails to attach to the queue. It does
this by allowing the user to pass a BackgroundWorkerHandle; if the
background worker in question is launched and dies without attaching
to the queue, then we know it never will. This logic works OK in
blocking mode, but when called with nowait = true we fail to notice
that this has happened due to an asymmetry in the logic. Repair.
Reported off-list by Rushabh Lathia. Patch by me.
M src/backend/storage/ipc/shm_mq.c
doc: Add advice on updating checkpoint_segments to max_wal_size
commit : 85e30f57cb33294107fc17704a5d8874439e0ae5
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 22 Oct 2015 13:59:58 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 22 Oct 2015 13:59:58 -0400
with suggestion from Michael Paquier
M doc/src/sgml/release-9.5.sgml
Fix incorrect translation of minus-infinity datetimes for json/jsonb.
commit : 5fb20a5ba6ce963ad529224ff5359aa1731c4068
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Oct 2015 11:06:24 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Oct 2015 11:06:24 -0700
Commit bda76c1c8cfb1d11751ba6be88f0242850481733 caused both plus and
minus infinity to be rendered as "infinity", which is not only wrong
but inconsistent with the pre-9.4 behavior of to_json(). Fix that by
duplicating the coding in date_out/timestamp_out/timestamptz_out more
closely. Per bug #13687 from Stepan Perlov. Back-patch to 9.4, like
the previous commit.
In passing, also re-pgindent json.c, since it had gotten a bit messed up by
recent patches (and I was already annoyed by indentation-related problems
in back-patching this fix ...)
M src/backend/utils/adt/date.c
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/timestamp.c
M src/include/utils/date.h
M src/include/utils/datetime.h
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
doc: Move documentation of max_wal_size to better position
commit : 2bfd2fe58db88abf86a920fe532b80cf2ea84a7f
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 20 Oct 2015 13:33:39 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 20 Oct 2015 13:33:39 -0400
M doc/src/sgml/config.sgml
Fix incorrect comment in plannodes.h
commit : b3967f89370755176f4da03fb042e7e3e45999b5
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 20 Oct 2015 11:11:35 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 20 Oct 2015 11:11:35 -0400
Etsuro Fujita
M src/include/nodes/plannodes.h
Put back ssl_renegotiation_limit parameter, but only allow 0.
commit : b06f1f286d5b9beb10cf7dc365cdb7150064e191
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 20 Oct 2015 09:56:04 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 20 Oct 2015 09:56:04 -0400
Per a report from Shay Rojansky, Npgsql sends ssl_renegotiation_limit=0
in the startup packet because it does not support renegotiation; other
clients which have not attempted to support renegotiation might well
behave similarly. The recent removal of this parameter forces them to
break compatibility with either current PostgreSQL versions, or
previous ones. Per discussion, the best solution is to accept the
parameter but only allow a value of 0.
Shay Rojansky, edited a little by me.
M src/backend/utils/misc/guc.c
Fix back-patch of commit 8e3b4d9d40244c037bbc6e182ea3fabb9347d482.
commit : ed6c516728c695477c5b6140ce80bc12641f72e2
author : Noah Misch <noah@leadboat.com>
date : Tue, 20 Oct 2015 00:57:25 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 20 Oct 2015 00:57:25 -0400
master emits an extra context message compared to 9.5 and earlier.
M src/test/regress/expected/plpgsql.out
Eschew "RESET statement_timeout" in tests.
commit : 01a96c77d638aad0d9d5b040ed62248481d3b5a0
author : Noah Misch <noah@leadboat.com>
date : Tue, 20 Oct 2015 00:37:22 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 20 Oct 2015 00:37:22 -0400
Instead, use transaction abort. Given an unlucky bout of latency, the
timeout would cancel the RESET itself. Buildfarm members gharial,
lapwing, mereswine, shearwater, and sungazer witness that. Back-patch
to 9.1 (all supported versions). The query_canceled test still could
timeout before entering its subtransaction; for whatever reason, that
has yet to happen on the buildfarm.
M src/test/regress/expected/plpgsql.out
M src/test/regress/expected/prepared_xacts.out
M src/test/regress/expected/prepared_xacts_1.out
M src/test/regress/sql/plpgsql.sql
M src/test/regress/sql/prepared_xacts.sql
Fix incorrect handling of lookahead constraints in pg_regprefix().
commit : 43e36f8dd065ee2d73d0b010488e624b7e509c3f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Oct 2015 13:54:53 -0700
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Oct 2015 13:54:53 -0700
pg_regprefix was doing nothing with lookahead constraints, which would
be fine if it were the right kind of nothing, but it isn't: we have to
terminate our search for a fixed prefix, not just pretend the LACON arc
isn't there. Otherwise, if the current state has both a LACON outarc and a
single plain-color outarc, we'd falsely conclude that the color represents
an addition to the fixed prefix, and generate an extracted index condition
that restricts the indexscan too much. (See added regression test case.)
Terminating the search is conservative: we could traverse the LACON arc
(thus assuming that the constraint can be satisfied at runtime) and then
examine the outarcs of the linked-to state. But that would be a lot more
work than it seems worth, because writing a LACON followed by a single
plain character is a pretty silly thing to do.
This makes a difference only in rather contrived cases, but it's a bug,
so back-patch to all supported branches.
M src/backend/regex/regprefix.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Fix order of arguments in ecpg generated typedef command.
commit : 93726145434c593770e51c129737342fb3634b8a
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 16 Oct 2015 17:29:05 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 16 Oct 2015 17:29:05 +0200
M src/interfaces/ecpg/preproc/ecpg.trailer
Miscellaneous cleanup of regular-expression compiler.
commit : 6a7a2ee77731fa21ef10a6f1cb7c3df727632d5d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 15:52:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 15:52:12 -0400
Revert our previous addition of "all" flags to copyins() and copyouts();
they're no longer needed, and were never anything but an unsightly hack.
Improve a couple of infelicities in the REG_DEBUG code for dumping
the NFA data structure, including adding code to count the total
number of states and arcs.
Add a couple of missed error checks.
Add some more documentation in the README file, and some regression tests
illustrating cases that exceeded the state-count limit and/or took
unreasonable amounts of time before this set of patches.
Back-patch to all supported branches.
M src/backend/regex/README
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Improve memory-usage accounting in regular-expression compiler.
commit : e91cfdead776111b62c3a4f36974544f4136421b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 15:36:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 15:36:17 -0400
This code previously counted the number of NFA states it created, and
complained if a limit was exceeded, so as to prevent bizarre regex patterns
from consuming unreasonable time or memory. That's fine as far as it went,
but the code paid no attention to how many arcs linked those states. Since
regexes can be contrived that have O(N) states but will need O(N^2) arcs
after fixempties() processing, it was still possible to blow out memory,
and take a long time doing it too. To fix, modify the bookkeeping to count
space used by both states and arcs.
I did not bother with including the "color map" in the accounting; it
can only grow to a few megabytes, which is not a lot in comparison to
what we're allowing for states+arcs (about 150MB on 64-bit machines
or half that on 32-bit machines).
Looking at some of the larger real-world regexes captured in the Tcl
regression test suite suggests that the most that is likely to be needed
for regexes found in the wild is under 10MB, so I believe that the current
limit has enough headroom to make it okay to keep it as a hard-wired limit.
In connection with this, redefine REG_ETOOBIG as meaning "regular
expression is too complex"; the previous wording of "nfa has too many
states" was already somewhat inapropos because of the error code's use
for stack depth overrun, and it was not very user-friendly either.
Back-patch to all supported branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/include/regex/regerrs.h
M src/include/regex/regex.h
M src/include/regex/regguts.h
Improve performance of pullback/pushfwd in regular-expression compiler.
commit : 1bb0fbca39b447d1ce6da5f6bcf9f468a6346a08
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 15:11:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 15:11:49 -0400
The previous coding would create a new intermediate state every time it
wanted to interchange the ordering of two constraint arcs. Certain regex
features such as \Y can generate large numbers of parallel constraint arcs,
and if we needed to reorder the results of that, we created unreasonable
numbers of intermediate states. To improve matters, keep a list of
already-created intermediate states associated with the state currently
being considered by the outer loop; we can re-use such states to place all
the new arcs leading to the same destination or source.
I also took the trouble to redefine push() and pull() to have a less risky
API: they no longer delete any state or arc that the caller might possibly
have a pointer to, except for the specifically-passed constraint arc.
This reduces the risk of re-introducing the same type of error seen in
the failed patch for CVE-2007-4772.
Back-patch to all supported branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
Improve performance of fixempties() pass in regular-expression compiler.
commit : e9cf3dc30a4ed82f2c284240841678db15491669
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 14:58:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 14:58:10 -0400
The previous coding took something like O(N^4) time to fully process a
chain of N EMPTY arcs. We can't really do much better than O(N^2) because
we have to insert about that many arcs, but we can do lots better than
what's there now. The win comes partly from using mergeins() to amortize
de-duplication of arcs across multiple source states, and partly from
exploiting knowledge of the ordering of arcs for each state to avoid
looking at arcs we don't need to consider during the scan. We do have
to be a bit careful of the possible reordering of arcs introduced by
the sort-merge coding of the previous commit, but that's not hard to
deal with.
Back-patch to all supported branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
Fix O(N^2) performance problems in regular-expression compiler.
commit : cff9e0659e8b79d4e075d30f04dac5a5587b8ac2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 14:43:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 14:43:17 -0400
Change the singly-linked in-arc and out-arc lists to be doubly-linked,
so that arc deletion is constant time rather than having worst-case time
proportional to the number of other arcs on the connected states.
Modify the bulk arc transfer operations copyins(), copyouts(), moveins(),
moveouts() so that they use a sort-and-merge algorithm whenever there's
more than a small number of arcs to be copied or moved. The previous
method is O(N^2) in the number of arcs involved, because it performs
duplicate checking independently for each copied arc. The new method may
change the ordering of existing arcs for the destination state, but nothing
really cares about that.
Provide another bulk arc copying method mergeins(), which is unused as
of this commit but is needed for the next one. It basically is like
copyins(), but the source arcs might not all come from the same state.
Replace the O(N^2) bubble-sort algorithm used in carcsort() with a qsort()
call.
These changes greatly improve the performance of regex compilation for
large or complex regexes, at the cost of extra space for arc storage during
compilation. The original tradeoff was probably fine when it was made, but
now we care more about speed and less about memory consumption.
Back-patch to all supported branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/include/regex/regguts.h
Fix regular-expression compiler to handle loops of constraint arcs.
commit : 0889e1857f07dea110e07fd7634af1ea773df951
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 14:14:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Oct 2015 14:14:41 -0400
It's possible to construct regular expressions that contain loops of
constraint arcs (that is, ^ $ AHEAD BEHIND or LACON arcs). There's no use
in fully traversing such a loop at execution, since you'd just end up in
the same NFA state without having consumed any input. Worse, such a loop
leads to infinite looping in the pullback/pushfwd stage of compilation,
because we keep pushing or pulling the same constraints around the loop
in a vain attempt to move them to the pre or post state. Such looping was
previously recognized in CVE-2007-4772; but the fix only handled the case
of trivial single-state loops (that is, a constraint arc leading back to
its source state) ... and not only that, it was incorrect even for that
case, because it broke the admittedly-not-very-clearly-stated API contract
of the pull() and push() subroutines. The first two regression test cases
added by this commit exhibit patterns that result in assertion failures
because of that (though there seem to be no ill effects in non-assert
builds). The other new test cases exhibit multi-state constraint loops;
in an unpatched build they will run until the NFA state-count limit is
exceeded.
To fix, remove the code added for CVE-2007-4772, and instead create a
general-purpose constraint-loop-breaking phase of regex compilation that
executes before we do pullback/pushfwd. Since we never need to traverse
a constraint loop fully, we can just break the loop at any chosen spot,
if we add clone states that can replicate any sequence of arc transitions
that would've traversed just part of the loop.
Also add some commentary clarifying why we have to have all these
machinations in the first place.
This class of problems has been known for some time --- we had a report
from Marc Mamin about two years ago, for example, and there are related
complaints in the Tcl bug tracker. I had discussed a fix of this kind
off-list with Henry Spencer, but didn't get around to doing something
about it until the issue was rediscovered by Greg Stark recently.
Back-patch to all supported branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Remove cautions about using volatile from spin.h.
commit : 22884414cbac345c9143738634123f76e61ca343
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 14:06:22 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 14:06:22 -0400
Commit 0709b7ee72e4bc71ad07b7120acd117265ab51d0 obsoleted this comment
but neglected to update it.
Thomas Munro
M src/include/storage/spin.h
Fix a problem with parallel workers being unable to restore role.
commit : 73d71cde5751e06d372431178e740835284eb132
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 11:37:19 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 11:37:19 -0400
check_role() tries to verify that the user has permission to become the
requested role, but this is inappropriate in a parallel worker, which
needs to exactly recreate the master's authorization settings. So skip
the check in that case.
This fixes a bug in commit 924bcf4f16d54c55310b28f77686608684734f42.
M src/backend/access/transam/parallel.c
M src/backend/commands/variable.c
M src/include/access/parallel.h
Invalidate caches after cranking up a parallel worker transaction.
commit : 14129d1c9e2d3afa064651012a55c9c84aa6821a
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 11:31:23 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 11:31:23 -0400
Starting a parallel worker transaction changes our notion of which XIDs
are in-progress or committed, and our notion of the current command
counter ID. Therefore, our view of these caches prior to starting
this transaction may no longer valid. Defend against that by clearing
them.
This fixes a bug in commit 924bcf4f16d54c55310b28f77686608684734f42.
M src/backend/access/transam/parallel.c
Tighten up application of parallel mode checks.
commit : d43e3adc7572d34988967475900dcd4f9e0a7b89
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 09:59:57 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 09:59:57 -0400
Commit 924bcf4f16d54c55310b28f77686608684734f42 failed to enforce
parallel mode checks during the commit of a parallel worker, because
we exited parallel mode prior to ending the transaction so that we
could pop the active snapshot. Re-establish parallel mode during
parallel worker commit. Without this, it's far too easy for unsafe
actions during the pre-commit sequence to crash the server instead of
hitting the error checks as intended.
Just to be extra paranoid, adjust a couple of the sanity checks in
xact.c to check not only IsInParallelMode() but also
IsParallelWorker().
M src/backend/access/transam/xact.c
Transfer current command counter ID to parallel workers.
commit : c451eaf8f628440ad93e933da8f08f7f4545c376
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 09:53:34 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 09:53:34 -0400
Commit 924bcf4f16d54c55310b28f77686608684734f42 correctly forbade
parallel workers to modify the command counter while in parallel mode,
but it inexplicably neglected to actually transfer the current command
counter from leader to workers. This can result in the workers seeing
a different set of tuples from the leader, which is bad. Repair.
M src/backend/access/transam/xact.c
Don't send protocol messages to a shm_mq that no longer exists.
commit : 26981d292758c6ee9185332e4abc990ff19c81a2
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 09:42:33 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 16 Oct 2015 09:42:33 -0400
Commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d introduced a mechanism
for relaying protocol messages from a background worker to another
backend via a shm_mq. However, there was no provision for shutting
down the communication channel. Therefore, a protocol message sent
late in the shutdown sequence, such as a DEBUG message resulting from
cranking up log_min_messages, could crash the server. To fix, install
an on_dsm_detach callback that disables sending messages to the shm_mq
when the associated DSM is detached.
M src/backend/access/transam/parallel.c
M src/backend/libpq/pqmq.c
M src/backend/storage/ipc/shm_mq.c
M src/include/libpq/pqmq.h
M src/include/storage/shm_mq.h
Fix NULL handling in datum_to_jsonb().
commit : a93b3782e3358cbb1ad8d65386a2e1478b805649
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Oct 2015 13:46:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Oct 2015 13:46:09 -0400
The function failed to adhere to its specification that the "tcategory"
argument should not be examined when the input value is NULL. This
resulted in a crash in some cases. Per bug #13680 from Boyko Yordanov.
In passing, re-pgindent some recent changes in jsonb.c, and fix a rather
ungrammatical comment.
Diagnosis and patch by Michael Paquier, cosmetic changes by me
M src/backend/utils/adt/jsonb.c
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/jsonb.sql
Allow FDWs to push down quals without breaking EvalPlanQual rechecks.
commit : 5043193b78919a1bd144563aadc2f7f726549913
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 15 Oct 2015 13:00:40 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 15 Oct 2015 13:00:40 -0400
This fixes a long-standing bug which was discovered while investigating
the interaction between the new join pushdown code and the EvalPlanQual
machinery: if a ForeignScan appears on the inner side of a paramaterized
nestloop, an EPQ recheck would re-return the original tuple even if
it no longer satisfied the pushed-down quals due to changed parameter
values.
This fix adds a new member to ForeignScan and ForeignScanState and a
new argument to make_foreignscan, and requires changes to FDWs which
push down quals to populate that new argument with a list of quals they
have chosen to push down. Therefore, I'm only back-patching to 9.5,
even though the bug is not new in 9.5.
Etsuro Fujita, reviewed by me and by Kyotaro Horiguchi.
M contrib/file_fdw/file_fdw.c
M contrib/postgres_fdw/postgres_fdw.c
M doc/src/sgml/fdwhandler.sgml
M src/backend/executor/nodeForeignscan.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/execnodes.h
M src/include/nodes/plannodes.h
M src/include/optimizer/planmain.h
Fix bogus comments
commit : 54e07be2dfd314a64dc2ce03a6a7f59cac1c8a13
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 15 Oct 2015 12:20:15 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 15 Oct 2015 12:20:15 -0300
Author: Amit Langote
M src/backend/commands/tablecmds.c
-- email subject limit ----------------------------------------- -- gitweb summary limit -------------------------- pg_upgrade: reorder controldata checks to match program output
commit : 41179e7ab328a12870fed942768a89dbe8742bf1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 13 Oct 2015 18:25:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 13 Oct 2015 18:25:32 -0400
Also improve comment for how float8_pass_by_value is used.
Backpatch through 9.5
M src/bin/pg_upgrade/controldata.c
Improve INSERT .. ON CONFLICT error message.
commit : bf8a361e101d830a6db105982a8527325c2e85fc
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 13 Oct 2015 15:33:07 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 13 Oct 2015 15:33:07 -0400
Peter Geoghegan, reviewed by me.
M src/backend/executor/execIndexing.c
M src/test/regress/output/constraints.source
On Windows, ensure shared memory handle gets closed if not being used.
commit : 39ac293940ec022f36510ba72470f23799e21dde
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Oct 2015 11:21:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Oct 2015 11:21:33 -0400
Postmaster child processes that aren't supposed to be attached to shared
memory were not bothering to close the shared memory mapping handle they
inherit from the postmaster process. That's mostly harmless, since the
handle vanishes anyway when the child process exits -- but the syslogger
process, if used, doesn't get killed and restarted during recovery from a
backend crash. That meant that Windows doesn't see the shared memory
mapping as becoming free, so it doesn't delete it and the postmaster is
unable to create a new one, resulting in failure to recover from crashes
whenever logging_collector is turned on.
Per report from Dmitry Vasilyev. It's a bit astonishing that we'd not
figured this out long ago, since it's been broken from the very beginnings
of out native Windows support; probably some previously-unexplained trouble
reports trace to this.
A secondary problem is that on Cygwin (perhaps only in older versions?),
exec() may not detach from the shared memory segment after all, in which
case these child processes did remain attached to shared memory, posing
the risk of an unexpected shared memory clobber if they went off the rails
somehow. That may be a long-gone bug, but we can deal with it now if it's
still live, by detaching within the infrastructure introduced here to deal
with closing the handle.
Back-patch to all supported branches.
Tom Lane and Amit Kapila
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/include/storage/pg_shmem.h
Sigh, need "use Config" as well.
commit : c6ab511c224f8775c0d392f8811c0a0a34758b3a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Oct 2015 19:49:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Oct 2015 19:49:22 -0400
This time with some manual testing behind it ...
M src/test/perl/TestLib.pm
Cause TestLib.pm to define $windows_os in all branches.
commit : 34557f5448e04366e7b64a402c0dd33decb6c346
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Oct 2015 19:35:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Oct 2015 19:35:38 -0400
Back-port of a part of commit 690ed2b76ab91eb79ea04ee2bfbdc8a2693f2a37 that
I'd depended on without realizing that it was only added recently. Since
it seems entirely likely that other such tests will need to be back-patched
in future, providing the flag seems like a better answer than just putting
a test in-line.
Per buildfarm.
M src/test/perl/TestLib.pm
Fix "pg_ctl start -w" to test child process status directly.
commit : a151a5c38510793830a63d74201e2d3561829170
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Oct 2015 18:30:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Oct 2015 18:30:36 -0400
pg_ctl start with -w previously relied on a heuristic that the postmaster
would surely always manage to create postmaster.pid within five seconds.
Unfortunately, that fails much more often than we would like on some of the
slower, more heavily loaded buildfarm members.
We have known for quite some time that we could remove the need for that
heuristic on Unix by using fork/exec instead of system() to launch the
postmaster. This allows us to know the exact PID of the postmaster, which
allows near-certain verification that the postmaster.pid file is the one
we want and not a leftover, and it also lets us use waitpid() to detect
reliably whether the child postmaster has exited or not.
What was blocking this change was not wanting to rewrite the Windows
version of start_postmaster() to avoid use of CMD.EXE. That's doable
in theory but would require fooling about with stdout/stderr redirection,
and getting the handling of quote-containing postmaster switches to
stay the same might be rather ticklish. However, we realized that
we don't have to do that to fix the problem, because we can test
whether the shell process has exited as a proxy for whether the
postmaster is still alive. That doesn't allow an exact check of the
PID in postmaster.pid, but we're no worse off than before in that
respect; and we do get to get rid of the heuristic about how long the
postmaster might take to create postmaster.pid.
On Unix, this change means that a second "pg_ctl start -w" immediately
after another such command will now reliably fail, whereas previously
it would succeed if done within two seconds of the earlier command.
Since that's a saner behavior anyway, it's fine. On Windows, the case can
still succeed within the same time window, since pg_ctl can't tell that the
earlier postmaster's postmaster.pid isn't the pidfile it is looking for.
To ensure stable test results on Windows, we can insert a short sleep into
the test script for pg_ctl, ensuring that the existing pidfile looks stale.
This hack can be removed if we ever do rewrite start_postmaster(), but that
no longer seems like a high-priority thing to do.
Back-patch to all supported versions, both because the current behavior
is buggy and because we must do that if we want the buildfarm failures
to go away.
Tom Lane and Michael Paquier
M src/bin/pg_ctl/pg_ctl.c
M src/bin/pg_ctl/t/001_start_stop.pl
Use JsonbIteratorToken consistently in automatic variable declarations.
commit : f75c4fc1dc93d60246df324bf595912d557bcba6
author : Noah Misch <noah@leadboat.com>
date : Sun, 11 Oct 2015 23:53:35 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 11 Oct 2015 23:53:35 -0400
Many functions stored JsonbIteratorToken values in variables of other
integer types. Also, standardize order relative to other declarations.
Expect compilers to generate the same code before and after this change.
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/jsonb_gin.c
M src/backend/utils/adt/jsonb_op.c
M src/backend/utils/adt/jsonb_util.c
M src/backend/utils/adt/jsonfuncs.c
Fix whitespace
commit : 7109c606d00f972359052bb8c8879a1ecfc1850f
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 11 Oct 2015 21:44:27 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 11 Oct 2015 21:44:27 -0400
M src/test/regress/sql/json_encoding.sql
Make prove_installcheck remove the old log directory, if any.
commit : 2539b9b0831c5642fd21284ce50003f08a313037
author : Noah Misch <noah@leadboat.com>
date : Sun, 11 Oct 2015 20:36:07 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 11 Oct 2015 20:36:07 -0400
prove_check already has been doing this. Back-patch to 9.4, like the
commit that introduced this logging.
M src/Makefile.global.in
Handle append_rel_list in expand_security_qual
commit : a26609e470601421b44424d6cc2683c4acabd086
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 9 Oct 2015 10:49:10 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 9 Oct 2015 10:49:10 -0400
During expand_security_quals, we take the security barrier quals on an
RTE and create a subquery which evaluates the quals. During this, we
have to replace any variables in the outer query which refer to the
original RTE with references to the columns from the subquery.
We need to also perform that replacement for any Vars in the
append_rel_list.
Only backpatching to 9.5 as we only go through this process in 9.4 for
auto-updatable security barrier views, which UNION ALL queries aren't.
Discovered by Haribabu Kommi
Patch by Dean Rasheed
M src/backend/optimizer/prep/prepsecurity.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Fix uninitialized-variable bug.
commit : e50431aa22e3b894ac107affd358052c20a899f7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Oct 2015 09:12:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Oct 2015 09:12:03 -0500
For some reason, neither of the compilers I usually use noticed the
uninitialized-variable problem I introduced in commit 7e2a18a9161fee7e.
That's hardly a good enough excuse though. Committing with brown paper bag
on head.
In addition to putting the operations in the right order, move the
declaration of "now" inside the loop; there's no need for it to be
outside, and that does wake up older gcc enough to notice any similar
future problem.
Back-patch to 9.4; earlier versions lack the time-to-SIGKILL stanza
so there's no bug.
M src/backend/postmaster/postmaster.c
Fix typo in docs.
commit : 36d4a50a886dacdb9e4a6716aca984edd3add83b
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 8 Oct 2015 13:21:03 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 8 Oct 2015 13:21:03 -0400
Pallavi Sontakke
M doc/src/sgml/func.sgml
Factor out encoding specific tests for json
commit : 48a78d80c83f7cd341e9761b5404562db6031c7e
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 7 Oct 2015 17:41:45 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 7 Oct 2015 17:41:45 -0400
This lets us remove the large alternative results files for the main
json and jsonb tests, which makes modifying those tests simpler for
committers and patch submitters.
Backpatch to 9.4 for jsonb and 9.3 for json.
M src/test/regress/expected/json.out
D src/test/regress/expected/json_1.out
A src/test/regress/expected/json_encoding.out
A src/test/regress/expected/json_encoding_1.out
M src/test/regress/expected/jsonb.out
D src/test/regress/expected/jsonb_1.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/json.sql
A src/test/regress/sql/json_encoding.sql
M src/test/regress/sql/jsonb.sql
Improve documentation of the role-dropping process.
commit : fc95734a14e588a847793ce4a734d9bf7fe50d14
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Oct 2015 16:12:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Oct 2015 16:12:05 -0400
In general one may have to run both REASSIGN OWNED and DROP OWNED to get
rid of all the dependencies of a role to be dropped. This was alluded to
in the REASSIGN OWNED man page, but not really spelled out in full; and in
any case the procedure ought to be documented in a more prominent place
than that. Add a section to the "Database Roles" chapter explaining this,
and do a bit of wordsmithing in the relevant commands' man pages.
M doc/src/sgml/ref/drop_owned.sgml
M doc/src/sgml/ref/drop_role.sgml
M doc/src/sgml/ref/drop_user.sgml
M doc/src/sgml/ref/reassign_owned.sgml
M doc/src/sgml/user-manag.sgml
docs: add JSONB containment example of a key and empty object
commit : c86555fc80bbbf276de42f43761991212b713575
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Oct 2015 10:30:54 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Oct 2015 10:30:54 -0400
Backpatch through 9.5
M doc/src/sgml/json.sgml
docs: Map operator @> to the proper SGML escape for '>'
commit : 9445a1cd3cc6dfae3644e2fe95da77046b507491
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Oct 2015 09:42:26 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Oct 2015 09:42:26 -0400
Backpatch through 9.5
M doc/src/sgml/json.sgml
M doc/src/sgml/rangetypes.sgml
docs: clarify JSONB operator descriptions
commit : 2169e878c4a542e41a7d66cbb40d9c6bfde23f57
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Oct 2015 09:06:49 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Oct 2015 09:06:49 -0400
No catalog bump as the catalog changes are for SQL operator comments.
Backpatch through 9.5
M doc/src/sgml/func.sgml
M doc/src/sgml/json.sgml
M src/include/catalog/pg_operator.h
Perform an immediate shutdown if the postmaster.pid file is removed.
commit : 02580df6c3ac288f2ed5e38ed42532512993d468
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Oct 2015 17:15:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Oct 2015 17:15:27 -0400
The postmaster now checks every minute or so (worst case, at most two
minutes) that postmaster.pid is still there and still contains its own PID.
If not, it performs an immediate shutdown, as though it had received
SIGQUIT.
The original goal behind this change was to ensure that failed buildfarm
runs would get fully cleaned up, even if the test scripts had left a
postmaster running, which is not an infrequent occurrence. When the
buildfarm script removes a test postmaster's $PGDATA directory, its next
check on postmaster.pid will fail and cause it to exit. Previously, manual
intervention was often needed to get rid of such orphaned postmasters,
since they'd block new test postmasters from obtaining the expected socket
address.
However, by checking postmaster.pid and not something else, we can provide
additional robustness: manual removal of postmaster.pid is a frequent DBA
mistake, and now we can at least limit the damage that will ensue if a new
postmaster is started while the old one is still alive.
Back-patch to all supported branches, since we won't get the desired
improvement in buildfarm reliability otherwise.
M src/backend/postmaster/postmaster.c
M src/backend/utils/init/miscinit.c
M src/include/miscadmin.h
Stamp 9.5beta1.
commit : b96df2c61710b39d24e98767cfe17b920b9319a6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 15:09:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 15:09:44 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
docs: update guidelines on when to use GIN and GiST indexes
commit : 7d88b3d154444fe102ef6a006f1234025e91c7fa
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 Oct 2015 13:38:36 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 Oct 2015 13:38:36 -0400
Report by Tomas Vondra
Backpatch through 9.5
M doc/src/sgml/textsearch.sgml
Docs: explain contrib/pg_stat_statements' handling of GC failure.
commit : d62359144da19297b13b2abf6c7d5d9220cfdf28
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:44:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:44:12 -0400
Failure to perform garbage collection now has a user-visible effect, so
explain that and explain that reducing pgss_max is the way to prevent it.
Per gripe from Andrew Dunstan.
M doc/src/sgml/pgstatstatements.sgml
Fix insufficiently-portable regression test case.
commit : c0f058e4d2c8dab6f6290dc85d2ad440691d562d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:19:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:19:14 -0400
Some of the buildfarm members are evidently miserly enough of stack space
to pass the originally-committed form of this test. Increase the
requirement 10X to hopefully ensure that it fails as-expected everywhere.
Security: CVE-2015-5289
M src/test/regress/expected/json.out
M src/test/regress/expected/json_1.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
Translation updates
commit : 149a8cdd7a299ce25eea9157baa636c3f00f2c5f
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Oct 2015 10:59:53 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Oct 2015 10:59:53 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 23a52bc86edcd39c3c6b80ee1f7374759c8711f8
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/it.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/pl.po
M src/bin/initdb/po/pt_BR.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/pl.po
M src/bin/pg_basebackup/po/pt_BR.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/pt_BR.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/pt_BR.po
M src/bin/pg_ctl/po/de.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_ctl/po/pl.po
M src/bin/pg_ctl/po/pt_BR.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/pl.po
M src/bin/pg_dump/po/pt_BR.po
M src/bin/pg_resetxlog/po/de.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/pg_resetxlog/po/pl.po
M src/bin/pg_resetxlog/po/pt_BR.po
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/po/de.po
A src/bin/pg_rewind/po/es.po
A src/bin/pg_rewind/po/pl.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/pt_BR.po
M src/bin/psql/po/zh_CN.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/pt_BR.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/pt_BR.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/pt_BR.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/pl.po
M src/interfaces/libpq/po/pt_BR.po
M src/pl/plperl/po/de.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/it.po
M src/pl/plperl/po/pl.po
M src/pl/plperl/po/pt_BR.po
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/pl.po
M src/pl/plpgsql/src/po/pt_BR.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/pl.po
M src/pl/plpython/po/pt_BR.po
M src/pl/tcl/po/de.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/it.po
M src/pl/tcl/po/pl.po
M src/pl/tcl/po/pt_BR.po
Last-minute updates for release notes.
commit : 808f1bdb3d9f662c4a46a43c6cf14a6ce33b4df5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 10:57:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 10:57:15 -0400
Add entries for security and not-quite-security issues.
Security: CVE-2015-5288, CVE-2015-5289
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Remove outdated comment about relation level autovacuum freeze limits.
commit : 56805a428cb95394eee7c853cfcb96c066e81256
author : Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 16:09:13 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 16:09:13 +0200
The documentation for the autovacuum_multixact_freeze_max_age and
autovacuum_freeze_max_age relation level parameters contained:
"Note that while you can set autovacuum_multixact_freeze_max_age very
small, or even zero, this is usually unwise since it will force frequent
vacuuming."
which hasn't been true since these options were made relation options,
instead of residing in the pg_autovacuum table (834a6da4f7).
Remove the outdated sentence. Even the lowered limits from 2596d70 are
high enough that this doesn't warrant calling out the risk in the CREATE
TABLE docs.
Per discussion with Tom Lane and Alvaro Herrera
Discussion: 26377.1443105453@sss.pgh.pa.us
Backpatch: 9.0- (in parts)
M doc/src/sgml/ref/create_table.sgml
Add regression tests for INSERT/UPDATE+RETURNING
commit : f9bb9c0a8a736efb567a676ad678d05a8dc35780
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 5 Oct 2015 10:14:51 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 5 Oct 2015 10:14:51 -0400
This adds regressions tests which are specific to INSERT+RETURNING and
UPDATE+RETURNING to ensure that the SELECT policies are added as
WithCheckOptions (and should therefore throw an error when the policy is
violated).
Per suggestion from Andres.
Back-patch to 9.5 as the prior commit was.
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Prevent stack overflow in query-type functions.
commit : 7bed97d486bda5761ba7e7982e4133aeded6b852
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:30 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:30 -0400
The tsquery, ltxtquery and query_int data types have a common ancestor.
Having acquired check_stack_depth() calls independently, each was
missing at least one call. Back-patch to 9.0 (all supported versions).
M contrib/intarray/_int_bool.c
M contrib/ltree/ltxtquery_io.c
M contrib/ltree/ltxtquery_op.c
M src/backend/utils/adt/tsquery_cleanup.c
Prevent stack overflow in container-type functions.
commit : acf0da1e6476fd3217781065c7e7654873376568
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
A range type can name another range type as its subtype, and a record
type can bear a column of another record type. Consequently, functions
like range_cmp() and record_recv() are recursive. Functions at risk
include operator family members and referents of pg_type regproc
columns. Treat as recursive any such function that looks up and calls
the same-purpose function for a record column type or the range subtype.
Back-patch to 9.0 (all supported versions).
An array type's element type is never itself an array type, so array
functions are unaffected. Recursion depth proportional to array
dimensionality, found in array_dim_to_jsonb(), is fine thanks to MAXDIM.
M src/backend/utils/adt/rangetypes.c
M src/backend/utils/adt/rowtypes.c
Prevent stack overflow in json-related functions.
commit : 98f30d2e55d530ff47b2756b395a2048200a5ea4
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
Sufficiently-deep recursion heretofore elicited a SIGSEGV. If an
application constructs PostgreSQL json or jsonb values from arbitrary
user input, application users could have exploited this to terminate all
active database connections. That applies to 9.3, where the json parser
adopted recursive descent, and later versions. Only row_to_json() and
array_to_json() were at risk in 9.2, both in a non-security capacity.
Back-patch to 9.2, where the json type was introduced.
Oskari Saarenmaa, reviewed by Michael Paquier.
Security: CVE-2015-5289
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/json_1.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
pgcrypto: Detect and report too-short crypt() salts.
commit : 4d6752277e792386e54b036aee8f64ee4fa84cf1
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
Certain short salts crashed the backend or disclosed a few bytes of
backend memory. For existing salt-induced error conditions, emit a
message saying as much. Back-patch to 9.0 (all supported versions).
Josh Kupershmidt
Security: CVE-2015-5288
M contrib/pgcrypto/crypt-blowfish.c
M contrib/pgcrypto/crypt-des.c
M contrib/pgcrypto/expected/crypt-blowfish.out
M contrib/pgcrypto/expected/crypt-des.out
M contrib/pgcrypto/expected/crypt-xdes.out
M contrib/pgcrypto/px-crypt.c
M contrib/pgcrypto/sql/crypt-blowfish.sql
M contrib/pgcrypto/sql/crypt-des.sql
M contrib/pgcrypto/sql/crypt-xdes.sql
Apply SELECT policies in INSERT/UPDATE+RETURNING
commit : bd9014768035dd70f8cc33c215a8b929c2e13a35
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 5 Oct 2015 07:55:11 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 5 Oct 2015 07:55:11 -0400
Similar to 7d8db3e, given that INSERT+RETURNING requires SELECT rights
on the table, apply the SELECT policies as WCOs to the tuples being
inserted. Apply the same logic to UPDATE+RETURNING.
Back-patch to 9.5 where RLS was added.
M src/backend/rewrite/rowsecurity.c
Do not write out WCOs in Query
commit : 31fb4df69d1364c79cfab0a2bd4470d0c48e942e
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 5 Oct 2015 07:38:56 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 5 Oct 2015 07:38:56 -0400
The WithCheckOptions list in Query are only populated during rewrite and
do not need to be written out or read in as part of a Query structure.
Further, move WithCheckOptions to the bottom and add comments to clarify
that it is only populated during rewrite.
Back-patch to 9.5 with a catversion bump, as we are still in alpha.
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/include/catalog/catversion.h
M src/include/nodes/parsenodes.h
Re-Align *_freeze_max_age reloption limits with corresponding GUC limits.
commit : 0577821b57253d0ae43ffdddc8f94f07866830ae
author : Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 11:53:43 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 11:53:43 +0200
In 020235a5754 I lowered the autovacuum_*freeze_max_age minimums to
allow for easier testing of wraparounds. I did not touch the
corresponding per-table limits. While those don't matter for the purpose
of wraparound, it seems more consistent to lower them as well.
It's noteworthy that the previous reloption lower limit for
autovacuum_multixact_freeze_max_age was too high by one magnitude, even
before 020235a5754.
Discussion: 26377.1443105453@sss.pgh.pa.us
Backpatch: back to 9.0 (in parts), like the prior patch
M src/backend/access/common/reloptions.c
ALTER TABLE .. FORCE ROW LEVEL SECURITY
commit : 90f334d2ca1a8bae2d0cd8a0898fb8ef90257565
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 4 Oct 2015 21:05:18 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 4 Oct 2015 21:05:18 -0400
To allow users to force RLS to always be applied, even for table owners,
add ALTER TABLE .. FORCE ROW LEVEL SECURITY.
row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump
output is complete (by default).
Also add SECURITY_NOFORCE_RLS context to avoid data corruption when
ALTER TABLE .. FORCE ROW SECURITY is being used. The
SECURITY_NOFORCE_RLS security context is used only during referential
integrity checks and is only considered in check_enable_rls() after we
have already checked that the current user is the owner of the relation
(which should always be the case during referential integrity checks).
Back-patch to 9.5 where RLS was added.
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/ref/alter_table.sgml
M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/backend/parser/gram.y
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/init/miscinit.c
M src/backend/utils/misc/rls.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/psql/describe.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_class.h
M src/include/miscadmin.h
M src/include/nodes/parsenodes.h
M src/test/modules/test_ddl_deparse/test_ddl_deparse.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/output/misc.source
M src/test/regress/sql/rowsecurity.sql
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
commit : e78dc6b829219cacaccc59957b5375585e919099
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 19:38:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 19:38:00 -0400
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
Improve contrib/pg_stat_statements' handling of garbage collection failure.
commit : 39a716d93300eeb28b959a0b248009a10fa49d3c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 17:58:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 17:58:30 -0400
If we can't read the query texts file (whether because out-of-memory, or
for some other reason), give up and reset the file to empty, discarding all
stored query texts, though not the statistics per se. We used to leave
things alone and hope for better luck next time, but the problem is that
the file is only going to get bigger and even harder to slurp into memory.
Better to do something that will get us out of trouble.
Likewise reset the file to empty for any other failure within gc_qtexts().
The previous behavior after a write error was to discard query texts but
not do anything to truncate the file, which is just weird.
Also, increase the maximum supported file size from MaxAllocSize to
MaxAllocHugeSize; this makes it more likely we'll be able to do a garbage
collection successfully.
Also, fix recalculation of mean_query_len within entry_dealloc() to match
the calculation in gc_qtexts(). The previous coding overlooked the
possibility of dropped texts (query_len == -1) and would underestimate the
mean of the remaining entries in such cases, thus possibly causing excess
garbage collection cycles.
In passing, add some errdetail to the log entry that complains about
insufficient memory to read the query texts file, which after all was
Jim Nasby's original complaint.
Back-patch to 9.4 where the current handling of query texts was
introduced.
Peter Geoghegan, rather editorialized upon by me
M contrib/pg_stat_statements/pg_stat_statements.c
Further twiddling of nodeHash.c hashtable sizing calculation.
commit : e5c94c7bbcf091617f0720a3ccbe898cd8beff17
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 15:55:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 15:55:07 -0400
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The simplest way to enforce the limit correctly is to
round max_pointers down to a power of 2 when it isn't one already.
(Note that the constraint to INT_MAX / 2, if it were doing anything useful
at all, is properly applied after that.)
M src/backend/executor/nodeHash.c
Fix some issues in new hashtable size calculations in nodeHash.c.
commit : ca5b42d85486f814b3b510e436157f443fd73683
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 14:06:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 14:06:40 -0400
Limit the size of the hashtable pointer array to not more than
MaxAllocSize, per reports from Kouhei Kaigai and others of "invalid memory
alloc request size" failures. There was discussion of allowing the array
to get larger than that by using the "huge" palloc API, but so far no proof
that that is actually a good idea, and at this point in the 9.5 cycle major
changes from old behavior don't seem like the way to go.
Fix a rather serious secondary bug in the new code, which was that it
didn't ensure nbuckets remained a power of 2 when recomputing it for the
multiple-batch case.
Clean up sloppy division of labor between ExecHashIncreaseNumBuckets and
its sole call site.
M src/backend/executor/nodeHash.c
M src/include/executor/hashjoin.h
Disallow invalid path elements in jsonb_set
commit : 544ccf644288132f805260c4eb9fd12029c5cf8c
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 4 Oct 2015 13:28:16 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 4 Oct 2015 13:28:16 -0400
Null path elements and, where the object is an array, invalid integer
elements now cause an error.
Incorrect behaviour noted by Thom Brown, patch from Dmitry Dolgov.
Backpatch to 9.5 where jsonb_set was introduced
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/jsonb.sql
Group cluster_name and update_process_title settings together
commit : e45f8f882055d5f864815aa29ffcd2b5e3c2013b
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 4 Oct 2015 11:14:28 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 4 Oct 2015 11:14:28 -0400
M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/utils/guc_tables.h
Document that row_security is a boolean GUC.
commit : 4365d9c18fc1ebb14de92595aa0340c5b8301547
author : Noah Misch <noah@leadboat.com>
date : Sat, 3 Oct 2015 20:20:22 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sat, 3 Oct 2015 20:20:22 -0400
Oversight in commit 537bd178c73b1d25938347b17e9e3e62898fc231.
Back-patch to 9.5, like that commit.
M doc/src/sgml/config.sgml
Make BYPASSRLS behave like superuser RLS bypass.
commit : 01ba7894f3f72ea57d1cfdc4f40f6231bc6cd9cd
author : Noah Misch <noah@leadboat.com>
date : Sat, 3 Oct 2015 20:19:57 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sat, 3 Oct 2015 20:19:57 -0400
Specifically, make its effect independent from the row_security GUC, and
make it affect permission checks pertinent to views the BYPASSRLS role
owns. The row_security GUC thereby ceases to change successful-query
behavior; it can only make a query fail with an error. Back-patch to
9.5, where BYPASSRLS was introduced.
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_role.sgml
M src/backend/utils/misc/rls.c
M src/include/catalog/pg_authid.h
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Improve errhint() about replication slot naming restrictions.
commit : cfddb5df5a84923160b23890d6086bcbcd1fd655
author : Andres Freund <andres@anarazel.de>
date : Sat, 3 Oct 2015 15:29:08 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 3 Oct 2015 15:29:08 +0200
The existing hint talked about "may only contain letters", but the
actual requirement is more strict: only lower case letters are allowed.
Reported-By: Rushabh Lathia
Author: Rushabh Lathia
Discussion: AGPqQf2x50qcwbYOBKzb4x75sO_V3g81ZsA8+Ji9iN5t_khFhQ@mail.gmail.com
Backpatch: 9.4-, where replication slots were added
M contrib/test_decoding/expected/ddl.out
M src/backend/replication/slot.c
Fix several bugs related to ON CONFLICT's EXCLUDED pseudo relation.
commit : 7285d66494a4c588ccf743a81f93b85b6995214f
author : Andres Freund <andres@anarazel.de>
date : Sat, 3 Oct 2015 15:12:10 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 3 Oct 2015 15:12:10 +0200
Four related issues:
1) attnos/varnos/resnos for EXCLUDED were out of sync when a column
after one dropped in the underlying relation was referenced.
2) References to whole-row variables (i.e. EXCLUDED.*) lead to errors.
3) It was possible to reference system columns in the EXCLUDED pseudo
relations, even though they would not have valid contents.
4) References to EXCLUDED were rewritten by the RLS machinery, as
EXCLUDED was treated as if it were the underlying relation.
To fix the first two issues, generate the excluded targetlist with
dropped columns in mind and add an entry for whole row
variables. Instead of unconditionally adding a wholerow entry we could
pull up the expression if needed, but doing it unconditionally seems
simpler. The wholerow entry is only really needed for ruleutils/EXPLAIN
support anyway.
The remaining two issues are addressed by changing the EXCLUDED RTE to
have relkind = composite. That fits with EXCLUDED not actually being a
real relation, and allows to treat it differently in the relevant
places. scanRTEForColumn now skips looking up system columns when the
RTE has a composite relkind; fireRIRrules() already had a corresponding
check, thereby preventing RLS expansion on EXCLUDED.
Also add tests for these issues, and improve a few comments around
excluded handling in setrefs.c.
Reported-By: Peter Geoghegan, Geoff Winkless
Author: Andres Freund, Amit Langote, Peter Geoghegan
Discussion: CAEzk6fdzJ3xYQZGbcuYM2rBd2BuDkUksmK=mY9UYYDugg_GgZg@mail.gmail.com,
CAM3SWZS+CauzbiCEcg-GdE6K6ycHE_Bz6Ksszy8AoixcMHOmsA@mail.gmail.com
Backpatch: 9.5, where ON CONFLICT was introduced
M src/backend/optimizer/plan/setrefs.c
M src/backend/parser/analyze.c
M src/backend/parser/parse_relation.c
M src/test/regress/expected/insert_conflict.out
M src/test/regress/expected/rules.out
M src/test/regress/sql/insert_conflict.sql
M src/test/regress/sql/rules.sql
doc: Update URLs of external projects
commit : 0777a887c24197d1d9d611ecc4b85a2d74b616b2
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 2 Oct 2015 21:50:59 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 2 Oct 2015 21:50:59 -0400
M doc/src/sgml/external-projects.sgml
doc: Make some index terms and terminology more consistent
commit : 5f904924bc270fd2d8dcc29f8267515e79a07baf
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 2 Oct 2015 21:22:44 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 2 Oct 2015 21:22:44 -0400
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_policy.sgml
M doc/src/sgml/ref/create_role.sgml
Update time zone data files to tzdata release 2015g.
commit : 19b06cc669fe128ad6181a97a00bcc26889ad0da
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 19:15:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 19:15:39 -0400
DST law changes in Cayman Islands, Fiji, Moldova, Morocco, Norfolk Island,
North Korea, Turkey, Uruguay. New zone America/Fort_Nelson for Canadian
Northern Rockies.
M src/timezone/data/africa
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backzone
M src/timezone/data/europe
M src/timezone/data/iso3166.tab
M src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
M src/timezone/data/zone1970.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Pacific.txt
Clarify FDW documentation about ON CONFLICT.
commit : 63e86ecacd505f2e1c125ff2361f47754f3e18c0
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 2 Oct 2015 16:55:47 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 2 Oct 2015 16:55:47 -0400
Etsuro Fujita, reviewed by Peter Geoghegan
M doc/src/sgml/fdwhandler.sgml
Add recursion depth protection to LIKE matching.
commit : bdc5d95b60bc1f17962a6b6184924b3672bd2f60
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 15:00:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 15:00:52 -0400
Since MatchText() recurses, it could in principle be driven to stack
overflow, although quite a long pattern would be needed.
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_match.c
Add recursion depth protections to regular expression matching.
commit : 20c627707c44deaed92c5d67b350f27e06e24228
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:51:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:51:58 -0400
Some of the functions in regex compilation and execution recurse, and
therefore could in principle be driven to stack overflow. The Tcl crew
has seen this happen in practice in duptraverse(), though their fix was
to put in a hard-wired limit on the number of recursive levels, which is
not too appetizing --- fortunately, we have enough infrastructure to check
the actually available stack. Greg Stark has also seen it in other places
while fuzz testing on a machine with limited stack space. Let's put guards
in to prevent crashes in all these places.
Since the regex code would leak memory if we simply threw elog(ERROR),
we have to introduce an API that checks for stack depth without throwing
such an error. Fortunately that's not difficult.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/backend/regex/rege_dfa.c
M src/backend/regex/regexec.c
M src/backend/tcop/postgres.c
M src/include/miscadmin.h
M src/include/regex/regguts.h
Fix potential infinite loop in regular expression execution.
commit : 51f235931dd25d704cb2f257eaa97ee2cd13c3e6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:26:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:26:36 -0400
In cfindloop(), if the initial call to shortest() reports that a
zero-length match is possible at the current search start point, but then
it is unable to construct any actual match to that, it'll just loop around
with the same start point, and thus make no progress. We need to force the
start point to be advanced. This is safe because the loop over "begin"
points has already tried and failed to match starting at "close", so there
is surely no need to try that again.
This bug was introduced in commit e2bd904955e2221eddf01110b1f25002de2aaa83,
wherein we allowed continued searching after we'd run out of match
possibilities, but evidently failed to think hard enough about exactly
where we needed to search next.
Because of the way this code works, such a match failure is only possible
in the presence of backrefs --- otherwise, shortest()'s judgment that a
match is possible should always be correct. That probably explains how
come the bug has escaped detection for several years.
The actual fix is a one-liner, but I took the trouble to add/improve some
comments related to the loop logic.
After fixing that, the submitted test case "()*\1" didn't loop anymore.
But it reported failure, though it seems like it ought to match a
zero-length string; both Tcl and Perl think it does. That seems to be from
overenthusiastic optimization on my part when I rewrote the iteration match
logic in commit 173e29aa5deefd9e71c183583ba37805c8102a72: we can't just
"declare victory" for a zero-length match without bothering to set match
data for capturing parens inside the iterator node.
Per fuzz testing by Greg Stark. The first part of this is a bug in all
supported branches, and the second part is a bug since 9.2 where the
iteration rewrite happened.
M src/backend/regex/regexec.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Add some more query-cancel checks to regular expression matching.
commit : bb704a781ada30b34b377937e8e39c2dae532cec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:45:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:45:39 -0400
Commit 9662143f0c35d64d7042fbeaf879df8f0b54be32 added infrastructure to
allow regular-expression operations to be terminated early in the event
of SIGINT etc. However, fuzz testing by Greg Stark disclosed that there
are still cases where regex compilation could run for a long time without
noticing a cancel request. Specifically, the fixempties() phase never
adds new states, only new arcs, so it doesn't hit the cancel check I'd put
in newstate(). Add one to newarc() as well to cover that.
Some experimentation of my own found that regex execution could also run
for a long time despite a pending cancel. We'd put a high-level cancel
check into cdissect(), but there was none inside the core text-matching
routines longest() and shortest(). Ordinarily those inner loops are very
very fast ... but in the presence of lookahead constraints, not so much.
As a compromise, stick a cancel check into the stateset cache-miss
function, which is enough to guarantee a cancel check at least once per
lookahead constraint test.
Making this work required more attention to error handling throughout the
regex executor. Henry Spencer had apparently originally intended longest()
and shortest() to be incapable of incurring errors while running, so
neither they nor their subroutines had well-defined error reporting
behaviors. However, that was already broken by the lookahead constraint
feature, since lacon() can surely suffer an out-of-memory failure ---
which, in the code as it stood, might never be reported to the user at all,
but just silently be treated as a non-match of the lookahead constraint.
Normalize all that by inserting explicit error tests as needed. I took the
opportunity to add some more comments to the code, too.
Back-patch to all supported branches, like the previous patch.
M src/backend/regex/regc_nfa.c
M src/backend/regex/rege_dfa.c
M src/backend/regex/regexec.c
Docs: add disclaimer about hazards of using regexps from untrusted sources.
commit : c56b2aa6efd1c0d090a9747a8220bf5110e9f9fd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:30:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:30:42 -0400
It's not terribly hard to devise regular expressions that take large
amounts of time and/or memory to process. Recent testing by Greg Stark has
also shown that machines with small stack limits can be driven to stack
overflow by suitably crafted regexps. While we intend to fix these things
as much as possible, it's probably impossible to eliminate slow-execution
cases altogether. In any case we don't want to treat such things as
security issues. The history of that code should already discourage
prudent DBAs from allowing execution of regexp patterns coming from
possibly-hostile sources, but it seems like a good idea to warn about the
hazard explicitly.
Currently, similar_escape() allows access to enough of the underlying
regexp behavior that the warning has to apply to SIMILAR TO as well.
We might be able to make it safer if we tightened things up to allow only
SQL-mandated capabilities in SIMILAR TO; but that would be a subtly
non-backwards-compatible change, so it requires discussion and probably
could not be back-patched.
Per discussion among pgsql-security list.
M doc/src/sgml/func.sgml
Docs: add another example of creating a range type.
commit : 1dc6f557e7020269436cbf8a66e68bc6e66def0c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 12:20:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 12:20:01 -0400
The "floatrange" example is a bit too simple because float8mi can be
used without any additional type conversion. Add an example that does
have to account for that, and do some minor other wordsmithing.
M doc/src/sgml/rangetypes.sgml
Don't disable commit_ts in standby if enabled locally
commit : 65dc1fc99a257a98961bfb964a1a95b2f521cd74
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 2 Oct 2015 12:49:01 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 2 Oct 2015 12:49:01 -0300
Bug noticed by Fujii Masao
M src/backend/access/transam/commit_ts.c
pg_rewind: Improve some messages
commit : 0f51a848ab98325e497a227155648facd9d0cf9b
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 1 Oct 2015 21:42:00 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 1 Oct 2015 21:42:00 -0400
The output of a typical pg_rewind run contained a mix of capitalized and
not-capitalized and punctuated and not-punctuated phrases for no
apparent reason. Make that consistent. Also fix some problems in other
messages.
M src/bin/pg_rewind/file_ops.c
M src/bin/pg_rewind/libpq_fetch.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_rewind/timeline.c
Fix message punctuation according to style guide
commit : 867bc6849f141e17cd4d3b416f48cc46839f2d76
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 1 Oct 2015 21:39:56 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 1 Oct 2015 21:39:56 -0400
M src/backend/access/transam/xlogreader.c
Fix pg_dump to handle inherited NOT VALID check constraints correctly.
commit : 5ea47e8f2a7d524eb491b1ffffbc98a012745409
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 16:19:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 16:19:49 -0400
This case seems to have been overlooked when unvalidated check constraints
were introduced, in 9.2. The code would attempt to dump such constraints
over again for each child table, even though adding them to the parent
table is sufficient.
In 9.2 and 9.3, also fix contrib/pg_upgrade/Makefile so that the "make
clean" target fully cleans up after a failed test. This evidently got
dealt with at some point in 9.4, but it wasn't back-patched. I ran into
it while testing this fix ...
Per bug #13656 from Ingmar Brouns.
M src/bin/pg_dump/pg_dump.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix commit_ts for standby
commit : a742ef86c228d8a0e9d174c651cfc4f96ac77e61
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 1 Oct 2015 15:06:55 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 1 Oct 2015 15:06:55 -0300
Module initialization was still not completely correct after commit
6b61955135e9, per crash report from Takashi Ohnishi. To fix, instead of
trying to monkey around with the value of the GUC setting directly, add
a separate boolean flag that enables the feature on a standby, but only
for the startup (recovery) process, when it sees that its master server
has the feature enabled.
Discussion: http://www.postgresql.org/message-id/ca44c6c7f9314868bdc521aea4f77cbf@MP-MSGSS-MBX004.msg.nttdata.co.jp
Also change the deactivation routine to delete all segment files rather
than leaving the last one around. (This doesn't need separate
WAL-logging, because on recovery we execute the same deactivation
routine anyway.)
In passing, clean up the code structure somewhat, particularly so that
xlog.c doesn't know so much about when to activate/deactivate the
feature.
Thanks to Fujii Masao for testing and Petr Jelínek for off-list discussion.
Back-patch to 9.5, where commit_ts was introduced.
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/include/access/commit_ts.h
Fix documentation error in commit 8703059c6b55c427100e00a09f66534b6ccbfaa1.
commit : d312cc37e4e4081149d3874974d9d7618ca574af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 10:31:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 10:31:22 -0400
Etsuro Fujita spotted a thinko in the README commentary.
M src/backend/optimizer/README
Fix mention of htup.h in storage.sgml
commit : c9a8d05465b5ed662235966554cb70d61d00707c
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 1 Oct 2015 23:00:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 1 Oct 2015 23:00:52 +0900
Previously it was documented that the details on HeapTupleHeaderData
struct could be found in htup.h. This is not correct because it's now
defined in htup_details.h.
Back-patch to 9.3 where the definition of HeapTupleHeaderData struct
was moved from htup.h to htup_details.h.
Michael Paquier
M doc/src/sgml/storage.sgml
Improve LISTEN startup time when there are many unread notifications.
commit : 8c8a834b14712de5252858aebbd4c5900c105c78
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Sep 2015 23:32:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Sep 2015 23:32:23 -0400
If some existing listener is far behind, incoming new listener sessions
would start from that session's read pointer and then need to advance over
many already-committed notification messages, which they have no interest
in. This was expensive in itself and also thrashed the pg_notify SLRU
buffers a lot more than necessary. We can improve matters considerably
in typical scenarios, without much added cost, by starting from the
furthest-ahead read pointer, not the furthest-behind one. We do have to
consider only sessions in our own database when doing this, which requires
an extra field in the data structure, but that's a pretty small cost.
Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced.
Matt Newell, slightly adjusted by me
M src/backend/commands/async.c
Don't dump core when destroying an unused ParallelContext.
commit : 91d97f03ca2a9ed56b322b69dde0392db835f722
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Sep 2015 18:36:31 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 30 Sep 2015 18:36:31 -0400
If a transaction or subtransaction creates a ParallelContext but ends
without calling InitializeParallelDSM, the previous code would
seg fault. Fix that.
M src/backend/access/transam/parallel.c
Include policies based on ACLs needed
commit : 75096c458aa8e27160112cc20a18fec3a111e4b0
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 30 Sep 2015 07:39:24 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 30 Sep 2015 07:39:24 -0400
When considering which policies should be included, rather than look at
individual bits of the query (eg: if a RETURNING clause exists, or if a
WHERE clause exists which is referencing the table, or if it's a
FOR SHARE/UPDATE query), consider any case where we've determined
the user needs SELECT rights on the relation while doing an UPDATE or
DELETE to be a case where we apply SELECT policies, and any case where
we've deteremind that the user needs UPDATE rights on the relation while
doing a SELECT to be a case where we apply UPDATE policies.
This simplifies the logic and addresses concerns that a user could use
UPDATE or DELETE with a WHERE clauses to determine if rows exist, or
they could use SELECT .. FOR UPDATE to lock rows which they are not
actually allowed to modify through UPDATE policies.
Use list_append_unique() to avoid adding the same quals multiple times,
as, on balance, the cost of checking when adding the quals will almost
always be cheaper than keeping them and doing busywork for each tuple
during execution.
Back-patch to 9.5 where RLS was added.
M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
Fix incorrect tps number calculation in "excluding connections establishing".
commit : 3c4c5acc40720a178e06da6258ce20d3c6e025ab
author : Tatsuo Ishii <ishii@postgresql.org>
date : Wed, 30 Sep 2015 10:36:23 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Wed, 30 Sep 2015 10:36:23 +0900
The tolerance (larger than actual tps number) increases as the number
of threads decreases. The bug has been there since the thread support
was introduced in 9.0. Because back patching introduces incompatible
behavior changes regarding the tps number, the fix is committed to
master and 9.5 stable branches only.
Problem spotted by me and fix proposed by Fabien COELHO. Note that his
original patch included more than fixes (a code re-factoring) which is
not related to the problem and I omitted the part.
M src/bin/pgbench/pgbench.c
Code review for transaction commit timestamps
commit : d8c7bb21ea2a3122cac96b2996d3122f25c160c3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 29 Sep 2015 14:40:56 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 29 Sep 2015 14:40:56 -0300
There are three main changes here:
1. No longer cause a start failure in a standby if the feature is
disabled in postgresql.conf but enabled in the master. This reverts one
part of commit 4f3924d9cd43; what we keep is the ability of the standby
to activate/deactivate the module (which includes creating and removing
segments as appropriate) during replay of such actions in the master.
2. Replay WAL records affecting commitTS even if the feature is
disabled. This means the standby will always have the same state as the
master after replay.
3. Have COMMIT PREPARE record the transaction commit time as well. We
were previously only applying it in the normal transaction commit path.
Author: Petr Jelínek
Discussion: http://www.postgresql.org/message-id/CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com
Discussion: http://www.postgresql.org/message-id/CAHGQGwFuzfO4JscM9LCAmCDCxp_MfLvN4QdB+xWsS-FijbjTYQ@mail.gmail.com
Additionally, I cleaned up nearby code related to replication origins,
which I found a bit hard to follow, and fixed a couple of typos.
Backpatch to 9.5, where this code was introduced.
Per bug reports from Fujii Masao and subsequent discussion.
M src/backend/access/rmgrdesc/xlogdesc.c
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/include/access/commit_ts.h
Fix plperl to handle non-ASCII error message texts correctly.
commit : a16b9b19389d1832286f4d8f259dab0d5be88856
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Sep 2015 10:52:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Sep 2015 10:52:22 -0400
We were passing error message texts to croak() verbatim, which turns out
not to work if the text contains non-ASCII characters; Perl mangles their
encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert
the text into a UTF8-encoded SV first.
It's hard to test this without risking failures in different database
encodings; but we can follow the lead of plpython, which is already
assuming that no-break space (U+00A0) has an equivalent in all encodings
we care about running the regression tests in (cf commit 2dfa15de5).
Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems
too risky to put something like this into 9.0's final minor release.
Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
M src/pl/plperl/SPI.xs
M src/pl/plperl/Util.xs
M src/pl/plperl/expected/plperl_elog.out
M src/pl/plperl/expected/plperl_elog_1.out
M src/pl/plperl/plperl.c
M src/pl/plperl/plperl_helpers.h
M src/pl/plperl/sql/plperl_elog.sql
Comment update for join pushdown.
commit : 9a6fbc2ac709aa8152e6d5d44a107d2d7c67b6f4
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 29 Sep 2015 07:42:30 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 29 Sep 2015 07:42:30 -0400
Etsuro Fujita
M src/backend/optimizer/util/pathnode.c
Fix compiler warning for non-TIOCGWINSZ case
commit : 60fcee9e5e77dc748a9787fae34328917683b95e
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Sep 2015 18:42:30 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Sep 2015 18:42:30 -0400
Backpatch to 9.5 where the error was introduced.
M src/bin/psql/print.c
Fix compiler warning about unused function in non-readline case.
commit : c4e6d506c6b028d6ccdac4e2a23b3484fba6c39e
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Sep 2015 18:29:20 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Sep 2015 18:29:20 -0400
Backpatch to all live branches to keep the code in sync.
M src/bin/psql/input.c
Fix "sesssion" typo
commit : aea76d128ad85f38aa0f4255fb9d46d95b835755
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Sep 2015 19:13:42 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Sep 2015 19:13:42 -0300
It was introduced alongside replication origins, by commit
5aa2350426c, so backpatch to 9.5.
Pointed out by Fujii Masao
M src/backend/access/transam/xact.c
M src/backend/access/transam/xloginsert.c
M src/backend/replication/logical/origin.c
M src/include/replication/origin.h
Fix poor errno handling in libpq's version of our custom OpenSSL BIO.
commit : b67c9c1939f10e94186d2736039ff623dbb2ce3f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Sep 2015 18:02:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Sep 2015 18:02:38 -0400
Thom Brown reported that SSL connections didn't seem to work on Windows in
9.5. Asif Naeem figured out that the cause was my_sock_read() looking at
"errno" when it needs to look at "SOCK_ERRNO". This mistake was introduced
in commit 680513ab79c7e12e402a2aad7921b95a25a4bcc8, which cloned the
backend's custom SSL BIO code into libpq, and didn't translate the errno
handling properly. Moreover, it introduced unnecessary errno save/restore
logic, which was particularly confusing because it was incomplete; and it
failed to check for all three of EINTR, EAGAIN, and EWOULDBLOCK in
my_sock_write. (That might not be necessary; but since we're copying
well-tested backend code that does do that, it seems prudent to copy it
faithfully.)
M src/interfaces/libpq/fe-secure-openssl.c
Ensure a few policies remain for pg_upgrade
commit : ce585027ebc26554d77cde9d8f2721a8cca55381
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 28 Sep 2015 15:48:36 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 28 Sep 2015 15:48:36 -0400
To make sure that pg_dump/pg_restore function properly with RLS
policies, arrange to have a few of them left around at the end of the
regression tests.
Back-patch to 9.5 where RLS was added.
M src/test/regress/expected/rowsecurity.out
M src/test/regress/output/misc.source
M src/test/regress/sql/rowsecurity.sql
Fix ON CONFLICT DO UPDATE for tables with oids.
commit : 90586ef127c593002897ee0bcafdf2adb6a18c7d
author : Andres Freund <andres@anarazel.de>
date : Mon, 28 Sep 2015 19:12:48 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 28 Sep 2015 19:12:48 +0200
When taking the UPDATE path in an INSERT .. ON CONFLICT .. UPDATE tables
with oids were not supported. The tuple generated by the update target
list was projected without space for an oid - a simple oversight.
Reported-By: Peter Geoghegan
Author: Andres Freund
Backpatch: 9.5, where ON CONFLICT was introduced
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/insert_conflict.out
M src/test/regress/sql/insert_conflict.sql
Don't try to create a temp install without abs_top_builddir.
commit : 80e2694b284cd9395b1ee8ef476f5f720ee50566
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 28 Sep 2015 10:47:05 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 28 Sep 2015 10:47:05 -0400
Otherwise, we effectively act as if abs_top_builddir were the root
directory, which is quite dangerous if the user happens to have
permissions to do things there. This can crop up in PGXS builds,
for example.
Report by Sandro Santilli, patch by me, review by Noah Misch.
M src/Makefile.global.in
pg_dump: Fix some messages
commit : 27af56b59515a676e733a143e0ebaf9e0c921be6
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 27 Sep 2015 20:29:40 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 27 Sep 2015 20:29:40 -0400
Make quoting style match existing style. Improve plural support.
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump_sort.c
reindexdb: Fix mistake in help output
commit : 90d037772ec161436590699c5c6b057d1a0170d6
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 27 Sep 2015 11:22:16 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 27 Sep 2015 11:22:16 -0400
M src/bin/scripts/reindexdb.c
pg_ctl: Improve help formatting and order
commit : 63ab1a398166daafcea2aaebbf0c48cb78b5be32
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 26 Sep 2015 21:09:52 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 26 Sep 2015 21:09:52 -0400
M src/bin/pg_ctl/pg_ctl.c
doc: Tweak "cube" index entry
commit : 0160c1d23910a71def6166c6fd3d4586216b7305
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 26 Sep 2015 21:00:59 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 26 Sep 2015 21:00:59 -0400
With the arrival of the CUBE key word/feature, the index entries for the
cube extension and the CUBE feature were collapsed into one. Tweak the
entry for the cube extension so they are separate entries.
M doc/src/sgml/cube.sgml
Remove legacy multixact truncation support.
commit : 6e8af37643099310e5d47a12152872e325b930f0
author : Andres Freund <andres@anarazel.de>
date : Sat, 26 Sep 2015 19:04:25 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 26 Sep 2015 19:04:25 +0200
In 9.5 and master there is no need to support legacy truncation. This is
just committed separately to make it easier to backpatch the WAL logged
multixact truncation to 9.3 and 9.4 if we later decide to do so.
I bumped master's magic from 0xD086 to 0xD088 and 9.5's from 0xD085 to
0xD087 to avoid 9.5 reusing a value that has been in use on master while
keeping the numbers increasing between major versions.
Discussion: 20150621192409.GA4797@alap3.anarazel.de
Backpatch: 9.5
M src/backend/access/transam/multixact.c
M src/backend/access/transam/xlog.c
M src/backend/commands/vacuum.c
M src/include/access/multixact.h
M src/include/access/xlog_internal.h
Rework the way multixact truncations work.
commit : bd7c348d83a4576163b635010e49dbcac7126f01
author : Andres Freund <andres@anarazel.de>
date : Sat, 26 Sep 2015 19:04:25 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 26 Sep 2015 19:04:25 +0200
The fact that multixact truncations are not WAL logged has caused a fair
share of problems. Amongst others it requires to do computations during
recovery while the database is not in a consistent state, delaying
truncations till checkpoints, and handling members being truncated, but
offset not.
We tried to put bandaids on lots of these issues over the last years,
but it seems time to change course. Thus this patch introduces WAL
logging for multixact truncations.
This allows:
1) to perform the truncation directly during VACUUM, instead of delaying it
to the checkpoint.
2) to avoid looking at the offsets SLRU for truncation during recovery,
we can just use the master's values.
3) simplify a fair amount of logic to keep in memory limits straight,
this has gotten much easier
During the course of fixing this a bunch of additional bugs had to be
fixed:
1) Data was not purged from memory the member's SLRU before deleting
segments. This happened to be hard or impossible to hit due to the
interlock between checkpoints and truncation.
2) find_multixact_start() relied on SimpleLruDoesPhysicalPageExist - but
that doesn't work for offsets that haven't yet been flushed to
disk. Add code to flush the SLRUs to fix. Not pretty, but it feels
slightly safer to only make decisions based on actual on-disk state.
3) find_multixact_start() could be called concurrently with a truncation
and thus fail. Via SetOffsetVacuumLimit() that could lead to a round
of emergency vacuuming. The problem remains in
pg_get_multixact_members(), but that's quite harmless.
For now this is going to only get applied to 9.5+, leaving the issues in
the older branches in place. It is quite possible that we need to
backpatch at a later point though.
For the case this gets backpatched we need to handle that an updated
standby may be replaying WAL from a not-yet upgraded primary. We have to
recognize that situation and use "old style" truncation (i.e. looking at
the SLRUs) during WAL replay. In contrast to before, this now happens in
the startup process, when replaying a checkpoint record, instead of the
checkpointer. Doing truncation in the restartpoint is incorrect, they
can happen much later than the original checkpoint, thereby leading to
wraparound. To avoid "multixact_redo: unknown op code 48" errors
standbys would have to be upgraded before primaries.
A later patch will bump the WAL page magic, and remove the legacy
truncation codepaths. Legacy truncation support is just included to make
a possible future backpatch easier.
Discussion: 20150621192409.GA4797@alap3.anarazel.de
Reviewed-By: Robert Haas, Alvaro Herrera, Thomas Munro
Backpatch: 9.5 for now
M src/backend/access/rmgrdesc/mxactdesc.c
M src/backend/access/transam/multixact.c
M src/backend/access/transam/slru.c
M src/backend/access/transam/xlog.c
M src/backend/commands/vacuum.c
M src/include/access/multixact.h
M src/include/access/slru.h
M src/include/storage/lwlock.h
M src/tools/pgindent/typedefs.list
Second try at fixing O(N^2) problem in foreign key references.
commit : c9645f75785c607a31ba4acebf87d0ad38446aeb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 13:16:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 13:16:30 -0400
This replaces ill-fated commit 5ddc72887a012f6a8b85707ef27d85c274faf53d,
which was reverted because it broke active uses of FK cache entries. In
this patch, we still do nothing more to invalidatable cache entries than
mark them as needing revalidation, so we won't break active uses. To keep
down the overhead of InvalidateConstraintCacheCallBack(), keep a list of
just the currently-valid cache entries. (The entries are large enough that
some added space for list links doesn't seem like a big problem.) This
would still be O(N^2) when there are many valid entries, though, so when
the list gets too long, just force the "sinval reset" behavior to remove
everything from the list. I set the threshold at 1000 entries, somewhat
arbitrarily. Possibly that could be fine-tuned later. Another item for
future study is whether it's worth adding reference counting so that we
could safely remove invalidated entries. As-is, problem cases are likely
to end up with large and mostly invalid FK caches.
Like the previous attempt, backpatch to 9.3.
Jan Wieck and Tom Lane
M src/backend/utils/adt/ri_triggers.c
Further fix for psql's code for locale-aware formatting of numeric output.
commit : 5eb7024379ec0701ce2fae242ae90d7d56ee72bb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 12:20:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 12:20:45 -0400
(Third time's the charm, I hope.)
Additional testing disclosed that this code could mangle already-localized
output from the "money" datatype. We can't very easily skip applying it
to "money" values, because the logic is tied to column right-justification
and people expect "money" output to be right-justified. Short of
decoupling that, we can fix it in what should be a safe enough way by
testing to make sure the string doesn't contain any characters that would
not be expected in plain numeric output.
M src/bin/psql/print.c
Further fix for psql's code for locale-aware formatting of numeric output.
commit : da4af91cefaabe493577f1d6d17ee78f2e66389c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 00:00:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 00:00:33 -0400
On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.
We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.
This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases. Still, wrong is wrong, so back-patch.
M src/bin/psql/print.c
Fix psql's code for locale-aware formatting of numeric output.
commit : f1ee153dcf1a3bd64889f56bee6a863f54e97d99
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 23:01:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 23:01:04 -0400
This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636. More generally, it made lots of unverified assumptions
about what the input string could possibly look like. Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point. While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).
This has been broken for a long time, so back-patch to all supported
branches.
M src/bin/psql/print.c
Allow planner to use expression-index stats for function calls in WHERE.
commit : 45d256c2792e20c52235470e62a70c9c80a96274
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 18:35:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 18:35:46 -0400
Previously, a function call appearing at the top level of WHERE had a
hard-wired selectivity estimate of 0.3333333, a kludge conveniently dated
in the source code itself to July 1992. The expectation at the time was
that somebody would soon implement estimator support functions analogous
to those for operators; but no such code has appeared, nor does it seem
likely to in the near future. We do have an alternative solution though,
at least for immutable functions on single relations: creating an
expression index on the function call will allow ANALYZE to gather stats
about the function's selectivity. But the code in clause_selectivity()
failed to make use of such data even if it exists.
Refactor so that that will happen. I chose to make it try this technique
for any clause type for which clause_selectivity() doesn't have a special
case, not just functions. To avoid adding unnecessary overhead in the
common case where we don't learn anything new, make selfuncs.c provide an
API that hooks directly to examine_variable() and then var_eq_const(),
rather than the previous coding which laboriously constructed an OpExpr
only so that it could be expensively deconstructed again.
I preserved the behavior that the default estimate for a function call
is 0.3333333. (For any other expression node type, it's 0.5, as before.)
I had originally thought to make the default be 0.5 across the board, but
changing a default estimate that's survived for twenty-three years seems
like something not to do without a lot more testing than I care to put
into it right now.
Per a complaint from Jehan-Guillaume de Rorthais. Back-patch into 9.5,
but not further, at least for the moment.
M src/backend/optimizer/path/clausesel.c
M src/backend/utils/adt/selfuncs.c
M src/include/utils/selfuncs.h
Improve handling of collations in contrib/postgres_fdw.
commit : 59d765b6554093701329be935b52d82d9af01401
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 12:47:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 12:47:30 -0400
If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation. (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.) To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var. (When it can, FDW_COLLATE_SAFE is
appropriate.) We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.
An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.
Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation. We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has). So just set the state to
UNSAFE rather than failing immediately.
Per report from Jeevan Chalke. This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
Make pg_controldata report newest XID with valid commit timestamp
commit : eac3b3365e6220ce03bc05914c8e7f5430341373
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 24 Sep 2015 23:31:17 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 24 Sep 2015 23:31:17 +0900
Previously pg_controldata didn't report newestCommitTs and this was
an oversight in commit 73c986a.
Also this patch changes pg_resetxlog so that it uses the same sentences
as pg_controldata does, regarding oldestCommitTs and newestCommitTs,
for the sake of consistency.
Back-patch to 9.5 where track_commit_timestamp was added.
Euler Taveira
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_resetxlog/pg_resetxlog.c
Lower *_freeze_max_age minimum values.
commit : ef4fccd2b6a60bdf89a4300741028218e36461aa
author : Andres Freund <andres@anarazel.de>
date : Thu, 24 Sep 2015 14:53:33 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 24 Sep 2015 14:53:33 +0200
The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 10000000
multixacts can contain a lot of members.
Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.
While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.
Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=OztbDGGrovkkEzQ@mail.gmail.com
Backpatch: back to 9.0 (in parts)
M src/backend/utils/misc/guc.c
Make ANALYZE compute basic statistics even for types with no "=" operator.
commit : cfb2024ae40e3bbf7a7390bbb053504b757705c2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Sep 2015 18:26:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Sep 2015 18:26:49 -0400
Previously, ANALYZE simply ignored columns of datatypes that have neither
a btree nor hash opclass (which means they have no recognized equality
operator). Without a notion of equality, we can't identify most-common
values nor estimate the number of distinct values. But we can still
count nulls and compute the average physical column width, and those
stats might be of value. Moreover there are some tools out there that
don't work so well if rows are missing from pg_statistic. So let's
add suitable logic for this case.
While this is arguably a bug fix, it also has the potential to change
query plans, and the gain seems not worth taking a risk of that in
stable branches. So back-patch into 9.5 but not further.
Oleksandr Shulgin, rewritten a bit by me.
M src/backend/commands/analyze.c
Docs: fix typo in to_char() example.
commit : fe6d2ab473fdbe4b9408d8da3e97a5091171c743
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Sep 2015 10:40:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Sep 2015 10:40:25 -0400
Per bug #13631 from KOIZUMI Satoru.
M doc/src/sgml/func.sgml
test_decoding: Protect against rare spurious test failures.
commit : 55728ea501de5a153e4dc55c21fb4b6f4d0f44c4
author : Andres Freund <andres@anarazel.de>
date : Tue, 22 Sep 2015 15:33:30 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 22 Sep 2015 15:33:30 +0200
A bunch of tests missed specifying that empty transactions shouldn't be
displayed. That causes problems when e.g. autovacuum runs in an
unfortunate moment. The tests in question only run for a very short
time, making this quite unlikely.
Reported-By: Buildfarm member axolotl
Backpatch: 9.4, where logical decoding was introduced
M contrib/test_decoding/expected/binary.out
M contrib/test_decoding/sql/binary.sql
Correct value of LW_SHARED_MASK.
commit : 62e503b0c29bbb9e0ac7ebce6990bf3c7c3c9a89
author : Andres Freund <andres@anarazel.de>
date : Tue, 22 Sep 2015 11:05:48 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 22 Sep 2015 11:05:48 +0200
The previous wrong value lead to wrong LOCK_DEBUG output, never showing
any shared lock holders.
Reported-By: Alexander Korotkov
Discussion: CAPpHfdsPmWqz9FB0AnxJrwp1=KLF0n=-iB+QvR0Q8GSmpFVdUQ@mail.gmail.com
Backpatch: 9.5, where the bug was introduced.
M src/backend/storage/lmgr/lwlock.c
doc: Tweak synopsis indentation for consistency
commit : 265728e1b60858f9db8a3e7fb538477a28fc74a3
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Sep 2015 23:31:43 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Sep 2015 23:31:43 -0400
M doc/src/sgml/ref/create_event_trigger.sgml
M doc/src/sgml/ref/import_foreign_schema.sgml
Fix whitespace
commit : a8bb248141c14911b5748bad6130e7de0cbba92e
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Sep 2015 13:39:34 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Sep 2015 13:39:34 -0400
M src/interfaces/ecpg/ecpglib/execute.c
Fix possible internal overflow in numeric multiplication.
commit : 3dfffac701cf95e3d9b86f12a3875f9b1b531231
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Sep 2015 12:11:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Sep 2015 12:11:32 -0400
mul_var() postpones propagating carries until it risks overflow in its
internal digit array. However, the logic failed to account for the
possibility of overflow in the carry propagation step, allowing wrong
results to be generated in corner cases. We must slightly reduce the
when-to-propagate-carries threshold to avoid that.
Discovered and fixed by Dean Rasheed, with small adjustments by me.
This has been wrong since commit d72f6c75038d8d37e64a29a04b911f728044d83b,
so back-patch to all supported branches.
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Remove the SECURITY_ROW_LEVEL_DISABLED security context bit.
commit : bbdb9dfbc3c722b4c811c5cbfa03ce79b7b74824
author : Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:47:17 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:47:17 -0400
This commit's parent made superfluous the bit's sole usage. Referential
integrity checks have long run as the subject table's owner, and that
now implies RLS bypass. Safe use of the bit was tricky, requiring
strict control over the SQL expressions evaluating therein. Back-patch
to 9.5, where the bit was introduced.
Based on a patch by Stephen Frost.
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/cache/plancache.c
M src/backend/utils/init/miscinit.c
M src/backend/utils/misc/rls.c
M src/include/miscadmin.h
M src/include/utils/plancache.h
Remove the row_security=force GUC value.
commit : 6dae6edcd88cf3be06acf247c10de925bc065274
author : Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:45:41 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:45:41 -0400
Every query of a single ENABLE ROW SECURITY table has two meanings, with
the row_security GUC selecting between them. With row_security=force
available, every function author would have been advised to either set
the GUC locally or test both meanings. Non-compliance would have
threatened reliability and, for SECURITY DEFINER functions, security.
Authors already face an obligation to account for search_path, and we
should not mimic that example. With this change, only BYPASSRLS roles
need exercise the aforementioned care. Back-patch to 9.5, where the
row_security GUC was introduced.
Since this narrows the domain of pg_db_role_setting.setconfig and
pg_proc.proconfig, one might bump catversion. A row_security=force
setting in one of those columns will elicit a clear message, so don't.
M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/rls.c
M src/include/utils/plancache.h
M src/include/utils/rls.h
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Restrict file mode creation mask during tmpfile().
commit : 1be9d65e17abc6215a6faae9bc3f714dd3d040b6
author : Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:42:27 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:42:27 -0400
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
M src/bin/pg_dump/pg_backup_tar.c
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
commit : 3d3bc2905f2ed6a4858501031c086383be7bcf6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Sep 2015 16:48:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Sep 2015 16:48:44 -0400
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
written (commit 1785acebf2ed14fd66955e2d9a55d77a025f418d), but missed that
the pfree needed to be protected with an if-test. Just to make sure things
are left in a clean state, reset numLockOwners as well.
Per low-memory testing by Andreas Seltenreich. Back-patch to all supported
branches.
M src/backend/storage/lmgr/lock.c
Let compiler handle size calculation of bool types.
commit : b46f5ebd9c8f6ec37e27c56749266fc2e362902b
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 17 Sep 2015 15:41:04 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 17 Sep 2015 15:41:04 +0200
Back in the day this did not work, but modern compilers should handle it themselves.
M src/interfaces/ecpg/ecpglib/data.c
M src/interfaces/ecpg/ecpglib/execute.c
Simplify GETTEXT_FILES list
commit : 866a034c3f9f2b6c3ef23df0f1d9e2e4b7533a3a
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 18 Sep 2015 22:40:41 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 18 Sep 2015 22:40:41 -0400
M src/bin/pg_rewind/nls.mk
Add missing serial comma
commit : bd313ba8a91a19659bf92014df96f7e58bfdd2fe
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 18 Sep 2015 22:40:10 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 18 Sep 2015 22:40:10 -0400
M src/backend/access/transam/xlog.c
Cache argument type information in json(b) aggregate functions.
commit : 1e1ae6e0b0c11e6044c0dacd61cb17c8d8bc87f1
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 18 Sep 2015 14:39:39 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 18 Sep 2015 14:39:39 -0400
These functions have been looking up type info for every row they
process. Instead of doing that we only look them up the first time
through and stash the information in the aggregate state object.
Affects json_agg, json_object_agg, jsonb_agg and jsonb_object_agg.
There is plenty more work to do in making these more efficient,
especially the jsonb functions, but this is a virtually cost free
improvement that can be done right away.
Backpatch to 9.5 where the jsonb variants were introduced.
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
Fix low-probability memory leak in regex execution.
commit : a39331fa573fc2bd6f93322ff190da26ddc477b5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Sep 2015 13:55:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Sep 2015 13:55:17 -0400
After an internal failure in shortest() or longest() while pinning down the
exact location of a match, find() forgot to free the DFA structure before
returning. This is pretty unlikely to occur, since we just successfully
ran the "search" variant of the DFA; but it could happen, and it would
result in a session-lifespan memory leak since this code uses malloc()
directly. Problem seems to have been aboriginal in Spencer's library,
so back-patch all the way.
In passing, correct a thinko in a comment I added awhile back about the
meaning of the "ntree" field.
I happened across these issues while comparing our code to Tcl's version
of the library.
M src/backend/regex/regcomp.c
M src/backend/regex/regexec.c
M src/include/regex/regguts.h
Order some new options on man pages more sensibly, minor improvements
commit : e8e2999470bd8148e8caf2c86a24b7a6fd4085f1
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 17 Sep 2015 20:56:58 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 17 Sep 2015 20:56:58 -0400
M doc/src/sgml/ref/alter_database.sgml
M doc/src/sgml/ref/create_database.sgml
M doc/src/sgml/ref/create_policy.sgml
M doc/src/sgml/ref/pg_ctl-ref.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_receivexlog.sgml
M doc/src/sgml/ref/pg_restore.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/ref/vacuumdb.sgml
Honour TEMP_CONFIG when testing pg_upgrade
commit : 104184d9562365432479691b917ebab45e55e214
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 17 Sep 2015 11:57:00 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 17 Sep 2015 11:57:00 -0400
This setting contains extra configuration for the temp instance, as used
in pg_regress' --temp-config flag.
Backpatch to 9.2 where test.sh was introduced.
M src/bin/pg_upgrade/test.sh
Fix documentation of regular expression character-entry escapes.
commit : d97bdb082690980a78ca6e2bbe0c6d863caef32f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 14:50:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 14:50:12 -0400
The docs claimed that \uhhhh would be interpreted as a Unicode value
regardless of the database encoding, but it's never been implemented
that way: \uhhhh and \xhhhh actually mean exactly the same thing, namely
the character that pg_mb2wchar translates to 0xhhhh. Moreover we were
falsely dismissive of the usefulness of Unicode code points above FFFF.
Fix that.
It's been like this for ages, so back-patch to all supported branches.
M doc/src/sgml/func.sgml
Don't use "#" as an abbreviation for "number" in PL/Tcl error messages.
commit : 3047a9b9ef0db126c7f40acde51f78a1bbaa6dd6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 12:08:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 12:08:57 -0400
Also, rewrite one error message to make it follow our message style
guidelines better.
Euler Taveira and Tom Lane
M src/pl/tcl/pltcl.c
Remove no-longer-used T_PrivGrantee node tag.
commit : 5b7aef85139f9f103b5a369261c538769da64c90
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 10:48:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 10:48:11 -0400
Oversight in commit 31eae6028eca4365e7165f5f33fee1ed0486aee0, which
replaced PrivGrantee nodes with RoleSpec nodes. Spotted by Yugo Nagata.
M src/include/nodes/nodes.h
Review program help output for wording and formatting
commit : ea00ff5f1058d2ede0b3ddda47b8713f11a6832a
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 16 Sep 2015 00:37:39 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 16 Sep 2015 00:37:39 -0400
M src/bin/pg_basebackup/pg_receivexlog.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_resetxlog/pg_resetxlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pgbench/pgbench.c
M src/bin/psql/help.c
M src/bin/scripts/vacuumdb.c
Enforce ALL/SELECT policies in RETURNING for RLS
commit : 68b5201128c2d0c8a3a0051ff7c2534b037e1eab
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Sep 2015 15:49:40 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Sep 2015 15:49:40 -0400
For the UPDATE/DELETE RETURNING case, filter the records which are not
visible to the user through ALL or SELECT policies from those considered
for the UPDATE or DELETE. This is similar to how the GRANT system
works, which prevents RETURNING unless the caller has SELECT rights on
the relation.
Per discussion with Robert, Dean, Tom, and Kevin.
Back-patch to 9.5 where RLS was introduced.
M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
RLS refactoring
commit : 23a4b897f731e1a2be7fe989a34016d7a6287148
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Sep 2015 15:49:40 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Sep 2015 15:49:40 -0400
This refactors rewrite/rowsecurity.c to simplify the handling of the
default deny case (reducing the number of places where we check for and
add the default deny policy from three to one) by splitting up the
retrival of the policies from the application of them.
This also allowed us to do away with the policy_id field. A policy_name
field was added for WithCheckOption policies and is used in error
reporting, when available.
Patch by Dean Rasheed, with various mostly cosmetic changes by me.
Back-patch to 9.5 where RLS was introduced to avoid unnecessary
differences, since we're still in alpha, per discussion with Robert.
M src/backend/commands/policy.c
M src/backend/executor/execMain.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/rewrite/rowsecurity.c
M src/backend/utils/cache/relcache.c
M src/include/nodes/parsenodes.h
M src/include/rewrite/rowsecurity.h
M src/test/modules/test_rls_hooks/expected/test_rls_hooks.out
M src/test/modules/test_rls_hooks/test_rls_hooks.c
Revert "Fix an O(N^2) problem in foreign key references".
commit : ed301d6dbe32eaad4f226903d430336e5a0d72aa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Sep 2015 11:08:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Sep 2015 11:08:56 -0400
Commit 5ddc72887a012f6a8b85707ef27d85c274faf53d does not actually work
because it will happily blow away ri_constraint_cache entries that are
in active use in outer call levels. In any case, it's a very ugly,
brute-force solution to the problem of limiting the cache size.
Revert until it can be redesigned.
M src/backend/utils/adt/ri_triggers.c
Add POLICY to COMMENT documentation
commit : 225f539bd00ad58bac41d8d30bd0bd112f8c6a29
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Sep 2015 10:56:29 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 15 Sep 2015 10:56:29 -0400
COMMENT supports POLICY but the documentation hadn't caught up with
that fact.
Patch by Charles Clavadetscher
Back-patch to 9.5 where POLICY was added.
M doc/src/sgml/ref/comment.sgml
Improve log messages related to tablespace_map file
commit : fb98859ea0cac3f85041ca052bfdd0b1c8814932
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 15 Sep 2015 23:21:51 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 15 Sep 2015 23:21:51 +0900
This patch changes the log message which is logged when the server
successfully renames backup_label file to *.old but fails to rename
tablespace_map file during the shutdown. Previously the WARNING
message "online backup mode was not canceled" was logged in that case.
However this message is confusing because the backup mode is treated
as canceled whenever backup_label is successfully renamed. So this
commit makes the server log the message "online backup mode canceled"
in that case.
Also this commit changes errdetail messages so that they follow the
error message style guide.
Back-patch to 9.5 where tablespace_map file is introduced.
Original patch by Amit Kapila, heavily modified by me.
M src/backend/access/transam/xlog.c
Fix the fastpath rule for jsonb_concat with an empty operand.
commit : f243072a9ca3d135745441ab016996a00d183bd2
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 13 Sep 2015 17:06:45 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 13 Sep 2015 17:06:45 -0400
To prevent perverse results, we now only return the other operand if
it's not scalar, and if both operands are of the same kind (array or
object).
Original bug complaint and patch from Oskari Saarenmaa, extended by me
to cover the cases of different kinds of jsonb.
Backpatch to 9.5 where jsonb_concat was introduced.
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/jsonb.sql
doc: Remove dead links
commit : 63c0f5b20b7012633bbd85cea039e9d44c054953
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 12 Sep 2015 23:49:11 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 12 Sep 2015 23:49:11 -0400
The web pages of Andy Dong at Berkeley don't exist anymore, and he is no
longer there.
M doc/src/sgml/cube.sgml
Fix typo in create_policy.sgml
commit : dc3573b5d310eb42f478892870a0889a50693530
author : Stephen Frost <sfrost@snowman.net>
date : Sat, 12 Sep 2015 17:17:03 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Sat, 12 Sep 2015 17:17:03 -0400
WTIH -> WITH
Pointed out by Dmitriy Olshevskiy
Backpatch to 9.5 where create_policy.sgml was added.
M doc/src/sgml/ref/create_policy.sgml
Update SQL features list
commit : d96c80c1d6f513f0588a19af8a00f4df9eba7837
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 12 Sep 2015 00:07:56 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 12 Sep 2015 00:07:56 -0400
M src/backend/catalog/sql_features.txt
pg_dump, pg_upgrade: allow postgres/template1 tablespace moves
commit : 3243fce882d4a4dc294e331289e873f9246d7c68
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 11 Sep 2015 15:51:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 11 Sep 2015 15:51:11 -0400
Modify pg_dump to restore postgres/template1 databases to non-default
tablespaces by switching out of the database to be moved, then switching
back.
Also, to fix potentially cases where the old/new tablespaces might not
match, fix pg_upgrade to process new/old tablespaces separately in all
cases.
Report by Marti Raudsepp
Patch by Marti Raudsepp, me
Backpatch through 9.0
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_upgrade/info.c
Add missing ReleaseBuffer call in BRIN revmap code
commit : 25b3ddd1de54563b631484f6d56bd56bef906102
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Sep 2015 15:29:46 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 11 Sep 2015 15:29:46 -0300
I think this particular branch is actually dead, but the analysis to
prove that is not trivial, so instead take the weasel way.
Reported by Jinyu Zhang
Backpatch to 9.5, where BRIN was introduced.
M src/backend/access/brin/brin_revmap.c
Fix an O(N^2) problem in foreign key references.
commit : 974f910b64511ace9d00a9458577fe439b63ec01
author : Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 11 Sep 2015 13:20:17 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 11 Sep 2015 13:20:17 -0500
Commit 45ba424f improved foreign key lookups during bulk updates
when the FK value does not change. When restoring a schema dump
from a database with many (say 100,000) foreign keys, this cache
would grow very big and every ALTER TABLE command was causing an
InvalidateConstraintCacheCallBack(), which uses a sequential hash
table scan. This could cause a severe performance regression in
restoring a schema dump (including during pg_upgrade).
The patch uses a heuristic method of detecting when the hash table
should be destroyed and recreated.
InvalidateConstraintCacheCallBack() adds the current size of the
hash table to a counter. When that sum reaches 1,000,000, the hash
table is flushed. This fixes the regression without noticeable
harm to the bulk update use case.
Jan Wieck
Backpatch to 9.3 where the performance regression was introduced.
M src/backend/utils/adt/ri_triggers.c
Correct description of PageHeaderData layout in documentation
commit : 5b0317b5af58eb6ba42614104644589a0be7c569
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 11 Sep 2015 13:02:15 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 11 Sep 2015 13:02:15 +0900
Back-patch to 9.3 where PageHeaderData layout was changed.
Michael Paquier
M doc/src/sgml/storage.sgml
doc: Spell checking
commit : 683bfbdb99b4168652a7b536b0ccc7217de8ba36
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 10 Sep 2015 21:22:21 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 10 Sep 2015 21:22:21 -0400
M doc/src/sgml/backup.sgml
M doc/src/sgml/brin.sgml
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/client-auth.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/custom-scan.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/fdwhandler.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/indices.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/logicaldecoding.sgml
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/manage-ag.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/queries.sgml
M doc/src/sgml/recovery-config.sgml
M doc/src/sgml/ref/alter_database.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/comment.sgml
M doc/src/sgml/ref/create_database.sgml
M doc/src/sgml/ref/create_domain.sgml
M doc/src/sgml/ref/create_function.sgml
M doc/src/sgml/ref/insert.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_recvlogical.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M doc/src/sgml/ref/pg_xlogdump.sgml
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/ref/pgtestfsync.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/replication-origins.sgml
Fix setrefs.c comment properly.
commit : edebc04dbd564fd738df1f1ca4f2c05c5cad123d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Sep 2015 10:23:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Sep 2015 10:23:56 -0400
The "typo" alleged in commit 1e460d4bd was actually a comment that was
correct when written, but I missed updating it in commit b5282aa89.
Use a slightly less specific (and hopefully more future-proof) description
of what is collected. Back-patch to 9.2 where that commit appeared, and
revert the comment to its then-entirely-correct state before that.
M src/backend/optimizer/plan/setrefs.c
Fix typo in setrefs.c
commit : 9adaccab2a9e44cf53d2d5c2d3b780ac10e10a5f
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 09:22:11 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 09:22:11 -0400
We're adding OIDs, not TIDs, to invalItems.
Pointed out by Etsuro Fujita.
Back-patch to all supported branches.
M src/backend/optimizer/plan/setrefs.c
Fix minor bug in regexp makesearch() function.
commit : d76113dda77417d176e299b167e95db0266986d5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Sep 2015 20:14:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Sep 2015 20:14:58 -0400
The list-wrangling here was done wrong, allowing the same state to get
put into the list twice. The following loop then would clone it twice.
The second clone would wind up with no inarcs, so that there was no
observable misbehavior AFAICT, but a useless state in the finished NFA
isn't an especially good thing.
M src/backend/regex/regcomp.c
Remove files signaling a standby promotion request at postmaster startup
commit : 65f37b3e9b0aea59cc98a2e23f45bb8fb6a56395
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 22:51:44 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 22:51:44 +0900
This commit makes postmaster forcibly remove the files signaling
a standby promotion request. Otherwise, the existence of those files
can trigger a promotion too early, whether a user wants that or not.
This removal of files is usually unnecessary because they can exist
only during a few moments during a standby promotion. However
there is a race condition: if pg_ctl promote is executed and creates
the files during a promotion, the files can stay around even after
the server is brought up to new master. Then, if new standby starts
by using the backup taken from that master, the files can exist
at the server startup and should be removed in order to avoid
an unexpected promotion.
Back-patch to 9.1 where promote signal file was introduced.
Problem reported by Feike Steenbergen.
Original patch by Michael Paquier, modified by me.
Discussion: 20150528100705.4686.91426@wrigleys.postgresql.org
M src/backend/access/transam/xlog.c
M src/backend/postmaster/postmaster.c
M src/include/access/xlog.h
Lock all relations referred to in updatable views
commit : 9801bae217e9d3f72e2d1f3dd780bf0bf9365dae
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 8 Sep 2015 17:02:53 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 8 Sep 2015 17:02:53 -0400
Even views considered "simple" enough to be automatically updatable may
have mulitple relations involved (eg: in a where clause). We need to
make sure and lock those relations when rewriting the query.
Back-patch to 9.3 where updatable views were added.
Pointed out by Andres, patch thanks to Dean Rasheed.
M src/backend/rewrite/rewriteHandler.c
Add gin_fuzzy_search_limit to postgresql.conf.sample.
commit : 97b7b9560f3dbe1c48dfb4630f50444eb7e8adc8
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 02:25:50 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 02:25:50 +0900
This was forgotten in 8a3631f (commit that originally added the parameter)
and 0ca9907 (commit that added the documentation later that year).
Back-patch to all supported versions.
M src/backend/utils/misc/postgresql.conf.sample
Fix error message wording in previous sslinfo commit
commit : bbbe5a9d8a35f0f7a983488d35dd86006229ea0c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 8 Sep 2015 11:10:20 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 8 Sep 2015 11:10:20 -0300
M contrib/sslinfo/sslinfo.c
In the pg_rewind test suite, receive WAL fully before promoting.
commit : 58feb1a94a5ea0ae3395b1818ba76ab68485a7a4
author : Noah Misch <noah@leadboat.com>
date : Mon, 7 Sep 2015 19:01:00 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 7 Sep 2015 19:01:00 -0400
If a transaction never reaches the standby, later tests find unexpected
cluster state. A "tail-copy: query result matches" test failure has
been the usual symptom. Among the buildfarm members having run this
test suite, most have exhibited that symptom at least once. Back-patch
to 9.5, where pg_rewind was introduced.
Michael Paquier, reported by Christoph Berg.
M src/bin/pg_rewind/RewindTest.pm
Add more sanity checks in contrib/sslinfo
commit : 73d2d2e6a1721f94e4d01d7502bf99452008170e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 7 Sep 2015 19:18:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 7 Sep 2015 19:18:29 -0300
We were missing a few return checks on OpenSSL calls. Should be pretty
harmless, since we haven't seen any user reports about problems, and
this is not a high-traffic module anyway; still, a bug is a bug, so
backpatch this all the way back to 9.0.
Author: Michael Paquier, while reviewing another sslinfo patch
M contrib/sslinfo/sslinfo.c
Change type of DOW/DOY to UNITS
commit : a1242402854178eded9bd4f2b8cd8ef46d1e9864
author : Greg Stark <stark@mit.edu>
date : Mon, 7 Sep 2015 13:35:09 +0100
committer: Greg Stark <stark@mit.edu>
date : Mon, 7 Sep 2015 13:35:09 +0100
M src/interfaces/ecpg/pgtypeslib/dt_common.c
Make GIN's cleanup pending list process interruptable
commit : d592a8745fd0320fd5e691b59bf5a95d9834a286
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 17:17:15 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 17:17:15 +0300
Cleanup process could be called by ordinary insert/update and could take a lot
of time. Add vacuum_delay_point() to make this process interruptable. Under
vacuum this call will also throttle a vacuum process to decrease system load,
called from insert/update it will not throttle, and that reduces a latency.
Backpatch for all supported branches.
Jeff Janes <jeff.janes@gmail.com>
M src/backend/access/gin/ginfast.c
Update site address of Snowball project
commit : 552723a3bf6d3caefafaa0afe9afcde31ccdb481
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 15:21:34 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 15:21:34 +0300
M doc/src/sgml/textsearch.sgml
Move DTK_ISODOW DTK_DOW and DTK_DOY to be type UNITS rather than RESERV. RESERV is meant for tokens like "now" and having them in that category throws errors like these when used as an input date:
commit : c11100d0fa46b5a0c3c796b8d538060ce7d14ac9
author : Greg Stark <stark@mit.edu>
date : Sun, 6 Sep 2015 02:04:37 +0100
committer: Greg Stark <stark@mit.edu>
date : Sun, 6 Sep 2015 02:04:37 +0100
stark=# SELECT 'doy'::timestamptz;
ERROR: unexpected dtype 33 while parsing timestamptz "doy"
LINE 1: SELECT 'doy'::timestamptz;
^
stark=# SELECT 'dow'::timestamptz;
ERROR: unexpected dtype 32 while parsing timestamptz "dow"
LINE 1: SELECT 'dow'::timestamptz;
^
Found by LLVM's Libfuzzer
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/timestamp.c
Fix CreateTableSpace() so it will compile without HAVE_SYMLINK.
commit : 5692b4acb26fea7c834c9ad0712cce2ec251d512
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Sep 2015 16:15:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Sep 2015 16:15:38 -0400
This has been broken since 9.3 (commit 82b1b213cad3a69c to be exact),
which suggests that nobody is any longer using a Windows build system that
doesn't provide a symlink emulation. Still, it's wrong on its own terms,
so repair.
YUriy Zhuravlev
M src/backend/commands/tablespace.c
Fix misc typos.
commit : 25600c42e078e0d10eedf2794a0c7d02178232e0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 5 Sep 2015 11:35:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 5 Sep 2015 11:35:49 +0300
Oskari Saarenmaa. Backpatch to stable branches where applicable.
M contrib/btree_gist/btree_ts.c
M contrib/btree_gist/btree_utils_var.c
M contrib/cube/cube.c
M doc/src/sgml/ref/alter_role.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/sources.sgml
M src/backend/access/brin/brin_revmap.c
M src/backend/access/common/heaptuple.c
M src/backend/access/gin/ginfast.c
M src/backend/access/gist/gistproc.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/xact.c
M src/backend/optimizer/path/costsize.c
M src/backend/replication/logical/origin.c
M src/backend/utils/adt/regproc.c
M src/include/storage/lwlock.h
Fix brin index summarizing while vacuuming.
commit : b1cbc8529d076b71c9c2f8403139f7235072a357
author : Tatsuo Ishii <ishii@postgresql.org>
date : Sat, 5 Sep 2015 09:19:25 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Sat, 5 Sep 2015 09:19:25 +0900
If the number of heap blocks is not multiples of pages per range, the
summarizing produces wrong summary information for the last brin index
tuple while vacuuming.
Problem reported by Tatsuo Ishii and fixed by Amit Langote.
Discussion at "[HACKERS] BRIN INDEX value (message id :20150903.174935.1946402199422994347.t-ishii@sraoss.co.jp)
Backpatched to 9.5 in which brin index was added.
M src/backend/access/brin/brin.c
Fix subtransaction cleanup after an outer-subtransaction portal fails.
commit : a2538da89f664671d1790cb8dbb4b94849ed923c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Sep 2015 13:36:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Sep 2015 13:36:49 -0400
Formerly, we treated only portals created in the current subtransaction as
having failed during subtransaction abort. However, if the error occurred
while running a portal created in an outer subtransaction (ie, a cursor
declared before the last savepoint), that has to be considered broken too.
To allow reliable detection of which ones those are, add a bookkeeping
field to struct Portal that tracks the innermost subtransaction in which
each portal has actually been executed. (Without this, we'd end up
failing portals containing functions that had called the subtransaction,
thereby breaking plpgsql exception blocks completely.)
In addition, when we fail an outer-subtransaction Portal, transfer its
resources into the subtransaction's resource owner, so that they're
released early in cleanup of the subxact. This fixes a problem reported by
Jim Nasby in which a function executed in an outer-subtransaction cursor
could cause an Assert failure or crash by referencing a relation created
within the inner subtransaction.
The proximate cause of the Assert failure is that AtEOSubXact_RelationCache
assumed it could blow away a relcache entry without first checking that the
entry had zero refcount. That was a bad idea on its own terms, so add such
a check there, and to the similar coding in AtEOXact_RelationCache. This
provides an independent safety measure in case there are still ways to
provoke the situation despite the Portal-level changes.
This has been broken since subtransactions were invented, so back-patch
to all supported branches.
Tom Lane and Michael Paquier
M src/backend/access/transam/xact.c
M src/backend/commands/portalcmds.c
M src/backend/tcop/pquery.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/mmgr/portalmem.c
M src/include/utils/portal.h
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
Document that max_worker_processes must be high enough in standby.
commit : cb9cc382b41de4fab2d718f0f8de3441c85aa7f7
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 3 Sep 2015 22:30:16 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 3 Sep 2015 22:30:16 +0900
The setting values of some parameters including max_worker_processes
must be equal to or higher than the values on the master. However,
previously max_worker_processes was not listed as such parameter
in the document. So this commit adds it to that list.
Back-patch to 9.4 where max_worker_processes was added.
M doc/src/sgml/high-availability.sgml
M src/backend/access/transam/xlog.c
Disable fsync throughout TAP test suites.
commit : 8d60549d6d39fbc1501f11a31f007c36975891e8
author : Noah Misch <noah@leadboat.com>
date : Thu, 3 Sep 2015 00:29:11 -0400
committer: Noah Misch <noah@leadboat.com>
date : Thu, 3 Sep 2015 00:29:11 -0400
Most suites already did so via start_test_server(), but the pg_rewind,
pg_ctl and pg_controldata suites ran a postmaster or initdb with fsync
enabled. This halves the pg_rewind suite's runtime on buildfarm member
tern. It makes tern and that machine's other buildfarm members less
vulnerable to noise failures from postmaster startup overrunning the 60s
pg_ctl timeout. Back-patch to 9.5, where pg_rewind was introduced.
M src/bin/pg_controldata/t/001_pg_controldata.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/test/perl/TestLib.pm
Document that PL/Python now returns floats using repr() not str().
commit : e2e78acccaa94e7d64dc2bc0b124cfcf23520918
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Sep 2015 19:25:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Sep 2015 19:25:58 -0400
Commit 1ce7a57ca neglected to update the user-facing documentation,
which described the old behavior precisely.
M doc/src/sgml/plpython.sgml
pg_upgrade docs: clarify rsync and move verification step
commit : 813e08123bd9eb7d7eb7bc6eac43b74f5a9a1ef8
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 1 Sep 2015 16:42:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 1 Sep 2015 16:42:43 -0400
These are adjustments based on someone using the new standby upgrade
steps.
Report by Andy Colson
Backpatch through 9.5
M doc/src/sgml/ref/pgupgrade.sgml
Allow notifications to bgworkers without database connections.
commit : b8a439b650c4791575720dec847be61467a710a4
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 1 Sep 2015 15:30:19 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 1 Sep 2015 15:30:19 -0400
Previously, if one background worker registered another background
worker and set bgw_notify_pid while for the second background worker,
it would not receive notifications from the postmaster unless, at the
time the "parent" was registered, BGWORKER_BACKEND_DATABASE_CONNECTION
was set.
To fix, instead instead of including only those background workers that
requested database connections in the postmater's BackendList, include
them all. There doesn't seem to be any reason not do this, and indeed
it removes a significant amount of duplicated code. The other option
is to make PostmasterMarkPIDForWorkerNotify look at BackgroundWorkerList
in addition to BackendList, but that adds more code duplication instead
of getting rid of it.
Patch by me. Review and testing by Ashutosh Bapat.
M src/backend/postmaster/postmaster.c
Use <substeps> in pg_upgrade's procedure
commit : c1564b3928e527c799bd41c2c80c4d6851bb5e15
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 1 Sep 2015 14:58:28 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 1 Sep 2015 14:58:28 -0300
For clarity, so that the substeps are not numbered identically to the
outer procedure's steps.
Per report from Andy Colson in
http://www.postgresql.org/message-id/55D789B5.7040308@squeakycode.net
M doc/src/sgml/ref/pgupgrade.sgml
docs: remove outdated note about unique indexes
commit : 06502185d8352258560b7fad82571d159dff8658
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 31 Aug 2015 17:05:22 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 31 Aug 2015 17:05:22 -0400
Patch by Josh Kupershmidt
Backpatch through 9.5
M doc/src/sgml/indices.sgml
psql: print longtable as a possible \pset option
commit : bda58e98d535762b46a9d6315f4e49d9c93e81d8
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 31 Aug 2015 12:24:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 31 Aug 2015 12:24:16 -0400
For some reason this message was not updated when the longtable option
was added.
Backpatch through 9.3
M src/bin/psql/command.c
Small grammar fix
commit : bafeb010b2500b31d303f4c2879cec54481dafdd
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 31 Aug 2015 14:07:17 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 31 Aug 2015 14:07:17 +0200
Josh Kupershmidt
M doc/src/sgml/pgprewarm.sgml
Fix sepgsql regression tests.
commit : 1c419abffba7a105948495f498780f1cf9ab7fc4
author : Joe Conway <mail@joeconway.com>
date : Sun, 30 Aug 2015 11:09:19 -0700
committer: Joe Conway <mail@joeconway.com>
date : Sun, 30 Aug 2015 11:09:19 -0700
The regression tests for sepgsql were broken by changes in the
base distro as-shipped policies. Specifically, definition of
unconfined_t in the system default policy was changed to bypass
multi-category rules, which the regression test depended on.
Fix that by defining a custom privileged domain
(sepgsql_regtest_superuser_t) and using it instead of system's
unconfined_t domain. The new sepgsql_regtest_superuser_t domain
performs almost like the current unconfined_t, but restricted by
multi-category policy as the traditional unconfined_t was.
The custom policy module is a self defined domain, and so should not
be affected by related future system policy changes. However, it still
uses the unconfined_u:unconfined_r pair for selinux-user and role.
Those definitions have not been changed for several years and seem
less risky to rely on than the unconfined_t domain. Additionally, if
we define custom user/role, they would need to be manually defined
at the operating system level, adding more complexity to an already
non-standard and complex regression test.
Back-patch to 9.3. The regression tests will need more work before
working correctly on 9.2. Starting with 9.2, sepgsql has had dependencies
on libselinux versions that are only available on newer distros with
the changed set of policies (e.g. RHEL 7.x). On 9.1 sepgsql works
fine with the older distros with original policy set (e.g. RHEL 6.x),
and on which the existing regression tests work fine. We might want
eventually change 9.1 sepgsql regression tests to be more independent
from the underlying OS policies, however more work will be needed to
make that happen and it is not clear that it is worth the effort.
Kohei KaiGai with review by Adam Brightwell and me, commentary by
Stephen, Alvaro, Tom, Robert, and others.
M contrib/sepgsql/expected/alter.out
M contrib/sepgsql/expected/ddl.out
M contrib/sepgsql/expected/dml.out
M contrib/sepgsql/expected/label.out
M contrib/sepgsql/expected/misc.out
M contrib/sepgsql/launcher
M contrib/sepgsql/sepgsql-regtest.te
M contrib/sepgsql/sql/alter.sql
M contrib/sepgsql/sql/ddl.sql
M contrib/sepgsql/sql/dml.sql
M contrib/sepgsql/sql/label.sql
Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.
commit : ffbc387bfc57b47ec7f120582cfff54f6434f3d4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Aug 2015 16:09:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Aug 2015 16:09:25 -0400
On recent AIX it's necessary to configure gcc to use the native assembler
(because the GNU assembler hasn't been updated to handle AIX 6+). This
caused PG builds to fail with assembler syntax errors, because we'd try
to compile s_lock.h's gcc asm fragment for PPC, and that assembly code
relied on GNU-style local labels. We can't substitute normal labels
because it would fail in any file containing more than one inlined use of
tas(). Fortunately, that code is stable enough, and the PPC ISA is simple
enough, that it doesn't seem like too much of a maintenance burden to just
hand-code the branch offsets, removing the need for any labels.
Note that the AIX assembler only accepts "$" for the location counter
pseudo-symbol. The usual GNU convention is "."; but it appears that all
versions of gas for PPC also accept "$", so in theory this patch will not
break any other PPC platforms.
This has been reported by a few people, but Steve Underwood gets the credit
for being the first to pursue the problem far enough to understand why it
was failing. Thanks also to Noah Misch for additional testing.
M src/include/storage/s_lock.h
Ensure locks are acquired on RLS-added relations
commit : d03f3314b35cc4ac2be832cf63ae67a69ee4d93c
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 28 Aug 2015 11:39:43 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 28 Aug 2015 11:39:43 -0400
During fireRIRrules(), get_row_security_policies can add to
securityQuals and withCheckOptions. Make sure to lock any relations
added at that point and before firing RIR rules on those expressions.
Back-patch to 9.5 where RLS was added.
M src/backend/rewrite/rewriteHandler.c
Simplify Perl chmod calls
commit : aed688eb730f0e46bc7950589d7577db6bb2d724
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 25 Aug 2015 09:58:49 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 25 Aug 2015 09:58:49 -0400
The Perl chmod function already takes multiple file arguments, so we
don't need a separate looping function.
M src/test/ssl/ServerSetup.pm
dblink docs: fix typo to use "connname" (3 n's), not "conname"
commit : 440fc48cac7f450bb71d1f06f0d1326c63e3e42f
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 27 Aug 2015 13:43:10 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 27 Aug 2015 13:43:10 -0400
This makes the parameter names match the documented prototype names.
Report by Erwin Brandstetter
Backpatch through 9.0
M doc/src/sgml/dblink.sgml
release notes: abbreviated key speedup only for varchar/text
commit : ce56a649cf0b9aba41d68481895b3da0a82981d4
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Aug 2015 14:46:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Aug 2015 14:46:48 -0400
Report by Peter Geoghegan
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
release notes: backpatch removal of xpath item to 9.5 tree
commit : aa9630cce04d3512e1ca5131013a0a669b39fcac
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Aug 2015 14:40:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Aug 2015 14:40:53 -0400
Backpatch a93545e13f832d457e00420d44ccce1f88f899d4 to the 9.5 tree
Backpatch to 9.5 only
M doc/src/sgml/release-9.5.sgml
9.5 release notes: mention lack of char() sort improvements
commit : 63c6522dae38e3cf6d1af795db441686e716b331
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Aug 2015 10:33:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 26 Aug 2015 10:33:02 -0400
Report by Peter Geoghegan
Backpatch through 9.5
M doc/src/sgml/datatype.sgml
Reestablish alignment of pg_controldata output.
commit : bff62dfb873be1f2469402c6e22cfb93b639f9cd
author : Joe Conway <mail@joeconway.com>
date : Tue, 25 Aug 2015 18:46:02 -0700
committer: Joe Conway <mail@joeconway.com>
date : Tue, 25 Aug 2015 18:46:02 -0700
Until 9.4, pg_controldata output was all aligned. At some point
during 9.5 development, a new item was added, namely
"Current track_commit_timestamp setting:" which is two characters
too long to be aligned with the rest of the output. Fix this by
removing the noise word "Current" and adding the requisite number
of padding spaces. Since the six preceding items are also similar
in nature, remove "Current" and pad those as well in order to
maintain overall consistency. Backpatch to 9.5 where new offending
item was added.
M src/bin/pg_controldata/pg_controldata.c
Docs: be explicit about datatype matching for lead/lag functions.
commit : 7c0c4d07e777957a5fad54e81b4f42f420031060
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 19:11:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 19:11:17 -0400
The default argument, if given, has to be of exactly the same datatype
as the first argument; but this was not stated in so many words, and
the error message you get about it might not lead your thought in the
right direction. Per bug #13587 from Robert McGehee.
A quick scan says that these are the only two built-in functions with two
anyelement arguments and no other polymorphic arguments. There are plenty
of cases of, eg, anyarray and anyelement, but those seem less likely to
confuse. For instance this doesn't seem terribly hard to figure out:
"function array_remove(integer[], numeric) does not exist". So I've
contented myself with fixing these two cases.
M doc/src/sgml/func.sgml
Fix potential platform dependence in gist regression test.
commit : b8c91352a2e168e1c24cc33862a0d95f13fd0957
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 11:43:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 11:43:37 -0400
The results of the KNN-search test cases were indeterminate, as they asked
the system to sort pairs of points that are exactly equidistant from the
query reference point. It's a bit surprising that we've seen no
platform-specific failures from this in the buildfarm. Perhaps IEEE-float
math is well enough standardized that no such failures will ever occur on
supported platforms ... but since this entire regression test has yet to be
shipped in any non-alpha release, that seems like an unduly optimistic
assumption. Tweak the queries so that the correct output is uniquely
defined.
(The other queries in this test are also underdetermined; but it looks like
they are regurgitating index rows in insertion order, so for the moment
assume that that behavior is stable enough.)
Per Greg Stark's experiments with VAX. Back-patch to 9.5 where this test
script was introduced.
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql
Avoid use of float arithmetic in bipartite_match.c.
commit : 4022f94c350f96fc5feff0503d3e2f2f6f9086cc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 23 Aug 2015 13:02:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 23 Aug 2015 13:02:13 -0400
Since the distances used in this algorithm are small integers (not more
than the size of the U set, in fact), there is no good reason to use float
arithmetic for them. Use short ints instead: they're smaller, faster, and
require no special portability assumptions.
Per testing by Greg Stark, which disclosed that the code got into an
infinite loop on VAX for lack of IEEE-style float infinities. We don't
really care all that much whether Postgres can run on a VAX anymore,
but there seems sufficient reason to change this code anyway.
In passing, make a few other small adjustments to make the code match
usual Postgres coding style a bit better.
M src/backend/lib/bipartite_match.c
M src/include/lib/bipartite_match.h
Fix typo in C comment.
commit : 57823244ad087a2dc807a6e60fefce26f81bd5dc
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sun, 23 Aug 2015 10:41:08 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sun, 23 Aug 2015 10:41:08 -0500
Merlin Moncure
Backpatch to 9.5, where the misspelling was introduced
M src/backend/commands/trigger.c
Improve whitespace
commit : 27347c4841ca880af61f1b767f24c6e248686c99
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 22 Aug 2015 21:41:29 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 22 Aug 2015 21:41:29 -0400
M src/backend/utils/misc/postgresql.conf.sample
Improve spelling
commit : 63b04a37626ab5982c14438e408e35d88328ad87
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 22 Aug 2015 21:41:13 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 22 Aug 2015 21:41:13 -0400
M contrib/btree_gist/Makefile
Avoid O(N^2) behavior when enlarging SPI tuple table in spi_printtup().
commit : 68a14ca74be03ab189b83c2bbf0b68c5d1daba44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 20:32:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 20:32:11 -0400
For no obvious reason, spi_printtup() was coded to enlarge the tuple
pointer table by just 256 slots at a time, rather than doubling the size at
each reallocation, as is our usual habit. For very large SPI results, this
makes for O(N^2) time spent in repalloc(), which of course soon comes to
dominate the runtime. Use the standard doubling approach instead.
This is a longstanding performance bug, so back-patch to all active
branches.
Neil Conway
M src/backend/executor/spi.c
Clean up roles from roleattributes test
commit : 93fcb4ae3e4b20e8562f0a8cab3a3a486ad84e76
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 21 Aug 2015 15:51:29 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 21 Aug 2015 15:51:29 -0400
Having the roles remain after the test ends up causing repeated 'make
installcheck' runs to fail and may be risky from a security perspective
also, so remove them at the end of the test.
M src/test/regress/expected/roleattributes.out
M src/test/regress/sql/roleattributes.sql
Do not allow *timestamp to be passed as NULL
commit : d6968e625770d021c8db15094ea732b40be2c5aa
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 21 Aug 2015 14:36:54 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 21 Aug 2015 14:36:54 -0300
The code had bugs that would cause crashes if NULL was passed as that
argument (originally intended to mean not to bother returning its
value), and after inspection it turns out that nothing seems interested
in the case that *ts is NULL anyway. Therefore, remove the partial
checks intended to support that case.
Author: Michael Paquier
though I didn't include a proposed Assert.
Backpatch to 9.5.
M src/backend/access/transam/commit_ts.c
Fix plpython crash when returning string representation of a RECORD result.
commit : 19446280fce0b9aebef40c6b5390cf1170c5c770
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 12:21:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 12:21:37 -0400
PLyString_ToComposite() blithely overwrote proc->result.out.d, even though
for a composite result type the other union variant proc->result.out.r is
the one that should be valid. This could result in a crash if out.r had
in fact been filled in (proc->result.is_rowtype == 1) and then somebody
later attempted to use that data; as per bug #13579 from Paweł Michalak.
Just to add insult to injury, it didn't work for RECORD results anyway,
because record_in() would refuse the case.
Fix by doing the I/O function lookup in a local PLyTypeInfo variable,
as we were doing already in PLyObject_ToComposite(). This is not a great
technique because any fn_extra data allocated by the input function will
be leaked permanently (thanks to using TopMemoryContext as fn_mcxt).
But that's a pre-existing issue that is much less serious than a crash,
so leave it to be fixed separately.
This bug would be a potential security issue, except that plpython is
only available to superusers and the crash requires coding the function
in a way that didn't work before today's patches.
Add regression test cases covering all the supported methods of converting
composite results.
Back-patch to 9.1 where the faulty coding was introduced.
M src/pl/plpython/expected/plpython_composite.out
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/sql/plpython_composite.sql
Allow record_in() and record_recv() to work for transient record types.
commit : 20bef3fe2ed180c64a5140b8ebeba439afd1bb95
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 11:19:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 11:19:33 -0400
If we have the typmod that identifies a registered record type, there's no
reason that record_in() should refuse to perform input conversion for it.
Now, in direct SQL usage, record_in() will always be passed typmod = -1
with type OID RECORDOID, because no typmodin exists for type RECORD, so the
case can't arise. However, some InputFunctionCall users such as PLs may be
able to supply the right typmod, so we should allow this to support them.
Note: the previous coding and comment here predate commit 59c016aa9f490b53.
There has been no case since 8.1 in which the passed type OID wouldn't be
valid; and if it weren't, this error message wouldn't be apropos anyway.
Better to let lookup_rowtype_tupdesc complain about it.
Back-patch to 9.1, as this is necessary for my upcoming plpython fix.
I'm committing it separately just to make it a bit more visible in the
commit history.
M src/backend/utils/adt/rowtypes.c
Rename 'cmd' to 'cmd_name' in CreatePolicyStmt
commit : 49f9a2831b8c5c8941eec9baa5d44b471971704e
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 21 Aug 2015 08:22:29 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 21 Aug 2015 08:22:29 -0400
To avoid confusion, rename CreatePolicyStmt's 'cmd' to 'cmd_name',
parse_policy_command's 'cmd' to 'polcmd', and AlterPolicy's 'cmd_datum'
to 'polcmd_datum', per discussion with Noah and as a follow-up to his
correction of copynodes/equalnodes handling of the CreatePolicyStmt
'cmd' field.
Back-patch to 9.5 where the CreatePolicyStmt was introduced, as we
are still only in alpha.
M src/backend/commands/policy.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/parser/gram.y
M src/include/nodes/parsenodes.h
In AlterRole, make bypassrls an int
commit : 0070fd8d3c1c8a733c041bfcedd41e38cee0a963
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 21 Aug 2015 08:22:29 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 21 Aug 2015 08:22:29 -0400
When reworking bypassrls in AlterRole to operate the same way the other
attribute handling is done, I missed that the variable was incorrectly a
bool rather than an int. This meant that on platforms with an unsigned
char, we could end up with incorrect behavior during ALTER ROLE.
Pointed out by Andres thanks to tests he did changing our bool to be the
one from stdbool.h which showed this and a number of other issues.
Add regression tests to test CREATE/ALTER role for the various role
attributes. Arrange to leave roles behind for testing pg_dumpall, but
none which have the LOGIN attribute.
Back-patch to 9.5 where the AlterRole bug exists.
M src/backend/commands/user.c
A src/test/regress/expected/roleattributes.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
A src/test/regress/sql/roleattributes.sql
doc: Whitespace and formatting fixes
commit : 338a8622560f45062958dd290abed66c6004e0ef
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 20 Aug 2015 22:34:35 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 20 Aug 2015 22:34:35 -0400
M doc/src/sgml/brin.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/pageinspect.sgml
M doc/src/sgml/ref/drop_policy.sgml
M doc/src/sgml/ref/insert.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/syntax.sgml
Update config.guess and config.sub
commit : f17e2471734c73da8079451c17a2212884979168
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 19 Aug 2015 11:45:52 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 19 Aug 2015 11:45:52 -0400
M config/config.guess
M config/config.sub
Fix bug in calculations of hash join buckets.
commit : 24bf2ee22233244eb9e2c71de754b1c71258d004
author : Kevin Grittner <kgrittn@postgresql.org>
date : Wed, 19 Aug 2015 08:31:13 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Wed, 19 Aug 2015 08:31:13 -0500
Commit 8cce08f168481c5fc5be4e7e29b968e314f1b41e used a left-shift
on a literal of 1 that could (in large allocations) be shifted by
31 or more bits. This was assigned to a local variable that was
already declared to be a long to protect against overruns of int,
but the literal in this shift needs to be declared long to allow it
to work correctly in some compilers.
Backpatch to 9.5, where the bug was introduced.
Report and patch by KaiGai Kohei, slighly modified based on
discussion.
M src/backend/executor/nodeHash.c
Fix a few bogus statement type names in plpgsql error messages.
commit : 4c3754ffe0f5f85cdecd01d7c1ab55df94559302
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Aug 2015 19:22:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Aug 2015 19:22:37 -0400
plpgsql's error location context messages ("PL/pgSQL function fn-name line
line-no at stmt-type") would misreport a CONTINUE statement as being an
EXIT, and misreport a MOVE statement as being a FETCH. These are clear
bugs that have been there a long time, so back-patch to all supported
branches.
In addition, in 9.5 and HEAD, change the description of EXECUTE from
"EXECUTE statement" to just plain EXECUTE; there seems no good reason why
this statement type should be described differently from others that have
a well-defined head keyword. And distinguish GET STACKED DIAGNOSTICS from
plain GET DIAGNOSTICS. These are a bit more of a judgment call, and also
affect existing regression-test outputs, so I did not back-patch into
stable branches.
Pavel Stehule and Tom Lane
M src/pl/plpgsql/src/pl_funcs.c
M src/test/regress/expected/event_trigger.out
M src/test/regress/expected/plpgsql.out
M src/test/regress/expected/triggers.out
psql: Make EXECUTE PROCEDURE tab completion a bit narrower.
commit : f25087d26aa9c63ce90cd8e87131b6dbe943ba86
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 18 Aug 2015 12:49:04 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 18 Aug 2015 12:49:04 -0400
If the user has typed GRANT EXECUTE, the correct completion is "ON",
not "PROCEDURE".
Daniel Verite
M src/bin/psql/tab-complete.c
Improve configure test for the sse4.2 crc instruction.
commit : 2c5c11ae9e0c5f4605fb9cdd2e8bd94fe0a06d95
author : Andres Freund <andres@anarazel.de>
date : Mon, 17 Aug 2015 11:15:46 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 17 Aug 2015 11:15:46 +0200
With optimizations enabled at least one compiler, clang 3.7, optimized
away the crc intrinsics knowing that the result went on unused and has
no side effects. That can trigger errors in code generation when the
intrinsic is used, as we chose to use the intrinsics without any
additional compiler flag. Return the computed value to prevent that.
With some more pedantic warning flags (-Wold-style-definition) the
configure test failed to recognize the existence of _mm_crc32_u*
intrinsics due to an independent warning in the test because the test
turned on -Werror, but that's not actually needed here.
Discussion: 20150814092039.GH4955@awork2.anarazel.de
Backpatch: 9.5, where the use of crc intrinsics was integrated.
M config/c-compiler.m4
M configure
Add docs about postgres_fdw's setting of search_path and other GUCs.
commit : 9a18a2bfb9f93e4a1aa405e752608746e04619f2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 14:31:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 14:31:04 -0400
This behavior wasn't documented, but it should be because it's user-visible
in triggers and other functions executed on the remote server.
Per question from Adam Fuchs.
Back-patch to 9.3 where postgres_fdw was added.
M doc/src/sgml/postgres-fdw.sgml
Improve documentation about MVCC-unsafe utility commands.
commit : 656363d83970195e875c5c2153ef097e112b859f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 13:30:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 13:30:16 -0400
The table-rewriting forms of ALTER TABLE are MVCC-unsafe, in much the same
way as TRUNCATE, because they replace all rows of the table with newly-made
rows with a new xmin. (Ideally, concurrent transactions with old snapshots
would continue to see the old table contents, but the data is not there
anymore --- and if it were there, it would be inconsistent with the table's
updated rowtype, so there would be serious implementation problems to fix.)
This was nowhere documented though, and the problem was only documented for
TRUNCATE in a note in the TRUNCATE reference page. Create a new "Caveats"
section in the MVCC chapter that can be home to this and other limitations
on serializable consistency.
In passing, fix a mistaken statement that VACUUM and CLUSTER would reclaim
space occupied by a dropped column. They don't reconstruct existing tuples
so they couldn't do that.
Back-patch to all supported branches.
M doc/src/sgml/mvcc.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/truncate.sgml
Repair unsafe use of shared typecast-lookup table in plpgsql DO blocks.
commit : 1f6a7eba466d0cb31cd2f374603799935fcb9df8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 12:00:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 12:00:36 -0400
DO blocks use private simple_eval_estates to avoid intra-transaction memory
leakage, cf commit c7b849a89. I had forgotten about that while writing
commit 0fc94a5ba, but it means that expression execution trees created
within a DO block disappear immediately on exiting the DO block, and hence
can't safely be linked into plpgsql's session-wide cast hash table.
To fix, give a DO block a private cast hash table to go with its private
simple_eval_estate. This is less efficient than one could wish, since
DO blocks can no longer share any cast lookup work with other plpgsql
execution, but it shouldn't be too bad; in any case it's no worse than
what happened in DO blocks before commit 0fc94a5ba.
Per bug #13571 from Feike Steenbergen. Preliminary analysis by
Oleksandr Shulgin.
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
M src/test/regress/expected/plpgsql.out
M src/test/regress/sql/plpgsql.sql
Correct type of waitMode variable in ExecInsertIndexTuples().
commit : 6942663d1bde1e6d6e6da38710d3e6aade900e63
author : Andres Freund <andres@anarazel.de>
date : Sat, 15 Aug 2015 17:02:47 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 15 Aug 2015 17:02:47 +0200
It was a bool, even though it should be CEOUC_WAIT_MODE. That's unlikely
to have a negative effect with the current definition of bool (char),
but it's definitely wrong.
Discussion: 20150812084351.GD8470@awork2.anarazel.de
Backpatch: 9.5, where ON CONFLICT was merged
M src/backend/executor/execIndexing.c
vacuumdb: Don't assign negative values to a boolean.
commit : 32951f9aa9acfd4b6318f6daf39c3d1c10a264ba
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 16:49:36 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 16:49:36 +0200
Since a17923204736 (vacuumdb: enable parallel mode) -1 has been assigned
to a boolean. That can, justifiedly, trigger compiler warnings. There's
also no need for ternary logic, result was only ever set to 0 or -1. So
don't.
Discussion: 20150812084351.GD8470@awork2.anarazel.de
Backpatch: 9.5
M src/bin/scripts/vacuumdb.c
Don't use 'bool' as a struct member name in help_config.c.
commit : d19c1b0b24d53f41222bf808dc6b40404b2954a1
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 16:02:20 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 16:02:20 +0200
Doing so doesn't work if bool is a macro rather than a typedef.
Although c.h spends some effort to support configurations where bool is
a preexisting macro, help_config.c has existed this way since
2003 (b700a6), and there have not been any reports of
problems. Backpatch anyway since this is as riskless as it gets.
Discussion: 20150812084351.GD8470@awork2.anarazel.de
Backpatch: 9.0-master
M src/backend/utils/misc/help_config.c
Use the correct type for TableInfo->relreplident.
commit : feb473a57acb648f29e1520b07b146ba1dc4e22d
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 15:52:10 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 15:52:10 +0200
Mistakenly relreplident was stored as a bool. That works today as c.h
typedefs bool to a char, but isn't very future proof.
Discussion: 20150812084351.GD8470@awork2.anarazel.de
Backpatch: 9.4 where replica identity was introduced.
M src/bin/pg_dump/pg_dump.h
Encoding PG_UHC is code page 949.
commit : f19ad6fbe46afe5005fb0f38ebd436c7cfcbb9ec
author : Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:13 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:13 -0400
This fixes presentation of non-ASCII messages to the Windows event log
and console in rare cases involving Korean locale. Processes like the
postmaster and checkpointer, but not processes attached to databases,
were affected. Back-patch to 9.4, where MessageEncoding was introduced.
The problem exists in all supported versions, but this change has no
effect in the absence of the code recognizing PG_UHC MessageEncoding.
Noticed while investigating bug #13427 from Dmitri Bourlatchkov.
M src/backend/utils/mb/encnames.c
Restore old pgwin32_message_to_UTF16() behavior outside transactions.
commit : 92516bf1954bd53914f0423bd2817487bd367596
author : Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:09 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:09 -0400
Commit 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 replaced with a hard
error the dubious pg_do_encoding_conversion() behavior when outside a
transaction. Reintroduce the historic soft failure locally within
pgwin32_message_to_UTF16(). This fixes errors when writing messages in
less-common encodings to the Windows event log or console. Back-patch
to 9.4, where the aforementioned commit first appeared.
Per bug #13427 from Dmitri Bourlatchkov.
M src/backend/utils/mb/mbutils.c
Update key words table for 9.5
commit : b435f191abbdd09bb97bc386ffe71d24d6934f57
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 14 Aug 2015 12:10:35 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 14 Aug 2015 12:10:35 -0400
M doc/src/sgml/keywords.sgml
MSVC: Exclude 'brin' contrib module
commit : 7321841b7c7edc1fd9f6545638e890fdb963aea3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 19:28:54 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 19:28:54 -0300
The build script is not able to parse the Makefile, so remove it.
M src/tools/msvc/Mkvcbuild.pm
Re-add BRIN isolation test
commit : ae372e60b98990863058edc596df8a20207b08d0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 14:41:52 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 14:41:52 -0300
This time, instead of using a core isolation test, put it on its own
test module; this way it can require the pageinspect module to be
present before running.
The module's Makefile is loosely modeled after test_decoding's, so that
it's easy to add further tests for either pg_regress or isolationtester
later.
Backpatch to 9.5.
M src/test/modules/Makefile
A src/test/modules/brin/.gitignore
A src/test/modules/brin/Makefile
A src/test/modules/brin/expected/summarization-and-inprogress-insertion.out
A src/test/modules/brin/specs/summarization-and-inprogress-insertion.spec
Improve regression test case to avoid depending on system catalog stats.
commit : 657cdb3a21b09a7f02497b8c2e9f46b7bfc59993
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Aug 2015 13:25:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Aug 2015 13:25:01 -0400
In commit 95f4e59c32866716 I added a regression test case that examined
the plan of a query on system catalogs. That isn't a terribly great idea
because the catalogs tend to change from version to version, or even
within a version if someone makes an unrelated regression-test change that
populates the catalogs a bit differently. Usually I try to make planner
test cases rely on test tables that have not changed since Berkeley days,
but I got sloppy in this case because the submitted crasher example queried
the catalogs and I didn't spend enough time on rewriting it. But it was a
problem waiting to happen, as I was rudely reminded when I tried to port
that patch into Salesforce's Postgres variant :-(. So spend a little more
effort and rewrite the query to not use any system catalogs. I verified
that this version still provokes the Assert if 95f4e59c32866716's code fix
is reverted.
I also removed the EXPLAIN output from the test, as it turns out that the
assertion occurs while considering a plan that isn't the one ultimately
selected anyway; so there's no value in risking any cross-platform
variation in that printout.
Back-patch to 9.2, like the previous patch.
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Use materialize SRF mode in brin_page_items
commit : 1136971daef209a40eb495b4bd74ce50fbd0fe63
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 13:02:10 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 13:02:10 -0300
This function was using the single-value-per-call mechanism, but the
code relied on a relcache entry that wasn't kept open across calls.
This manifested as weird errors in buildfarm during the short time that
the "brin-1" isolation test lived.
Backpatch to 9.5, where it was introduced.
M contrib/pageinspect/brinfuncs.c
Fix declaration of isarray variable.
commit : edebddbb845575206d07145af2d718609b01f6ad
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 13 Aug 2015 13:22:29 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 13 Aug 2015 13:22:29 +0200
Found and fixed by Andres Freund.
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/extern.h
Fix unitialized variables
commit : 652ca927ca4d9553691b9c6385111bea353070d8
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 00:12:07 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Aug 2015 00:12:07 -0300
As complained by clang, reported by Andres Freund. Brown paper bag bug
in ccc4c074994d.
Add some comments, too.
Backpatch to 9.5, like that one.
M src/backend/access/brin/brin_pageops.c
Undo mistaken tightening in join_is_legal().
commit : ec94bc1473475128ef4e7b62636e66effd314102
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 21:18:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 21:18:45 -0400
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we can miss valid plans, and might indeed fail
to find a plan at all, as in recent report from Andreas Seltenreich.
That code was added way back in commit c17117649b9ae23d, but I failed to
include a regression test case then; my bad. Put it back with a better
explanation, and a test this time. The logic does end up a bit different
than before though: I now believe it's appropriate to make this check
first, thereby allowing such a case whether or not we'd consider the
previous SJ(s) to commute with this one. (Presumably, we already decided
they did; but it was confusing to have this consideration in the middle
of the code that was handling the other case.)
Back-patch to all active branches, like the previous patch.
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Close some holes in BRIN page assignment
commit : fc0a6402306db3cc93a5f760acabab687998be1d
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 12 Aug 2015 14:20:38 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 12 Aug 2015 14:20:38 -0300
In some corner cases, it is possible for the BRIN index relation to be
extended by brin_getinsertbuffer but the new page not be used
immediately for anything by its callers; when this happens, the page is
initialized and the FSM is updated (by brin_getinsertbuffer) with the
info about that page, but these actions are not WAL-logged. A later
index insert/update can use the page, but since the page is already
initialized, the initialization itself is not WAL-logged then either.
Replay of this sequence of events causes recovery to fail altogether.
There is a related corner case within brin_getinsertbuffer itself, in
which we extend the relation to put a new index tuple there, but later
find out that we cannot do so, and do not return the buffer; the page
obtained from extension is not even initialized. The resulting page is
lost forever.
To fix, shuffle the code so that initialization is not the
responsibility of brin_getinsertbuffer anymore, in normal cases;
instead, the initialization is done by its callers (brin_doinsert and
brin_doupdate) once they're certain that the page is going to be used.
When either those functions determine that the new page cannot be used,
before bailing out they initialize the page as an empty regular page,
enter it in FSM and WAL-log all this. This way, the page is usable for
future index insertions, and WAL replay doesn't find trying to insert
tuples in pages whose initialization didn't make it to the WAL. The
same strategy is used in brin_getinsertbuffer when it cannot return the
new page.
Additionally, add a new step to vacuuming so that all pages of the index
are scanned; whenever an uninitialized page is found, it is initialized
as empty and WAL-logged. This closes the hole that the relation is
extended but the system crashes before anything is WAL-logged about it.
We also take this opportunity to update the FSM, in case it has gotten
out of date.
Thanks to Heikki Linnakangas for finding the problem that kicked some
additional analysis of BRIN page assignment code.
Backpatch to 9.5, where BRIN was introduced.
Discussion: https://www.postgresql.org/message-id/20150723204810.GY5596@postgresql.org
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_pageops.c
M src/include/access/brin_page.h
M src/include/access/brin_pageops.h
Handle PQresultErrorField(PG_DIAG_SQLSTATE) returning NULL in streamutil.c.
commit : 2e6f6f3abe6fd249cc8a4d5eb194295ac3988b19
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 17:09:35 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 17:09:35 +0200
In ff27db5d I missed that PQresultErrorField() may return NULL if
there's no sqlstate associated with an error.
Spotted-By: Coverity
Reported-By: Michael Paquier
Discussion: CAB7nPqQ3o10SY6NVdU4pjq85GQTN5tbbkq2gnNUh2fBNU3rKyQ@mail.gmail.com
Backpatch: 9.5, like ff27db5d
M src/bin/pg_basebackup/streamutil.c
Fix two off-by-one errors in bufmgr.c.
commit : 43a8ed26c97e36d971b6018d1bc94ad5c52d169b
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 17:09:34 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 17:09:34 +0200
In 4b4b680c I passed a buffer index number (starting from 0) instead of
a proper Buffer id (which start from 1 for shared buffers) in two
places.
This wasn't noticed so far as one of those locations isn't compiled at
all (PrintPinnedBufs) and the other one (InvalidBuffer) requires a
unlikely, but possible, set of circumstances to trigger a symptom.
To reduce the likelihood of such incidents a bit also convert existing
open coded mappings from buffer descriptors to buffer ids with
BufferDescriptorGetBuffer().
Author: Qingqing Zhou
Reported-By: Qingqing Zhou
Discussion: CAJjS0u2ai9ooUisKtkV8cuVUtEkMTsbK8c7juNAjv8K11zeCQg@mail.gmail.com
Backpatch: 9.5 where the private ref count infrastructure was introduced
M src/backend/storage/buffer/bufmgr.c
Fix some possible low-memory failures in regexp compilation.
commit : c5bfcc18a09b3f56ae0fd434ff6c72bd185949c1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 00:48:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 00:48:11 -0400
newnfa() failed to set the regex error state when malloc() fails.
Several places in regcomp.c failed to check for an error after calling
subre(). Each of these mistakes could lead to null-pointer-dereference
crashes in memory-starved backends.
Report and patch by Andreas Seltenreich. Back-patch to all branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
Minor cleanups in slot related code.
commit : 58d2e7fb70584598e026a39f515c5f3c5e589857
author : Andres Freund <andres@anarazel.de>
date : Tue, 11 Aug 2015 12:32:49 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 11 Aug 2015 12:32:49 +0200
Fix a bunch of typos, and remove two superflous includes.
Author: Gurjeet Singh
Discussion: CABwTF4Wh_dBCzTU=49pFXR6coR4NW1ynb+vBqT+Po=7fuq5iCw@mail.gmail.com
Backpatch: 9.4
M src/backend/replication/logical/logical.c
M src/backend/replication/slot.c
Fix privilege dumping from servers too old to have that type of privilege.
commit : 1cd46851678b304b684f7ab68b4ae888828027f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 20:10:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 20:10:15 -0400
pg_dump produced fairly silly GRANT/REVOKE commands when dumping types from
pre-9.2 servers, and when dumping functions or procedural languages from
pre-7.3 servers. Those server versions lack the typacl, proacl, and/or
lanacl columns respectively, and pg_dump substituted default values that
were in fact incorrect. We ended up revoking all the owner's own
privileges for the object while granting all privileges to PUBLIC.
Of course the owner would then have those privileges again via PUBLIC, so
long as she did not try to revoke PUBLIC's privileges; which may explain
the lack of field reports. Nonetheless this is pretty silly behavior.
The stakes were raised by my recent patch to make pg_dump dump shell types,
because 9.2 and up pg_dump would proceed to emit bogus GRANT/REVOKE
commands for a shell type if dumping from a pre-9.2 server; and the server
will not accept GRANT/REVOKE commands for a shell type. (Perhaps it
should, but that's a topic for another day.) So the resulting dump script
wouldn't load without errors.
The right thing to do is to act as though these objects have default
privileges (null ACL entries), which causes pg_dump to print no
GRANT/REVOKE commands at all for them. That fixes the silly results
and also dodges the problem with shell types.
In passing, modify getProcLangs() to be less creatively different about
how to handle missing columns when dumping from older server versions.
Every other data-acquisition function in pg_dump does that by substituting
appropriate default values in the version-specific SQL commands, and I see
no reason why this one should march to its own drummer. Its use of
"SELECT *" was likewise not conformant with anyplace else, not to mention
it's not considered good SQL style for production queries.
Back-patch to all supported versions. Although 9.0 and 9.1 pg_dump don't
have the issue with typacl, they are more likely than newer versions to be
used to dump from ancient servers, so we ought to fix the proacl/lanacl
issues all the way back.
M src/bin/pg_dump/pg_dump.c
Accept alternate spellings of __sparcv7 and __sparcv8.
commit : f8e4e0e3f3fe261317c4fd751ea4b9379ac54e94
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:34:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:34:51 -0400
Apparently some versions of gcc prefer __sparc_v7__ and __sparc_v8__.
Per report from Waldemar Brodkorb.
M src/include/storage/s_lock.h
Further mucking with PlaceHolderVar-related restrictions on join order.
commit : fda25b22018095fa86bee5a31920344976eb7479
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:18:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:18:17 -0400
Commit 85e5e222b1dd02f135a8c3bf387d0d6d88e669bd turns out not to have taken
care of all cases of the partially-evaluatable-PlaceHolderVar problem found
by Andreas Seltenreich's fuzz testing. I had set it up to check for risky
PHVs only in the event that we were making a star-schema-based exception to
the param_source_rels join ordering heuristic. However, it turns out that
the problem can occur even in joins that satisfy the param_source_rels
heuristic, in which case allow_star_schema_join() isn't consulted.
Refactor so that we check for risky PHVs whenever the proposed join has
any remaining parameterization.
Back-patch to 9.2, like the previous patch (except for the regression test
case, which only works back to 9.3 because it uses LATERAL).
Note that this discovery implies that problems of this sort could've
occurred in 9.2 and up even before the star-schema patch; though I've not
tried to prove that experimentally.
M src/backend/optimizer/path/joinpath.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Temporarily(?) remove BRIN isolation test.
commit : 0ae43b6a631ce8507ef4bd68ce297853a8986fe8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 10:22:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 10:22:37 -0400
Commit 2834855cb added a not-very-carefully-thought-out isolation test
to check a BRIN index bug fix. The test depended on the availability
of the pageinspect contrib module, which meant it did not work in
several common testing scenarios such as "make check-world". It's not
clear whether we want a core test depending on a contrib module like
that, but in any case, failing to deal with the possibility that the
module isn't present in the installation-under-test is not acceptable.
Remove that test pending some better solution.
D src/test/isolation/expected/brin-1.out
M src/test/isolation/isolation_schedule
D src/test/isolation/specs/brin-1.spec
Fix copy & paste mistake in pg_get_replication_slots().
commit : 2949987d37cf8d13ca0582610c17a4ddbc246193
author : Andres Freund <andres@anarazel.de>
date : Mon, 10 Aug 2015 13:28:19 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 10 Aug 2015 13:28:19 +0200
XLogRecPtr was compared with InvalidTransactionId instead of
InvalidXLogRecPtr. As both are defined to the same value this doesn't
cause any actual problems, but it's still wrong.
Backpatch: 9.4-master, bug was introduced in 9.4
M src/backend/replication/slotfuncs.c
Don't start to stream after pg_receivexlog --create-slot.
commit : 86baf3c24dfb6f351d0a1653552d0973ad7c4e3d
author : Andres Freund <andres@anarazel.de>
date : Mon, 10 Aug 2015 13:28:19 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 10 Aug 2015 13:28:19 +0200
Immediately starting to stream after --create-slot is inconvenient in a
number of situations (e.g. when configuring a slot for use in
recovery.conf) and it's easy to just call pg_receivexlog twice in the
rest of the cases.
Author: Michael Paquier
Discussion: CAB7nPqQ9qEtuDiKY3OpNzHcz5iUA+DUX9FcN9K8GUkCZvG7+Ew@mail.gmail.com
Backpatch: 9.5, where the option was introduced
M doc/src/sgml/ref/pg_receivexlog.sgml
M src/bin/pg_basebackup/pg_receivexlog.c
Remove gram.y's precedence declaration for OVERLAPS.
commit : 6e03d476c93458203c1c0307abaf9068d5793aeb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Aug 2015 19:01:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Aug 2015 19:01:04 -0400
The allowed syntax for OVERLAPS, viz "row OVERLAPS row", is sufficiently
constrained that we don't actually need a precedence declaration for
OVERLAPS; indeed removing this declaration does not change the generated
gram.c file at all. Let's remove it to avoid confusion about whether
OVERLAPS has precedence or not. If we ever generalize what we allow for
OVERLAPS, we might need to put back a precedence declaration for it,
but we might want some other level than what it has today --- and leaving
the declaration there would just risk confusion about whether that would
be an incompatible change.
Likewise, remove OVERLAPS from the documentation's precedence table.
Per discussion with Noah Misch. Back-patch to 9.5 where we hacked up some
nearby precedence decisions.
M doc/src/sgml/syntax.sgml
M src/backend/parser/gram.y
Fix typo in LDAP example
commit : 64ac985b5946de4bf7cae21383508477023e0688
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 9 Aug 2015 14:49:47 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 9 Aug 2015 14:49:47 +0200
Reported by William Meitzen
M doc/src/sgml/client-auth.sgml
Fix broken multibyte regression tests.
commit : 479cb1e420c40d78b49535c0ceeaa5f65c7d6797
author : Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 9 Aug 2015 10:55:41 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 9 Aug 2015 10:55:41 +0900
commit 9043Fe390f4f0b4586cfe59cbd22314b9c3e2957 broke multibyte
regression tests because the commit removes the warning message when
temporary hash indexes is created, which has been added by commit
07af523870bcfe930134054febd3a6a114942e5b.
Back patched to 9.5 stable tree.
M src/test/mb/expected/big5.out
M src/test/mb/expected/euc_jp.out
M src/test/mb/expected/euc_kr.out
M src/test/mb/expected/euc_tw.out
M src/test/mb/expected/gb18030.out
M src/test/mb/expected/mule_internal.out
M src/test/mb/expected/sjis.out
M src/test/mb/expected/utf8.out
docs: fix typo in rules.sgml
commit : 5e0cef8a667746d4abaec16f395b150f46493d80
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 8 Aug 2015 20:40:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 8 Aug 2015 20:40:53 -0400
Report by Dean Rasheed
Patch by Dean Rasheed
Backpatch through 9.5
M doc/src/sgml/rules.sgml
9.5 release notes: add increase buffer mapping partitions item
commit : 966aa524edfe8bac837caf0e48ca00d08d8dd5df
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 8 Aug 2015 13:38:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 8 Aug 2015 13:38:31 -0400
Report by Robert Haas, Andres Freund
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
Further adjustments to PlaceHolderVar removal.
commit : 085338822a2364b5d3afbb13c635b00df43ade45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 7 Aug 2015 14:13:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 7 Aug 2015 14:13:38 -0400
A new test case from Andreas Seltenreich showed that we were still a bit
confused about removing PlaceHolderVars during join removal. Specifically,
remove_rel_from_query would remove a PHV that was used only underneath
the removable join, even if the place where it's used was the join partner
relation and not the join clause being deleted. This would lead to a
"too late to create a new PlaceHolderInfo" error later on. We can defend
against that by checking ph_eval_at to see if the PHV could possibly be
getting used at some partner rel.
Also improve some nearby LATERAL-related logic. I decided that the check
on ph_lateral needed to take precedence over the check on ph_needed, in
case there's a lateral reference underneath the join being considered.
(That may be impossible, but I'm not convinced of it, and it's easy enough
to defend against the case.) Also, I realized that remove_rel_from_query's
logic for updating LateralJoinInfos is dead code, because we don't build
those at all until after join removal.
Back-patch to 9.3. Previous versions didn't have the LATERAL issues, of
course, and they also didn't attempt to remove PlaceHolderInfos during join
removal. (I'm starting to wonder if changing that was really such a great
idea.)
M src/backend/optimizer/plan/analyzejoins.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix attach-related race condition in shm_mq_send_bytes.
commit : caf89b31aa79b472a451a5b13657db0da43decee
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 7 Aug 2015 09:04:07 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 7 Aug 2015 09:04:07 -0500
Spotted by Antonin Houska.
M src/backend/storage/ipc/shm_mq.c
Address points made in post-commit review of replication origins.
commit : 37163e22bddb30a235c9748f49ad54d5e99db142
author : Andres Freund <andres@anarazel.de>
date : Fri, 7 Aug 2015 15:08:51 +0200
committer: Andres Freund <andres@anarazel.de>
date : Fri, 7 Aug 2015 15:08:51 +0200
Amit reviewed the replication origins patch and made some good
points. Address them. This fixes typos in error messages, docs and
comments and adds a missing error check (although in a
should-never-happen scenario).
Discussion: CAA4eK1JqUBVeWWKwUmBPryFaje4190ug0y-OAUHWQ6tD83V4xg@mail.gmail.com
Backpatch: 9.5, where replication origins were introduced.
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/replication-origins.sgml
M src/backend/access/transam/xloginsert.c
M src/backend/replication/logical/origin.c
9.5 release notes: updates from Andres Freund and Jeff Janes
commit : 892a18ebf0eb2d4182efbcfe12e2ddc142da3693
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 22:33:15 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 22:33:15 -0400
Report by Andres Freund and Jeff Janes
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
Fix old oversight in join removal logic.
commit : de0227d8aef18c1013b26ab193e48a5122435154
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 22:14:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 22:14:07 -0400
Commit 9e7e29c75ad441450f9b8287bd51c13521641e3b introduced an Assert that
join removal didn't reduce the eval_at set of any PlaceHolderVar to empty.
At first glance it looks like join_is_removable ensures that's true --- but
actually, the loop in join_is_removable skips PlaceHolderVars that are not
referenced above the join due to be removed. So, if we don't want any
empty eval_at sets, the right thing to do is to delete any now-unreferenced
PlaceHolderVars from the data structure entirely.
Per fuzz testing by Andreas Seltenreich. Back-patch to 9.3 where the
aforesaid Assert was added.
M src/backend/optimizer/plan/analyzejoins.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
9.5 release notes: mention ON CONFLICT DO NOTHING for FDWs
commit : e663f7561683c8ba7663a8c2115e5a00f84f17c2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 21:08:08 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 21:08:08 -0400
Report by Peter Geoghegan
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
Fix eclass_useful_for_merging to give valid results for appendrel children.
commit : a8725c2bade5cb5c51b1203f8037614b49f0c3f7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 20:14:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 20:14:37 -0400
Formerly, this function would always return "true" for an appendrel child
relation, because it would think that the appendrel parent was a potential
join target for the child. In principle that should only lead to some
inefficiency in planning, but fuzz testing by Andreas Seltenreich disclosed
that it could lead to "could not find pathkey item to sort" planner errors
in odd corner cases. Specifically, we would think that all columns of a
child table's multicolumn index were interesting pathkeys, causing us to
generate a MergeAppend path that sorts by all the columns. However, if any
of those columns weren't actually used above the level of the appendrel,
they would not get added to that rel's targetlist, which would result in
being unable to resolve the MergeAppend's sort keys against its targetlist
during createplan.c.
Backpatch to 9.3. In older versions, columns of an appendrel get added
to its targetlist even if they're not mentioned above the scan level,
so that the failure doesn't occur. It might be worth back-patching this
fix to older versions anyway, but I'll refrain for the moment.
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/path/pathkeys.c
M src/include/optimizer/paths.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
9.5 release notes: mention change to CRC-32C
commit : 054d33fd012c7b61518f2552b49e7c3653882605
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 18:03:39 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 18:03:39 -0400
Report by Andres Freund
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
9.5 release notes: adjustments suggested by Andres Freund
commit : 3e2a3727333441e3aa166639adbe735ab7b17712
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 17:34:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 17:34:38 -0400
Report by Andres Freund
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
9.5 release notes: add non-LEAKPROOF view pushdown mention
commit : 5437eba2eefb32895b912c92535012471701121c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 16:07:27 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 6 Aug 2015 16:07:27 -0400
Report by Dean Rasheed
Backpatch through 9.5
M doc/src/sgml/release-9.5.sgml
Further fixes for degenerate outer join clauses.
commit : df3b0f47b9766ff14f50c3e381d8c00a9c2b7a4f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 15:35:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 15:35:27 -0400
Further testing revealed that commit f69b4b9495269cc4 was still a few
bricks shy of a load: minor tweaking of the previous test cases resulted
in the same wrong-outer-join-order problem coming back. After study
I concluded that my previous changes in make_outerjoininfo() were just
accidentally masking the problem, and should be reverted in favor of
forcing syntactic join order whenever an upper outer join's predicate
doesn't mention a lower outer join's LHS. This still allows the
chained-outer-joins style that is the normally optimizable case.
I also tightened things up some more in join_is_legal(). It seems to me
on review that what's really happening in the exception case where we
ignore a mismatched special join is that we're allowing the proposed join
to associate into the RHS of the outer join we're comparing it to. As
such, we should *always* insist that the proposed join be a left join,
which eliminates a bunch of rather dubious argumentation. The case where
we weren't enforcing that was the one that was already known buggy anyway
(it had a violatable Assert before the aforesaid commit) so it hardly
deserves a lot of deference.
Back-patch to all active branches, like the previous patch. The added
regression test case failed in all branches back to 9.1, and I think it's
only an unrelated change in costing calculations that kept 9.0 from
choosing a broken plan.
M src/backend/optimizer/README
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix incorrect calculation in shm_mq_receive.
commit : 6d9864d900e3651413a94e1f86a93f6a03f4dc42
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 6 Aug 2015 13:25:45 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 6 Aug 2015 13:25:45 -0400
If some, but not all, of the length word has already been read, and the
next attempt to read sees exactly the number of bytes needed to complete
the length word, or fewer, then we'll incorrectly read less than all of
the available data.
Antonin Houska
M src/backend/storage/ipc/shm_mq.c
Fix `make installcheck` for serializable transactions.
commit : 680b82eea87291e7e14c03a647de654a65617f04
author : Kevin Grittner <kgrittn@postgresql.org>
date : Thu, 6 Aug 2015 10:35:14 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Thu, 6 Aug 2015 10:35:14 -0500
Commit e5550d5fec66aa74caad1f79b79826ec64898688 added some new
tests for ALTER TABLE which involved table scans. When
default_transaction_isolation = 'serializable' these acquire
relation-level SIReadLocks. The test results didn't cope with
that. Add SIReadLock as the minimum lock level for purposes of
these tests.
This could also be fixed by excluding this type of lock from the
my_locks view, but it would be a bug for SIReadLock to show up for
a relation which was not otherwise locked, so do it this way to
allow that sort of condition to cause a regression test failure.
There is some question whether we could avoid taking SIReadLocks
during these operations, but confirming the safety of that and
figuring out how to avoid the locks is not trivial, and would be
a separate patch.
Backpatch to 9.4 where the new tests were added.
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Improve includes introduced in the replication origins patch.
commit : 449b13313caf63c2db936cc46d8a25cfcd9a0d04
author : Andres Freund <andres@anarazel.de>
date : Thu, 6 Aug 2015 12:38:35 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 6 Aug 2015 12:38:35 +0200
pg_resetxlog.h contained two superfluous includes, origin.h superfluously
depended on logical.h, and pg_xlogdump's rmgrdesc.h only indirectly
included origin.h.
Backpatch: 9.5, where replication origins were introduced.
M src/bin/pg_resetxlog/pg_resetxlog.c
M src/bin/pg_xlogdump/rmgrdesc.c
M src/include/replication/origin.h
Reconcile nodes/*funcs.c with recent work.
commit : 4877281f3a1640577bedd1e92a83931469284368
author : Noah Misch <noah@leadboat.com>
date : Wed, 5 Aug 2015 20:44:27 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 5 Aug 2015 20:44:27 -0400
A few of the discrepancies had semantic significance, but I did not
track down the resulting user-visible bugs, if any. Back-patch to 9.5,
where all but one discrepancy appeared. The _equalCreateEventTrigStmt()
situation dates to 9.3 but does not affect semantics.
catversion bump due to readfuncs.c field order changes.
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/include/catalog/catversion.h
Link $(WIN32RES) into single-file modules only when PGFILEDESC is set.
commit : 2fcedad3cac54ec01034f3e225dd7915e59ff8ff
author : Noah Misch <noah@leadboat.com>
date : Wed, 5 Aug 2015 20:43:07 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 5 Aug 2015 20:43:07 -0400
Commit 0ffc201a51395ca71fe429ef86c872850a5850ee included this object
unconditionally. Being unprepared for that, most external, single-file
modules failed to build. This better aligns the GNU make build system
with the heuristic in the MSVC build's Project::AddDirResourceFile().
In-tree, installed modules set PGFILEDESC, so they will see no change.
Also, under PGXS, omit the nonfunctioning rule to build win32ver.rc.
Back-patch to 9.5, where the aforementioned commit first appeared.
M src/makefiles/Makefile.win32
M src/makefiles/pgxs.mk
Fix BRIN to use SnapshotAny during summarization
commit : 94a8b45feb3019d2e6b04806415dd8bc85994706
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 5 Aug 2015 16:20:50 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 5 Aug 2015 16:20:50 -0300
For correctness of summarization results, it is critical that the
snapshot used during the summarization scan is able to see all tuples
that are live to all transactions -- including tuples inserted or
deleted by in-progress transactions. Otherwise, it would be possible
for a transaction to insert a tuple, then idle for a long time while a
concurrent transaction executes summarization of the range: this would
result in the inserted value not being considered in the summary.
Previously we were trying to use a MVCC snapshot in conjunction with
adding a "placeholder" tuple in the index: the snapshot would see all
committed tuples, and the placeholder tuple would catch insertions by
any new inserters. The hole is that prior insertions by transactions
that are still in progress by the time the MVCC snapshot was taken were
ignored.
Kevin Grittner reported this as a bogus error message during vacuum with
default transaction isolation mode set to repeatable read (because the
error report mentioned a function name not being invoked during), but
the problem is larger than that.
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves
the way we need using SnapshotAny visibility rules. This change
simplifies the BRIN code a bit, mainly by removing large comments that
were mistaken. Instead, rely on the SnapshotAny semantics to provide
what it needs. (The business about a placeholder tuple needs to remain:
that covers the case that a transaction inserts a a tuple in a page that
summarization already scanned.)
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org
In passing, remove a couple of unused declarations from brin.h and
reword a comment to be proper English. This part submitted by Kevin
Grittner.
Backpatch to 9.5, where BRIN was introduced.
M src/backend/access/brin/brin.c
M src/backend/catalog/index.c
M src/include/access/brin.h
M src/include/catalog/index.h
A src/test/isolation/expected/brin-1.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/brin-1.spec
Make real sure we don't reassociate joins into or out of SEMI/ANTI joins.
commit : 06663971bba43ea967daf00fff0b70ee066c3a13
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Aug 2015 14:39:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Aug 2015 14:39:07 -0400
Per the discussion in optimizer/README, it's unsafe to reassociate anything
into or out of the RHS of a SEMI or ANTI join. An example from Piotr
Stefaniak showed that join_is_legal() wasn't sufficiently enforcing this
rule, so lock it down a little harder.
I couldn't find a reasonably simple example of the optimizer trying to
do this, so no new regression test. (Piotr's example involved the random
search in GEQO accidentally trying an invalid case and triggering a sanity
check way downstream in clause selectivity estimation, which did not seem
like a sequence of events that would be useful to memorialize in a
regression test as-is.)
Back-patch to all active branches.
M src/backend/optimizer/path/joinrels.c
Fix debug message output when connecting to a logical slot.
commit : 34a4318e7d64d93d48add738257ae0f6289799f6
author : Andres Freund <andres@anarazel.de>
date : Wed, 5 Aug 2015 13:26:01 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 5 Aug 2015 13:26:01 +0200
Previously the message erroneously printed the same LSN twice as the
assignment to the start_lsn variable was before the message. Correct
that.
Reported-By: Marko Tiikkaja
Author: Marko Tiikkaja
Backpatch: 9.5, where logical decoding was introduced
M src/backend/replication/logical/logical.c
Fix comment atomics.h.
commit : 04521eba3f024fdc226d6f0465e2bba7d37828a7
author : Andres Freund <andres@anarazel.de>
date : Wed, 5 Aug 2015 13:06:04 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 5 Aug 2015 13:06:04 +0200
I appear to accidentally have switched the comments for
pg_atomic_write_u32 and pg_atomic_read_u32 around. Also fix some minor
typos I found while fixing.
Noticed-By: Amit Kapila
Backpatch: 9.5
M src/include/port/atomics.h
Docs: add an explicit example about controlling overall greediness of REs.
commit : 5c499d5cd2da2fd67f1b234a2994dd940f28fbc2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 21:09:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 21:09:12 -0400
Per discussion of bug #13538.
M doc/src/sgml/func.sgml
Fix pg_dump to dump shell types.
commit : 1f507c7e9dc5b2e8373018fea2f002531c9c1d3a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 19:34:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 19:34:12 -0400
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell type behind,
for convenience in testing the case in pg_dump and pg_upgrade.
Back-patch to all supported branches.
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/test/regress/expected/create_type.out
M src/test/regress/sql/create_type.sql
Fix bogus "out of memory" reports in tuplestore.c.
commit : e2035dc9a7a8056eab7c33a1c677cd25312eb312
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 18:18:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 18:18:46 -0400
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied that logic into tuplestore.c without
noticing that the assumption failed to hold for the much smaller array
elements used by tuplestore. Given rather small work_mem, this could
result in an improper complaint about "unexpected out-of-memory situation",
as reported by Brent DeSpain in bug #13530.
The easiest way to fix this is just to increase tuplestore's initial
array size so that the assumption holds. Rather than relying on magic
constants, though, let's export a #define from aset.c that represents
the safe allocation threshold, and make tuplestore's calculation depend
on that.
Do the same in tuplesort.c to keep the logic looking parallel, even though
tuplesort.c isn't actually at risk at present. This will keep us from
breaking it if we ever muck with the allocation parameters in aset.c.
Back-patch to all supported versions. The error message doesn't occur
pre-9.3, not so much because the problem can't happen as because the
pre-9.3 tuplestore code neglected to check for it. (The chance of
trouble is a great deal larger as of 9.3, though, due to changes in the
array-size-increasing strategy.) However, allowing LACKMEM() to become
true unexpectedly could still result in less-than-desirable behavior,
so let's patch it all the way back.
M src/backend/utils/mmgr/aset.c
M src/backend/utils/sort/tuplesort.c
M src/backend/utils/sort/tuplestore.c
M src/include/utils/memutils.h
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
commit : a6f43986bf5a6a5b36c899aa9b12f26e5fab687e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 14:55:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 14:55:32 -0400
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation and some upper-level outer relation. That's fine so long as we're
talking about distinct parameters; but the patch also allowed creation of
nestloop paths for cases where the inner relation's parameter was a
PlaceHolderVar whose eval_at set included the current outer relation and
some upper-level one. That does *not* work.
In principle we could allow such a PlaceHolderVar to be evaluated at the
lower join node using values passed down from the upper relation along with
values from the join's own outer relation. However, nodeNestloop.c only
supports simple Vars not arbitrary expressions as nestloop parameters.
createplan.c is also a few bricks shy of being able to handle such cases;
it misplaces the PlaceHolderVar parameters in the plan tree, which is why
the visible symptoms of this bug are "plan should not reference subplan's
variable" and "failed to assign all NestLoopParams to plan nodes" planner
errors.
Adding the necessary complexity to make this work doesn't seem like it
would be repaid in significantly better plans, because in cases where such
a PHV exists, there is probably a corresponding join order constraint that
would allow a good plan to be found without using the star-schema exception.
Furthermore, adding complexity to nodeNestloop.c would create a run-time
penalty even for plans where this whole consideration is irrelevant.
So let's just reject such paths instead.
Per fuzz testing by Andreas Seltenreich; the added regression test is based
on his example query. Back-patch to 9.2, like the previous patch.
M src/backend/optimizer/path/joinpath.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Cap wal_buffers to avoid a server crash when it's set very large.
commit : cd52e4a2b945403659219350c4d4c6e6539a1e11
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 4 Aug 2015 12:58:54 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 4 Aug 2015 12:58:54 -0400
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just under 2GB, assuming the usual value
for XLOG_BLCKSZ.
Josh Berkus, per an analysis by Andrew Gierth.
M src/backend/utils/misc/guc.c
Update comment to match behavior of latest code.
commit : 9d7d0e640c21bfa36e1eeb7e7c9fcdbb2cfb9763
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 4 Aug 2015 11:45:29 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 4 Aug 2015 11:45:29 -0400
Peter Geoghegan
M src/backend/utils/sort/tuplesort.c
Stamp 9.5alpha2.
commit : 6bd01f082b2de4a502173e2d48a728c131f35a02
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Aug 2015 16:34:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Aug 2015 16:34:55 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
RLS: Keep deny policy when only restrictive exist
commit : 8f439658524d4a3566682ff9e25d4791c5498e53
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 3 Aug 2015 15:32:49 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 3 Aug 2015 15:32:49 -0400
Only remove the default deny policy when a permissive policy exists
(either from the hook or defined by the user). If only restrictive
policies exist then no rows will be visible, as restrictive policies
shouldn't make rows visible. To address this requirement, a single
"USING (true)" permissive policy can be created.
Update the test_rls_hooks regression tests to create the necessary
"USING (true)" permissive policy.
Back-patch to 9.5 where RLS was added.
Per discussion with Dean.
M src/backend/rewrite/rowsecurity.c
M src/test/modules/test_rls_hooks/expected/test_rls_hooks.out
M src/test/modules/test_rls_hooks/sql/test_rls_hooks.sql
M src/test/modules/test_rls_hooks/test_rls_hooks.c
Translation updates
commit : 58b30d9829ce9c3273e8ca32be62ebc2fd0e8153
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 3 Aug 2015 14:10:33 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 3 Aug 2015 14:10:33 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 01a9485e7f9d18e1195250ec68634f1d3c9497f6
M src/backend/po/es.po
M src/backend/po/it.po
M src/backend/po/ru.po
M src/bin/initdb/po/it.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/de.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/de.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/pg_rewind/nls.mk
A src/bin/pg_rewind/po/it.po
A src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/it.po
M src/bin/scripts/po/ru.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ru.po
M src/pl/plpgsql/src/po/it.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/it.po
Update 9.5 release notes through today.
commit : 11daccb445260de9ce03e4408ac7d908545b3319
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Aug 2015 12:29:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Aug 2015 12:29:11 -0400
M doc/src/sgml/release-9.5.sgml
Fix psql \d output of policies.
commit : 8f45a58d394bbe83c54306ba769ac02c9239c259
author : Joe Conway <mail@joeconway.com>
date : Mon, 3 Aug 2015 09:08:01 -0700
committer: Joe Conway <mail@joeconway.com>
date : Mon, 3 Aug 2015 09:08:01 -0700
psql neglected to wrap parenthesis around USING and WITH CHECK
expressions -- fixed. Back-patched to 9.5 where RLS policies were
introduced.
M src/bin/psql/describe.c
Make recovery rename tablespace_map to *.old if backup_label is not present.
commit : 46e9019bbce96c309d27d4b164bf9a2d0d8292eb
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 3 Aug 2015 23:04:41 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 3 Aug 2015 23:04:41 +0900
If tablespace_map file is present without backup_label file, there is
no use of such file. There is no harm in retaining it, but it is better
to get rid of the map file so that we don't have any redundant file
in data directory and it will avoid any sort of confusion. It seems
prudent though to just rename the file out of the way rather than
delete it completely, also we ignore any error that occurs in rename
operation as even if map file is present without backup_label file,
it is harmless.
Back-patch to 9.5 where tablespace_map file was introduced.
Amit Kapila, reviewed by Robert Haas, Alvaro Herrera and me.
M src/backend/access/transam/xlog.c
Fix pg_rewind when pg_xlog is a symlink.
commit : 615b69595525385bbf050a170912b7671cacc5c8
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 3 Aug 2015 15:23:56 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 3 Aug 2015 15:23:56 +0300
pg_xlog is often a symlink, typically to a different filesystem. Don't
get confused and comlain about by that, and just always pretend that it's a
normal directory, even if it's really a symlink.
Also add a test case for this.
Backpatch to 9.5.
M src/bin/pg_rewind/RewindTest.pm
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/t/001_basic.pl
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_rewind/t/003_extrafiles.pl
A src/bin/pg_rewind/t/004_pg_xlog_symlink.pl
Clean up pg_rewind regression test script.
commit : 2b917a58aec17ca5cf64196ee1d5d77ef8635caf
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 3 Aug 2015 13:06:47 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 3 Aug 2015 13:06:47 +0300
Since commit 01f6bb4b2, TestLib.pm has exported path to tmp_check directory,
so let's use that also for the pg_rewind test clusters etc.
Also, in master, the $tempdir_short variable has not been used since commit
13d856e17, which moved the initdb-running code to TestLib.pm.
Backpatch to 9.5.
M src/bin/pg_rewind/RewindTest.pm
Make modules/test_ddl_deparse/.gitignore match its siblings.
commit : 642ae4ee7dcb9b48a4abd1f02a46ff4d71aef931
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Aug 2015 00:02:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Aug 2015 00:02:26 -0400
Not sure why /tmp_check/ was omitted from this one, but even if it
isn't really needed right now, it's inconsistent not to include it.
M src/test/modules/test_ddl_deparse/.gitignore
contrib/isn now needs a .gitignore file.
commit : 61015249259462020629703a4990234c4629cbee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 23:57:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 23:57:32 -0400
Oversight in commit cb3384a0cb4cf900622b77865f60e31259923079.
Back-patch to 9.1, like that commit.
A contrib/isn/.gitignore
Fix a number of places that produced XX000 errors in the regression tests.
commit : 89e80b03297555277473fc3978b83c68ec9847b8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 23:49:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 23:49:19 -0400
It's against project policy to use elog() for user-facing errors, or to
omit an errcode() selection for errors that aren't supposed to be "can't
happen" cases. Fix all the violations of this policy that result in
ERRCODE_INTERNAL_ERROR log entries during the standard regression tests,
as errors that can reliably be triggered from SQL surely should be
considered user-facing.
I also looked through all the files touched by this commit and fixed
other nearby problems of the same ilk. I do not claim to have fixed
all violations of the policy, just the ones in these files.
In a few places I also changed existing ERRCODE choices that didn't
seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR
by something more specific.
Back-patch to 9.5, but no further; changing ERRCODE assignments in
stable branches doesn't seem like a good idea.
M contrib/tablefunc/tablefunc.c
M src/backend/access/common/reloptions.c
M src/backend/access/heap/heapam.c
M src/backend/commands/copy.c
M src/backend/commands/vacuum.c
M src/backend/executor/execQual.c
M src/backend/utils/adt/txid.c
M src/pl/plperl/plperl.c
M src/pl/plpython/plpy_elog.c
M src/pl/plpython/plpy_exec.c
M src/pl/tcl/pltcl.c
M src/test/regress/expected/txid.out
M src/test/regress/regress.c
Avoid calling memcpy() with a NULL source pointer and count == 0.
commit : c75b1f75b3d159c0e71c1ec7f42c922bce448d89
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 15:48:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 15:48:27 -0400
As in commit 0a52d378b03b7d5a, avoid doing something that has undefined
results according to the C standard, even though in practice there does
not seem to be any problem with it.
This fixes two places in numeric.c that demonstrably could call memcpy()
with such arguments. I looked through that file and didn't see any other
places with similar hazards; this is not to claim that there are not such
places in other files.
Per report from Piotr Stefaniak. Back-patch to 9.5 which is where the
previous commit was added. We're more or less setting a precedent that
we will not worry about this type of issue in pre-9.5 branches unless
someone demonstrates a problem in the field.
M src/backend/utils/adt/numeric.c
Fix output of ISBN-13 numbers beginning with 979.
commit : ea8385df6ce95507951f6c12fa4defb5b3ba9cda
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 22:12:33 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 22:12:33 +0300
An EAN beginning with 979 (but not 9790 - those are ISMN's) are accepted
as ISBN numbers, but they cannot be represented in the old, 10-digit ISBN
format. They must be output in the new 13-digit ISBN-13 format. We printed
out an incorrect value for those.
Also add a regression test, to test this and some other basic functionality
of the module.
Patch by Fabien Coelho. This fixes bug #13442, reported by B.Z. Backpatch
to 9.1, where we started to recognize ISBN-13 numbers.
M contrib/isn/Makefile
A contrib/isn/expected/isn.out
M contrib/isn/isn.c
A contrib/isn/sql/isn.sql
Fix incorrect order of lock file removal and failure to close() sockets.
commit : 72697d2ba77074713cd4008995a97cf284de1712
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 14:54:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 14:54:44 -0400
Commit c9b0cbe98bd783e24a8c4d8d8ac472a494b81292 accidentally broke the
order of operations during postmaster shutdown: it resulted in removing
the per-socket lockfiles after, not before, postmaster.pid. This creates
a race-condition hazard for a new postmaster that's started immediately
after observing that postmaster.pid has disappeared; if it sees the
socket lockfile still present, it will quite properly refuse to start.
This error appears to be the explanation for at least some of the
intermittent buildfarm failures we've seen in the pg_upgrade test.
Another problem, which has been there all along, is that the postmaster
has never bothered to close() its listen sockets, but has just allowed them
to close at process death. This creates a different race condition for an
incoming postmaster: it might be unable to bind to the desired listen
address because the old postmaster is still incumbent. This might explain
some odd failures we've seen in the past, too. (Note: this is not related
to the fact that individual backends don't close their client communication
sockets. That behavior is intentional and is not changed by this patch.)
Fix by adding an on_proc_exit function that closes the postmaster's ports
explicitly, and (in 9.3 and up) reshuffling the responsibility for where
to unlink the Unix socket files. Lock file unlinking can stay where it
is, but teach it to unlink the lock files in reverse order of creation.
M src/backend/libpq/pqcomm.c
M src/backend/postmaster/postmaster.c
M src/backend/utils/init/miscinit.c
M src/include/libpq/libpq.h
Fix race condition that lead to WALInsertLock deadlock with commit_delay.
commit : 54f23a45f3742e9533dbfa7c1177f02f116b0457
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 20:08:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 20:08:10 +0300
If a call to WaitForXLogInsertionsToFinish() returned a value in the middle
of a page, and another backend then started to insert a record to the same
page, and then you called WaitXLogInsertionsToFinish() again, the second
call might return a smaller value than the first call. The problem was in
GetXLogBuffer(), which always updated the insertingAt value to the
beginning of the requested page, not the actual requested location. Because
of that, the second call might return a xlog pointer to the beginning of
the page, while the first one returned a later position on the same page.
XLogFlush() performs two calls to WaitXLogInsertionsToFinish() in
succession, and holds WALWriteLock on the second call, which can deadlock
if the second call to WaitXLogInsertionsToFinish() blocks.
Reported by Spiros Ioannou. Backpatch to 9.4, where the more scalable
WALInsertLock mechanism, and this bug, was introduced.
M src/backend/access/transam/xlog.c
Micro optimize LWLockAttemptLock() a bit.
commit : 9074e41dbd41bc45ef79aeac1b6496bf087509a7
author : Andres Freund <andres@anarazel.de>
date : Fri, 31 Jul 2015 20:50:35 +0200
committer: Andres Freund <andres@anarazel.de>
date : Fri, 31 Jul 2015 20:50:35 +0200
LWLockAttemptLock pointlessly read the lock's state in every loop
iteration, even though pg_atomic_compare_exchange_u32() returns the old
value. Instead do that only once before the loop iteration.
Additionally there's no need to have the expected_state variable,
old_state mostly had the same value anyway.
Noticed-By: Heikki Linnakangas
Backpatch: 9.5, no reason to let the branches diverge at this point
M src/backend/storage/lmgr/lwlock.c
Fix issues around the "variable" support in the lwlock infrastructure.
commit : 27b719173516b54df63a1bba4266798e9f77bbb9
author : Andres Freund <andres@anarazel.de>
date : Fri, 31 Jul 2015 20:20:43 +0200
committer: Andres Freund <andres@anarazel.de>
date : Fri, 31 Jul 2015 20:20:43 +0200
The lwlock scalability work introduced two race conditions into the
lwlock variable support provided for xlog.c. First, and harmlessly on
most platforms, it set/read the variable without the spinlock in some
places. Secondly, due to the removal of the spinlock, it was possible
that a backend missed changes to the variable's state if it changed in
the wrong moment because checking the lock's state, the variable's state
and the queuing are not protected by a single spinlock acquisition
anymore.
To fix first move resetting the variable's from LWLockAcquireWithVar to
WALInsertLockRelease, via a new function LWLockReleaseClearVar. That
prevents issues around waiting for a variable's value to change when a
new locker has acquired the lock, but not yet set the value. Secondly
re-check that the variable hasn't changed after enqueing, that prevents
the issue that the lock has been released and already re-acquired by the
time the woken up backend checks for the lock's state.
Reported-By: Jeff Janes
Analyzed-By: Heikki Linnakangas
Reviewed-By: Heikki Linnakangas
Discussion: 5592DB35.2060401@iki.fi
Backpatch: 9.5, where the lwlock scalability went in
M src/backend/access/transam/xlog.c
M src/backend/storage/lmgr/lwlock.c
M src/include/storage/lwlock.h
Fix some planner issues with degenerate outer join clauses.
commit : 7968238eb17ed5f2f1123271549b7921fa1d3aba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Aug 2015 20:57:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Aug 2015 20:57:41 -0400
An outer join clause that didn't actually reference the RHS (perhaps only
after constant-folding) could confuse the join order enforcement logic,
leading to wrong query results. Also, nested occurrences of such things
could trigger an Assertion that on reflection seems incorrect.
Per fuzz testing by Andreas Seltenreich. The practical use of such cases
seems thin enough that it's not too surprising we've not heard field
reports about it.
This has been broken for a long time, so back-patch to all active branches.
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Teach predtest.c that "foo" implies "foo IS NOT NULL".
commit : 8dccf030e884ea8c723275a070acf8a8ed1eebe1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Aug 2015 14:31:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Aug 2015 14:31:46 -0400
Per complaint from Peter Holzer. It's useful to cover this special case,
since for a boolean variable "foo", earlier parts of the planner will have
reduced variants like "foo = true" to just "foo", and thus we may fail
to recognize the applicability of a partial index with predicate
"foo IS NOT NULL".
Back-patch to 9.5, but not further; given the lack of previous complaints
this doesn't seem like behavior to change in stable branches.
M src/backend/optimizer/util/predtest.c
Fix an oversight in checking whether a join with LATERAL refs is legal.
commit : edf26ed033f18bddc9bfe5c239388330150766a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Jul 2015 19:26:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Jul 2015 19:26:33 -0400
In many cases, we can implement a semijoin as a plain innerjoin by first
passing the righthand-side relation through a unique-ification step.
However, one of the cases where this does NOT work is where the RHS has
a LATERAL reference to the LHS; that makes the RHS dependent on the LHS
so that unique-ification is meaningless. joinpath.c understood this,
and so would not generate any join paths of this kind ... but join_is_legal
neglected to check for the case, so it would think that we could do it.
The upshot would be a "could not devise a query plan for the given query"
failure once we had failed to generate any join paths at all for the bogus
join pair.
Back-patch to 9.3 where LATERAL was added.
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Consolidate makefile code for setting top_srcdir, srcdir and VPATH.
commit : c7446194fa8fbbb9e8d948668bb47563ab58f45f
author : Noah Misch <noah@leadboat.com>
date : Thu, 30 Jul 2015 20:48:41 -0400
committer: Noah Misch <noah@leadboat.com>
date : Thu, 30 Jul 2015 20:48:41 -0400
Responsibility was formerly split between Makefile.global and pgxs.mk.
As a result of commit b58233c71b93a32fcab7219585cafc25a27eb769, in the
PGXS case, these variables were unset while parsing Makefile.global and
callees. Inclusion of Makefile.custom did not work from PGXS, and the
subtle difference seemed like a recipe for future bugs. Back-patch to
9.4, where that commit first appeared.
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Fix volatility marking of commit timestamp functions
commit : 71b66e78e432d99325db6356f056cb3f03b3d7b7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 30 Jul 2015 15:19:49 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 30 Jul 2015 15:19:49 -0300
They are marked stable, but since they act on instantaneous state and it
is possible to consult state of transactions as they commit, the results
could change mid-query. They need to be marked volatile, and this
commit does so.
There would normally be a catversion bump here, but this is so much a
niche feature and I don't believe there's real damage from the incorrect
marking, that I refrained.
Backpatch to 9.5, where commit timestamps where introduced.
Per note from Fujii Masao.
M src/include/catalog/pg_proc.h
Fix broken assertion in BRIN code
commit : 244c378e243e3649efc99fe96ec9f123bbe9ffbc
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 30 Jul 2015 15:07:19 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 30 Jul 2015 15:07:19 -0300
The code was assuming that any NULL value in scan keys was due to IS
NULL or IS NOT NULL, but it turns out to be possible to get them with
other operators too, if they are used in contrived-enough ways. Easiest
way out of the problem seems to check explicitely for the IS NOT NULL
flag, instead of assuming it must be set if the IS NULL flag is not set,
when a null scan key is found; if neither flag is set, follow the lead
of other index AMs and assume that all indexable operators must be
strict, and thus the query is never satisfiable.
Also, add a comment to try and lure some future hacker into improving
analysis of scan keys in brin.
Per report from Andreas Seltenreich; diagnosis by Tom Lane.
Backpatch to 9.5.
Discussion: http://www.postgresql.org/message-id/20646.1437919632@sss.pgh.pa.us
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_inclusion.c
M src/backend/access/brin/brin_minmax.c
Improve CREATE FUNCTION doc WRT to LEAKPROOF RLS interaction.
commit : 7be60a2459135199f8edff7f553b6d551729d79f
author : Joe Conway <mail@joeconway.com>
date : Thu, 30 Jul 2015 10:16:49 -0700
committer: Joe Conway <mail@joeconway.com>
date : Thu, 30 Jul 2015 10:16:49 -0700
Patch by Dean Rasheed. Back-patched to 9.5 where RLS was introduced.
M doc/src/sgml/ref/create_function.sgml
Use appropriate command type when retrieving relation's policies.
commit : 23b5e726da6ef5ebbc1dbc821320ee35fa1d0737
author : Joe Conway <mail@joeconway.com>
date : Thu, 30 Jul 2015 09:38:13 -0700
committer: Joe Conway <mail@joeconway.com>
date : Thu, 30 Jul 2015 09:38:13 -0700
When retrieving policies, if not working on the root target relation,
we actually want the relation's SELECT policies, regardless of
the top level query command type. For example in UPDATE t1...FROM t2
we need to apply t1's UPDATE policies and t2's SELECT policies.
Previously top level query command type was applied to all relations,
which was wrong. Add some regression coverage to ensure we don't
violate this principle in the future.
Report and patch by Dean Rasheed. Cherry picked from larger refactoring
patch and tweaked by me. Back-patched to 9.5 where RLS was introduced.
M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Avoid some zero-divide hazards in the planner.
commit : e91a1643ac723477d6ec2d47c8486cd0013660bb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Jul 2015 12:11:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Jul 2015 12:11:23 -0400
Although I think on all modern machines floating division by zero
results in Infinity not SIGFPE, we still don't want infinities
running around in the planner's costing estimates; too much risk
of that leading to insane behavior.
grouping_planner() failed to consider the possibility that final_rel
might be known dummy and hence have zero rowcount. (I wonder if it
would be better to set a rows estimate of 1 for dummy relations?
But at least in the back branches, changing this convention seems
like a bad idea, so I'll leave that for another day.)
Make certain that get_variable_numdistinct() produces a nonzero result.
The case that can be shown to be broken is with stadistinct < 0.0 and
small ntuples; we did not prevent the result from rounding to zero.
For good luck I applied clamp_row_est() to all the nonconstant return
values.
In ExecChooseHashTableSize(), Assert that we compute positive nbuckets
and nbatch. I know of no reason to think this isn't the case, but it
seems like a good safety check.
Per reports from Piotr Stefaniak. Back-patch to all active branches.
M src/backend/executor/nodeHash.c
M src/backend/optimizer/plan/planner.c
M src/backend/utils/adt/selfuncs.c
Fix calculation of latency of pgbench backslash commands.
commit : 2e75be6660dbaaf2da09b98c54d47c9fe0ac8cfa
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 30 Jul 2015 14:50:51 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 30 Jul 2015 14:50:51 +0300
When we loop back to the top of doCustom after processing a backslash
command, we must reset the "now" timestamp, because that's used to
calculate the time spent executing the previous command.
Report and fix by Fabien Coelho. Backpatch to 9.5, where this was broken.
M src/bin/pgbench/pgbench.c
Blacklist xlc 32-bit inlining.
commit : a664d4790e5f93726f264c77c044a7ce4c1a675c
author : Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:49:48 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:49:48 -0400
Per a suggestion from Tom Lane. Back-patch to 9.0 (all supported
versions). While only 9.4 and up have code known to elicit this
compiler bug, we were disabling inlining by accident until commit
43d89a23d59c487bc9258fad7a6187864cb8c0c0.
M config/test_quiet_include.h
Remove redundant "make install" from pg_upgrade test suite.
commit : 1471c0e27c2f71bed551463e8072da9c01c63dae
author : Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:49:36 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:49:36 -0400
A top-level "make install" includes pg_upgrade since commit
9fa8b0ee90c44c0f97d16bf65e94322988c94864. Back-patch to 9.5, where that
commit first appeared.
M src/bin/pg_upgrade/test.sh
MSVC: Revert most 9.5 changes to pre-9.5 vcregress.pl tests.
commit : fdb8ea9366785d7e2a31469c1389ca8a6f11889f
author : Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:48:56 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:48:56 -0400
The reverted changes did not narrow the semantic gap between the MSVC
build system and the GNU make build system. For targets old and new
that run multiple suites (contribcheck, modulescheck, tapcheck), restore
vcregress.pl to mimicking "make -k" rather than the "make -S" default.
Lack of "-k" would be more burdensome than lack of "-S". Keep changes
reflecting contemporary changes to the GNU make build system, and keep
updates to Makefile parsing. Keep the loss of --psqldir in "check" and
"ecpgcheck" targets; it had been a no-op when used alongside
--temp-install. No log message mentioned any of the reverted changes.
Based on a germ by Michael Paquier. Back-patch to 9.5.
M src/tools/msvc/vcregress.pl
MSVC: Remove duplicate PATH entry in test harness.
commit : 95eb4b265502c26c9f72f0f554df41e273551858
author : Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:48:43 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:48:43 -0400
Back-patch to 9.5, where commit 4cb7d671fddc8855c8def2de51fb23df1c8ac0af
introduced it.
M src/tools/msvc/vcregress.pl
MSVC: Future-proof installation file skip logic.
commit : f7dca86fc3a2c423824a2056994319c348992913
author : Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:48:25 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:48:25 -0400
This code relied on knowing exactly where in the source tree temporary
installations might appear. A reasonable hacker may not think to update
this code when adding use of a temporary installation, making it
fragile. Observe that commit 9fa8b0ee90c44c0f97d16bf65e94322988c94864
broke it unnoticed, and commit dcae5faccab64776376d354decda0017c648bb53
fixed it unnoticed. Back-patch to 9.5 only; use of temporary
installations is unlikely to change in released versions.
M src/tools/msvc/Install.pm
Create new ParseExprKind for use by policy expressions.
commit : 43797ed42a7c0365c9143ad6efdc566ac9d93fd8
author : Joe Conway <mail@joeconway.com>
date : Wed, 29 Jul 2015 15:41:00 -0700
committer: Joe Conway <mail@joeconway.com>
date : Wed, 29 Jul 2015 15:41:00 -0700
Policy USING and WITH CHECK expressions were using EXPR_KIND_WHERE for
parse analysis, which results in inappropriate ERROR messages when
the expression contains unsupported constructs such as aggregates.
Create a new ParseExprKind called EXPR_KIND_POLICY and tailor the
related messages to fit.
Reported by Noah Misch. Reviewed by Dean Rasheed, Alvaro Herrera,
and Robert Haas. Back-patch to 9.5 where RLS was introduced.
M src/backend/commands/policy.c
M src/backend/parser/parse_agg.c
M src/backend/parser/parse_expr.c
M src/include/parser/parse_node.h
M src/test/modules/test_rls_hooks/test_rls_hooks.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Add some test coverage of EvalPlanQual with non-locked tables.