Stamp 9.4.8.
commit : d130536e93378d9b6512d268639324ba7f60a815
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2016 16:52:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2016 16:52:03 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Translation updates
commit : c20dd81034ebeed38a372e3696dfe12550a26ce4
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 9 May 2016 10:06:37 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 9 May 2016 10:06:37 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 1f2562b35928021c6463a1e5f82f1682486fb4cf
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/pt_BR.po
M src/bin/initdb/po/it.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/psql/po/de.po
M src/bin/psql/po/it.po
M src/bin/scripts/po/it.po
M src/interfaces/libpq/po/pt_BR.po
M src/pl/plperl/po/it.po
M src/pl/plpython/po/it.po
M src/pl/tcl/po/it.po
Release notes for 9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22.
commit : 0a06b5b926b185db0b77cc02401a61a8e1bd0f58
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 May 2016 17:26:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 May 2016 17:26:24 -0400
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
Distrust external OpenSSL clients; clear err queue
commit : e3b14de9f0453d29c1d77b081d312b2eac6b192a
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 8 Apr 2016 13:48:14 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 8 Apr 2016 13:48:14 -0400
OpenSSL has an unfortunate tendency to mix per-session state error
handling with per-thread error handling. This can cause problems when
programs that link to libpq with OpenSSL enabled have some other use of
OpenSSL; without care, one caller of OpenSSL may cause problems for the
other caller. Backend code might similarly be affected, for example
when a third party extension independently uses OpenSSL without taking
the appropriate precautions.
To fix, don't trust other users of OpenSSL to clear the per-thread error
queue. Instead, clear the entire per-thread queue ahead of certain I/O
operations when it appears that there might be trouble (these I/O
operations mostly need to call SSL_get_error() to check for success,
which relies on the queue being empty). This is slightly aggressive,
but it's pretty clear that the other callers have a very dubious claim
to ownership of the per-thread queue. Do this is both frontend and
backend code.
Finally, be more careful about clearing our own error queue, so as to
not cause these problems ourself. It's possibly that control previously
did not always reach SSLerrmessage(), where ERR_get_error() was supposed
to be called to clear the queue's earliest code. Make sure
ERR_get_error() is always called, so as to spare other users of OpenSSL
the possibility of similar problems caused by libpq (as opposed to
problems caused by a third party OpenSSL library like PHP's OpenSSL
extension). Again, do this is both frontend and backend code.
See bug #12799 and https://bugs.php.net/bug.php?id=68276
Based on patches by Dave Vitek and Peter Eisentraut.
From: Peter Geoghegan <pg@bowt.ie>
M src/backend/libpq/be-secure.c
M src/interfaces/libpq/fe-secure.c
Fix pg_upgrade to not fail when new-cluster TOAST rules differ from old.
commit : e1aecebc041db969abe7cacb351577938f11a2af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 May 2016 22:05:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 May 2016 22:05:51 -0400
This patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much
simpler solution for the case where the new cluster would choose to create
a TOAST table but the old cluster doesn't have one: just don't create a
TOAST table.
The existing code failed in at least two different ways if the situation
arose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the
lock sanity check in create_toast_table failed; (2) pg_upgrade did not
provide a pg_type OID for the new toast table, so that the crosscheck in
TypeCreate failed. While both these problems were introduced by later
patches, they show that the hack being used to cause TOAST table creation
is overwhelmingly fragile (and untested). I also note that before the
TypeCreate crosscheck was added, the code would have resulted in assigning
an indeterminate pg_type OID to the toast table, possibly causing a later
OID conflict in that catalog; so that it didn't really work even when
committed.
If we simply don't create a TOAST table, there will only be a problem if
the code tries to store a tuple that's wider than a page, and field
compression isn't sufficient to get it under a page. Given that the TOAST
creation threshold is intended to be about a quarter of a page, it's very
hard to believe that cross-version differences in the do-we-need-a-toast-
table heuristic could result in an observable problem. So let's just
follow the old version's conclusion about whether a TOAST table is needed.
(If we ever do change needs_toast_table() so much that this conclusion
doesn't apply, we can devise a solution at that time, and hopefully do
it in a less klugy way than 4c6780fd17aa43ed did.)
Back-patch to 9.3, like the previous patch.
Discussion: <8110.1462291671@sss.pgh.pa.us>
M contrib/pg_upgrade/dump.c
M contrib/pg_upgrade/pg_upgrade.c
M contrib/pg_upgrade/pg_upgrade.h
M src/backend/catalog/toasting.c
M src/include/catalog/binary_upgrade.h
Fix possible read past end of string in to_timestamp().
commit : 1180868d11343f4ec01bf5d4964e360fceaab5ff
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 May 2016 12:09:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 May 2016 12:09:20 -0400
to_timestamp() handles the TH/th format codes by advancing over two input
characters, whatever those are. It failed to notice whether there were
two characters available to be skipped, making it possible to advance
the pointer past the end of the input string and keep on parsing.
A similar risk existed in the handling of "Y,YYY" format: it would advance
over three characters after the "," whether or not three characters were
available.
In principle this might be exploitable to disclose contents of server
memory. But the security team concluded that it would be very hard to use
that way, because the parsing loop would stop upon hitting any zero byte,
and TH/th format codes can't be consecutive --- they have to follow some
other format code, which would have to match whatever data is there.
So it seems impractical to examine memory very much beyond the end of the
input string via this bug; and the input string will always be in local
memory not in disk buffers, making it unlikely that anything very
interesting is close to it in a predictable way. So this doesn't quite
rise to the level of needing a CVE.
Thanks to Wolf Roediger for reporting this bug.
M src/backend/utils/adt/formatting.c
Update time zone data files to tzdata release 2016d.
commit : a5148e80003b6c932aea882687ed8ded3921b332
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 May 2016 20:08:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 May 2016 20:08:58 -0400
DST law changes in Russia (Magadan, Tomsk regions) and Venezuela.
Historical corrections for Russia. There are new zone names Europe/Kirov
and Asia/Tomsk reflecting the fact that these regions now have different
time zone histories from adjacent regions.
M src/timezone/data/asia
M src/timezone/data/europe
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/Asia.txt
M src/timezone/tznames/Default
doc: Fix more typos
commit : db5999a92755289bd97990f9a081a6d73f4f2015
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 4 May 2016 14:07:00 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 4 May 2016 14:07:00 -0400
From: Alexander Law <exclusion@gmail.com>
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/pg_xlogdump.sgml
doc: Fix typos
commit : e301d52941fa39b60ffea79dc67f8da6d340c1e8
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 3 May 2016 21:06:25 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 3 May 2016 21:06:25 -0400
From: Alexander Law <exclusion@gmail.com>
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/protocol.sgml
Fix configure's incorrect version tests for flex and perl.
commit : 1ba874505f903296dfc4cc156dc1601cd8f8d531
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 May 2016 11:18:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 May 2016 11:18:11 -0400
awk's equality-comparison operator is "==" not "=". We got this right
in many places, but not in configure's checks for supported version
numbers of flex and perl. It hadn't been noticed because unsupported
versions are so old as to be basically extinct in the wild, and because
the only consequence is whether or not a WARNING flies by during
configure.
Daniel Gustafsson noted the problem with respect to the test for flex,
I found the other by reviewing other awk calls.
M config/perl.m4
M config/programs.m4
M configure
Remove unused macros.
commit : a840c14286bcd2ea3241ca7ff0aa2c28f0472418
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 2 May 2016 10:07:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 2 May 2016 10:07:49 +0300
CHECK_PAGE_OFFSET_RANGE() has been unused forever.
CHECK_RELATION_BLOCK_RANGE() has been unused in pgstatindex.c ever since
bt_page_stats() and bt_page_items() functions were moved from pgstattuple
to pageinspect module. It still exists in pageinspect/btreefuncs.c.
Daniel Gustafsson
M contrib/pageinspect/btreefuncs.c
M contrib/pgstattuple/pgstatindex.c
Fix mishandling of equivalence-class tests in parameterized plans.
commit : 72edc8ffeb0e94949b217bc4c264a50281b10203
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Apr 2016 20:19:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Apr 2016 20:19:38 -0400
Given a three-or-more-way equivalence class, such as X.Y = Y.Y = Z.Z,
it was possible for the planner to omit one of the quals needed to
enforce that all members of the equivalence class are actually equal.
This only happened in the case of a parameterized join node for two
of the relations, that is a plan tree like
Nested Loop
-> Scan X
-> Nested Loop
-> Scan Y
-> Scan Z
Filter: Z.Z = X.X
The eclass machinery normally expects to apply X.X = Y.Y when those
two relations are joined, but in this shape of plan tree they aren't
joined until the top node --- and, if the lower nested loop is marked
as parameterized by X, the top node will assume that the relevant eclass
condition(s) got pushed down into the lower node. On the other hand,
the scan of Z assumes that it's only responsible for constraining Z.Z
to match any one of the other eclass members. So one or another of
the required quals sometimes fell between the cracks, depending on
whether consideration of the eclass in get_joinrel_parampathinfo()
for the lower nested loop chanced to generate X.X = Y.Y or X.X = Z.Z
as the appropriate constraint there. If it generated the latter,
it'd erroneously suppose that the Z scan would take care of matters.
To fix, force X.X = Y.Y to be generated and applied at that join node
when this case occurs.
This is *extremely* hard to hit in practice, because various planner
behaviors conspire to mask the problem; starting with the fact that the
planner doesn't really like to generate a parameterized plan of the
above shape. (It might have been impossible to hit it before we
tweaked things to allow this plan shape for star-schema cases.) Many
thanks to Alexander Kirkouski for submitting a reproducible test case.
The bug can be demonstrated in all branches back to 9.2 where parameterized
paths were introduced, so back-patch that far.
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/util/relnode.c
M src/include/optimizer/paths.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Remember asking for feedback during walsender shutdown.
commit : 596f936055c562c63696699d03c76e24189dec7c
author : Andres Freund <andres@anarazel.de>
date : Thu, 28 Apr 2016 22:09:51 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 28 Apr 2016 22:09:51 -0700
Since 5a991ef8 we're explicitly asking for feedback from the receiving
side when shutting down walsender, if there's not yet replicated
data.
Unfortunately we didn't remember (i.e. set waiting_for_ping_response to
true) having asked for feedback, leading to scenarios in which replies
were requested at a high frequency.
I can't reproduce this problem on my laptop, I think that's because the
problem requires a significant TCP window to manifest due to the
!pq_is_send_pending() condition. But since this clearly is a bug, let's
fix it. There's quite possibly more wrong than just this though.
While fiddling with WalSndDone(), I rewrote a hard to understand comment
about looking at the flush vs. the write position.
Reported-By: Nick Cleaton, Magnus Hagander
Author: Nick Cleaton
Discussion: CAFgz3kus=rC_avEgBV=+hRK5HYJ8vXskJRh8yEAbahJGTzF2VQ@mail.gmail.com
CABUevExsjROqDcD0A2rnJ6HK6FuKGyewJr3PL12pw85BHFGS2Q@mail.gmail.com
Backpatch: 9.4, were 5a991ef8 introduced the use of feedback messages
during shutdown.
M src/backend/replication/walsender.c
Adjust DatumGetBool macro, this time for sure.
commit : 65c2eeb003bfc4e37f504e429bded6f0c0b40d43
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Apr 2016 11:50:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Apr 2016 11:50:58 -0400
Commit 23a41573c attempted to fix the DatumGetBool macro to ignore bits
in a Datum that are to the left of the actual bool value. But it did that
by casting the Datum to bool; and on compilers that use C99 semantics for
bool, that ends up being a whole-word test, not a 1-byte test. This seems
to be the true explanation for contrib/seg failing in VS2015. To fix, use
GET_1_BYTE() explicitly. I think in the previous patch, I'd had some idea
of not having to commit to bool being exactly 1 byte wide, but regardless
of what the compiler's bool is, boolean columns and Datums are certainly
1 byte wide.
The previous fix was (eventually) back-patched into all active versions,
so do likewise with this one.
M src/include/postgres.h
pg_upgrade: Fix indentation of if() block
commit : 3be77da179a187dc7eacd2b2104b53ec62ab9fa7
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 28 Apr 2016 08:29:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 28 Apr 2016 08:29:02 -0400
Incorrect indentation introduced in commit
3d2e1851096752c3ca4dee5c16b552332de09946.
Reported-by: Andres Freund
Backpatch-through: 9.3 and 9.4 only
M src/bin/pg_dump/pg_dump.c
doc: Fix typo
commit : b5a9dc7cea864fd15da4e3c5690e91c51cdfc0d6
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 24 Apr 2016 20:44:22 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 24 Apr 2016 20:44:22 -0400
From: Andreas Seltenreich <andreas.seltenreich@credativ.de>
M doc/src/sgml/logicaldecoding.sgml
Rename strtoi() to strtoint().
commit : 2a715371c44399f8ec538b3c8df0590400c75678
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Apr 2016 16:53:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Apr 2016 16:53:15 -0400
NetBSD has seen fit to invent a libc function named strtoi(), which
conflicts with the long-established static functions of the same name in
datetime.c and ecpg's interval.c. While muttering darkly about intrusions
on application namespace, we'll rename our functions to avoid the conflict.
Back-patch to all supported branches, since this would affect attempts
to build any of them on recent NetBSD.
Thomas Munro
M src/backend/utils/adt/datetime.c
M src/interfaces/ecpg/pgtypeslib/interval.c
doc: Fix typos
commit : b39938f01208d2860239792aa9e802a9cf8c286b
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 23 Apr 2016 14:48:02 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 23 Apr 2016 14:48:02 -0400
From: Erik Rijkers <er@xs4all.nl>
M doc/src/sgml/pgbench.sgml
Add putenv support for msvcrt from Visual Studio 2013
commit : c238a41014db7f818982641a8b95fae15515c88e
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 22 Apr 2016 05:18:59 -0400
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 22 Apr 2016 05:18:59 -0400
This was missed when VS 2013 support was added.
Michael Paquier
M src/port/win32env.c
Fix planner failure with full join in RHS of left join.
commit : 3232c242724e743c0dd3afd972cb0cb5b5d12c33
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 20:05:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 20:05:58 -0400
Given a left join containing a full join in its righthand side, with
the left join's joinclause referencing only one side of the full join
(in a non-strict fashion, so that the full join doesn't get simplified),
the planner could fail with "failed to build any N-way joins" or related
errors. This happened because the full join was seen as overlapping the
left join's RHS, and then recent changes within join_is_legal() caused
that function to conclude that the full join couldn't validly be formed.
Rather than try to rejigger join_is_legal() yet more to allow this,
I think it's better to fix initsplan.c so that the required join order
is explicit in the SpecialJoinInfo data structure. The previous coding
there essentially ignored full joins, relying on the fact that we don't
flatten them in the joinlist data structure to preserve their ordering.
That's sufficient to prevent a wrong plan from being formed, but as this
example shows, it's not sufficient to ensure that the right plan will
be formed. We need to work a bit harder to ensure that the right plan
looks sane according to the SpecialJoinInfos.
Per bug #14105 from Vojtech Rylko. This was apparently induced by
commit 8703059c6 (though now that I've seen it, I wonder whether there
are related cases that could have failed before that); so back-patch
to all active branches. Unfortunately, that patch also went into 9.0,
so this bug is a regression that won't be fixed in that branch.
M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Improve TranslateSocketError() to handle more Windows error codes.
commit : 56dee70d90563cfce41ca019dac64458a4fc22e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 16:58:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 16:58:47 -0400
The coverage was rather lean for cases that bind() or listen() might
return. Add entries for everything that there's a direct equivalent
for in the set of Unix errnos that elog.c has heard of.
M src/backend/port/win32/socket.c
M src/include/port/win32.h
Remove dead code in win32.h.
commit : 27a8361272af7cc3d654db65a3829774b557b220
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 16:16:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 16:16:19 -0400
There's no longer a need for the MSVC-version-specific code stanza that
forcibly redefines errno code symbols, because since commit 73838b52 we're
unconditionally redefining them in the stanza before this one anyway.
Now it's merely confusing and ugly, so get rid of it; and improve the
comment that explains what's going on here.
Although this is just cosmetic, back-patch anyway since I'm intending
to back-patch some less-cosmetic changes in this same hunk of code.
M src/include/port/win32.h
Provide errno-translation wrappers around bind() and listen() on Windows.
commit : 5e2fb8862bfc4ba8f0ed4ce0b99931db91ad84b1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 15:44:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 15:44:18 -0400
Fix Windows builds to report something useful rather than "could not bind
IPv4 socket: No error" when bind() fails.
Back-patch of commits d1b7d4877b9a71f4 and 22989a8e34168f57.
Discussion: <4065.1452450340@sss.pgh.pa.us>
M src/backend/port/win32/socket.c
M src/include/port/win32.h
Fix ruleutils.c's dumping of ScalarArrayOpExpr containing an EXPR_SUBLINK.
commit : 679c92238c74ed6c96e4251d7ea68f8a096ff674
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 14:20:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2016 14:20:18 -0400
When we shoehorned "x op ANY (array)" into the SQL syntax, we created a
fundamental ambiguity as to the proper treatment of a sub-SELECT on the
righthand side: perhaps what's meant is to compare x against each row of
the sub-SELECT's result, or perhaps the sub-SELECT is meant as a scalar
sub-SELECT that delivers a single array value whose members should be
compared against x. The grammar resolves it as the former case whenever
the RHS is a select_with_parens, making the latter case hard to reach ---
but you can get at it, with tricks such as attaching a no-op cast to the
sub-SELECT. Parse analysis would throw away the no-op cast, leaving a
parsetree with an EXPR_SUBLINK SubLink directly under a ScalarArrayOpExpr.
ruleutils.c was not clued in on this fine point, and would naively emit
"x op ANY ((SELECT ...))", which would be parsed as the first alternative,
typically leading to errors like "operator does not exist: text = text[]"
during dump/reload of a view or rule containing such a construct. To fix,
emit a no-op cast when dumping such a parsetree. This might well be
exactly what the user wrote to get the construct accepted in the first
place; and even if she got there with some other dodge, it is a valid
representation of the parsetree.
Per report from Karl Czajkowski. He mentioned only a case involving
RLS policies, but actually the problem is very old, so back-patch to
all supported branches.
Report: <20160421001832.GB7976@moraine.isi.edu>
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Honor PGCTLTIMEOUT environment variable for pg_regress' startup wait.
commit : f05ac711b1ded87902d1e35ce3964a1b16185a10
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2016 23:48:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2016 23:48:13 -0400
In commit 2ffa86962077c588 we made pg_ctl recognize an environment variable
PGCTLTIMEOUT to set the default timeout for starting and stopping the
postmaster. However, pg_regress uses pg_ctl only for the "stop" end of
that; it has bespoke code for starting the postmaster, and that code has
historically had a hard-wired 60-second timeout. Further buildfarm
experience says it'd be a good idea if that timeout were also controlled
by PGCTLTIMEOUT, so let's make it so. Like the previous patch, back-patch
to all active branches.
Discussion: <13969.1461191936@sss.pgh.pa.us>
M src/test/regress/pg_regress.c
Fix memory leak and other bugs in ginPlaceToPage() & subroutines.
commit : ef35afa35c422928d8fb900dd69cfc182f076bf0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2016 14:25:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2016 14:25:15 -0400
Commit 36a35c550ac114ca turned the interface between ginPlaceToPage and
its subroutines in gindatapage.c and ginentrypage.c into a royal mess:
page-update critical sections were started in one place and finished in
another place not even in the same file, and the very same subroutine
might return having started a critical section or not. Subsequent patches
band-aided over some of the problems with this design by making things
even messier.
One user-visible resulting problem is memory leaks caused by the need for
the subroutines to allocate storage that would survive until ginPlaceToPage
calls XLogInsert (as reported by Julien Rouhaud). This would not typically
be noticeable during retail index updates. It could be visible in a GIN
index build, in the form of memory consumption swelling to several times
the commanded maintenance_work_mem.
Another rather nasty problem is that in the internal-page-splitting code
path, we would clear the child page's GIN_INCOMPLETE_SPLIT flag well before
entering the critical section that it's supposed to be cleared in; a
failure in between would leave the index in a corrupt state. There were
also assorted coding-rule violations with little immediate consequence but
possible long-term hazards, such as beginning an XLogInsert sequence before
entering a critical section, or calling elog(DEBUG) inside a critical
section.
To fix, redefine the API between ginPlaceToPage() and its subroutines
by splitting the subroutines into two parts. The "beginPlaceToPage"
subroutine does what can be done outside a critical section, including
full computation of the result pages into temporary storage when we're
going to split the target page. The "execPlaceToPage" subroutine is called
within a critical section established by ginPlaceToPage(), and it handles
the actual page update in the non-split code path. The critical section,
as well as the XLOG insertion call sequence, are both now always started
and finished in ginPlaceToPage(). Also, make ginPlaceToPage() create and
work in a short-lived memory context to eliminate the leakage problem.
(Since a short-lived memory context had been getting created in the most
common code path in the subroutines, this shouldn't cause any noticeable
performance penalty; we're just moving the overhead up one call level.)
In passing, fix a bunch of comments that had gone unmaintained throughout
all this klugery.
Report: <571276DD.5050303@dalibo.com>
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginentrypage.c
M src/include/access/gin_private.h
Further reduce the number of semaphores used under --disable-spinlocks.
commit : 21b7f49eb88a6d39acf9569cddf65f1985318056
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Apr 2016 13:33:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Apr 2016 13:33:07 -0400
Per discussion, there doesn't seem to be much value in having
NUM_SPINLOCK_SEMAPHORES set to 1024: under any scenario where you are
running more than a few backends concurrently, you really had better have a
real spinlock implementation if you want tolerable performance. And 1024
semaphores is a sizable fraction of the system-wide SysV semaphore limit
on many platforms. Therefore, reduce this setting's default value to 128
to make it less likely to cause out-of-semaphores problems.
M src/include/pg_config_manual.h
doc: Add missing parentheses
commit : f6a849b282267c4ee139577de6a32aa8f337a364
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 15 Apr 2016 20:44:10 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 15 Apr 2016 20:44:10 -0400
From: Alexander Law <exclusion@gmail.com>
M doc/src/sgml/ecpg.sgml
Fix possible crash in ALTER TABLE ... REPLICA IDENTITY USING INDEX.
commit : 8eed31ffb84cda04cb20f3e780213c17f9f3223f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Apr 2016 12:11:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Apr 2016 12:11:27 -0400
Careless coding added by commit 07cacba983ef79be could result in a crash
or a bizarre error message if someone tried to select an index on the
OID column as the replica identity index for a table. Back-patch to 9.4
where the feature was introduced.
Discussion: CAKJS1f8TQYgTRDyF1_u9PVCKWRWz+DkieH=U7954HeHVPJKaKg@mail.gmail.com
David Rowley
M src/backend/commands/tablecmds.c
M src/test/regress/expected/replica_identity.out
M src/test/regress/sql/replica_identity.sql
Fix memory leak in GIN index scans.
commit : 0479eccdcf0db59336aa45c6501666cd9f590b6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Apr 2016 00:02:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Apr 2016 00:02:26 -0400
The code had a query-lifespan memory leak when encountering GIN entries
that have posting lists (rather than posting trees, ie, there are a
relatively small number of heap tuples containing this index key value).
With a suitable data distribution this could add up to a lot of leakage.
Problem seems to have been introduced by commit 36a35c550, so back-patch
to 9.4.
Julien Rouhaud
M src/backend/access/gin/ginget.c
Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.
commit : 00456911f43ab3def50b70813aea645e979e1687
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Apr 2016 19:42:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Apr 2016 19:42:22 -0400
When re-reading an update involving both an old tuple and a new tuple from
disk, reorderbuffer.c was careless about whether the new tuple is suitably
aligned for direct access --- in general, it isn't. We'd missed seeing
this in the buildfarm because the contrib/test_decoding tests exercise this
code path only a few times, and by chance all of those cases have old
tuples with length a multiple of 4, which is usually enough to make the
access to the new tuple's t_len safe. For some still-not-entirely-clear
reason, however, Debian's sparc build gets a bus error, as reported by
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?
The lack of previous field reports is probably because you need all of
these conditions to trigger a crash: an alignment-picky platform (not
Intel), a transaction large enough to spill to disk, an update within
that xact that changes a primary-key field and has an odd-length old tuple,
and of course logical decoding tracing the transaction.
Avoid the alignment assumption by using memcpy instead of fetching t_len
directly, and add a test case that exposes the crash on picky platforms.
Back-patch to 9.4 where the bug was introduced.
Discussion: <20160413094117.GC21485@msg.credativ.de>
M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
M src/backend/replication/logical/reorderbuffer.c
Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies works.
commit : 5daf1012a902bfc00b365360f35ea972a3b19e13
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Apr 2016 18:57:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Apr 2016 18:57:52 -0400
As reported by Michael Feld, pg_upgrade'ing an installation having
extensions with operator families that contain just a single operator class
failed to reproduce the extension membership of those operator families.
This caused no immediate ill effects, but would create problems when later
trying to do a plain dump and restore, because the seemingly-not-part-of-
the-extension operator families would appear separately in the pg_dump
output, and then would conflict with the families created by loading the
extension. This has been broken ever since extensions were introduced,
and many of the standard contrib extensions are affected, so it's a bit
astonishing nobody complained before.
The cause of the problem is a perhaps-ill-considered decision to omit
such operator families from pg_dump's output on the grounds that the
CREATE OPERATOR CLASS commands could recreate them, and having explicit
CREATE OPERATOR FAMILY commands would impede loading the dump script into
pre-8.3 servers. Whatever the merits of that decision when 8.3 was being
written, it looks like a poor tradeoff now. We can fix the pg_upgrade
problem simply by removing that code, so that the operator families are
dumped explicitly (and then will be properly made to be part of their
extensions).
Although this fixes the behavior of future pg_upgrade runs, it does nothing
to clean up existing installations that may have improperly-linked operator
families. Given the small number of complaints to date, maybe we don't
need to worry about providing an automated solution for that; anyone who
needs to clean it up can do so with manual "ALTER EXTENSION ADD OPERATOR
FAMILY" commands, or even just ignore the duplicate-opfamily errors they
get during a pg_restore. In any case we need this fix.
Back-patch to all supported branches.
Discussion: <20228.1460575691@sss.pgh.pa.us>
M src/bin/pg_dump/pg_dump.c
Fix freshly-introduced PL/Python portability bug.
commit : 112e5d2a8b32d574daba9fec9b34bdad01937f76
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Apr 2016 18:17:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Apr 2016 18:17:02 -0400
It turns out that those PyErr_Clear() calls I removed from plpy_elog.c
in 7e3bb080387f4143 et al were not quite as random as they appeared: they
mask a Python 2.3.x bug. (Specifically, it turns out that PyType_Ready()
can fail if the error indicator is set on entry, and PLy_traceback's fetch
of frame.f_code may be the first operation in a session that requires the
"frame" type to be readied. Ick.) Put back the clear call, but in a more
centralized place closer to what it's protecting, and this time with a
comment warning what it's really for.
Per buildfarm member prairiedog. Although prairiedog was only failing
on HEAD, it seems clearly possible for this to occur in older branches
as well, so back-patch to 9.2 the same as the previous patch.
M src/pl/plpython/plpy_elog.c
Fix access-to-already-freed-memory issue in plpython's error handling.
commit : d54de3962a12e6075eae80fe75afc3ab59eea0d5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Apr 2016 23:15:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Apr 2016 23:15:55 -0400
PLy_elog() could attempt to access strings that Python had already freed,
because the strings that PLy_get_spi_error_data() returns are simply
pointers into storage associated with the error "val" PyObject. That's
fine at the instant PLy_get_spi_error_data() returns them, but just after
that PLy_traceback() intentionally releases the only refcount on that
object, allowing it to be freed --- so that the strings we pass to
ereport() are dangling pointers.
In principle this could result in garbage output or a coredump. In
practice, I think the risk is pretty low, because there are no Python
operations between where we decrement that refcount and where we use the
strings (and copy them into PG storage), and thus no reason for Python
to recycle the storage. Still, it's clearly hazardous, and it leads to
Valgrind complaints when running under a Valgrind that hasn't been
lobotomized to ignore Python memory allocations.
The code was a mess anyway: we fetched the error data out of Python
(clearing Python's error indicator) with PyErr_Fetch, examined it, pushed
it back into Python with PyErr_Restore (re-setting the error indicator),
then immediately pulled it back out with another PyErr_Fetch. Just to
confuse matters even more, there were some gratuitous-and-yet-hazardous
PyErr_Clear calls in the "examine" step, and we didn't get around to doing
PyErr_NormalizeException until after the second PyErr_Fetch, making it even
less clear which object was being manipulated where and whether we still
had a refcount on it. (If PyErr_NormalizeException did substitute a
different "val" object, it's possible that the problem could manifest for
real, because then we'd be doing assorted Python stuff with no refcount
on the object we have string pointers into.)
So, rearrange all that into some semblance of sanity, and don't decrement
the refcount on the Python error objects until the end of PLy_elog().
In HEAD, I failed to resist the temptation to reformat some messy bits
from 5c3c3cd0a3046339 along the way.
Back-patch as far as 9.2, because the code is substantially the same
that far back. I believe that 9.1 has the bug as well; but the code
around it is rather different and I don't want to take a chance on
breaking something for what seems a low-probability problem.
M src/pl/plpython/plpy_elog.c
Fix possible use of uninitialised value in ts_headline()
commit : b2a9e161ddb94daf3fa69e177b7e48ee944ec5a2
author : Teodor Sigaev <teodor@sigaev.ru>
date : Fri, 8 Apr 2016 21:25:47 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Fri, 8 Apr 2016 21:25:47 +0300
Found during investigation of failure of skink buildfarm member and its
valgrind report.
Backpatch to all supported branches
M src/backend/tsearch/wparser_def.c
Turn down MSVC compiler verbosity
commit : f79a7fa90a7111974aa986ddf2b108f4525d89ab
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 8 Apr 2016 12:25:10 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 8 Apr 2016 12:25:10 -0400
Most of what is produced by the detailed verbosity level is of no
interest at all, so switch to the normal level for more usable output.
Christian Ullrich
Backpatch to all live branches
M src/tools/msvc/build.pl
Fix broken ALTER INDEX documentation
commit : af3d9fdb88cf7346117885bf731a1aa259d83161
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 5 Apr 2016 19:03:42 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 5 Apr 2016 19:03:42 -0300
Commit b8a91d9d1c put the description of the new IF EXISTS clause in the
wrong place -- move it where it belongs.
Backpatch to 9.2.
M doc/src/sgml/ref/alter_index.sgml
Disallow newlines in parameter values to be set in ALTER SYSTEM.
commit : 28148e25823a42877b2f2ee0961afcb8b5243a72
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Apr 2016 18:05:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Apr 2016 18:05:24 -0400
As noted by Julian Schauder in bug #14063, the configuration-file parser
doesn't support embedded newlines in string literals. While there might
someday be a good reason to remove that restriction, there doesn't seem
to be one right now. However, ALTER SYSTEM SET could accept strings
containing newlines, since many of the variable-specific value-checking
routines would just see a newline as whitespace. This led to writing a
postgresql.auto.conf file that was broken and had to be removed manually.
Pending a reason to work harder, just throw an error if someone tries this.
In passing, fix several places in the ALTER SYSTEM logic that failed to
provide an errcode() for an ereport(), and thus would falsely log the
failure as an internal XX000 error.
Back-patch to 9.4 where ALTER SYSTEM was introduced.
M src/backend/utils/misc/guc.c
Fix latent portability issue in pgwin32_dispatch_queued_signals().
commit : 7901a7f31fe82bbab8ad701fe04188b985c8f1ec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Apr 2016 11:13:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Apr 2016 11:13:17 -0400
The first iteration of the signal-checking loop would compute sigmask(0)
which expands to 1<<(-1) which is undefined behavior according to the
C standard. The lack of field reports of trouble suggest that it
evaluates to 0 on all existing Windows compilers, but that's hardly
something to rely on. Since signal 0 isn't a queueable signal anyway,
we can just make the loop iterate from 1 instead, and save a few cycles
as well as avoiding the undefined behavior.
In passing, avoid evaluating the volatile expression UNBLOCKED_SIGNAL_QUEUE
twice in a row; there's no reason to waste cycles like that.
Noted by Aleksander Alekseev, though this isn't his proposed fix.
Back-patch to all supported branches.
M src/backend/port/win32/signal.c
Remove TZ environment-variable entry from postgres reference page.
commit : e0fb3a20e4941f6be1e8e524b788d6a5c97e0b00
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Mar 2016 21:38:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Mar 2016 21:38:15 -0400
The server hasn't paid attention to the TZ environment variable since
commit ca4af308c32d03db, but that commit missed removing this documentation
reference, as did commit d883b916a947a3c6 which added the reference where
it now belongs (initdb).
Back-patch to 9.2 where the behavior changed. Also back-patch
d883b916a947a3c6 as needed.
Matthew Somerville
M doc/src/sgml/ref/postgres-ref.sgml
Avoid possibly-unsafe use of Windows' FormatMessage() function.
commit : 2fed676c937cdcdfafa72865308b84a7f273e730
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Mar 2016 11:54:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Mar 2016 11:54:57 -0400
Whenever this function is used with the FORMAT_MESSAGE_FROM_SYSTEM flag,
it's good practice to include FORMAT_MESSAGE_IGNORE_INSERTS as well.
Otherwise, if the message contains any %n insertion markers, the function
will try to fetch argument strings to substitute --- which we are not
passing, possibly leading to a crash. This is exactly analogous to the
rule about not giving printf() a format string you're not in control of.
Noted and patched by Christian Ullrich.
Back-patch to all supported branches.
M src/backend/libpq/auth.c
M src/backend/port/win32/socket.c
M src/interfaces/libpq/fe-auth.c
M src/port/dirmod.c