Hello release team,
new PostgreSQL microreleases were released two weeks ago, with a
series of crash fixes and incorrect SQL behaviours. As done with
previous microreleases they should go to lenny and etch.
Unstable already got the new 8.3.5 two weeks ago, which built on most
arches (m68k still missing). Can you please unblock it for Lenny?
I uploaded 8.1.15 [1] and 7.4.23 [2] to s-p-u. Please note that the
8.1 upload encompasses both 8.1.14 and 8.1.15 (I didn't upload 8.1.14
because at that time the previous s-p-u upload wasn't accepted yet).
I didn't update 7.4 in etch until now, since its main purpose is to
provide a smooth upgrade to 8.1, but I think it cannot hurt to update
it anyway for people who actually need 7.4. So this includes 4
microreleases. However, 7.4 does not get many changes any more anyway,
so the total number of changes is still pretty small.
Please let me know if you want autoconf-cleaned diffs or something
else.
Thank you!
Martin
[0] http://packages.qa.debian.org/p/postgresql-8.3/news/20081104T211837Z.html
[1] http://www.postgresql.org/docs/8.1/static/release.html#RELEASE-8-1-15
[2] http://www.postgresql.org/docs/7.4/static/release.html#RELEASE-7-4-23
postgresql-8.1 (8.1.15-0etch1) stable; urgency=low
.
* New upstream bugfix release 8.1.15:
- Fix GiST index corruption due to marking the wrong index entry
"dead" after a deletion. This would result in index searches failing to
find rows they should have found.
- Fix backend crash when the client encoding cannot represent a
localized error message.
- Fix possible crash when deeply nested functions are invoked from a
trigger.
- Fix mis-expansion of rule queries when a sub-SELECT appears in a
function call in FROM, a multi-row VALUES list, or a RETURNING list.
The usual symptom of this problem is an "unrecognized node type"
error.
- Ensure an error is reported when a newly-defined PL/pgSQL trigger
function is invoked as a normal function.
- Prevent possible collision of relfilenode numbers when moving a
table to another tablespace with "ALTER SET TABLESPACE".
The command tried to re-use the existing filename, instead of
picking one that is known unused in the destination directory.
- Fix incorrect tsearch2 headline generation when single query item
matches first word of text.
- Fix improper display of fractional seconds in interval values when
using a non-ISO datestyle in an "--enable-integer-datetimes" build.
- Ensure SPI_getvalue and SPI_getbinval behave correctly when the
passed tuple and tuple descriptor have different numbers of columns.
This situation is normal when a table has had columns added or
removed, but these two functions didn't handle it properly. The
only likely consequence is an incorrect error indication.
- Fix ecpg's parsing of "CREATE ROLE".
- Fix recent breakage of pg_ctl restart.
* New upstream bugfix release 8.1.14:
- Widen local lock counters from 32 to 64 bits. This responds to reports
that the counters could overflow in sufficiently long transactions,
leading to unexpected "lock is already held" errors.
- Fix possible duplicate output of tuples during a GiST index scan.
- Add checks in executor startup to ensure that the tuples produced
by an "INSERT" or "UPDATE" will match the target table's current
rowtype. "ALTER COLUMN TYPE", followed by re-use of a previously cached
plan, could produce this type of situation. The check protects
against data corruption and/or crashes that could ensue.
- Fix AT TIME ZONE to first try to interpret its timezone argument as
a timezone abbreviation, and only try it as a full timezone name if
that fails, rather than the other way around as formerly. The timestamp
input functions have always resolved ambiguous zone names in this order.
Making AT TIME ZONE do so as well improves consistency, and fixes a
compatibility bug introduced in 8.1: in ambiguous cases we now behave
the same as 8.0 and before did, since in the older versions AT TIME ZONE
accepted -only* abbreviations.
- Fix datetime input functions to correctly detect integer overflow
when running on a 64-bit platform.
- Improve performance of writing very long log messages to syslog.
- Fix bug in backwards scanning of a cursor on a SELECT DISTINCT ON
query.
- Fix planner bug with nested sub-select expressions. If the outer
sub-select has no direct dependency on the parent query, but the inner
one does, the outer value might not get recalculated for new parent
query rows.
- Fix planner to estimate that GROUP BY expressions yielding boolean
results always result in two groups, regardless of the expressions'
contents. This is very substantially more accurate than the regular
GROUP BY estimate for certain boolean tests like "col" IS NULL.
- Fix PL/PgSQL to not fail when a FOR loop's target variable is a
record containing composite-type fields.
- Improve pg_dump and pg_restore's error reporting after failure to
send a SQL command.
- Fix pg_ctl to properly preserve postmaster command-line arguments
across a restart.
postgresql-7.4 (1:7.4.23-0etch1) stable; urgency=low
.
* New upstream bug fix release 7.4.23:
- Fix backend crash when the client encoding cannot represent a
localized error message.
- Fix incorrect tsearch2 headline generation when single query item
matches first word of text.
- Fix improper display of fractional seconds in interval values when
using a non-ISO datestyle in an "--enable-integer-datetimes" build.
- Ensure SPI_getvalue and SPI_getbinval behave correctly when the
passed tuple and tuple descriptor have different numbers of columns.
This situation is normal when a table has had columns added or
removed, but these two functions didn't handle it properly. The
only likely consequence is an incorrect error indication.
- Fix ecpg's parsing of "CREATE USER".
* New upstream bug fix release 7.4.22:
- Fix datetime input functions to correctly detect integer overflow
when running on a 64-bit platform.
- Improve performance of writing very long log messages to syslog.
- Fix bug in backwards scanning of a cursor on a SELECT DISTINCT ON
query.
- Fix planner to estimate that GROUP BY expressions yielding boolean
results always result in two groups, regardless of the expressions'
contents. This is very substantially more accurate than the regular
GROUP BY estimate for certain boolean tests like "col" IS NULL.
- Improve pg_dump and pg_restore's error reporting after failure to
send a SQL command.
* New upstream bug fix release 7.4.21:
- Make pg_get_ruledef() parenthesize negative constants.
Before this fix, a negative constant in a view or rule might be
dumped as, say, -42::integer, which is subtly incorrect: it should
be (-42)::integer due to operator precedence rules. Usually this
would make little difference, but it could interact with another
recent patch to cause PostgreSQL to reject what had been a valid
"SELECT DISTINCT" view query. Since this could result in pg_dump
output failing to reload, it is being treated as a high-priority
fix. The only released versions in which dump output is actually
incorrect are 8.3.1 and 8.2.7.
* New upstream bug fix release 7.4.20:
- Fix conversions between ISO-8859-5 and other encodings to handle
Cyrillic "Yo" characters (e and E with two dots).
- Fix a few datatype input functions that were allowing unused bytes
in their results to contain uninitialized, unpredictable values.
This could lead to failures in which two apparently identical
literal values were not seen as equal, resulting in the parser
complaining about unmatched ORDER BY and DISTINCT expressions.
- Fix a corner case in regular-expression substring matching
(substring(string from pattern)). The problem occurs when there is a
match to the pattern overall but the user has specified a parenthesized
subexpression and that subexpression hasn't got a match. An example is
substring('foo' from 'foo(bar)?'). This should return NULL, since (bar)
isn't matched, but it was mistakenly returning the whole-pattern match
instead (ie, foo).
- Fix incorrect result from ecpg's PGTYPEStimestamp_sub() function.
- Fix longstanding "LISTEN"/"NOTIFY" race condition. In rare cases a
session that had just executed a "LISTEN" might not get a notification,
even though one would be expected because the concurrent transaction
executing "NOTIFY" was observed to commit later.
A side effect of the fix is that a transaction that has executed a
not-yet-committed "LISTEN" command will not see any row in
pg_listener for the "LISTEN", should it choose to look; formerly it
would have. This behavior was never documented one way or the
other, but it is possible that some applications depend on the old
behavior.
- Fix display of constant expressions in ORDER BY and GROUP BY.
An explictly casted constant would be shown incorrectly. This could
for example lead to corruption of a view definition during dump and
reload.
- Fix libpq to handle NOTICE messages correctly during COPY OUT.
This failure has only been observed to occur when a user-defined
datatype's output routine issues a NOTICE, but there is no
guarantee it couldn't happen due to other causes.
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: Digital signature