Stamp 9.1.10.
commit : b444726ef6642ed2289a1dc10fe53644dba05623
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 23:13:47 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 23:13:47 -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
Revert "Document support for VPATH builds of extensions."
commit : 4a72c60e4a4ab3b60c809079924d019367428315
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 22:41:53 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 22:41:53 -0400
This reverts commit 6ed3c5f7b2846be9e176ea1c99b2d45bba0d6972.
M doc/src/sgml/extend.sgml
Revert "Backpatch pgxs vpath build and installation fixes (v2)"
commit : 791a71a679970c801f526c6b2bb5ef51d6c21ec5
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 22:39:30 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 22:39:30 -0400
This reverts commit 176c70b9f2ce382a5590e42afd7ba4edb87efecb.
pending resolution of
http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net
M src/Makefile.global.in
M src/makefiles/pgxs.mk
docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1
commit : 56e90da8da137c5a91c4086970b721c5ef7d6871
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 7 Oct 2013 21:35:01 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 7 Oct 2013 21:35:01 -0400
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
Oops. Unbreak the 9.1 build.
commit : d81855129ba6115fe27cf204ca2912f9369bfa47
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 8 Oct 2013 03:49:08 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 8 Oct 2013 03:49:08 +0300
I forgot to "git add" latest changes after backpatching the changes
for previous commit.
M src/backend/access/heap/heapam.c
Fix bugs in SSI tuple locking.
commit : 42c63cafb2af32795afa7dd5d3690186af313785
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 7 Oct 2013 23:57:40 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 7 Oct 2013 23:57:40 +0300
1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed
wrong offset number. heapTuple->t_self is set to the tid of the first
tuple in the chain that's visited, not the one actually being read.
2. CheckForSerializableConflictIn() uses the tuple's t_ctid field
instead of t_self to check for exiting predicate locks on the tuple. If
the tuple was updated, but the updater rolled back, t_ctid points to the
aborted dead tuple.
Reported by Hannu Krosing. Backpatch to 9.1.
M src/backend/access/heap/heapam.c
M src/backend/storage/lmgr/predicate.c
Translation updates
commit : 1c4dfd19a6ebb3c2a0471f0a57b9f13d0ccd9d02
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 16:15:26 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Oct 2013 16:15:26 -0400
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/pt_BR.po
M src/backend/po/ru.po
M src/bin/initdb/po/es.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/pt_BR.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/es.po
M src/bin/psql/po/fr.po
M src/bin/scripts/po/es.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/pt_BR.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpython/po/es.po
M src/pl/tcl/po/es.po
Eliminate xmin from hash tag for predicate locks on heap tuples.
commit : 556e6d0ba33388e8e230f11c88d3df25be79bb37
author : Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 7 Oct 2013 14:05:26 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 7 Oct 2013 14:05:26 -0500
If a tuple was frozen while its predicate locks mattered,
read-write dependencies could be missed, resulting in failure to
detect conflicts which could lead to anomalies in committed
serializable transactions.
This field was added to the tag when we still thought that it was
necessary to carry locks forward to a new version of an updated
row. That was later proven to be unnecessary, which allowed
simplification of the code, but elimination of xmin from the tag
was missed at the time.
Per report and analysis by Heikki Linnakangas.
Backpatch to 9.1.
M src/backend/storage/lmgr/predicate.c
M src/include/storage/predicate_internals.h
Document support for VPATH builds of extensions.
commit : 6ed3c5f7b2846be9e176ea1c99b2d45bba0d6972
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 6 Oct 2013 23:07:28 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 6 Oct 2013 23:07:28 -0400
Cédric Villemain and me.
M doc/src/sgml/extend.sgml
doc: Correct psycopg URL
commit : d648af0df403a32ff7e5cb1af638d239b4bd0bdd
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Oct 2013 21:33:26 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Oct 2013 21:33:26 -0400
M doc/src/sgml/external-projects.sgml
pg_basebackup: Add missing newline to error message
commit : c768cf616de9c32e154004e34dba20477112f996
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Oct 2013 21:25:39 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 2 Oct 2013 21:25:39 -0400
M src/bin/pg_basebackup/pg_basebackup.c
Backpatch pgxs vpath build and installation fixes (v2)
commit : 176c70b9f2ce382a5590e42afd7ba4edb87efecb
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Sep 2013 10:45:40 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Sep 2013 10:45:40 -0400
This time with the better installation fix, which I hope won't break the
buildfarm.
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Fix snapshot leak if lo_open called on non-existent object.
commit : cd6c03b5c15e2b8bf306d97ed9befaf83ace5f93
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 30 Sep 2013 11:29:09 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 30 Sep 2013 11:29:09 +0300
lo_open registers the currently active snapshot, and checks if the
large object exists after that. Normally, snapshots registered by lo_open
are unregistered at end of transaction when the lo descriptor is closed, but
if we error out before the lo descriptor is added to the list of open
descriptors, it is leaked. Fix by moving the snapshot registration to after
checking if the large object exists.
Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration
system was introduced in 8.4, so prior versions are not affected (and not
supported, anyway).
M src/backend/storage/large_object/inv_api.c
Revert "Backpatch pgxs vpath build and installation fixes."
commit : 03b6a6b48e932c4123bee4f6b2a71944da5bd05c
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Sep 2013 00:08:37 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Sep 2013 00:08:37 -0400
This reverts commit 15892461042f4e00322f4116236697dde022a2f8.
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Backpatch pgxs vpath build and installation fixes.
commit : 15892461042f4e00322f4116236697dde022a2f8
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 29 Sep 2013 17:33:02 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 29 Sep 2013 17:33:02 -0400
This is a backpatch of commits d942f9d9, 82b01026, and 6697aa2bc, back
to release 9.1 where we introduced extensions which make heavy use of
the PGXS infrastructure.
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Fix spurious warning after vacuuming a page on a table with no indexes.
commit : 096ad243351b09b059408d7d8f422df01b4f496b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 26 Sep 2013 11:24:40 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 26 Sep 2013 11:24:40 +0300
There is a rare race condition, when a transaction that inserted a tuple
aborts while vacuum is processing the page containing the inserted tuple.
Vacuum prunes the page first, which normally removes any dead tuples, but
if the inserting transaction aborts right after that, the loop after
pruning will see a dead tuple and remove it instead. That's OK, but if the
page is on a table with no indexes, and the page becomes completely empty
after removing the dead tuple (or tuples) on it, it will be immediately
marked as all-visible. That's OK, but the sanity check in vacuum would
throw a warning because it thinks that the page contains dead tuples and
was nevertheless marked as all-visible, even though it just vacuumed away
the dead tuples and so it doesn't actually contain any.
Spotted this while reading the code. It's difficult to hit the race
condition otherwise, but can be done by putting a breakpoint after the
heap_page_prune() call.
Backpatch all the way to 8.4, where this code first appeared.
M src/backend/commands/vacuumlazy.c
Fix pgindent comment breakage
commit : 1e691588c19f9c763bfb9e80682ed08033f467a1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 24 Sep 2013 18:19:14 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 24 Sep 2013 18:19:14 -0300
M src/backend/access/heap/visibilitymap.c
Use @libdir@ in both of regress/{input,output}/security_label.source
commit : ea0a8f0d2266986171043e73e078464f6fa95535
author : Noah Misch <noah@leadboat.com>
date : Mon, 23 Sep 2013 16:00:13 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 23 Sep 2013 16:00:13 -0400
Though @libdir@ almost always matches @abs_builddir@ in this context,
the test could only fail if they differed. Back-patch to 9.1, where the
test was introduced.
Hamid Quddus Akhtar
M src/test/regress/output/security_label.source
Fix SSL deadlock risk in libpq
commit : 5eaa369e2e669e0928f2531329825cf4f4d5c884
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 23 Sep 2013 08:33:41 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 23 Sep 2013 08:33:41 -0400
In libpq, we set up and pass to OpenSSL callback routines to handle
locking. When we run out of SSL connections, we try to clean things
up by de-registering the hooks. Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered during
SSL cleanup which lead to deadlocking. This moves the thread callback
cleanup to be after all SSL-cleanup related OpenSSL library calls.
I've been unable to reproduce the deadlock with this fix.
In passing, also move the close_SSL call to be after unlocking our
ssl_config mutex when in a failure state. While it looks pretty
unlikely to be an issue, it could have resulted in deadlocks if we
ended up in this code path due to something other than SSL_new
failing. Thanks to Heikki for pointing this out.
Back-patch to all supported versions; note that the close_SSL issue
only goes back to 9.0, so that hunk isn't included in the 8.4 patch.
Initially found and reported by Vesa-Matti J Kari; many thanks to
both Heikki and Andres for their help running down the specific
issue and reviewing the patch.
M src/interfaces/libpq/fe-secure.c
Ignore interrupts during quickdie().
commit : f0d76a515e88a2709e23693c2f9cfb979063dfe2
author : Noah Misch <noah@leadboat.com>
date : Wed, 11 Sep 2013 20:10:15 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 11 Sep 2013 20:10:15 -0400
Once the administrator has called for an immediate shutdown or a backend
crash has triggered a reinitialization, no mere SIGINT or SIGTERM should
change that course. Such derailment remains possible when the signal
arrives before quickdie() blocks signals. That being a narrow race
affecting most PostgreSQL signal handlers in some way, leave it for
another patch. Back-patch this to all supported versions.
M src/backend/tcop/postgres.c
Return error if allocation of new element was not possible.
commit : 994362a317ced987b6ea616b236c402d715ddcd5
author : Michael Meskes <meskes@postgresql.org>
date : Sun, 8 Sep 2013 12:59:43 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Sun, 8 Sep 2013 12:59:43 +0200
Found by Coverity.
M src/interfaces/ecpg/pgtypeslib/numeric.c
Close file to no leak file descriptor memory. Found by Coverity.
commit : aef9d25aa3dc90bf303897ffc445c92420df4a6d
author : Michael Meskes <meskes@postgresql.org>
date : Sun, 8 Sep 2013 12:49:54 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Sun, 8 Sep 2013 12:49:54 +0200
M src/interfaces/ecpg/preproc/pgc.l
Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies off.
commit : 8e67a28eea9b7d068bdbe8fc9978f7fb2edda54b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Sep 2013 18:32:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 3 Sep 2013 18:32:29 -0400
The previous coding attempted to activate all the GUC settings specified
in SET clauses, so that the function validator could operate in the GUC
environment expected by the function body. However, this is problematic
when restoring a dump, since the SET clauses might refer to database
objects that don't exist yet. We already have the parameter
check_function_bodies that's meant to prevent forward references in
function definitions from breaking dumps, so let's change CREATE FUNCTION
to not install the SET values if check_function_bodies is off.
Authors of function validators were already advised not to make any
"context sensitive" checks when check_function_bodies is off, if indeed
they're checking anything at all in that mode. But extend the
documentation to point out the GUC issue in particular.
(Note that we still check the SET clauses to some extent; the behavior
with !check_function_bodies is now approximately equivalent to what ALTER
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)
This problem can be demonstrated in all active branches, so back-patch
all the way.
M doc/src/sgml/plhandler.sgml
M src/backend/catalog/pg_proc.c
M src/test/regress/expected/guc.out
M src/test/regress/sql/guc.sql
Update time zone data files to tzdata release 2013d.
commit : f8730733e048159702a74b82b1106e0646bfaac5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Sep 2013 15:06:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Sep 2013 15:06:21 -0400
DST law changes in Israel, Morocco, Palestine, Paraguay.
Historical corrections for Macquarie Island.
M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/europe
M src/timezone/data/iso3166.tab
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
Fix relfrozenxid query in docs to include TOAST tables.
commit : c558e1e64db77634893ca062d1e8b8f841d54f56
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 2 Sep 2013 14:36:08 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 2 Sep 2013 14:36:08 -0400
The original query ignored TOAST tables which could result in tables
needing a vacuum not being reported.
Backpatch to all live branches.
M doc/src/sgml/maintenance.sgml
Unconditionally use the WSA equivalents of Socket error constants.
commit : b8288038baed0fd71f5c19a6a41f12265a719aea
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 26 Aug 2013 14:55:00 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 26 Aug 2013 14:55:00 -0400
This change will only apply to mingw compilers, and has been found
necessary by late versions of the mingw-w64 compiler. It's the same as
what is done elsewhere for the Microsoft compilers.
Backpatch of commit 73838b5251e.
Problem reported by Michael Cronenworth, although not his patch.
M src/include/port/win32.h
In locate_grouping_columns(), don't expect an exact match of Var typmods.
commit : f7bbd46dcfb057459f467da1b0385ae6c13e5977
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 23 Aug 2013 17:31:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 23 Aug 2013 17:31:03 -0400
It's possible that inlining of SQL functions (or perhaps other changes?)
has exposed typmod information not known at parse time. In such cases,
Vars generated by query_planner might have valid typmod values while the
original grouping columns only have typmod -1. This isn't a semantic
problem since the behavior of grouping only depends on type not typmod,
but it breaks locate_grouping_columns' use of tlist_member to locate the
matching entry in query_planner's result tlist.
We can fix this without an excessive amount of new code or complexity by
relying on the fact that locate_grouping_columns only gets called when
make_subplanTargetList has set need_tlist_eval == false, and that can only
happen if all the grouping columns are simple Vars. Therefore we only need
to search the sub_tlist for a matching Var, and we can reasonably define a
"match" as being a match of the Var identity fields
varno/varattno/varlevelsup. The code still Asserts that vartype matches,
but ignores vartypmod.
Per bug #8393 from Evan Martin. The added regression test case is
basically the same as his example. This has been broken for a very long
time, so back-patch to all supported branches.
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/tlist.c
M src/include/optimizer/tlist.h
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql
Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches.
commit : 649839dd9f1c08b7aadb654587edd9f86a3caa3f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Aug 2013 18:31:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Aug 2013 18:31:48 -0400
With this optimization flag enabled, recent versions of gcc can generate
incorrect code that assumes variable-length arrays (such as oidvector)
are actually fixed-length because they're embedded in some larger struct.
The known instance of this problem was fixed in 9.2 and up by commit
8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides
actually-variable-length catalog fields from the compiler altogether.
And we plan to gradually convert variable-length fields to official
"flexible array member" notation over time, which should prevent this type
of bug from reappearing as gcc gets smarter. We're not going to try to
back-port those changes into older branches, though, so apply this
band-aid instead.
Andres Freund
M configure
M configure.in
libpq: Report strerror on pthread_mutex_lock() failure
commit : a2e66c03a4cc3d300e743930ffcc903ee786ffd5
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 17 Aug 2013 21:46:32 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 17 Aug 2013 21:46:32 -0400
M src/interfaces/libpq/fe-secure.c
Make sure float4in/float8in accept all standard spellings of "infinity".
commit : 6084c0705ae03fa7641369e33a2c487585b8f942
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 3 Aug 2013 12:39:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 3 Aug 2013 12:39:57 -0400
The C99 and POSIX standards require strtod() to accept all these spellings
(case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity",
"-infinity". However, pre-C99 systems might accept only some or none of
these, and apparently Windows still doesn't accept "inf". To avoid
surprising cross-platform behavioral differences, manually check for each
of these spellings if strtod() fails. We were previously handling just
"infinity" and "-infinity" that way, but since C99 is most of the world
now, it seems likely that applications are expecting all these spellings
to work.
Per bug #8355 from Basil Peace. It turns out this fix won't actually
resolve his problem, because Python isn't being this careful; but that
doesn't mean we shouldn't be.
M src/backend/utils/adt/float.c
Fix old visibility bug in HeapTupleSatisfiesDirty
commit : c928dc9dfbbfa374f8614726428743d4445bc1d7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 2 Aug 2013 14:34:56 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 2 Aug 2013 14:34:56 -0400
If a tuple is locked but not updated by a concurrent transaction,
HeapTupleSatisfiesDirty would return that transaction's Xid in xmax,
causing callers to wait on it, when it is not necessary (in fact, if the
other transaction had used a multixact instead of a plain Xid to mark
the tuple, HeapTupleSatisfiesDirty would have behave differently and
*not* returned the Xmax).
This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998,
so it's almost 15 years old now. However, it's hard to see this
misbehave, because before we had NOWAIT the only consequence of this is
that transactions would wait for slightly more time than necessary; so
it's not surprising that this hasn't been reported yet.
Craig Ringer and Andres Freund
M src/backend/utils/time/tqual.c
Improve handling of pthread_mutex_lock error case
commit : 71127756af12ed64da9e82639f88b6ed13e5f600
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 1 Aug 2013 15:42:07 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 1 Aug 2013 15:42:07 -0400
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason. Add that and back-patch to 9.0 as the prior patch.
Pointed out by Alvaro Herrera
M src/interfaces/libpq/fe-secure.c
Add locking around SSL_context usage in libpq
commit : 0b821b8d7c137fbec215f8da286b4a40e53b13d5
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 1 Aug 2013 01:15:45 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 1 Aug 2013 01:15:45 -0400
I've been working with Nick Phillips on an issue he ran into when
trying to use threads with SSL client certificates. As it turns out,
the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file()
will modify our SSL_context without any protection from other threads
also calling that function or being at some other point and trying to
read from SSL_context.
To protect against this, I've written up the attached (based on an
initial patch from Nick and much subsequent discussion) which puts
locks around SSL_CTX_use_certificate_chain_file() and all of the other
users of SSL_context which weren't already protected.
Nick Phillips, much reworked by Stephen Frost
Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
M src/interfaces/libpq/fe-secure.c
Fix regexp_matches() handling of zero-length matches.
commit : 1346f40b584d8072bdacdf312027c0ef57e4b7c2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Jul 2013 11:31:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Jul 2013 11:31:33 -0400
We'd find the same match twice if it was of zero length and not immediately
adjacent to the previous match. replace_text_regexp() got similar cases
right, so adjust this search logic to match that. Note that even though
the regexp_split_to_xxx() functions share this code, they did not display
equivalent misbehavior, because the second match would be considered
degenerate and ignored.
Jeevan Chalke, with some cosmetic changes by me.
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/varlena.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
Restore REINDEX constraint validation.
commit : ed33ad39a2f353acc3d38591a749f324de3b6c23
author : Noah Misch <noah@leadboat.com>
date : Tue, 30 Jul 2013 18:36:52 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 30 Jul 2013 18:36:52 -0400
Refactoring as part of commit 8ceb24568054232696dddc1166a8563bc78c900a
had the unintended effect of making REINDEX TABLE and REINDEX DATABASE
no longer validate constraints enforced by the indexes in question;
REINDEX INDEX still did so. Indexes marked invalid remained so, and
constraint violations arising from data corruption went undetected.
Back-patch to 9.0, like the causative commit.
M src/backend/commands/indexcmds.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Fix contrib/cube and contrib/seg to build with bison 3.0.
commit : aa4982169d42660a848e4d25f52bdabcf3f12860
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Jul 2013 10:42:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Jul 2013 10:42:47 -0400
These modules used the YYPARSE_PARAM macro, which has been deprecated
by the bison folk since 1.875, and which they finally removed in 3.0.
Adjust the code to use the replacement facility, %parse-param, which
is a much better solution anyway since it allows specification of the
type of the extra parser parameter. We can thus get rid of a lot of
unsightly casting.
Back-patch to all active branches, since somebody might try to build
a back branch with up-to-date tools.
M contrib/cube/cube.c
M contrib/cube/cubeparse.y
M contrib/cube/cubescan.l
M contrib/seg/seg.c
M contrib/seg/segparse.y
M contrib/seg/segscan.l
Fix configure probe for sys/ucred.h.
commit : 3ba763bd95b6eb027bc87e73806241b460807091
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2013 11:39:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2013 11:39:18 -0400
The configure script's test for <sys/ucred.h> did not work on OpenBSD,
because on that platform <sys/param.h> has to be included first.
As a result, socket peer authentication was disabled on that platform.
Problem introduced in commit be4585b1c27ac5dbdd0d61740d18f7ad9a00e268.
Andres Freund, slightly simplified by me.
M configure
M configure.in
Fix booltestsel() for case where we have NULL stats but not MCV stats.
commit : 13f11c8a8cd0f696fc5f4aead96344e4a6173448
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Jul 2013 00:44:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Jul 2013 00:44:09 -0400
In a boolean column that contains mostly nulls, ANALYZE might not find
enough non-null values to populate the most-common-values stats,
but it would still create a pg_statistic entry with stanullfrac set.
The logic in booltestsel() for this situation did the wrong thing for
"col IS NOT TRUE" and "col IS NOT FALSE" tests, forgetting that null
values would satisfy these tests (so that the true selectivity would
be close to one, not close to zero). Per bug #8274.
Fix by Andrew Gierth, some comment-smithing by me.
M src/backend/utils/adt/selfuncs.c
Check for NULL result from strdup
commit : 15fdf7302a99b0f63394bc49c2528b4731a6627e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 23 Jul 2013 17:38:31 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 23 Jul 2013 17:38:31 -0400
Per Coverity Scan
M src/interfaces/libpq/fe-secure.c
Change post-rewriter representation of dropped columns in joinaliasvars.
commit : c1f51ed2960ac2678535c252072695a4a8325a92
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Jul 2013 16:23:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Jul 2013 16:23:11 -0400
It's possible to drop a column from an input table of a JOIN clause in a
view, if that column is nowhere actually referenced in the view. But it
will still be there in the JOIN clause's joinaliasvars list. We used to
replace such entries with NULL Const nodes, which is handy for generation
of RowExpr expansion of a whole-row reference to the view. The trouble
with that is that it can't be distinguished from the situation after
subquery pull-up of a constant subquery output expression below the JOIN.
Instead, replace such joinaliasvars with null pointers (empty expression
trees), which can't be confused with pulled-up expressions. expandRTE()
still emits the old convention, though, for convenience of RowExpr
generation and to reduce the risk of breaking extension code.
In HEAD and 9.3, this patch also fixes a problem with some new code in
ruleutils.c that was failing to cope with implicitly-casted joinaliasvars
entries, as per recent report from Feike Steenbergen. That oversight was
because of an inadequate description of the data structure in parsenodes.h,
which I've now corrected. There were some pre-existing oversights of the
same ilk elsewhere, which I believe are now all fixed.
M src/backend/optimizer/util/var.c
M src/backend/parser/parse_relation.c
M src/backend/parser/parse_target.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/utils/adt/ruleutils.c
M src/include/nodes/parsenodes.h
doc: Fix typos in conversion names.
commit : e23adeff0c288ff10a368b94cfb78ee291999113
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 19 Jul 2013 10:23:12 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 19 Jul 2013 10:23:12 -0400
David Christensen
M doc/src/sgml/func.sgml
Initialize day of year value.
commit : 4652abeb30b28dcb38621ea31f24936cdbdc83f8
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 19 Jul 2013 08:59:20 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 19 Jul 2013 08:59:20 +0200
There are cases where the day of year value in struct tm is used, but it never
got calculated. Problem found by Coverity scan.
M src/interfaces/ecpg/pgtypeslib/timestamp.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stderr
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test.stdout
M src/interfaces/ecpg/test/pgtypeslib/dt_test.pgc
Fix regex match failures for backrefs combined with non-greedy quantifiers.
commit : f4ceb7aa56e356da30a8de376a66f0fbcdbf938a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Jul 2013 21:22:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Jul 2013 21:22:53 -0400
An ancient logic error in cfindloop() could cause the regex engine to fail
to find matches that begin later than the start of the string. This
function is only used when the regex pattern contains a back reference,
and so far as we can tell the error is only reachable if the pattern is
non-greedy (i.e. its first quantifier uses the ? modifier). Furthermore,
the actual match must begin after some potential match that satisfies the
DFA but then fails the back-reference's match test.
Reported and fixed by Jeevan Chalke, with cosmetic adjustments by me.
M src/backend/regex/regexec.c
Clean up pg_basebackup libpq usage
commit : 2f397a08de49e28e3430ff7278f4648757dea2a3
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 15 Jul 2013 11:27:20 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 15 Jul 2013 11:27:20 -0400
When using libpq, it's generally preferrable to just use the strings
which are in the PQ structures instead of copying them out, so do
that instead in BaseBackup(), eliminating the strcpy()'s used there.
Also, in ReceiveAndUnpackTarFile(), check the string length for the
directory returned by the server for the tablespace path.
M src/bin/pg_basebackup/pg_basebackup.c
Ensure 64bit arithmetic when calculating tapeSpace
commit : 3cb7a393e8e93b1e67bb1e0d361dd1eb7d928ae7
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 14 Jul 2013 16:43:47 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 14 Jul 2013 16:43:47 -0400
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we allow work_mem to be
larger than 2GB and that allows maxTapes to be large enough that the
32bit arithmetic can overflow when multiplied against the buffer
overhead.
When this overflow happens, we end up adding the overflow to the
amount of space available, causing the amount of memory allocated to
be larger than work_mem.
Note that to reach this point, you have to set work mem to at least
24GB and be sorting a set which is at least that size. Given that a
user who can set work_mem to 24GB could also set it even higher, if
they were looking to run the system out of memory, this isn't
considered a security issue.
This overflow risk was found by the Coverity scanner.
Back-patch to all supported branches, as this issue has existed
since before 8.4.
M src/backend/utils/sort/tuplesort.c
Fixed incorrect description of EXEC SQL VAR command.
commit : 703bc145f773835637a8a01f2fe4cfb864835bb1
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 27 Jun 2013 16:00:32 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 27 Jun 2013 16:00:32 +0200
Thanks to MauMau <maumau307@gmail.com> for finding and fixing this.
M doc/src/sgml/ecpg.sgml
pg_upgrade: document possible pg_hba.conf options Previously, pg_upgrade docs recommended using .pgpass if using MD5 authentication to avoid being prompted for a password. Turns out pg_ctl never prompts for a password, so MD5 requires .pgpass --- document that. Also recommend 'peer' for authentication too. Backpatch back to 9.1.
commit : ad4c625ee464b409f341d4680127e816391fe94f
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Jul 2013 09:43:15 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Jul 2013 09:43:15 -0400
M doc/src/sgml/pgupgrade.sgml
Fix include-guard
commit : 271f7b0f8ab8f584fafc7703f1a9ac14d81ca21d
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 7 Jul 2013 13:36:20 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 7 Jul 2013 13:36:20 +0200
Looks like a cut/paste error in the original addition of the file.
Andres Freund
M src/include/utils/attoptcache.h
Also escape double quotes for ECPG's #line statement.
commit : 6dc4e62d0457b42969732aae0651a4bf25565ad5
author : Michael Meskes <meskes@postgresql.org>
date : Sat, 6 Jul 2013 22:08:53 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Sat, 6 Jul 2013 22:08:53 +0200
M src/interfaces/ecpg/preproc/output.c
Remove stray | character
commit : 456d37a0bfaf22ecd5c7e86778595278b32f43f8
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 5 Jul 2013 16:22:45 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 5 Jul 2013 16:22:45 +0200
Erikjan Rijkers
M doc/src/sgml/ref/copy.sgml
Applied patch by MauMau <maumau307@gmail.com> to escape filenames in #line statements.
commit : 2bb2a29c714293ba520d4332533ee62b7d774b28
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 5 Jul 2013 11:07:16 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 5 Jul 2013 11:07:16 +0200
M src/interfaces/ecpg/preproc/output.c
Mention extra_float_digits in floating point docs
commit : 8455b70fee2ddaabb5f76ed3aef11c97cbd10507
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Jul 2013 12:21:16 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Jul 2013 12:21:16 -0400
Make it easier for readers of the FP docs to find out about possibly
truncated values.
Per complaint from Tom Duffey in message
F0E0F874-C86F-48D1-AA2A-0C5365BF5118@trillitech.com
Author: Albe Laurenz
Reviewed by: Abhijit Menon-Sen
M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
Mark index-constraint comments with correct dependency in pg_dump.
commit : 50e66d37aceee0f38c44f41834f39cfdda34c796
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jun 2013 13:55:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jun 2013 13:55:04 -0400
When there's a comment on an index that was created with UNIQUE or PRIMARY
KEY constraint syntax, we need to label the comment as depending on the
constraint not the index, since only the constraint object actually appears
in the dump. This incorrect dependency can lead to parallel pg_restore
trying to restore the comment before the index has been created, per bug
#8257 from Lloyd Albin.
This patch fixes pg_dump to produce the right dependency in dumps made
in the future. Usually we also try to hack pg_restore to work around
bogus dependencies, so that existing (wrong) dumps can still be restored in
parallel mode; but that doesn't seem practical here since there's no easy
way to relate the constraint dump entry to the comment after the fact.
Andres Freund
M src/bin/pg_dump/pg_dump.c
Expect EWOULDBLOCK from a non-blocking connect() call only on Windows.
commit : c204aba26ce0c7efeaac193d274742423074bbd3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jun 2013 12:36:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jun 2013 12:36:44 -0400
On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is
*not* a success return, at least not on Linux. We need to treat it as a
failure to avoid giving a misleading error message. Per the Single Unix
Spec, only EINPROGRESS and EINTR returns indicate that the connection
attempt is in progress.
On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected
case. We must accept EINPROGRESS as well because Cygwin will return that,
and it doesn't seem worth distinguishing Cygwin from native Windows here.
It's not very clear whether EINTR can occur on Windows, but let's leave
that part of the logic alone in the absence of concrete trouble reports.
Also, remove the test for errno == 0, effectively reverting commit
da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko;
or at best it might have been a workaround for a platform-specific bug,
which we can hope is gone now thirteen years later. In any case, since
libpq makes no effort to reset errno to zero before calling connect(),
it seems unlikely that that test has ever reliably done anything useful.
Andres Freund and Tom Lane
M src/interfaces/libpq/fe-connect.c
Tweak wording in sequence-function docs to avoid PDF build failures.
commit : 0ae7d63b5c219f8e7f89b8f0f8df18843fed556f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jun 2013 00:27:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jun 2013 00:27:26 -0400
Adjust the wording in the first para of "Sequence Manipulation Functions"
so that neither of the link phrases in it break across line boundaries,
in either A4- or US-page-size PDF output. This fixes a reported build
failure for the 9.3beta2 A4 PDF docs, and future-proofs this particular
para against causing similar problems in future. (Perhaps somebody will
fix this issue in the SGML/TeX documentation tool chain someday, but I'm
not holding my breath.)
Back-patch to all supported branches, since the same problem could rise up
to bite us in future updates if anyone changes anything earlier than this
in func.sgml.
M doc/src/sgml/func.sgml
Document effect of constant folding on CASE.
commit : 8356d9498860cd377eb1edd8b64a840b6b411081
author : Noah Misch <noah@leadboat.com>
date : Wed, 26 Jun 2013 19:51:56 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 26 Jun 2013 19:51:56 -0400
Back-patch to all supported versions.
Laurenz Albe
M doc/src/sgml/func.sgml
Properly dump dropped foreign table cols in binary-upgrade mode.
commit : 1c6afc40f7f9e3fd823e415adbfa6b2ac6f9864d
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 25 Jun 2013 13:44:34 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 25 Jun 2013 13:44:34 -0400
In binary upgrade mode, we need to recreate and then drop dropped
columns so that all the columns get the right attribute number. This is
true for foreign tables as well as for native tables. For foreign
tables we have been getting the first part right but not the second,
leading to bogus columns in the upgraded database. Fix this all the way
back to 9.1, where foreign tables were introduced.
M src/bin/pg_dump/pg_dump.c
Support clean switchover.
commit : 3f145f6be3d307af1ac7ceb808b6cf0486bc0c9e
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 26 Jun 2013 02:20:11 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 26 Jun 2013 02:20:11 +0900
In replication, when we shutdown the master, walsender tries to send
all the outstanding WAL records to the standby, and then to exit. This
basically means that all the WAL records are fully synced between
two servers after the clean shutdown of the master. So, after
promoting the standby to new master, we can restart the stopped
master as new standby without the need for a fresh backup from
new master.
But there was one problem so far: though walsender tries to send all
the outstanding WAL records, it doesn't wait for them to be replicated
to the standby. Then, before receiving all the WAL records,
walreceiver can detect the closure of connection and exit. We cannot
guarantee that there is no missing WAL in the standby after clean
shutdown of the master. In this case, backup from new master is
required when restarting the stopped master as new standby.
This patch fixes this problem. It just changes walsender so that it
waits for all the outstanding WAL records to be replicated to the
standby before closing the replication connection.
Per discussion, this is a fix that needs to get backpatched rather than
new feature. So, back-patch to 9.1 where enough infrastructure for
this exists.
Patch by me, reviewed by Andres Freund.
M src/backend/replication/walsender.c
Ensure no xid gaps during Hot Standby startup
commit : a41c88194b19655d7f2cb556d0fdada227dea941
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sun, 23 Jun 2013 11:05:02 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sun, 23 Jun 2013 11:05:02 +0100
In some cases with higher numbers of subtransactions
it was possible for us to incorrectly initialize
subtrans leading to complaints of missing pages.
Bug report by Sergey Konoplev
Analysis and fix by Andres Freund
M src/backend/access/transam/xlog.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/procarray.h
Update CREATE FUNCTION documentation about argument names
commit : 27e9e86f6d2268d53555bc9474154f5286c64073
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 19 Jun 2013 22:31:42 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 19 Jun 2013 22:31:42 -0400
More languages than PL/pgSQL actually support parameter names.
M doc/src/sgml/ref/create_function.sgml
Fix docs on lock level for ALTER TABLE VALIDATE
commit : be039d4b29be88a7f8b57d6353c81bced54d1b83
author : Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 18 Jun 2013 12:05:48 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Tue, 18 Jun 2013 12:05:48 +0100
ALTER TABLE .. VALIDATE CONSTRAINT previously
gave incorrect details about lock levels and
therefore incomplete reasons to use the option.
Initial bug report and fix from Marko Tiikkaja
Reworded by me to include comments by Kevin Grittner
M doc/src/sgml/ref/alter_table.sgml
Fix pg_restore -l with the directory archive to display the correct format name.
commit : 81bb2d23bdf8d0b102c5fb0abd0a5df6fd74aba9
author : Fujii Masao <fujii@postgresql.org>
date : Sun, 16 Jun 2013 05:15:44 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Sun, 16 Jun 2013 05:15:44 +0900
Back-patch to 9.1 where the directory archive was introduced.
M src/bin/pg_dump/pg_backup_archiver.c
Only install a portal's ResourceOwner if it actually has one.
commit : cf0f08e03b51c58e72d56d52a9c07ffbe808a3f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jun 2013 13:11:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jun 2013 13:11:40 -0400
In most scenarios a portal without a ResourceOwner is dead and not subject
to any further execution, but a portal for a cursor WITH HOLD remains in
existence with no ResourceOwner after the creating transaction is over.
In this situation, if we attempt to "execute" the portal directly to fetch
data from it, we were setting CurrentResourceOwner to NULL, leading to a
segfault if the datatype output code did anything that required a resource
owner (such as trying to fetch system catalog entries that weren't already
cached). The case appears to be impossible to provoke with stock libpq,
but psqlODBC at least is able to cause it when working with held cursors.
Simplest fix is to just skip the assignment to CurrentResourceOwner, so
that any resources used by the data output operations will be managed by
the transaction-level resource owner instead. For consistency I changed
all the places that install a portal's resowner as current, even though
some of them are probably not reachable with a held cursor's portal.
Per report from Joshua Berry (with thanks to Hiroshi Inoue for developing
a self-contained test case). Back-patch to all supported versions.
M src/backend/commands/portalcmds.c
M src/backend/tcop/pquery.c
Improve description of loread/lowrite.
commit : e19c932edf199068895b4e3bc53218db59407f0b
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 12 Jun 2013 12:20:59 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 12 Jun 2013 12:20:59 -0400
Patch by me, reviewed by Tatsuo Ishii.
M doc/src/sgml/lobj.sgml
Fix cache flush hazard in cache_record_field_properties().
commit : e46753e9b935516b296bff8d46b9234bc46ee596
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Jun 2013 17:26:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Jun 2013 17:26:53 -0400
We need to increment the refcount on the composite type's cached tuple
descriptor while we do lookups of its column types. Otherwise a cache
flush could occur and release the tuple descriptor before we're done with
it. This fails reliably with -DCLOBBER_CACHE_ALWAYS, but the odds of a
failure in a production build seem rather low (since the pfree'd descriptor
typically wouldn't get scribbled on immediately). That may explain the
lack of any previous reports. Buildfarm issue noted by Christian Ullrich.
Back-patch to 9.1 where the bogus code was added.
M src/backend/utils/cache/typcache.c
Add description that loread()/lowrite() are corresponding to lo_read()/lo_write() in libpq to avoid confusion.
commit : 219ef8e33ce09725a9ae1c345c63b98884a101d6
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 11 Jun 2013 14:25:58 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 11 Jun 2013 14:25:58 +0900
M doc/src/sgml/lobj.sgml
Fix ordering of obj id for Rules and EventTriggers in pg_dump.
commit : 86742ac9c838cb383f951703f28938d371cb7858
author : Joe Conway <mail@joeconway.com>
date : Sun, 9 Jun 2013 17:31:51 -0700
committer: Joe Conway <mail@joeconway.com>
date : Sun, 9 Jun 2013 17:31:51 -0700
getSchemaData() must identify extension member objects and mark them
as not to be dumped. This must happen after reading all objects that can be
direct members of extensions, but before we begin to process table subsidiary
objects. Both rules and event triggers were wrong in this regard.
Backport rules portion of patch to 9.1 -- event triggers do not exist prior to 9.3.
Suggested fix by Tom Lane, initial complaint and patch by me.
M src/bin/pg_dump/common.c
Remove unnecessary restrictions about RowExprs in transformAExprIn().
commit : a2c2336f9601c7c3b62c910eb5716d196cdd8496
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Jun 2013 18:39:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Jun 2013 18:39:34 -0400
When the existing code here was written, it made sense to special-case
RowExprs because that was the only way that we could handle row comparisons
at all. Now that we have record_eq() and arrays of composites, the generic
logic for "scalar" types will in fact work on RowExprs too, so there's no
reason to throw error for combinations of RowExprs and other ways of
forming composite values, nor to ignore the possibility of using a
ScalarArrayOpExpr. But keep using the old logic when comparing two
RowExprs, for consistency with the main transformAExprOp() logic. (This
allows some cases with not-quite-identical rowtypes to succeed, so we might
get push-back if we removed it.) Per bug #8198 from Rafal Rzepecki.
Back-patch to all supported branches, since this works fine as far back as
8.4.
Rafal Rzepecki and Tom Lane
M src/backend/parser/parse_expr.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql
Remove ALTER DEFAULT PRIVILEGES' requirement of schema CREATE permissions.
commit : aee8a60c7232cc048e00a704fca49730a722432a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Jun 2013 15:26:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Jun 2013 15:26:55 -0400
Per discussion, this restriction isn't needed for any real security reason,
and it seems to confuse people more often than it helps them. It could
also result in some database states being unrestorable. So just drop it.
Back-patch to 9.0, where ALTER DEFAULT PRIVILEGES was introduced.
M doc/src/sgml/ref/alter_default_privileges.sgml
M src/backend/catalog/aclchk.c
Remove fixed limit on the number of concurrent AllocateFile() requests.
commit : 8c3fdbb56e8ab404bbd4d919c2cc53ca4b031516
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Jun 2013 13:47:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 9 Jun 2013 13:47:06 -0400
AllocateFile(), AllocateDir(), and some sister routines share a small array
for remembering requests, so that the files can be closed on transaction
failure. Previously that array had a fixed size, MAX_ALLOCATED_DESCS (32).
While historically that had seemed sufficient, Steve Toutant pointed out
that this meant you couldn't scan more than 32 file_fdw foreign tables in
one query, because file_fdw depends on the COPY code which uses
AllocateFile(). There are probably other cases, or will be in the future,
where this nonconfigurable limit impedes users.
We can't completely remove any such limit, at least not without a lot of
work, since each such request requires a kernel file descriptor and most
platforms limit the number we can have. (In principle we could
"virtualize" these descriptors, as fd.c already does for the main VFD pool,
but not without an additional layer of overhead and a lot of notational
impact on the calling code.) But we can at least let the array size be
configurable. Hence, change the code to allow up to max_safe_fds/2
allocated file requests. On modern platforms this should allow several
hundred concurrent file_fdw scans, or more if one increases the value of
max_files_per_process. To go much further than that, we'd need to do some
more work on the data structure, since the current code for closing
requests has potentially O(N^2) runtime; but it should still be all right
for request counts in this range.
Back-patch to 9.1 where contrib/file_fdw was introduced.
M src/backend/storage/file/fd.c
Don't downcase non-ascii identifier chars in multi-byte encodings.
commit : d7cb64aeb5a7e40f4ea75e60bba1d606ca06df7f
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 8 Jun 2013 10:20:54 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 8 Jun 2013 10:20:54 -0400
Long-standing code has called tolower() on identifier character bytes
with the high bit set. This is clearly an error and produces junk output
when the encoding is multi-byte. This patch therefore restricts this
activity to cases where there is a character with the high bit set AND
the encoding is single-byte.
There have been numerous gripes about this, most recently from Martin
Schäfer.
Backpatch to all live releases.
M src/backend/parser/scansup.c
Correct the documentation of pg_rewrite.ev_attr.
commit : 8af3f277b4f941404ae43251e23d6561f2250ebb
author : Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 7 Jun 2013 09:24:07 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 7 Jun 2013 09:24:07 -0500
It claimed the value was always zero; it is really always -1.
Per report from Hari Babu
backpatch 734fbbd1d2d1babfbd195414e2445024ad549ae3 to 8.4
M doc/src/sgml/catalogs.sgml
Minor docs wordsmithing.
commit : ca6566612cfb2a4eb15d31aab5df312ebb786372
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 7 Jun 2013 00:08:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 7 Jun 2013 00:08:02 -0400
Swap the order of a couple of phrases to clarify what the adjective
"subsequent" applies to.
Joshua Tolley
M doc/src/sgml/ref/select.sgml
Fix typo in comment.
commit : 3ebdf6c9f99b45adf2419db54c1303dabab4fe57
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jun 2013 18:25:26 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jun 2013 18:25:26 +0300
M src/backend/access/transam/xlog.c
Prevent pushing down WHERE clauses into unsafe UNION/INTERSECT nests.
commit : f753c9d596d835d47770d1b3eed6ea9c1d3af4a8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Jun 2013 23:44:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Jun 2013 23:44:14 -0400
The planner is aware that it mustn't push down upper-level quals into
subqueries if the quals reference subquery output columns that contain
set-returning functions or volatile functions, or are non-DISTINCT outputs
of a DISTINCT ON subquery. However, it missed making this check when
there were one or more levels of UNION or INTERSECT above the dangerous
expression. This could lead to "set-valued function called in context that
cannot accept a set" errors, as seen in bug #8213 from Eric Soroos, or to
silently wrong answers in the other cases.
To fix, refactor the checks so that we make the column-is-unsafe checks
during subquery_is_pushdown_safe(), which already has to recursively
inspect all arms of a set-operation tree. This makes
qual_is_pushdown_safe() considerably simpler, at the cost that we will
spend some cycles checking output columns that possibly aren't referenced
in any upper qual. But the cases where this code gets executed at all
are already nontrivial queries, so it's unlikely anybody will notice any
slowdown of planning.
This has been broken since commit 05f916e6add9726bf4ee046e4060c1b03c9961f2,
which makes the bug over ten years old. A bit surprising nobody noticed it
before now.
M src/backend/optimizer/path/allpaths.c
M src/test/regress/expected/union.out
M src/test/regress/sql/union.sql
Put analyze_keyword back in explain_option_name production.
commit : 940a85e5e1c32d479d43df89c410195063e786d2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Jun 2013 13:32:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Jun 2013 13:32:53 -0400
In commit 2c92edad48796119c83d7dbe6c33425d1924626d, I broke "EXPLAIN
(ANALYZE)" syntax, because I mistakenly thought that ANALYZE/ANALYSE were
only partially reserved and thus would be included in NonReservedWord;
but actually they're fully reserved so they still need to be called out
here.
A nicer solution would be to demote these words to type_func_name_keyword
status (they can't be less than that because of "VACUUM [ANALYZE] ColId").
While that works fine so far as the core grammar is concerned, it breaks
ECPG's grammar for reasons I don't have time to isolate at the moment.
So do this for the time being.
Per report from Kevin Grittner. Back-patch to 9.0, like the previous
commit.
M src/backend/parser/gram.y
Provide better message when CREATE EXTENSION can't find a target schema.
commit : f94979f618abffb63cad2266f39db8beeeb18afc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Jun 2013 17:22:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Jun 2013 17:22:29 -0400
The new message (and SQLSTATE) matches the corresponding error cases in
namespace.c.
This was thought to be a "can't happen" case when extension.c was written,
so we didn't think hard about how to report it. But it definitely can
happen in 9.2 and later, since we no longer require search_path to contain
any valid schema names. It's probably also possible in 9.1 if search_path
came from a noninteractive source. So, back-patch to all releases
containing this code.
Per report from Sean Chittenden, though this isn't exactly his patch.
M src/backend/commands/extension.c
Fix memory leak in LogStandbySnapshot().
commit : dc12e477eb8a9b502bb613299b9e2b3acd85a4d5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Jun 2013 14:58:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Jun 2013 14:58:57 -0400
The array allocated by GetRunningTransactionLocks() needs to be pfree'd
when we're done with it. Otherwise we leak some memory during each
checkpoint, if wal_level = hot_standby. This manifests as memory bloat
in the checkpointer process, or in bgwriter in versions before we made
the checkpointer separate.
Reported and fixed by Naoya Anzai. Back-patch to 9.0 where the issue
was introduced.
In passing, improve comments for GetRunningTransactionLocks(), and add
an Assert that we didn't overrun the palloc'd array.
M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/lock.c
Add semicolons to eval'd strings to hide a minor Perl behavioral change.
commit : 89bd9fe5fde46af8e2d93d2cb78a8142ac7caf4d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jun 2013 14:19:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jun 2013 14:19:36 -0400
"eval q{foo}" used to complain that the error was on line 2 of the eval'd
string, because eval internally tacked on "\n;" so that the end of the
erroneous command was indeed on line 2. But as of Perl 5.18 it more
sanely says that the error is on line 1. To avoid Perl-version-dependent
regression test results, use "eval q{foo;}" instead in the two places
where this matters. Per buildfarm.
Since people might try to use newer Perl versions with older PG releases,
back-patch as far as 9.0 where these test cases were added.
M src/pl/plperl/expected/plperl.out
M src/pl/plperl/expected/plperl_init.out
M src/pl/plperl/sql/plperl.sql
M src/pl/plperl/sql/plperl_init.sql
Allow type_func_name_keywords in some places where they weren't before.
commit : 1e5588cfd966ef5f4a1e31625b7079cff6d91a5a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2013 20:09:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2013 20:09:32 -0400
This change makes type_func_name_keywords less reserved than they were
before, by allowing them for role names, language names, EXPLAIN and COPY
options, and SET values for GUCs; which are all places where few if any
actual keywords could appear instead, so no new ambiguities are introduced.
The main driver for this change is to allow "COPY ... (FORMAT BINARY)"
to work without quoting the word "binary". That is an inconsistency that
has been complained of repeatedly over the years (at least by Pavel Golub,
Kurt Lidl, and Simon Riggs); but we hadn't thought of any non-ugly solution
until now.
Back-patch to 9.0 where the COPY (FORMAT BINARY) syntax was introduced.
M src/backend/parser/gram.y
Documentation fix for ALTER TYPE .. RENAME
commit : 39485bbdbadab26287e097474bb63acda4593abb
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 27 May 2013 11:12:54 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 27 May 2013 11:12:54 -0400
The documentation for ALTER TYPE .. RENAME claimed to support a
RESTRICT/CASCADE option at the 'type' level, which wasn't implemented
and doesn't make a whole lot of sense to begin with. What is supported,
and previously undocumented, is
ALTER TYPE .. RENAME ATTRIBUTE .. RESTRICT/CASCADE.
I've updated the documentation and back-patched this to 9.1 where it was
first introduced.
M doc/src/sgml/ref/alter_type.sgml
Fix typo in comment.
commit : 7b2d780f2ade55b9d569b1af093e74d4cbfc7792
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 23 May 2013 11:34:30 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 23 May 2013 11:34:30 -0400
Pavan Deolasee
M src/include/replication/syncrep.h
Fix fd.c to preserve errno where needed.
commit : 9d8bc2f0aeaa7f7fceb393fe5740cb709c0f27e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2013 15:04:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2013 15:04:46 -0400
PathNameOpenFile failed to ensure that the correct value of errno was
returned to its caller after a failure (because it incorrectly supposed
that free() can never change errno). In some cases this would result
in a user-visible failure because an expected ENOENT errno was replaced
with something else. Bogus EINVAL failures have been observed on OS X,
for example.
There were also a couple of places that could mangle an important value
of errno if FDDEBUG was defined. While the usefulness of that debug
support is highly debatable, we might as well make it safe to use,
so add errno save/restore logic to the DO_DB macro.
Per bug #8167 from Nelson Minar, diagnosed by RhodiumToad.
Back-patch to all supported branches.
M src/backend/storage/file/fd.c
Fix handling of OID wraparound while in standalone mode.
commit : ee249498a99a1b3be9906aa91f0783939ceb1e21
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2013 15:40:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2013 15:40:16 -0400
If OID wraparound should occur while in standalone mode (unlikely but
possible), we want to advance the counter to FirstNormalObjectId not
FirstBootstrapObjectId. Otherwise, user objects might be created with OIDs
in the system-reserved range. That isn't immediately harmful but it poses
a risk of conflicts during future pg_upgrade operations.
Noted by Andres Freund. Back-patch to all supported branches, since all of
them are supported sources for pg_upgrade operations.
M src/backend/access/transam/varsup.c
Guard against input_rows == 0 in estimate_num_groups().
commit : 0c2c0f82c2cd6d2fa83955e9d767059639010ffc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2013 17:15:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2013 17:15:43 -0400
This case doesn't normally happen, because the planner usually clamps
all row estimates to at least one row; but I found that it can arise
when dealing with relations excluded by constraints. Without a defense,
estimate_num_groups() can return zero, which leads to divisions by zero
inside the planner as well as assertion failures in the executor.
An alternative fix would be to change set_dummy_rel_pathlist() to make
the size estimate for a dummy relation 1 row instead of 0, but that seemed
pretty ugly; and probably someday we'll want to drop the convention that
the minimum rowcount estimate is 1 row.
Back-patch to 8.4, as the problem can be demonstrated that far back.
M src/backend/utils/adt/selfuncs.c
Fix pgp_pub_decrypt() so it works for secret keys with passwords.
commit : fd262376e9d81f77bde73ab70fa9abdcbc9c6199
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2013 13:06:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2013 13:06:57 -0400
Per report from Keith Fiske.
Marko Kreen
M contrib/pgcrypto/expected/pgp-pubkey-decrypt.out
M contrib/pgcrypto/pgp-pubkey.c
M contrib/pgcrypto/sql/pgp-pubkey-decrypt.sql
Use pg_dump's --quote-all-identifiers option in pg_upgrade.
commit : 56ac62570591615ed68137e4d3197e881ca3a405
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 May 2013 17:34:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 May 2013 17:34:45 -0400
This helps guard against changes in the set of reserved keywords from
one version to another. In theory it should only be an issue if we
de-reserve a keyword in a newer release, since that can create the type
of problem shown in bug #8128.
Back-patch to 9.1 where the --quote-all-identifiers option was added.
M contrib/pg_upgrade/dump.c
docs: log_line_prefix session id fix
commit : 6f3ec222fca384a6b63724c4a64029960de969fc
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 4 May 2013 13:15:54 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 4 May 2013 13:15:54 -0400
Restore 4-byte designation for docs. Fix 9.3 doc query to properly pad
to four digits.
Backpatch to all active branches
Per suggestions from Ian Lawrence Barwick
M doc/src/sgml/config.sgml
doc: fix log_line_prefix session_id %c item
commit : 8f80e35b55b83debc4cd08ec27510c05e08e2496
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 4 May 2013 11:09:44 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 4 May 2013 11:09:44 -0400
Backpatch to 9.1 and earlier
Report from Ian Lawrence Barwick
M doc/src/sgml/config.sgml
Fix thinko in comment.
commit : e1d1d8099300bbc55cd44afa4ecab0cca1f33953
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 May 2013 18:08:43 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 May 2013 18:08:43 +0300
WAL segment means a 16 MB physical WAL file; this comment meant a logical
4 GB log file.
Amit Langote. Apply to backbranches only, as the comment is gone in master.
M src/backend/access/transam/xlog.c
Install recycled WAL segments with current timeline ID during recovery.
commit : 424cc31a3785bd01108e6f4b20941c6442d3d2d0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Apr 2013 16:31:21 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Apr 2013 16:31:21 +0300
This is a follow-up to the earlier fix, which changed the recycling logic
to recycle WAL segments under the current recovery target timeline. That
turns out to be a bad idea, because installing a recycled segment with
a TLI higher than what we're recovering at the moment means that the recovery
logic will find the recycled WAL segment and try to replay it. It will fail,
but but the mere presence of such a WAL segment will mask any other, real,
file with the same log/seg, but smaller TLI.
Per report from Mitsumasa Kondo. Apply to 9.1 and 9.2, like the previous
fix. Master was already doing this differently; this patch makes 9.1 and
9.2 to do the same thing as master.
M src/backend/access/transam/xlog.c
Ensure ANALYZE phase is not skipped because of canceled truncate.
commit : 93641341f0993131dfb90aa7ac4add3305d00b9c
author : Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 29 Apr 2013 13:06:28 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Mon, 29 Apr 2013 13:06:28 -0500
Patch b19e4250b45e91c9cbdd18d35ea6391ab5961c8d attempted to
preserve existing behavior regarding statistics generation in the
case that a truncation attempt was canceled due to lock conflicts.
It failed to do this accurately in two regards: (1) autovacuum had
previously generated statistics if the truncate attempt failed to
initially get the lock rather than having started the attempt, and
(2) the VACUUM ANALYZE command had always generated statistics.
Both of these changes were unintended, and are reverted by this
patch. On review, there seems to be consensus that the previous
failure to generate statistics when the truncate was terminated
was more an unfortunate consequence of how that effort was
previously terminated than a feature we want to keep; so this
patch generates statistics even when an autovacuum truncation
attempt terminates early. Another unintended change which is kept
on the basis that it is an improvement is that when a VACUUM
command is truncating, it will the new heuristic for avoiding
blocking other processes, rather than keeping an
AccessExclusiveLock on the table for however long the truncation
takes.
Per multiple reports, with some renaming per patch by Jeff Janes.
Backpatch to 9.0, where problem was created.
M src/backend/commands/vacuumlazy.c
Ensure that user created rows in extension tables get dumped if the table is explicitly requested, either with a -t/--table switch of the table itself, or by -n/--schema switch of the schema containing the extension table. Patch reviewed by Vibhor Kumar and Dimitri Fontaine.
commit : 359c8e4545a0d67465205353bd0b086aedbf5293
author : Joe Conway <mail@joeconway.com>
date : Fri, 26 Apr 2013 11:54:59 -0700
committer: Joe Conway <mail@joeconway.com>
date : Fri, 26 Apr 2013 11:54:59 -0700
Backpatched to 9.1 when the extension management facility was added.
M src/bin/pg_dump/pg_dump.c
Avoid deadlock between concurrent CREATE INDEX CONCURRENTLY commands.
commit : 32ad1d696a0e7b50074d57b25708ffd1dc82600f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Apr 2013 16:58:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Apr 2013 16:58:14 -0400
There was a high probability of two or more concurrent C.I.C. commands
deadlocking just before completion, because each would wait for the others
to release their reference snapshots. Fix by releasing the snapshot
before waiting for other snapshots to go away.
Per report from Paul Hinze. Back-patch to all active branches.
M src/backend/commands/indexcmds.c
Fix typo in comment.
commit : ae76795214437f042151906d7f6f000382c2291c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 25 Apr 2013 14:03:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 25 Apr 2013 14:03:10 +0300
Peter Geoghegan
M src/backend/storage/lmgr/lock.c
Fix longstanding race condition in plancache.c.
commit : c13ed70a4f26bae435c297ae09b1be9f50f2eede
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 20 Apr 2013 16:59:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 20 Apr 2013 16:59:31 -0400
When creating or manipulating a cached plan for a transaction control
command (particularly ROLLBACK), we must not perform any catalog accesses,
since we might be in an aborted transaction. However, plancache.c busily
saved or examined the search_path for every cached plan. If we were
unlucky enough to do this at a moment where the path's expansion into
schema OIDs wasn't already cached, we'd do some catalog accesses; and with
some more bad luck such as an ill-timed signal arrival, that could lead to
crashes or Assert failures, as exhibited in bug #8095 from Nachiket Vaidya.
Fortunately, there's no real need to consider the search path for such
commands, so we can just skip the relevant steps when the subject statement
is a TransactionStmt. This is somewhat related to bug #5269, though the
failure happens during initial cached-plan creation rather than
revalidation.
This bug has been there since the plan cache was invented, so back-patch
to all supported branches.
M src/backend/utils/cache/plancache.c
Improve documentation about the relationship of extensions and schemas.
commit : d189deebd3c9e178c32c420a0df2b1ef9d445119
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Apr 2013 22:37:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Apr 2013 22:37:32 -0400
There's been some confusion expressed about this point, so clarify.
Extended version of a patch by David Wheeler.
M doc/src/sgml/extend.sgml
M doc/src/sgml/ref/create_extension.sgml
doc: Fix number of columns in table
commit : 7ef110757efeafd1201791166d65ae114aa1e3d0
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 4 Apr 2013 21:14:21 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 4 Apr 2013 21:14:21 -0400
M doc/src/sgml/keywords.sgml
Fix crash on compiling a regular expression with more than 32k colors.
commit : 88b000c1b6daabd9044cd3c68b0b9e94eacb4c65
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 4 Apr 2013 19:04:57 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 4 Apr 2013 19:04:57 +0300
Throw an error instead.
Backpatch to all supported branches.
M src/backend/regex/regc_color.c
M src/include/regex/regerrs.h
M src/include/regex/regex.h
M src/include/regex/regguts.h
Calculate # of semaphores correctly with --disable-spinlocks.
commit : 6ce083f08a7a30360695c0e9a927fe24f4c77143
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 4 Apr 2013 16:31:44 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 4 Apr 2013 16:31:44 +0300
The old formula didn't take into account that each WAL sender process needs
a spinlock. We had also already exceeded the fixed number of spinlocks
reserved for misc purposes (10). Bump that to 30.
Backpatch to 9.0, where WAL senders were introduced. If I counted correctly,
9.0 had exactly 10 predefined spinlocks, and 9.1 exceeded that, but bump the
limit in 9.0 too because 10 is uncomfortably close to the edge.
M src/backend/storage/lmgr/spin.c
Minor robustness improvements for isolationtester.
commit : 677fde06afd23f355e3d599eedc3ba7a66ef4e85
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Apr 2013 21:15:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Apr 2013 21:15:50 -0400
Notice and complain about PQcancel() failures. Also, don't dump core if
an error PGresult doesn't contain severity and message subfields, as it
might not if it was generated by libpq itself. (We have a longstanding
TODO item to improve that, but in the meantime isolationtester had better
cope.)
I tripped across the latter item while investigating a trouble report on
buildfarm member spoonbill. As for the former, there's no evidence that
PQcancel failure is actually involved in spoonbill's problem, but it still
seems like a bad idea to ignore an error return code.
M src/test/isolation/isolationtester.c