Stamp 9.0.5.
commit : 8522403c5cd2351a1292b868a85aeec0aab5f2b3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Sep 2011 18:00:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Sep 2011 18:00:48 -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
Update release notes for 9.1.1, 9.0.5, 8.4.9, 8.3.16, 8.2.22.
commit : 94a419558371951e7bfaf291aa0dc6dba1f57433
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Sep 2011 17:39:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Sep 2011 17:39:25 -0400
Man, we fixed a lotta bugs since April.
M doc/src/sgml/release-8.2.sgml
M doc/src/sgml/release-8.3.sgml
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
Translation updates
commit : b43bb707cc75be5e751875219657f5af9bbd4adb
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 22 Sep 2011 23:10:16 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 22 Sep 2011 23:10:16 +0300
M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
A src/backend/po/ko.po
A src/backend/po/pl.po
M src/backend/po/pt_BR.po
M src/backend/po/tr.po
M src/backend/po/zh_CN.po
M src/backend/po/zh_TW.po
M src/bin/initdb/nls.mk
M src/bin/initdb/po/cs.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/ko.po
A src/bin/initdb/po/pl.po
M src/bin/initdb/po/zh_CN.po
M src/bin/initdb/po/zh_TW.po
M src/bin/pg_config/nls.mk
A src/bin/pg_config/po/cs.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_config/po/ko.po
A src/bin/pg_config/po/pl.po
M src/bin/pg_config/po/zh_CN.po
M src/bin/pg_config/po/zh_TW.po
M src/bin/pg_controldata/nls.mk
A src/bin/pg_controldata/po/cs.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_controldata/po/ko.po
A src/bin/pg_controldata/po/pl.po
A src/bin/pg_controldata/po/ru.po
M src/bin/pg_controldata/po/zh_CN.po
M src/bin/pg_controldata/po/zh_TW.po
M src/bin/pg_ctl/nls.mk
A src/bin/pg_ctl/po/cs.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ko.po
A src/bin/pg_ctl/po/pl.po
M src/bin/pg_ctl/po/zh_CN.po
M src/bin/pg_ctl/po/zh_TW.po
M src/bin/pg_dump/nls.mk
A src/bin/pg_dump/po/cs.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ko.po
A src/bin/pg_dump/po/pl.po
M src/bin/pg_dump/po/pt_BR.po
M src/bin/pg_dump/po/tr.po
M src/bin/pg_dump/po/zh_CN.po
M src/bin/pg_dump/po/zh_TW.po
M src/bin/pg_resetxlog/nls.mk
A src/bin/pg_resetxlog/po/cs.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/pg_resetxlog/po/ja.po
M src/bin/pg_resetxlog/po/ko.po
A src/bin/pg_resetxlog/po/pl.po
M src/bin/pg_resetxlog/po/zh_CN.po
M src/bin/pg_resetxlog/po/zh_TW.po
M src/bin/psql/nls.mk
M src/bin/psql/po/cs.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ja.po
A src/bin/psql/po/ko.po
A src/bin/psql/po/pl.po
M src/bin/psql/po/pt_BR.po
M src/bin/psql/po/tr.po
M src/bin/psql/po/zh_CN.po
A src/bin/psql/po/zh_TW.po
M src/bin/scripts/nls.mk
M src/bin/scripts/po/cs.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/ja.po
M src/bin/scripts/po/ko.po
A src/bin/scripts/po/pl.po
M src/bin/scripts/po/zh_CN.po
M src/bin/scripts/po/zh_TW.po
M src/interfaces/ecpg/ecpglib/nls.mk
A src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/ja.po
A src/interfaces/ecpg/ecpglib/po/ko.po
A src/interfaces/ecpg/ecpglib/po/pl.po
M src/interfaces/ecpg/ecpglib/po/zh_CN.po
A src/interfaces/ecpg/ecpglib/po/zh_TW.po
M src/interfaces/ecpg/preproc/nls.mk
A src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/ko.po
A src/interfaces/ecpg/preproc/po/pl.po
M src/interfaces/ecpg/preproc/po/zh_CN.po
M src/interfaces/ecpg/preproc/po/zh_TW.po
M src/interfaces/libpq/nls.mk
M src/interfaces/libpq/po/cs.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ko.po
A src/interfaces/libpq/po/pl.po
M src/interfaces/libpq/po/pt_BR.po
M src/interfaces/libpq/po/tr.po
M src/interfaces/libpq/po/zh_CN.po
M src/interfaces/libpq/po/zh_TW.po
M src/pl/plperl/nls.mk
A src/pl/plperl/po/cs.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/ja.po
A src/pl/plperl/po/ko.po
A src/pl/plperl/po/pl.po
M src/pl/plperl/po/zh_CN.po
A src/pl/plperl/po/zh_TW.po
M src/pl/plpgsql/src/nls.mk
A src/pl/plpgsql/src/po/cs.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpgsql/src/po/ko.po
A src/pl/plpgsql/src/po/pl.po
M src/pl/plpgsql/src/po/zh_CN.po
M src/pl/plpgsql/src/po/zh_TW.po
M src/pl/plpython/nls.mk
A src/pl/plpython/po/cs.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/ja.po
A src/pl/plpython/po/ko.po
A src/pl/plpython/po/pl.po
M src/pl/plpython/po/zh_CN.po
A src/pl/plpython/po/zh_TW.po
M src/pl/tcl/nls.mk
A src/pl/tcl/po/cs.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ja.po
A src/pl/tcl/po/ko.po
A src/pl/tcl/po/pl.po
M src/pl/tcl/po/zh_CN.po
A src/pl/tcl/po/zh_TW.po
gistendscan() forgot to free so->giststate.
commit : b04214f6cf3a39f45579aba5b7e687fa4f44c84b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Sep 2011 04:28:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Sep 2011 04:28:01 -0400
This oversight led to a massive memory leak --- upwards of 10KB per tuple
--- during creation-time verification of an exclusion constraint based on a
GIST index. In most other scenarios it'd just be a leak of 10KB that would
be recovered at end of query, so not too significant; though perhaps the
leak would be noticeable in a situation where a GIST index was being used
in a nestloop inner indexscan. In any case, it's a real leak of long
standing, so patch all supported branches. Per report from Harald Fuchs.
M src/backend/access/gist/gistscan.c
deflist_to_tuplestore dumped core on an option with no value.
commit : cac73320ef0f35304e2dcade0fe1d32c07cb765f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Sep 2011 11:36:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Sep 2011 11:36:57 -0400
Make it return NULL for the option_value, instead.
Per report from Frank van Vugt. Back-patch to 8.4 where this code was
added.
M src/backend/foreign/foreign.c
Fix permissions on pg_largeobject_metadata.h in 9.0 branch.
commit : 4de174d4bfa8e162cf64fb9bf7393fea05b0dee7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Sep 2011 13:17:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Sep 2011 13:17:12 -0400
For some reason it was 0755 instead of 0644.
M src/include/catalog/pg_largeobject_metadata.h
Add missing format argument to ecpg_log() call
commit : ba24de13f6b4a1a2ceb6230840330e4192312e09
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 8 Sep 2011 22:09:08 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 8 Sep 2011 22:09:08 +0300
M src/interfaces/ecpg/ecpglib/execute.c
Fix corner case bug in numeric to_char().
commit : 6e7a3c364bf5df266bb7000ead399e779410962c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Sep 2011 17:06:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Sep 2011 17:06:26 -0400
Trailing-zero stripping applied by the FM specifier could strip zeroes
to the left of the decimal point, for a format with no digit positions
after the decimal point (such as "FM999.").
Reported and diagnosed by Marti Raudsepp, though I didn't use his patch.
M src/backend/utils/adt/formatting.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
In pg_upgrade, disallow migration of 8.3 clusters using contrib/ltree because its internal format was changed in 8.4.
commit : c3106a340f3177105b80a0a6e878eba1986ae9fe
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Sep 2011 14:42:36 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Sep 2011 14:42:36 -0400
Backpatch to 9.0 and 9.1.
Report by depesz, diagnosis by Tom.
M contrib/pg_upgrade/check.c
M contrib/pg_upgrade/pg_upgrade.h
M contrib/pg_upgrade/version_old_8_3.c
M doc/src/sgml/pgupgrade.sgml
Revert documentation patch about NEW/OLD and triggers.
commit : 336059fc0af59f60d1e4c4a1f28a06f97a0e30a9
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Sep 2011 09:24:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 7 Sep 2011 09:24:02 -0400
Backpatch to 9.0 and 9.1.
Patch from Josh Kupershmidt.
M doc/src/sgml/plpgsql.sgml
Properly document the existance of OLD/NEW trigger pl/pgsql trigger fields.
commit : a443343ccf2d7b105ce550b5746d993151569d93
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 22:54:19 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 22:54:19 -0400
Backpatch to 9.0 and 9.1.
Report from Pavel Stehule, patch from Josh Kupershmidt
M doc/src/sgml/plpgsql.sgml
Fix plpgsql "PERFORM" markup.
commit : 665af1ac5aab4b06f5626af22a90102715258687
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 15:20:17 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 15:20:17 -0400
Backpatch to 9.0 and 9.1.
M doc/src/sgml/plpgsql.sgml
Avoid possibly accessing off the end of memory in SJIS2004 conversion.
commit : d5e429b128b0e222f9458a7880427a60da065fa3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2011 14:50:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2011 14:50:28 -0400
The code in shift_jis_20042euc_jis_2004() would fetch two bytes even when
only one remained in the string. Since conversion functions aren't
supposed to assume null-terminated input, this poses a small risk of
fetching past the end of memory and incurring SIGSEGV. No such crash has
been identified in the field, but we've certainly seen the equivalent
happen in other code paths, so patch this one all the way back.
Report and patch by Noah Misch.
M src/backend/utils/mb/conversion_procs/euc2004_sjis2004/euc2004_sjis2004.c
Avoid possibly accessing off the end of memory in examine_attribute().
commit : ad1e8274ebd8cff2a9fb44c6a941110a35989375
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2011 14:35:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2011 14:35:36 -0400
Since the last couple of columns of pg_type are often NULL,
sizeof(FormData_pg_type) can be an overestimate of the actual size of the
tuple data part. Therefore memcpy'ing that much out of the catalog cache,
as analyze.c was doing, poses a small risk of copying past the end of
memory and incurring SIGSEGV. No such crash has been identified in the
field, but we've certainly seen the equivalent happen in other code paths,
so patch this one all the way back.
Per valgrind testing by Noah Misch, though this is not his proposed patch.
I chose to use SearchSysCacheCopy1 rather than inventing special-purpose
infrastructure for copying only the minimal part of a pg_type tuple.
M src/backend/commands/analyze.c
Document PERFORM limitation when using WITH queries.
commit : dcc728eef49bc0dbe2f88f9a56bda007afc9f46e
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 13:41:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 13:41:32 -0400
Backpatch to 9.0 and 9.1.
Report from depstein@alliedtesting.com.
M doc/src/sgml/plpgsql.sgml
Update type-conversion documentation for long-ago changes.
commit : 01543329514475e2c42d52891ff4245bb9f5d83c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2011 12:14:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Sep 2011 12:14:51 -0400
This example wasn't updated when we changed the behavior of bpcharlen()
in 8.0, nor when we changed the number of parameters taken by the bpchar()
cast function in 7.3. Per report from lsliang.
M doc/src/sgml/typeconv.sgml
Properly document semphore requirements by accounting for worker processes.
commit : 38052a9dbc90305b8f1fa5b87cbd7099778e66ab
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 11:08:35 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Sep 2011 11:08:35 -0400
Backpatch to 9.1 and 9.0.
Submitted by Anton Yuzhaninov, confirmed by Robert Haas
M doc/src/sgml/runtime.sgml
Update time zone data files to tzdata release 2011i.
commit : e6d4288c514bc7bab1d48bc5a733606d1f57dba9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Sep 2011 14:46:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Sep 2011 14:46:31 -0400
DST law changes in Canada, Egypt, Russia, Samoa, South Sudan.
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/northamerica
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
Document that contrib/pgtrgm only processes ASCII alphanumeric characters.
commit : 3de09ddac58882d9abc5e3327e4d2b0b1238ab54
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 5 Sep 2011 13:24:47 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 5 Sep 2011 13:24:47 -0400
Backpatch to 9.0 and 9.1.
M doc/src/sgml/pgtrgm.sgml
Guard against using plperl's Makefile without specifying --with-perl.
commit : ed7eff89fd64021a2b4150c7d2caca488274c80b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Sep 2011 20:07:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Sep 2011 20:07:42 -0400
The $(PERL) macro will be set by configure if it finds perl at all,
but $(perl_privlibexp) isn't configured unless you said --with-perl.
This results in confusing error messages if someone cd's into
src/pl/plperl and tries to build there despite the configure omission,
as reported by Tomas Vondra in bug #6198. Add simple checks to
provide a more useful report, while not disabling other use of the
makefile such as "make clean".
Back-patch to 9.0, which is as far as the patch applies easily.
M src/pl/plperl/GNUmakefile
Fix typo in pg_srand48 (srand48 in older branches).
commit : 0962182f01c1e29417b016a82c7947697daba82b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 3 Sep 2011 16:17:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 3 Sep 2011 16:17:44 -0400
">" should be ">>". This typo results in failure to use all of the bits
of the provided seed.
This might rise to the level of a security bug if we were relying on
srand48 for any security-critical purposes, but we are not --- in fact,
it's not used at all unless the platform lacks srandom(), which is
improbable. Even on such a platform the exposure seems minimal.
Reported privately by Andres Freund.
M src/port/erand48.c
Fix brace indentation of commit f8c74422010e63506fa69635ea61920bc042b70e to fit PostgreSQL style.
commit : 2cda30e757a95f2c2dfa9d3a1726959fa6b02357
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 2 Sep 2011 09:45:11 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 2 Sep 2011 09:45:11 +0200
M src/interfaces/ecpg/ecpglib/execute.c
In ecpglib restore LC_NUMERIC in case of an error.
commit : f8c74422010e63506fa69635ea61920bc042b70e
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 1 Sep 2011 15:27:38 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 1 Sep 2011 15:27:38 +0200
M src/interfaces/ecpg/ecpglib/execute.c
Move the line to undefine setlocale() macro on Win32 outside USE_REPL_SNPRINTF ifdef block. It has nothing to do with whether the replacement snprintf function is used. It caused no live bug, because the replacement snprintf function is always used on Win32, but it was nevertheless misplaced.
commit : a02e40990433e59dee14129c119184dcbca4c2e3
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 1 Sep 2011 09:13:37 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 1 Sep 2011 09:13:37 +0300
M src/include/port.h
Further repair of eqjoinsel ndistinct-clamping logic.
commit : 3505862a8d3e3b389ab926346061b7135fa44f79
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Sep 2011 00:18:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Sep 2011 00:18:39 -0400
Examination of examples provided by Mark Kirkwood and others has convinced
me that actually commit 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 was quite
a few bricks shy of a load. The useful part of that patch was clamping
ndistinct for the inner side of a semi or anti join, and the reason why
that's needed is that it's the only way that restriction clauses
eliminating rows from the inner relation can affect the estimated size of
the join result. I had not clearly understood why the clamping was
appropriate, and so mis-extrapolated to conclude that we should clamp
ndistinct for the outer side too, as well as for both sides of regular
joins. These latter actions were all wrong, and are reverted with this
patch. In addition, the clamping logic is now made to affect the behavior
of both paths in eqjoinsel_semi, with or without MCV lists to compare.
When we have MCVs, we suppose that the most common values are the ones
that are most likely to survive the decimation resulting from a lower
restriction clause, so we think of the clamping as eliminating non-MCV
values, or potentially even the least-common MCVs for the inner relation.
Back-patch to 8.4, same as previous fixes in this area.
M src/backend/utils/adt/selfuncs.c
Fix pg_upgrade to preserve toast relfrozenxids for old 8.3 servers.
commit : e724b969d82862a08255ba6f2921a7a66e65a852
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2011 21:50:00 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Aug 2011 21:50:00 -0400
This fixes a pg_upgrade bug that could lead to query errors when
clog files are improperly removed.
Backpatch to 8.4, 9.0, 9.1.
M src/bin/pg_dump/pg_dump.c
Improve eqjoinsel's ndistinct clamping to work for multiple levels of join.
commit : 53434c6f0dfa89bf287fadbde26b050b043c0c94
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Aug 2011 16:04:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Aug 2011 16:04:58 -0400
This patch fixes an oversight in my commit
7f3eba30c9d622d1981b1368f2d79ba0999cdff2 of 2008-10-23. That patch
accounted for baserel restriction clauses that reduced the number of rows
coming out of a table (and hence the number of possibly-distinct values of
a join variable), but not for join restriction clauses that might have been
applied at a lower level of join. To account for the latter, look up the
sizes of the min_lefthand and min_righthand inputs of the current join,
and clamp with those in the same way as for the base relations.
Noted while investigating a complaint from Ben Chobot, although this in
itself doesn't seem to explain his report.
Back-patch to 8.4; previous versions used different estimation methods
for which this heuristic isn't relevant.
M src/backend/utils/adt/selfuncs.c
Fix a missed case in code for "moving average" estimate of reltuples.
commit : 047f205f4eb8b1d1aa0c86345c35893423a5e224
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Aug 2011 14:49:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Aug 2011 14:49:57 -0400
It is possible for VACUUM to scan no pages at all, if the visibility map
shows that all pages are all-visible. In this situation VACUUM has no new
information to report about the relation's tuple density, so it wasn't
changing pg_class.reltuples ... but it updated pg_class.relpages anyway.
That's wrong in general, since there is no evidence to justify changing the
density ratio reltuples/relpages, but it's particularly bad if the previous
state was relpages=reltuples=0, which means "unknown tuple density".
We just replaced "unknown" with "zero". ANALYZE would eventually recover
from this, but it could take a lot of repetitions of ANALYZE to do so if
the relation size is much larger than the maximum number of pages ANALYZE
will scan, because of the moving-average behavior introduced by commit
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8.
The only known situation where we could have relpages=reltuples=0 and yet
the visibility map asserts everything's visible is immediately following
a pg_upgrade. It might be advisable for pg_upgrade to try to preserve the
relpages/reltuples statistics; but in any case this code is wrong on its
own terms, so fix it. Per report from Sergey Koposov.
Back-patch to 8.4, where the visibility map was introduced, same as the
previous change.
M src/backend/commands/vacuum.c
M src/backend/commands/vacuumlazy.c
M src/backend/utils/cache/relcache.c
Actually, all of parallel restore's limitations should be tested earlier.
commit : 2de0fdeb68d7176df35a880c9180bd9e2d9eca4c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Aug 2011 22:27:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Aug 2011 22:27:48 -0400
On closer inspection, whining in restore_toc_entries_parallel is really
much too late for any user-facing error case. The right place to do it
is at the start of RestoreArchive(), before we've done anything interesting
(suh as trying to DROP all the targets ...)
Back-patch to 8.4, where parallel restore was introduced.
M src/bin/pg_dump/pg_backup_archiver.c
Be more user-friendly about unsupported cases for parallel pg_restore.
commit : fbf776a2eb5a7dcca218458cb2139b97918382d5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Aug 2011 21:48:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Aug 2011 21:48:58 -0400
If we are unable to do a parallel restore because the input file is stdin
or is otherwise unseekable, we should complain and fail immediately, not
after having done some of the restore. Complaining once per thread isn't
so cool either, and the messages should be worded to make it clear this is
an unsupported case not some weird race-condition bug. Per complaint from
Lonni Friedman.
Back-patch to 8.4, where parallel restore was introduced.
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_custom.c
Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server.
commit : 42de04f6ae051c509c217fe527285a59d5a7314d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Aug 2011 16:37:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Aug 2011 16:37:08 -0400
These days, such a response is far more likely to signify a server-side
problem, such as fork failure. Reporting "server does not support SSL"
(in sslmode=require) could be quite misleading. But the results could
be even worse in sslmode=prefer: if the problem was transient and the
next connection attempt succeeds, we'll have silently fallen back to
protocol version 2.0, possibly disabling features the user needs.
Hence, it seems best to just eliminate the assumption that backing off
to non-SSL/2.0 protocol is the way to recover from an "E" response, and
instead treat the server error the same as we would in non-SSL cases.
I tested this change against a pre-7.0 server, and found that there
was a second logic bug in the "prefer" path: the test to decide whether
to make a fallback connection attempt assumed that we must have opened
conn->ssl, which in fact does not happen given an "E" response. After
fixing that, the code does indeed connect successfully to pre-7.0,
as long as you didn't set sslmode=require. (If you did, you get
"Unsupported frontend protocol", which isn't completely off base
given the server certainly doesn't support SSL.)
Since there seems no reason to believe that pre-7.0 servers exist anymore
in the wild, back-patch to all supported branches.
M src/interfaces/libpq/fe-connect.c
Ensure we discard unread/unsent data when abandoning a connection attempt.
commit : 431b638045814137a2037add85db577a7985b19d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Aug 2011 14:16:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Aug 2011 14:16:25 -0400
There are assorted situations wherein PQconnectPoll() will abandon a
connection attempt and try again with different parameters (eg, SSL versus
not SSL). However, the code forgot to discard any pending data in libpq's
I/O buffers when doing this. In at least one case (server returns E
message during SSL negotiation), there is unread input data which bollixes
the next connection attempt. I have not checked to see whether this is
possible in the other cases where we close the socket and retry, but it
seems like a matter of good defensive programming to add explicit
buffer-flushing code to all of them.
This is one of several issues exposed by Daniel Farina's report of
misbehavior after a server-side fork failure.
This has been wrong since forever, so back-patch to all supported branches.
M src/interfaces/libpq/fe-connect.c
Fix potential memory clobber in tsvector_concat().
commit : 20139f4f1cdd371d230d5389acf9ec8ff150b863
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Aug 2011 16:51:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Aug 2011 16:51:46 -0400
tsvector_concat() allocated its result workspace using the "conservative"
estimate of the sum of the two input tsvectors' sizes. Unfortunately that
wasn't so conservative as all that, because it supposed that the number of
pad bytes required could not grow. Which it can, as per test case from
Jesper Krogh, if there's a mix of lexemes with positions and lexemes
without them in the input data. The fix is to assume that we might add
a not-previously-present pad byte for each and every lexeme in the two
inputs; which really is conservative, but it doesn't seem worthwhile to
try to be more precise.
This is an aboriginal bug in tsvector_concat, so back-patch to all
versions containing it.
M src/backend/utils/adt/tsvector_op.c
In pg_upgrade, limit schema name filter to include toast tables. Bug introduced recently when trying to filter out temp tables.
commit : df957a79cc2600e9e172500939c82bcf100b4dfd
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 26 Aug 2011 00:12:39 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 26 Aug 2011 00:12:39 -0400
Backpatch to 9.0 and 9.1.
M contrib/pg_upgrade/info.c
M contrib/pg_upgrade/version_old_8_3.c
Fix psql lexer to avoid use of backtracking.
commit : 9354f5b76acf37c96ed0173ff8ab3e415bae2b04
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Aug 2011 14:33:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Aug 2011 14:33:08 -0400
Per previous experimentation, backtracking slows down lexing performance
significantly (by about a third). It's usually pretty easy to avoid, just
need to have rules that accept an incomplete construct and do whatever the
lexer would have done otherwise.
The backtracking was introduced by the patch that added quoted variable
substitution. Back-patch to 9.0 where that was added.
M src/bin/psql/psqlscan.l
Properly quote SQL/MED generic options in pg_dump output.
commit : b7cd5c836ae952b5911eac9ec5f888779a2d0b81
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 25 Aug 2011 12:37:32 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 25 Aug 2011 12:37:32 -0400
Shigeru Hanada
M src/bin/pg_dump/pg_dump.c
Fix pgstatindex() to give consistent results for empty indexes.
commit : 8a32c946586c8be422ff1ea18f6a6ea5c3141ebb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Aug 2011 23:50:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Aug 2011 23:50:20 -0400
For an empty index, the pgstatindex() function would compute 0.0/0.0 for
its avg_leaf_density and leaf_fragmentation outputs. On machines that
follow the IEEE float arithmetic standard with any care, that results in
a NaN. However, per report from Rushabh Lathia, Microsoft couldn't
manage to get this right, so you'd get a bizarre error on Windows.
Fix by forcing the results to be NaN explicitly, rather than relying on
the division operator to give that or the snprintf function to print it
correctly. I have some doubts that this is really the most useful
definition, but it seems better to remain backward-compatible with
those platforms for which the behavior wasn't completely broken.
Back-patch to 8.2, since the code is like that in all current releases.
M contrib/pgstattuple/pgstatindex.c
Add recovery.conf to the index in the user manual.
commit : 7ec0258091c7d1f3d109c9a7a1016e702b744ebe
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 23 Aug 2011 11:55:21 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 23 Aug 2011 11:55:21 +0300
Fujii Masao
M doc/src/sgml/recovery-config.sgml
Fix trigger WHEN conditions when both BEFORE and AFTER triggers exist.
commit : 52120ee8346aa42d26e4c2244574df4d90f4bda6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 21 Aug 2011 18:16:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 21 Aug 2011 18:16:08 -0400
Due to tuple-slot mismanagement, evaluation of WHEN conditions for AFTER
ROW UPDATE triggers could crash if there had been a BEFORE ROW trigger
fired for the same update. Fix by not trying to overload the use of
estate->es_trig_tuple_slot. Per report from Yoran Heling.
Back-patch to 9.0, when trigger WHEN conditions were introduced.
M src/backend/commands/trigger.c
M src/backend/executor/execMain.c
M src/backend/executor/execUtils.c
M src/include/nodes/execnodes.h
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Fix performance problem when building a lossy tidbitmap.
commit : 706493a1f7cbd9c7d3a792fd5066b55c145b9b01
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 20 Aug 2011 14:51:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 20 Aug 2011 14:51:02 -0400
As pointed out by Sergey Koposov, repeated invocations of tbm_lossify can
make building a large tidbitmap into an O(N^2) operation. To fix, make
sure we remove more than the minimum amount of information per call, and
add a fallback path to behave sanely if we're unable to fit the bitmap
within the requested amount of memory.
This has been wrong since the tidbitmap code was written, so back-patch
to all supported branches.
M src/backend/nodes/tidbitmap.c
Change PyInit_plpy to external linkage
commit : d4c24254fab0b9908211f990c4239664f3ed5630
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 18 Aug 2011 12:53:32 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 18 Aug 2011 12:53:32 +0300
Module initialization functions in Python 3 must have external
linkage, because PyMODINIT_FUNC does dllexport on Windows-like
platforms. Without this change, the build with Python 3 fails on
Windows.
M src/pl/plpython/plpython.c
Forget about targeting catalog cache invalidations by tuple TID.
commit : 1853e120f7badea0cd9b62ff2ad2a0dc60a5f1fe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 15:26:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 15:26:35 -0400
The TID isn't stable enough: we might queue an sinval event before a VACUUM
FULL, and then process it afterwards, when the target tuple no longer has
the same TID. So we must invalidate entries on the basis of hash value
only. The old coding can be shown to result in various bizarre,
hard-to-reproduce errors in the presence of concurrent VACUUM FULLs on
system catalogs, and could easily result in permanent catalog corruption,
up to and including complete loss of tables.
This commit is just a minimal fix that removes the unsafe comparison.
We should remove transmission of the tuple TID from sinval messages
altogether, and then arrange to suppress the extra message in the common
case of a heap_update that doesn't change the key hashvalue. But that's
going to be much more invasive, and will only produce a probably-marginal
performance gain, so it doesn't seem like material for a back-patch.
Back-patch to 9.0. Before that, VACUUM FULL refused to do any tuple moving
if it found any INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples (and
CLUSTER would give up altogether), so there was no risk of moving a tuple
that might be the subject of an unsent sinval message.
M src/backend/utils/cache/catcache.c
Fix incorrect order of operations during sinval reset processing.
commit : 38ef2e2fba79573f4ed37d572ea19217c8cf47ac
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 14:38:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 14:38:35 -0400
We have to be sure that we have revalidated each nailed-in-cache relcache
entry before we try to use it to load data for some other relcache entry.
The introduction of "mapped relations" in 9.0 broke this, because although
we updated the state kept in relmapper.c early enough, we failed to
propagate that information into relcache entries soon enough; in
particular, we could try to fetch pg_class rows out of pg_class before
we'd updated its relcache entry's rd_node.relNode value from the map.
This bug accounts for Dave Gould's report of failures after "vacuum full
pg_class", and I believe that there is risk for other system catalogs
as well.
The core part of the fix is to copy relmapper data into the relcache
entries during "phase 1" in RelationCacheInvalidate(), before they'll be
used in "phase 2". To try to future-proof the code against other similar
bugs, I also rearranged the order in which nailed relations are visited
during phase 2: now it's pg_class first, then pg_class_oid_index, then
other nailed relations. This should ensure that RelationClearRelation can
apply RelationReloadIndexInfo to all nailed indexes without risking use
of not-yet-revalidated relcache entries.
Back-patch to 9.0 where the relation mapper was introduced.
M src/backend/utils/cache/relcache.c
Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL.
commit : 44b6d53b467bfe848c34c7a8a174779bb2f43c39
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 13:48:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 13:48:16 -0400
This works around the problem that a catalog cache entry might contain a
toast pointer that we try to dereference just as a VACUUM FULL completes
on that catalog. We will see the sinval message on the cache entry when
we acquire lock on the toast table, but by that point we've already told
tuptoaster.c "here's the pointer to fetch", so it's difficult from a code
structural standpoint to update the pointer before we use it. Much less
painful to ensure that toast pointers are not invalidated in the first
place. We have to add a bit of code to deal with the case that a value
that previously wasn't toasted becomes so; but that should be a
seldom-exercised corner case, so the inefficiency shouldn't be significant.
Back-patch to 9.0. In prior versions, we didn't allow CLUSTER on system
catalogs, and VACUUM FULL didn't result in reassignment of toast OIDs, so
there was no problem.
M src/backend/access/heap/tuptoaster.c
M src/backend/commands/cluster.c
Fix race condition in relcache init file invalidation.
commit : 93519b0c620123301142ac49b79796be20c2dce8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 13:12:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Aug 2011 13:12:10 -0400
The previous code tried to synchronize by unlinking the init file twice,
but that doesn't actually work: it leaves a window wherein a third process
could read the already-stale init file but miss the SI messages that would
tell it the data is stale. The result would be bizarre failures in catalog
accesses, typically "could not read block 0 in file ..." later during
startup.
Instead, hold RelCacheInitLock across both the unlink and the sending of
the SI messages. This is more straightforward, and might even be a bit
faster since only one unlink call is needed.
This has been wrong since it was put in (in 2002!), so back-patch to all
supported releases.
M src/backend/access/transam/twophase.c
M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c
M src/include/utils/relcache.h
In pg_upgrade, avoid dumping orphaned temporary tables. This makes the pg_upgrade schema matching pattern match pg_dump/pg_dumpall.
commit : f239ec57277b3fffe1c5bd2694a9d0d726d3a259
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 15 Aug 2011 22:39:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 15 Aug 2011 22:39:38 -0400
Fix for 9.0, 9.1, and 9.2.
M contrib/pg_upgrade/info.c
M contrib/pg_upgrade/version_old_8_3.c
Fix unsafe order of operations in foreign-table DDL commands.
commit : 5707f355593c91a6c866835a7c55eabaede23628
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Aug 2011 15:40:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 14 Aug 2011 15:40:36 -0400
When updating or deleting a system catalog tuple, it's necessary to acquire
RowExclusiveLock on the catalog before looking up the tuple; otherwise a
concurrent VACUUM FULL on the catalog might move the tuple to a different
TID before we can apply the update. Coding patterns that find the tuple
via a table scan aren't at risk here, but when obtaining the tuple from a
catalog cache, correct ordering is important; and several routines in
foreigncmds.c got it wrong. Noted while running the regression tests in
parallel with VACUUM FULL of assorted system catalogs.
For consistency I moved all the heap_open calls to the starts of their
functions, including a couple for which there was no actual bug.
Back-patch to 8.4 where foreigncmds.c was added.
M src/backend/commands/foreigncmds.c
Fix incorrect timeout handling during initial authentication transaction.
commit : 739cbdd9c38252fe2e8241a704f9d9f9a5363e74
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Aug 2011 17:52:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Aug 2011 17:52:24 -0400
The statement start timestamp was not set before initiating the transaction
that is used to look up client authentication information in pg_authid.
In consequence, enable_sig_alarm computed a wrong value (far in the past)
for statement_fin_time. That didn't have any immediate effect, because the
timeout alarm was set without reference to statement_fin_time; but if we
subsequently blocked on a lock for a short time, CheckStatementTimeout
would consult the bogus value when we cancelled the lock timeout wait,
and then conclude we'd timed out, leading to immediate failure of the
connection attempt. Thus an innocent "vacuum full pg_authid" would cause
failures of concurrent connection attempts. Noted while testing other,
more serious consequences of vacuum full on system catalogs.
We should set the statement timestamp before StartTransactionCommand(),
so that the transaction start timestamp is also valid. I'm not sure if
there are any non-cosmetic effects of it not being valid, but the xact
timestamp is at least sent to the statistics machinery.
Back-patch to 9.0. Before that, the client authentication timeout was done
outside any transaction and did not depend on this state to be valid.
M src/backend/utils/init/postinit.c
Fix nested PlaceHolderVar expressions that appear only in targetlists.
commit : 8a14bdb10f0a9b123e5c6f70f33334b132b3da29
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Aug 2011 00:49:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Aug 2011 00:49:04 -0400
A PlaceHolderVar's expression might contain another, lower-level
PlaceHolderVar. If the outer PlaceHolderVar is used, the inner one
certainly will be also, and so we have to make sure that both of them get
into the placeholder_list with correct ph_may_need values during the
initial pre-scan of the query (before deconstruct_jointree starts).
We did this correctly for PlaceHolderVars appearing in the query quals,
but overlooked the issue for those appearing in the top-level targetlist;
with the result that nested placeholders referenced only in the targetlist
did not work correctly, as illustrated in bug #6154.
While at it, add some error checking to find_placeholder_info to ensure
that we don't try to create new placeholders after it's too late to do so;
they have to all be created before deconstruct_jointree starts.
Back-patch to 8.4 where the PlaceHolderVar mechanism was introduced.
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/util/placeholder.c
M src/include/optimizer/placeholder.h
M src/include/optimizer/planmain.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix thinko in documentation of local_preload_libraries.
commit : f60078232d587d62c7343780ce1c470e5f5c66a5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2011 21:18:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Aug 2011 21:18:02 -0400
Somebody added a cross-reference to shared_preload_libraries, but wrote the
wrong variable name when they did it (and didn't bother to make it a link
either).
Spotted by Christoph Anton Mitterer.
M doc/src/sgml/config.sgml
Fix markup for recent wal_level clarification.
commit : 082f906334502c65ac97d0fd1c60cd2b9a1233c7
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 4 Aug 2011 15:02:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 4 Aug 2011 15:02:03 -0400
Backpatch to 9.1 and 9.0.
M doc/src/sgml/config.sgml
In documentaiton, clarify which commands have reduced WAL volume for wal_level = minimum.
commit : 072e6076d10955da5ee46416607a8ff19afd6b40
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 4 Aug 2011 12:06:54 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 4 Aug 2011 12:06:54 -0400
Backpatch to 9.1 and 9.0.
M doc/src/sgml/config.sgml
Move CheckRecoveryConflictDeadlock() call to a safer place.
commit : d3061f036df68d4c495f6db79994b48725936241
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Aug 2011 15:16:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Aug 2011 15:16:44 -0400
This kluge was inserted in a spot apparently chosen at random: the lock
manager's state is not yet fully set up for the wait, and in particular
LockWaitCancel hasn't been armed by setting lockAwaited, so the ProcLock
will not get cleaned up if the ereport is thrown. This seems to not cause
any observable problem in trivial test cases, because LockReleaseAll will
silently clean up the debris; but I was able to cause failures with tests
involving subtransactions.
Fixes breakage induced by commit c85c941470efc44494fd7a5f426ee85fc65c268c.
Back-patch to all affected branches.
M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/lock.c
M src/backend/storage/lmgr/proc.c
M src/include/storage/standby.h
Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.
commit : 0f904c95a4000caa717868d9bfaf5a423eefdb0b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Aug 2011 13:24:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Aug 2011 13:24:06 -0400
It was initialized in the wrong place and to the wrong value. With bad
luck this could result in incorrect query-cancellation failures in hot
standby sessions, should a HS backend be holding pin on buffer number 1
while trying to acquire a lock.
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/lmgr/proc.c
M src/include/storage/proc.h
Avoid integer overflow when LIMIT + OFFSET >= 2^63.
commit : f00fbad6bd43141faae05cd13a518fd28ae94673
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 2 Aug 2011 10:47:17 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 2 Aug 2011 10:47:17 +0300
This fixes bug #6139 reported by Hitoshi Harada.
M src/backend/executor/nodeLimit.c
Fix pg_restore's direct-to-database mode for standard_conforming_strings.
commit : 78e957dd46ce639559ff433a800fae47eb755cce
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Jul 2011 14:07:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Jul 2011 14:07:09 -0400
pg_backup_db.c contained a mini SQL lexer with which it tried to identify
boundaries between SQL commands, but that code was not designed to cope
with standard_conforming_strings, and would get the wrong answer if a
backslash immediately precedes a closing single quote in such a string,
as per report from Julian Mehnle. The bug only affects direct-to-database
restores from archive files made with standard_conforming_strings = on.
Rather than complicating the code some more to try to fix that, let's just
rip it all out. The only reason it was needed was to cope with COPY data
embedded into ordinary archive entries, which was a layout that was used
only for about the first three weeks of the archive format's existence,
and never in any production release of pg_dump. Instead, just rely on the
archive file layout to tell us whether we're printing COPY data or not.
This bug represents a data corruption hazard in all releases in which
standard_conforming_strings can be turned on, ie 8.2 and later, so
back-patch to all supported branches.
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_db.h
Fix typo.
commit : bc9d2e7c4ae1cb4f0392194f539ba3e6847f42f5
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 27 Jul 2011 11:20:07 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 27 Jul 2011 11:20:07 -0400
Noted by Josh Kupershmidt.
M doc/src/sgml/ref/comment.sgml
Add missing newlines at end of error messages
commit : 9df8ce848245592b6b8ac919319be3167ef774ac
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 26 Jul 2011 23:28:44 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 26 Jul 2011 23:28:44 +0300
M src/bin/psql/command.c
M src/bin/psql/common.c
Clarify which relkinds accept column comments.
commit : 6f8f9c2bdd30eef9c3f1858fb413f5f4e39d6010
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 26 Jul 2011 09:34:55 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 26 Jul 2011 09:34:55 -0400
Per discussion with Josh Kupershmidt.
M doc/src/sgml/ref/comment.sgml
Fix previous patch so it also works if not USE_SSL (mea culpa).
commit : 65c033cbe913972872a10b17deae636243ae96df
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Jul 2011 23:29:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Jul 2011 23:29:15 -0400
On balance, the need to cover this case changes my mind in favor of pushing
all error-message generation duties into the two fe-secure.c routines.
So do it that way.
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-secure.c
Improve libpq's error reporting for SSL failures.
commit : 77e4fd5c4a500a4e6b24076c83bee17f55690831
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Jul 2011 16:29:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Jul 2011 16:29:18 -0400
In many cases, pqsecure_read/pqsecure_write set up useful error messages,
which were then overwritten with useless ones by their callers. Fix this
by defining the responsibility to set an error message to be entirely that
of the lower-level function when using SSL.
Back-patch to 8.3; the code is too different in 8.2 to be worth the
trouble.
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-secure.c
Use OpenSSL's SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag.
commit : f0dadcc60b527f1a99bdae5239e645fa765c628d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Jul 2011 15:18:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Jul 2011 15:18:02 -0400
This disables an entirely unnecessary "sanity check" that causes failures
in nonblocking mode, because OpenSSL complains if we move or compact the
write buffer. The only actual requirement is that we not modify pending
data once we've attempted to send it, which we don't. Per testing and
research by Martin Pihlak, though this fix is a lot simpler than his patch.
I put the same change into the backend, although it's less clear whether
it's necessary there. We do use nonblock mode in some situations in
streaming replication, so seems best to keep the same behavior in the
backend as in libpq.
Back-patch to all supported releases.
M src/backend/libpq/be-secure.c
M src/interfaces/libpq/fe-secure.c
Fix PQsetvalue() to avoid possible crash when adding a new tuple.
commit : fe0e1a633a164cfc0cddae0ee318d40230a491b0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Jul 2011 12:24:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Jul 2011 12:24:14 -0400
PQsetvalue unnecessarily duplicated the logic in pqAddTuple, and didn't
duplicate it exactly either --- pqAddTuple does not care what is in the
tuple-pointer array positions beyond the last valid entry, whereas the
code in PQsetvalue assumed such positions would contain NULL. This led
to possible crashes if PQsetvalue was applied to a PGresult that had
previously been enlarged with pqAddTuple, for instance one built from a
server query. Fix by relying on pqAddTuple instead of duplicating logic,
and not assuming anything about the contents of res->tuples[res->ntups].
Back-patch to 8.4, where PQsetvalue was introduced.
Andrew Chernow
M src/interfaces/libpq/fe-exec.c
In pg_upgrade, fix the -l/log option to work on Windows.
commit : 431b7b84fe0fb830499561a31021932550817a8e
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 20 Jul 2011 18:31:08 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 20 Jul 2011 18:31:08 -0400
Also, double-quote the log file name in all places, to allow (on all
platforms) log file names with spaces.
Back patch to 9.0 and 9.1.
M contrib/pg_upgrade/pg_upgrade.c
Adapted expected result for latest change to ecpglib.
commit : 3089a3a1011dcf5dfc34143892f482e7c8f8e797
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 18 Jul 2011 18:56:15 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 18 Jul 2011 18:56:15 +0200
M src/interfaces/ecpg/test/expected/compat_informix-rnull.stderr
Made ecpglib write double with a precision of 15 digits.
commit : 77a7a57f7fb8f9c1fc6449938f459d17cc2cfc80
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 18 Jul 2011 16:25:27 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 18 Jul 2011 16:25:27 +0200
Patch originally by Akira Kurosawa <kurosawa-akira@mxc.nes.nec.co.jp>.
M src/interfaces/ecpg/ecpglib/execute.c
Fix SSPI login when multiple roundtrips are required
commit : d662e3970d265a9edc645d2755cf427ed33498c1
author : Magnus Hagander <magnus@hagander.net>
date : Sat, 16 Jul 2011 19:58:53 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Sat, 16 Jul 2011 19:58:53 +0200
This fixes SSPI login failures showing "The function
requested is not supported", often showing up when connecting
to localhost. The reason was not properly updating the SSPI
handle when multiple roundtrips were required to complete the
authentication sequence.
Report and analysis by Ahmed Shinwari, patch by Magnus Hagander
M src/backend/libpq/auth.c
Fix two ancient bugs in GiST code to re-find a parent after page split:
commit : 75f386df50939072c060a1656b1209c13b5545f8
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 15 Jul 2011 10:54:56 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 15 Jul 2011 10:54:56 +0300
First, when following a right-link, we incorrectly marked the current page
as the parent of the right sibling. In reality, the parent of the right page
is the same as the parent of the current page (or some page to the right of
it, gistFindCorrectParent() will sort that out).
Secondly, when we follow a right-link, we must prepend, not append, the right
page to our list of pages to visit. That's because we assume that once we
hit a leaf page in the list, all the rest are leaf pages too, and give up.
To hit these bugs, you need concurrent actions and several unlucky accidents.
Another backend must split the root page, while you're in process of
splitting a lower-level page. Furthermore, while you scan the internal nodes
to re-find the parent, another backend needs to again split some more internal
pages. Even then, the bugs don't necessarily manifest as user-visible errors
or index corruption.
While we're at it, make the error reporting a bit better if gistFindPath()
fails to re-find the parent. It used to be an assertion, but an elog() seems
more appropriate.
Backpatch to all supported branches.
M src/backend/access/gist/gist.c
In planner, don't assume that empty parent tables aren't really empty.
commit : 0dd46a776651b2cb49c120a2deb169526ad4afb8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Jul 2011 17:30:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Jul 2011 17:30:57 -0400
There's a heuristic in estimate_rel_size() to clamp the minimum size
estimate for a table to 10 pages, unless we can see that vacuum or analyze
has been run (and set relpages to something nonzero, so this will always
happen for a table that's actually empty). However, it would be better
not to do this for inheritance parent tables, which very commonly are
really empty and can be expected to stay that way. Per discussion of a
recent pgsql-performance report from Anish Kejariwal. Also prevent it
from happening for indexes (although this is more in the nature of
documentation, since CREATE INDEX normally initializes relpages to
something nonzero anyway).
Back-patch to 9.0, because the ability to collect statistics across a
whole inheritance tree has improved the planner's estimates to the point
where this relatively small error makes a significant difference. In the
referenced report, merge or hash joins were incorrectly estimated as
cheaper than a nestloop with inner indexscan on the inherited table.
That was less likely before 9.0 because the lack of inherited stats would
have resulted in a default (and rather pessimistic) estimate of the cost
of a merge or hash join.
M src/backend/optimizer/util/plancat.c
Fix another oversight in logging of changes in postgresql.conf settings.
commit : 9a9e530713d3ccf20a485c8cc61d6d599340d985
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 8 Jul 2011 17:03:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 8 Jul 2011 17:03:12 -0400
We were using GetConfigOption to collect the old value of each setting,
overlooking the possibility that it didn't exist yet. This does happen
in the case of adding a new entry within a custom variable class, as
exhibited in bug #6097 from Maxim Boguk.
To fix, add a missing_ok parameter to GetConfigOption, but only in 9.1
and HEAD --- it seems possible that some third-party code is using that
function, so changing its API in a minor release would cause problems.
In 9.0, create a near-duplicate function instead.
M src/backend/utils/misc/guc-file.l
M src/backend/utils/misc/guc.c
M src/include/utils/guc.h
Update examples for string-related functions.
commit : d1ca2a1ee93916d69836d7a1924aa7601bcfb635
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Jul 2011 19:34:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 7 Jul 2011 19:34:28 -0400
In the example for decode(), show the bytea result in hex format,
since that's now the default. Use an E'' string in the example for
quote_literal(), so that it works regardless of the
standard_conforming_strings setting. On the functions-for-binary-strings
page, leave the examples as-is for readability, but add a note pointing out
that they are shown in escape format. Per comments from Thom Brown.
Also, improve the description for encode() and decode() a tad.
Backpatch to 9.0, where bytea_output was introduced.
M doc/src/sgml/func.sgml
Fix use of unportable %m format
commit : f1d869276f7c256ade9d5dd6a4d8143821cdac1c
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 7 Jul 2011 21:21:57 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 7 Jul 2011 21:21:57 +0300
M contrib/pg_upgrade/file.c
Fix psql's counting of script file line numbers during COPY.
commit : 245b5f1794eff632f9dd1252f29f65aad02e871d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Jul 2011 12:04:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Jul 2011 12:04:40 -0400
handleCopyIn incremented pset.lineno for each line of COPY data read from
a file. This is correct when reading from the current script file (i.e.,
we are doing COPY FROM STDIN followed by in-line data), but it's wrong if
the data is coming from some other file. Per bug #6083 from Steve Haslam.
Back-patch to all supported versions.
M src/bin/psql/copy.c
Fix typo in sslmode documentation
commit : 1e7b52d753f84ed46095a68f23e992a95e41f13f
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 5 Jul 2011 09:45:19 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 5 Jul 2011 09:45:19 +0200
Per bug #6089, noted by Sidney Cadot
M doc/src/sgml/libpq.sgml
Clarify that you need ActiveState perl 5.8 *or later* to build on Windows.
commit : 6bb8659ecf358bc83ed141120e0a6c73724fe0e4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 4 Jul 2011 22:30:27 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 4 Jul 2011 22:30:27 +0300
M doc/src/sgml/install-win32.sgml
Back-patch Fix bat file quoting of %ENV from commit 19b7fac8.
commit : 1e8b78e521e2dc12bd1fd5831e5b9b427a07e70c
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 4 Jul 2011 10:12:27 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 4 Jul 2011 10:12:27 -0400
M src/tools/msvc/builddoc.bat
M src/tools/msvc/install.bat
M src/tools/msvc/pgbison.bat
M src/tools/msvc/pgflex.bat
Fix omissions in documentation of the pg_roles view.
commit : c7e84d53375f0c3405da584b06d758e015d8ce30
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jul 2011 22:12:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jul 2011 22:12:25 -0400
Somehow, column rolconfig got removed from the documentation of the
pg_roles view in the 9.0 cycle, although the column is actually still
there. In 9.1, we'd also forgotten to document the rolreplication column.
Spotted by Sakamoto Masahiko.
M doc/src/sgml/catalogs.sgml
Fix EXPLAIN to handle gating Result nodes within inner-indexscan subplans.
commit : 789d3d4541e95c6079a55196bd63a6ab90e57c7c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jul 2011 01:35:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 3 Jul 2011 01:35:15 -0400
It is possible for a NestLoop plan node to pass an OUTER Var into an
"inner indexscan" that is an Append construct (derived from an inheritance
tree or UNION ALL subquery). The OUTER tuple is then passed down at
runtime to the leaf indexscan node(s) where it will actually be used.
EXPLAIN has to likewise pass the information about the nestloop's outer
subplan down through the Append node, else it will fail to print the
outer-reference Vars (with complaints like "bogus varno: 65001").
However, there was a case missed in all this: we could also have gating
Result nodes that were inserted into the appendrel plan tree to deal with
pseudoconstant qual conditions. So EXPLAIN has to pass down the outer plan
node to a Result's subplan, too. Per example from Jon Nelson.
The problem is gone in 9.1 because we replaced the nestloop outer-tuple
kluge with a Param-based data transfer mechanism. Also, so far as I can
tell, the case can't happen before 8.4 because of restrictions on what
sorts of appendrel members could be pulled up into the parent query.
So this patch is only needed for 8.4 and 9.0.
M src/backend/commands/explain.c
In pg_upgrade 9.0 and 9.1, document suggestion of using a non-default port number to avoid unintended client connections.
commit : 46242281b44c7546b321ba503b8d99cc299ca746
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 1 Jul 2011 23:09:14 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 1 Jul 2011 23:09:14 -0400
M doc/src/sgml/pgupgrade.sgml
Restore correct btree preprocessing of "indexedcol IS NULL" conditions.
commit : bbfcc71496051651accb71540130c6d36377a692
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Jun 2011 19:47:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Jun 2011 19:47:07 -0400
Such a condition is unsatisfiable in combination with any other type of
btree-indexable condition (since we assume btree operators are always
strict). 8.3 and 8.4 had an explicit test for this, which I removed in
commit 29c4ad98293e3c5cb3fcdd413a3f4904efff8762, mistakenly thinking that
the case would be subsumed by the more general handling of IS (NOT) NULL
added in that patch. Put it back, and improve the comments about it, and
add a regression test case.
Per bug #6079 from Renat Nasyrov, and analysis by Dean Rasheed.
M src/backend/access/nbtree/nbtutils.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Protect pg_stat_reset_shared() against NULL input
commit : cbfd82aad252fd86b560a7b7c3d87260a34a595e
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 29 Jun 2011 19:35:11 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 29 Jun 2011 19:35:11 +0200
Per bug #6082, reported by Steve Haslam
M src/backend/utils/adt/pgstatfuncs.c
Reduce impact of btree page reuse on Hot Standby by fixing off-by-1 error. WAL records of type XLOG_BTREE_REUSE_PAGE were generated using a latestRemovedXid one higher than actually needed because xid used was page opaque->btpo.xact rather than an actually removed xid. Noticed on an otherwise quiet system by Noah Misch.
commit : 5cd81b8df0a9f3e4cb407e815b9a789138fd0356
author : Simon Riggs <simon@2ndQuadrant.com>
date : Mon, 27 Jun 2011 22:15:46 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Mon, 27 Jun 2011 22:15:46 +0100
Noah Misch and Simon Riggs
M src/backend/access/nbtree/nbtpage.c
In pg_upgrade docs, clarify that link mode uses "hard" links.
commit : 3a2906545f839aaf3a49f08a6f8d2cb1f841168f
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 23 Jun 2011 19:57:45 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 23 Jun 2011 19:57:45 -0400
Backpatch to 9.1 and 9.0.
M doc/src/sgml/pgupgrade.sgml
Fix pg_upgrade status message capitalization mistake.
commit : 7412f5cd29b8da364e88f5a63a17c8573dbad73b
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2011 14:49:09 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Jun 2011 14:49:09 -0400
Backpatch to 9.1 and 9.0.
Dan McGee
M contrib/pg_upgrade/check.c
Apply upstream fix for blowfish signed-character bug (CVE-2011-2483).
commit : 3246a1791de01e6adbb1ee295dae65fa4fe12c6c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Jun 2011 14:41:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Jun 2011 14:41:05 -0400
A password containing a character with the high bit set was misprocessed
on machines where char is signed (which is most). This could cause the
preceding one to three characters to fail to affect the hashed result,
thus weakening the password. The result was also unportable, and failed
to match some other blowfish implementations such as OpenBSD's.
Since the fix changes the output for such passwords, upstream chose
to provide a compatibility hack: password salts beginning with $2x$
(instead of the usual $2a$ for blowfish) are intentionally processed
"wrong" to give the same hash as before. Stored password hashes can
thus be modified if necessary to still match, though it'd be better
to change any affected passwords.
In passing, sync a couple other upstream changes that marginally improve
performance and/or tighten error checking.
Back-patch to all supported branches. Since this issue is already
public, no reason not to commit the fix ASAP.
M contrib/pgcrypto/crypt-blowfish.c
M contrib/pgcrypto/px-crypt.c
Fix missed use of "cp -i" in an example, per Fujii Masao.
commit : 57ad59a2c187a285cff956743ea460026f231b51
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Jun 2011 16:27:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Jun 2011 16:27:40 -0400
Also be more careful about markup: use & not just &.
M doc/src/sgml/backup.sgml
Fix thinko in previous patch for optimizing EXISTS-within-EXISTS.
commit : 5f129cf942bb16d5e6d9db01db1789c98116baa1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Jun 2011 14:33:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Jun 2011 14:33:20 -0400
When recursing after an optimization in pull_up_sublinks_qual_recurse, the
available_rels value passed down must include only the relations that are
in the righthand side of the new SEMI or ANTI join; it's incorrect to pull
up a sub-select that refers to other relations, as seen in the added test
case. Per report from BangarRaju Vadapalli.
While at it, rethink the idea of recursing below a NOT EXISTS. That is
essentially the same situation as pulling up ANY/EXISTS sub-selects that
are in the ON clause of an outer join, and it has the same disadvantage:
we'd force the two joins to be evaluated according to the syntactic nesting
order, because the lower join will most likely not be able to commute with
the ANTI join. That could result in having to form a rather large join
product, whereas the handling of a correlated subselect is not quite that
dumb. So until we can handle those cases better, #ifdef NOT_USED that
case. (I think it's okay to pull up in the EXISTS/ANY cases, because SEMI
joins aren't so inflexible about ordering.)
Back-patch to 8.4, same as for previous patch in this area. Fortunately
that patch hadn't made it into any shipped releases yet.
M src/backend/optimizer/prep/prepjointree.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Fixed string in German translation that causes segfault.
commit : b8e287711c2f0ce2aed0c1eeb50bc0154025c289
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 20 Jun 2011 13:53:15 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 20 Jun 2011 13:53:15 +0200
Applied patch by Christoph Berg <cb@df7cb.de> to replace placeholder "%s" by
correct string.
M src/backend/po/de.po
Fix thinko in previous patch to always update pg_class.reltuples/relpages.
commit : ccdce73b2145a0a762188709b89ca73e7d2efcd8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Jun 2011 14:01:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Jun 2011 14:01:01 -0400
I mis-simplified the test where ANALYZE decided if it could get away
without doing anything: under the new regime, that's never allowed. Per
bug #6068 from Jeff Janes. Back-patch to 8.4, just like previous patch.
M src/backend/commands/analyze.c
Don't use "cp -i" in the example WAL archive_command.
commit : ae7fc61bc3138d4e938f0faf353a92f0fb4d89ca
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Jun 2011 19:13:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Jun 2011 19:13:12 -0400
This is a dangerous example to provide because on machines with GNU cp,
it will silently do the wrong thing and risk archive corruption. Worse,
during the 9.0 cycle somebody "improved" the discussion by removing the
warning that used to be there about that, and instead leaving the
impression that the command would work as desired on most Unixen.
It doesn't. Try to rectify the damage by providing an example that is safe
most everywhere, and then noting that you can try cp -i if you want but
you'd better test that.
In back-patching this to all supported branches, I also added an example
command for Windows, which wasn't provided before 9.0.
M doc/src/sgml/backup.sgml
Obtain table locks as soon as practical during pg_dump.
commit : 7975f2baa955397fbeb64b5301235ed1dd0f9be6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Jun 2011 18:19:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Jun 2011 18:19:14 -0400
For some reason, when we (I) added table lock acquisition to pg_dump,
we didn't think about making it happen as soon as possible after the
start of the transaction. What with subsequent additions, there was
actually quite a lot going on before we got around to that; which sort
of defeats the purpose. Rearrange the order of calls in dumpSchema()
to close the risk window as much as we easily can. Back-patch to all
supported branches.
M src/bin/pg_dump/common.c
Add overflow checks to int4 and int8 versions of generate_series().
commit : 51328d56a412578480bad0fb65b7cf58816d71b8
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 17 Jun 2011 14:28:45 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 17 Jun 2011 14:28:45 -0400
The previous code went into an infinite loop after overflow. In fact,
an overflow is not really an error; it just means that the current
value is the last one we need to return. So, just arrange to stop
immediately when overflow is detected.
Back-patch all the way.
M src/backend/utils/adt/int.c
M src/backend/utils/adt/int8.c
Respect Hot Standby controls while recycling btree index pages. Btree pages were recycled after VACUUM deletes all records on a page and then a subsequent VACUUM occurs after the RecentXmin horizon is reached. Using RecentXmin meant that we did not respond correctly to the user controls provide to avoid Hot Standby conflicts and so spurious conflicts could be generated in some workload combinations. We now reuse pages only when we reach RecentGlobalXmin, which can be much later in the presence of long running queries and is also controlled by vacuum_defer_cleanup_age.
commit : 1c7ddbf3501e989d6b783dc516c44c3535dbe03f
author : Simon Riggs <simon@2ndQuadrant.com>
date : Thu, 16 Jun 2011 10:12:50 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Thu, 16 Jun 2011 10:12:50 +0100
Noah Misch and Simon Riggs
M src/backend/access/nbtree/nbtpage.c
Fix failure to account for memory used by tuplestore_putvalues().
commit : 669ac03af62328e4eb572dacb8ba319414ef1211
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Jun 2011 14:05:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Jun 2011 14:05:22 -0400
This oversight could result in a tuplestore using much more than the
intended amount of memory. It would only happen in a code path that loaded
a tuplestore via tuplestore_putvalues(), and many of those won't emit huge
amounts of data; but cases such as holdable cursors and plpgsql's RETURN
NEXT command could have the problem. The fix ensures that the tuplestore
will switch to write-to-disk mode when it overruns work_mem.
The potential overrun was finite, because we would still count the space
used by the tuple pointer array, so the tuplestore code would eventually
flip into write-to-disk mode anyway. When storing wide tuples we would
go far past the expected work_mem usage before that happened; but this
may account for the lack of prior reports.
Back-patch to 8.4, where tuplestore_putvalues was introduced.
Per bug #6061 from Yann Delorme.
M src/backend/utils/sort/tuplestore.c
In pg_upgrade, document that link mode has to have data directories on the same file system, and that authentication should lock out normal users.
commit : 6122849416fdde839ca44ca50906642708c5db21
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 Jun 2011 18:14:56 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 Jun 2011 18:14:56 -0400
Per suggestsion from #postgresql irc channel.
Backpatch to 9.0.
M doc/src/sgml/pgupgrade.sgml
Fix assorted issues with build and install paths containing spaces.
commit : 52463867275cfd40a29c0705f43ce67f54c3f78e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Jun 2011 12:50:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Jun 2011 12:50:16 -0400
Apparently there is no buildfarm critter exercising this case after all,
because it fails in several places. With this patch, build, install,
check-world, and installcheck-world pass for me on OS X.
M src/Makefile.shlib
M src/interfaces/ecpg/test/Makefile
M src/makefiles/pgxs.mk
M src/pl/plperl/GNUmakefile
M src/pl/plpython/Makefile
M src/pl/tcl/Makefile
M src/test/regress/GNUmakefile
Fix grammatical mistake introduced by previous commit
commit : a2b354afb603ad9b1e527ed6e2f7180271f97fa2
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 14 Jun 2011 13:48:23 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 14 Jun 2011 13:48:23 -0400
Per note from Tom
M doc/src/sgml/ddl.sgml
Mention DROP TABLE as well as ALTER TABLE NO INHERIT
commit : 247fd8105aa6bcb3201dbc19e206fcb27b940040
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 14 Jun 2011 11:20:52 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 14 Jun 2011 11:20:52 -0400
... when talking about how good they are in replacement of bulk DELETE
in partitioned setups.
The original wording was a bit confusing.
Per an observation from David Wheeler.
M doc/src/sgml/ddl.sgml
Fix aboriginal copy-paste mistake in error message
commit : a03f1d399dbfdc87798742329270d99962216100
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 13 Jun 2011 17:50:30 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 13 Jun 2011 17:50:30 -0400
Spotted by Jaime Casanova
M src/backend/catalog/pg_shdepend.c
Expand warnings on locks acquired by CREATE INDEX CONCURRENTLY
commit : 2602e637505ed9b4500bb0f17abcb630b2b711b3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 13 Jun 2011 17:12:26 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 13 Jun 2011 17:12:26 -0400
The previous wording wasn't explicit enough, which could misled readers
into thinking that the locks acquired are more restricted in nature than
they really are. The resulting optimism can be damaging to morale when
confronted with reality, as has been observed in the field.
Greg Smith
M doc/src/sgml/ref/create_index.sgml
Remove parentheses from mention of current_schemas function.
commit : 6350d75bf2faa81cf7b8ccd3ceeb5fe4adefc7f5
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 13 Jun 2011 13:02:54 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 13 Jun 2011 13:02:54 -0400
This is more consistent with what we do elsewhere, and hopefully avoids
creating the perception that current_schemas takes no arguments.
As suggested by Brendan Jurd
M doc/src/sgml/config.sgml
Add doc cross-reference to search_path discussion of current_schemas().
commit : c06bdaf92c78d3d5bc6efdc4474abbf33ab7a047
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 13 Jun 2011 12:37:49 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 13 Jun 2011 12:37:49 -0400
Brendan Jurd
M doc/src/sgml/config.sgml
Work around gcc 4.6.0 bug that breaks WAL replay.
commit : 45d792f70272ed57b932816562f31c2f79426c2a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2011 17:03:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Jun 2011 17:03:11 -0400
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and make the code more readable
to boot, by getting rid of the direct references. Improve the comments
while at it.
Back-patch to all supported versions, in case they get built with 4.6.0.
Tom Lane, with some cosmetic suggestions from Alex Hunsaker
M src/backend/access/transam/xlog.c
M src/include/access/xlog_internal.h
Use the correct eventlog severity for error
commit : cdd08887b9f160271f8d6695d5914c53814105c6
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 9 Jun 2011 18:21:38 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Thu, 9 Jun 2011 18:21:38 +0200
M src/bin/pg_ctl/pg_ctl.c
Support silent mode for service registrations on win32
commit : 15fe829b23ad1871ed0b27d807371cbd37768289
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 9 Jun 2011 18:18:45 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Thu, 9 Jun 2011 18:18:45 +0200
Using -s when registering a service will now suppress
the application eventlog entries stating that the service
is starting and started.
MauMau
M doc/src/sgml/ref/pg_ctl-ref.sgml
M src/bin/pg_ctl/pg_ctl.c
Fix documentation of information_schema.element_types
commit : ffa653b945cb6a03e64b7c7c0d61b7ee916ada1b
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 9 Jun 2011 07:24:14 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 9 Jun 2011 07:24:14 +0300
The documentation of the columns collection_type_identifier and
dtd_identifier was wrong. This effectively reverts commits
8e1ccad51901e83916dae297cd9afa450957a36c and
57352df66d3a0885899d39c04c067e63c7c0ba30 and updates the name
array_type_identifier (the name in SQL:1999) to
collection_type_identifier.
closes bug #5926
M doc/src/sgml/information_schema.sgml
Allow building with perl 5.14.
commit : cb252c2acd415d304e3254e99f82058d11a69e04
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 4 Jun 2011 19:35:04 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 4 Jun 2011 19:35:04 -0400
Patch from Alex Hunsaker.
M src/pl/plperl/plperl.c
M src/pl/plperl/plperl.h
Fix documentation reference to "above" example
commit : 39dbc62adedc8758580d099e4a21f1e5a4a0bf85
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 4 Jun 2011 23:12:27 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 4 Jun 2011 23:12:27 +0300
found by Thom Brown
M doc/src/sgml/plpython.sgml
More ECPG documentation fixes
commit : ec688fd346e7f3413bd69ff2413a1e6da6aec402
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 4 Jun 2011 22:29:26 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 4 Jun 2011 22:29:26 +0300
Marc Cousin
M doc/src/sgml/ecpg.sgml
ECPG documentation fix
commit : 843c280626ae97dbf521d27992abfdfdfe69e279
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 4 Jun 2011 22:11:20 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 4 Jun 2011 22:11:20 +0300
Marc Cousin, Satoshi Nagayasu
M doc/src/sgml/ecpg.sgml
Expose the "*VALUES*" alias that we generate for a stand-alone VALUES list.
commit : ab1aaf3d220645501a33a4f044d42507f280c8d7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Jun 2011 15:48:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Jun 2011 15:48:25 -0400
We were trying to make that strictly an internal implementation detail,
but it turns out that it's exposed anyway when dumping a view defined
like
CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1;
This comes out as
CREATE VIEW ... ORDER BY "*VALUES*".column1;
which fails to parse when reloading the dump.
Hacking ruleutils.c to suppress the column qualification looks like it'd
be a risky business, so instead promote the RTE alias to full-fledged
usability.
Per bug #6049 from Dylan Adams. Back-patch to all supported branches.
M src/backend/parser/analyze.c
Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence.
commit : bc0550f994539b4cd3b93487439c754e251fedb8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Jun 2011 15:31:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Jun 2011 15:31:02 -0400
My previous commit disallowed this operation, but did nothing about
cleaning up the damage if one had already been done. With the operation
disallowed, it's okay to just forcibly clear xmax in a sequence's tuple,
since any value seen there could not represent a live transaction's lock.
So, any sequence-specific operation will repair the problem automatically,
whether or not the user has already seen "could not access status of
transaction" failures.
M src/backend/commands/sequence.c
Disallow SELECT FOR UPDATE/SHARE on sequences.
commit : c117838597b1a28f6f0feb4a41adff1a7e5e0bc9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Jun 2011 14:46:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Jun 2011 14:46:22 -0400
We can't allow this because such an operation stores its transaction XID
into the sequence tuple's xmax. Because VACUUM doesn't process sequences
(and we don't want it to start doing so), such an xmax value won't get
frozen, meaning it will eventually refer to nonexistent pg_clog storage,
and even wrap around completely. Since the row lock is ignored by nextval
and setval, the usefulness of the operation is highly debatable anyway.
Per reports of trouble with pgpool 3.0, which had ill-advisedly started
using such commands as a form of locking.
In HEAD, also disallow SELECT FOR UPDATE/SHARE on toast tables. Although
this does work safely given the current implementation, there seems no
good reason to allow it. I refrained from changing that behavior in
back branches, however.
M src/backend/executor/execMain.c
Protect GIST logic that assumes penalty values can't be negative.
commit : b26d8fda6535799be6eee1e93a8f11756b11af95
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 May 2011 17:53:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 May 2011 17:53:55 -0400
Apparently sane-looking penalty code might return small negative values,
for example because of roundoff error. This will confuse places like
gistchoose(). Prevent problems by clamping negative penalty values to
zero. (Just to be really sure, I also made it force NaNs to zero.)
Back-patch to all supported branches.
Alexander Korotkov
M doc/src/sgml/gist.sgml
M src/backend/access/gist/gistutil.c
Fix portability bugs in use of credentials control messages for peer auth.
commit : e73bd1e343c07970ed7d31c83b3d5035abd4e996
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 May 2011 19:16:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 May 2011 19:16:11 -0400
Even though our existing code for handling credentials control messages has
been basically unchanged since 2001, it was fundamentally wrong: it did not
ensure proper alignment of the supplied buffer, and it was calculating
buffer sizes and message sizes incorrectly. This led to failures on
platforms where alignment padding is relevant, for instance FreeBSD on
64-bit platforms, as seen in a recent Debian bug report passed on by
Martin Pitt (http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=612888).
Rewrite to do the message-whacking using the macros specified in RFC 2292,
following a suggestion from Theo de Raadt in that thread. Tested by me
on Debian/kFreeBSD-amd64; since OpenBSD and NetBSD document the identical
CMSG API, it should work there too.
Back-patch to all supported branches.
M src/backend/libpq/auth.c
M src/interfaces/libpq/fe-auth.c
Fix VACUUM so that it always updates pg_class.reltuples/relpages.
commit : 73bd34c81ebd2208f4bd207b83f8a4df8aec82d2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 May 2011 17:05:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 May 2011 17:05:33 -0400
When we added the ability for vacuum to skip heap pages by consulting the
visibility map, we made it just not update the reltuples/relpages
statistics if it skipped any pages. But this could leave us with extremely
out-of-date stats for a table that contains any unchanging areas,
especially for TOAST tables which never get processed by ANALYZE. In
particular this could result in autovacuum making poor decisions about when
to process the table, as in recent report from Florian Helmberger. And in
general it's a bad idea to not update the stats at all. Instead, use the
previous values of reltuples/relpages as an estimate of the tuple density
in unvisited pages. This approach results in a "moving average" estimate
of reltuples, which should converge to the correct value over multiple
VACUUM and ANALYZE cycles even when individual measurements aren't very
good.
This new method for updating reltuples is used by both VACUUM and ANALYZE,
with the result that we no longer need the grotty interconnections that
caused ANALYZE to not update the stats depending on what had happened
in the parent VACUUM command.
Also, fix the logic for skipping all-visible pages during VACUUM so that it
looks ahead rather than behind to decide what to do, as per a suggestion
from Greg Stark. This eliminates useless scanning of all-visible pages at
the start of the relation or just after a not-all-visible page. In
particular, the first few pages of the relation will not be invariably
included in the scanned pages, which seems to help in not overweighting
them in the reltuples estimate.
Back-patch to 8.4, where the visibility map was introduced.
M src/backend/commands/analyze.c
M src/backend/commands/vacuum.c
M src/backend/commands/vacuumlazy.c
M src/backend/postmaster/pgstat.c
M src/include/commands/vacuum.h
M src/include/pgstat.h
Fix null-dereference crash in parse_xml_decl().
commit : ab7c5a90828472c2261048a7195ab9218b55e296
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 28 May 2011 12:36:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 28 May 2011 12:36:04 -0400
parse_xml_decl's header comment says you can pass NULL for any unwanted
output parameter, but it failed to honor this contract for the "standalone"
flag. The only currently-affected caller is xml_recv, so the net effect is
that sending a binary XML value containing a standalone parameter in its
xml declaration would crash the backend. Per bug #6044 from Christopher
Dillard.
In passing, remove useless initializations of parse_xml_decl's output
parameters in xml_parse.
Back-patch to 8.3, where this code was introduced.
M src/backend/utils/adt/xml.c
Preserve caller's memory context in ProcessCompletedNotifies().
commit : 722548e4309c28631ada292fe6cad04ae8f9c151
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 May 2011 12:10:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 May 2011 12:10:32 -0400
This is necessary to avoid long-term memory leakage, because the main loop
in PostgresMain expects to be executing in MessageContext, and hence is a
bit sloppy about freeing stuff that is only needed for the duration of
processing the current client message. The known case of an actual leak
is when encoding conversion has to be done on the incoming command string,
but there might be others. Per report from Per-Olov Esgard.
Back-patch to 9.0, where the bug was introduced by the LISTEN/NOTIFY
rewrite.
M src/backend/commands/async.c
Make decompilation of optimized CASE constructs more robust.
commit : 0bd7305ffb16b238dea79d5f98f88c745fe21db8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 May 2011 19:25:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 May 2011 19:25:19 -0400
We had some hacks in ruleutils.c to cope with various odd transformations
that the optimizer could do on a CASE foo WHEN "CaseTestExpr = RHS" clause.
However, the fundamental impossibility of covering all cases was exposed
by Heikki, who pointed out that the "=" operator could get replaced by an
inlined SQL function, which could contain nearly anything at all. So give
up on the hacks and just print the expression as-is if we fail to recognize
it as "CaseTestExpr = RHS". (We must cover that case so that decompiled
rules print correctly; but we are not under any obligation to make EXPLAIN
output be 100% valid SQL in all cases, and already could not do so in some
other cases.) This approach requires that we have some printable
representation of the CaseTestExpr node type; I used "CASE_TEST_EXPR".
Back-patch to all supported branches, since the problem case fails in all.
M src/backend/utils/adt/ruleutils.c
Avoid uninitialized bits in the result of QTN2QT().
commit : c2a366d9d9d3b1e2dc4c65d9a9fab5c1c0d6c246
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 May 2011 14:20:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 May 2011 14:20:08 -0400
Found with additional valgrind testing.
Noah Misch
M src/backend/utils/adt/tsquery_util.c
Lobotomize typmod check in convert_tuples_by_position, back branches only.
commit : e48433e9f81d6aceef2b538f1783fbcc91e1074f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 May 2011 14:42:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 May 2011 14:42:18 -0400
convert_tuples_by_position was rejecting attempts to coerce a record field
with -1 typmod to the same type with a non-default typmod. This is in fact
the "correct" thing to do (since we're just going to do a type relabeling,
not invoke any length-conversion cast function); but it results in
rejecting valid cases like bug #6020, because the source record's tupdesc
is built from Params that don't have typmod assigned. Since that's a
regression from previous versions, which accepted this code, we have to do
something about it. In HEAD, I've fixed the problem properly by causing
the Params to receive the correct typmods; but the potential for incidental
behavioral changes seems high enough to make it unattractive to make the
same change in released branches. (And it couldn't be fixed that way in
8.4 anyway...) Hence this patch just modifies convert_tuples_by_position
to not complain if either the input or the output tupdesc has typmod -1.
This is still a shade tighter checking than we did before 9.0, since before
that plpgsql failed to consider typmods at all when checking record
compatibility. (convert_tuples_by_position is currently used only by
plpgsql, so we're not affecting other behavior.)
Back-patch to 8.4, since we recently back-ported convert_tuples_by_position
into that branch.
M src/backend/access/common/tupconvert.c
Replace strdup() with pstrdup(), to avoid leaking memory.
commit : 7541d32e86b739afb41e711a4c790aed446dd0e2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 18 May 2011 22:30:24 -0400
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 18 May 2011 22:30:24 -0400
It's been like this since the seg module was introduced, so backpatch to
8.2 which is the oldest supported version.
M contrib/seg/seg.c
Install defenses against overflow in BuildTupleHashTable().
commit : 168174c44522b5f5bfad53500fd5dd46aad74f70
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 May 2011 12:52:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 May 2011 12:52:51 -0400
The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways in which that could go bad. First, BuildTupleHashTable
declared the parameter as "int" but most callers were passing "long"s,
so on 64-bit machines undetected overflow could occur leading to a bogus
negative value. The obvious fix for that is to change the parameter to
"long", which is what I've done in HEAD. In the back branches that seems a
bit risky, though, since third-party code might be calling this function.
So for them, just put in a kluge to treat negative inputs as INT_MAX.
Second, hash_create can go nuts with extremely large requested table sizes
(notably, my_log2 becomes an infinite loop for inputs larger than
LONG_MAX/2). What seems most appropriate to avoid that is to bound the
initial table size request to work_mem.
This fixes bug #6035 reported by Daniel Schreiber. Although the reported
case only occurs back to 8.4 since it involves WITH RECURSIVE, I think
it's a good idea to install the defenses in all supported branches.
M src/backend/executor/execGrouping.c
Fix write-past-buffer-end in ldapServiceLookup().
commit : 30cf86fdf49ec6a5c74aab6dcd7cef78e7f1dd54
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 May 2011 11:56:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 May 2011 11:56:38 -0400
The code to assemble ldap_get_values_len's output into a single string
wrote the terminating null one byte past where it should. Fix that,
and make some other cosmetic adjustments to make the code a trifle more
readable and more in line with usual Postgres coding style.
Also, free the "result" string when done with it, to avoid a permanent
memory leak.
Bug report and patch by Albe Laurenz, cosmetic adjustments by me.
M src/interfaces/libpq/fe-connect.c
Shut down WAL receiver if it's still running at end of recovery. We used to just check that it's not running and PANIC if it was, but that can rightfully happen if recovery stops at recovery target.
commit : fbc56f706cdadaaf2a686dacece8b403dfaef50b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 11 May 2011 12:46:08 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 11 May 2011 12:46:08 +0300
M src/backend/access/transam/xlog.c
Update documentation to state there is three-value logic, not three-value boolean logic.
commit : f71b5c77fa0015492a26838eb489293effee1723
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 9 May 2011 21:04:22 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 9 May 2011 21:04:22 -0400
Backpatch to 9.0.X since we just got another bug report about this
today.
M doc/src/sgml/func.sgml
Fix pull_up_sublinks' failure to handle nested pull-up opportunities.
commit : 65a7cd0e9ced21ec7ad67c11cd9a263640fe22e9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 May 2011 15:56:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 May 2011 15:56:43 -0400
After finding an EXISTS or ANY sub-select that can be converted to a
semi-join or anti-join, we should recurse into the body of the sub-select.
This allows cases such as EXISTS-within-EXISTS to be optimized properly.
The original coding would leave the lower sub-select as a SubLink, which
is no better and often worse than what we can do with a join. Per example
from Wayne Conrad.
Back-patch to 8.4. There is a related issue in older versions' handling
of pull_up_IN_clauses, but they're lame enough anyway about the whole area
that it seems not worth the extra work to try to fix.
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/prep/prepjointree.c
Add missing gitignore file
commit : e79518e93744a547ff874832dd40638b9531105e
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 2 May 2011 01:03:04 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 2 May 2011 01:03:04 +0300
A contrib/uuid-ossp/.gitignore
Catch errors in for loop in makefile
commit : c8c93c6e73b98fc8e0e371a8391d4824732437f2
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 2 May 2011 00:47:09 +0300
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 2 May 2011 00:47:09 +0300
Add "|| exit" so that the rule aborts when a command fails.
This is the minimal backpatch version. The fix in head is more
elaborate.
M src/makefiles/pgxs.mk
Make CLUSTER lock the old table's toast table before copying data.
commit : fb69fd176aaa8eab0315c4f891297c03c0b5d825
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 May 2011 17:57:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 May 2011 17:57:40 -0400
We must lock out autovacuuming of the old toast table before computing the
OldestXmin horizon we will use. Otherwise, autovacuum could start on the
toast table later, compute a later OldestXmin horizon, and remove as DEAD
toast tuples that we still need (because we think their parent tuples are
only RECENTLY_DEAD). Per further thought about bug #5998.
M src/backend/commands/cluster.c
Remove special case for xmin == xmax in HeapTupleSatisfiesVacuum().
commit : 007a6e53ace7e9f015252f14316394ef4b97ae2e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Apr 2011 16:29:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Apr 2011 16:29:51 -0400
VACUUM was willing to remove a committed-dead tuple immediately if it was
deleted by the same transaction that inserted it. The idea is that such a
tuple could never have been visible to any other transaction, so we don't
need to keep it around to satisfy MVCC snapshots. However, there was
already an exception for tuples that are part of an update chain, and this
exception created a problem: we might remove TOAST tuples (which are never
part of an update chain) while their parent tuple stayed around (if it was
part of an update chain). This didn't pose a problem for most things,
since the parent tuple is indeed dead: no snapshot will ever consider it
visible. But MVCC-safe CLUSTER had a problem, since it will try to copy
RECENTLY_DEAD tuples to the new table. It then has to copy their TOAST
data too, and would fail if VACUUM had already removed the toast tuples.
Easiest fix is to get rid of the special case for xmin == xmax. This may
delay reclaiming dead space for a little bit in some cases, but it's by far
the most reliable way to fix the issue.
Per bug #5998 from Mark Reid. Back-patch to 8.3, which is the oldest
version with MVCC-safe CLUSTER.
M src/backend/utils/time/tqual.c
Rewrite pg_size_pretty() to avoid compiler bug.
commit : cb0bcf45cbe1092081331f3f759c3ab7580d0cb1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Apr 2011 01:45:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Apr 2011 01:45:02 -0400
Convert it to use successive shifts right instead of increasing a divisor.
This is probably a tad more efficient than the original coding, and it's
nicer-looking than the previous patch because we don't need a special case
to avoid overflow in the last branch. But the real reason to do it is to
avoid a Solaris compiler bug, as per results from buildfarm member moa.
M src/backend/utils/adt/dbsize.c
The arguments to pg_ctl kill are not optional - remove brackets in the docs.
commit : c02bc6356f26c6b4373fbac0118409b544ea85f0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 28 Apr 2011 12:51:02 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 28 Apr 2011 12:51:02 +0300
Fujii Masao
M doc/src/sgml/ref/pg_ctl-ref.sgml
Add comments about the need to avoid uninitialized bits in datatype values.
commit : db3cf2529304f96eabedd21f292bc661d5772aee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Apr 2011 14:06:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Apr 2011 14:06:05 -0400
There was already one recommendation in the documentation about writing
C functions to ensure padding bytes are zeroes, but make it stronger.
Also fix an example that was still using direct assignment to a varlena
length word, which no longer works since the varvarlena changes.
M doc/src/sgml/xfunc.sgml
Fix array- and path-creating functions to ensure padding bytes are zeroes.
commit : 433853e9269ee81627400c7edb1e4f9a001d3816
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Apr 2011 13:58:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Apr 2011 13:58:44 -0400
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
M src/backend/utils/adt/array_userfuncs.c
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/geo_ops.c
Complain if pg_hba.conf contains "hostssl" but SSL is disabled.
commit : af9fb26e2df7b5cfe161d088ce8417b2ceb66063
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Apr 2011 15:40:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Apr 2011 15:40:14 -0400
Most commenters agreed that this is more friendly than silently failing
to match the line during actual connection attempts. Also, this will
prevent corner cases that might arise when trying to handle such a line
when the SSL code isn't turned on. An example is that specifying
clientcert=1 in such a line would formerly result in a completely
misleading complaint that root.crt wasn't present, as seen in a recent
report from Marc-Andre Laverdiere. While we could have instead fixed
that specific behavior, it seems likely that we'd have a continuing stream
of such bizarre behaviors if we keep on allowing hostssl lines when SSL is
disabled.
Back-patch to 8.4, where clientcert was introduced. Earlier versions don't
have this specific issue, and the code is enough different to make this
patch not applicable without more work than it seems worth.
M src/backend/libpq/hba.c
Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX.
commit : 6ba0d8d5ac47b686ac31a2b390ab6a0f181753d1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Apr 2011 16:22:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Apr 2011 16:22:17 -0400
The expression that tried to round the value to the nearest TB could
overflow, leading to bogus output as reported in bug #5993 from Nicola
Cossu. This isn't likely to ever happen in the intended usage of the
function (if it could, we'd be needing to use a wider datatype instead);
but it's not hard to give the expected output, so let's do so.
M src/backend/utils/adt/dbsize.c
Fix use of incorrect constant RemoveRoleFromObjectACL.
commit : 147d6269f3e2d20e1790520e117e574092719ca3
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 20 Apr 2011 22:23:58 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 20 Apr 2011 22:23:58 -0400
This could cause failures when DROP OWNED BY attempt to remove default
privileges on sequences. Back-patching to 9.0.
Shigeru Hanada
M src/backend/catalog/aclchk.c
Fix bugs in indexing of in-doubt HOT-updated tuples.
commit : b381b58286f8fac4d8b08e54e223f238742d1652
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2011 20:34:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2011 20:34:16 -0400
If we find a DELETE_IN_PROGRESS HOT-updated tuple, it is impossible to know
whether to index it or not except by waiting to see if the deleting
transaction commits. If it doesn't, the tuple might again be LIVE, meaning
we have to index it. So wait and recheck in that case.
Also, we must not rely on ii_BrokenHotChain to decide that it's possible to
omit tuples from the index. That could result in omitting tuples that we
need, particularly in view of yesterday's fixes to not necessarily set
indcheckxmin (but it's broken even without that, as per my analysis today).
Since this is just an extremely marginal performance optimization, dropping
the test shouldn't hurt.
These cases are only expected to happen in system catalogs (they're
possible there due to early release of RowExclusiveLock in most
catalog-update code paths). Since reindexing of a system catalog isn't a
particularly performance-critical operation anyway, there's no real need to
be concerned about possible performance degradation from these changes.
The worst aspects of this bug were introduced in 9.0 --- 8.x will always
wait out a DELETE_IN_PROGRESS tuple. But I think dropping index entries
on the strength of ii_BrokenHotChain is dangerous even without that, so
back-patch removal of that optimization to 8.3 and 8.4.
M src/backend/catalog/index.c
Set indcheckxmin true when REINDEX fixes an invalid or not-ready index.
commit : 1d6249d64ddbd7796c1ccaef801b709d5108bc2e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2011 19:01:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2011 19:01:25 -0400
Per comment from Greg Stark, it's less clear that HOT chains don't conflict
with the index than it would be for a valid index. So, let's preserve the
former behavior that indcheckxmin does get set when there are
potentially-broken HOT chains in this case. This change does not cause any
pg_index update that wouldn't have happened anyway, so we're not
re-introducing the previous bug with pg_index updates, and surely the case
is not significant from a performance standpoint; so let's be as
conservative as possible.
M src/backend/catalog/index.c
Quotes in strings injected into bki file need to escaped. In particular, "People's Republic of China" locale on Windows was causing initdb to fail.
commit : 8a6d60fd0c01671773055558b687199ede961a97
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 20 Apr 2011 09:49:44 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 20 Apr 2011 09:49:44 +0300
This fixes bug #5818 reported by yulei. On master, this makes the mapping
of "People's Republic of China" to just "China" obsolete. In 9.0 and 8.4,
just fix the escaping. Earlier versions didn't have locale names in bki
file.
M src/bin/initdb/initdb.c
Avoid changing an index's indcheckxmin horizon during REINDEX.
commit : ebcbc8cfe6c2d9c587ae2a25e545f09b58b666b0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2011 18:51:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2011 18:51:03 -0400
There can never be a need to push the indcheckxmin horizon forward, since
any HOT chains that are actually broken with respect to the index must
pre-date its original creation. So we can just avoid changing pg_index
altogether during a REINDEX operation.
This offers a cleaner solution than my previous patch for the problem
found a few days ago that we mustn't try to update pg_index while we are
reindexing it. System catalog indexes will always be created with
indcheckxmin = false during initdb, and with this modified code we should
never try to change their pg_index entries. This avoids special-casing
system catalogs as the former patch did, and should provide a performance
benefit for many cases where REINDEX formerly caused an index to be
considered unusable for a short time.
Back-patch to 8.3 to cover all versions containing HOT. Note that this
patch changes the API for index_build(), but I believe it is unlikely that
any add-on code is calling that directly.
M src/backend/bootstrap/bootstrap.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/commands/cluster.c
M src/backend/commands/indexcmds.c
M src/include/catalog/index.h
Revert "Prevent incorrect updates of pg_index while reindexing pg_index itself."
commit : 1da9966230a30405ea5981403d4f4a9d83cb1ecb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2011 16:57:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2011 16:57:57 -0400
This reverts commit a03e3e1fd1d4ecfeb1096aeb7854b717061a75d9 of 2011-04-15.
There's a better way to do it, which will follow shortly.
M src/backend/catalog/index.c
Silence compiler warning about unused variable on Windows.
commit : b2e2d3a3781c717ee826d01d83e55009321ac24d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 19 Apr 2011 14:54:48 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 19 Apr 2011 14:54:48 +0300
M src/interfaces/libpq/fe-connect.c
Prevent incorrect updates of pg_index while reindexing pg_index itself.
commit : a03e3e1fd1d4ecfeb1096aeb7854b717061a75d9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Apr 2011 20:19:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Apr 2011 20:19:03 -0400
The places that attempt to change pg_index.indcheckxmin during a reindexing
operation cannot be executed safely if pg_index itself is the subject of
the operation. This is the explanation for a couple of recent reports of
VACUUM FULL failing with
ERROR: duplicate key value violates unique constraint "pg_index_indexrelid_index"
DETAIL: Key (indexrelid)=(2678) already exists.
However, there isn't any real need to update indcheckxmin in such a
situation, if we assume that pg_index can never contain a truly broken HOT
chain. This assumption holds if new indexes are never created on it during
concurrent operations, which is something we don't consider safe for any
system catalog, not just pg_index. Accordingly, modify the code to not
manipulate indcheckxmin when reindexing any system catalog.
Back-patch to 8.3, where HOT was introduced. The known failure scenarios
involve 9.0-style VACUUM FULL, so there might not be any real risk before
9.0, but let's not assume that.
M src/backend/catalog/index.c
Note that Bison on GnuWin32 has trouble with paths with spaces
commit : c1d42380633b86058b99020452eebece91fc2bf2
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 15 Apr 2011 15:27:02 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 15 Apr 2011 15:27:02 +0200
Peter Eisentraut
M doc/src/sgml/install-win32.sgml
Specify which versions of the Platform SDK are supported
commit : 52a6150445247255c065581e1b08170a87df13e4
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 15 Apr 2011 15:00:42 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 15 Apr 2011 15:00:42 +0200
Anything including Visual Studio 2010 compilers is not yet
supported for building on Windows.
M doc/src/sgml/install-win32.sgml