From: Tom Lane Date: Mon, 9 May 2005 00:10:35 +0000 (+0000) Subject: Update release notes for upcoming re-releases. X-Git-Tag: REL7_3_10 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=e5921b3230f175669faf4b97cd967a2dd5023fdc;p=postgresql Update release notes for upcoming re-releases. --- diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml index 5f9870b438..efe527db21 100644 --- a/doc/src/sgml/release.sgml +++ b/doc/src/sgml/release.sgml @@ -1,5 +1,5 @@ @@ -10,7 +10,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.163.2.21 2005/05/05 20:09: Release date - 2005-05-05 + 2005-05-09 @@ -87,6 +87,17 @@ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0'; Change encoding function signature to prevent misuse +Repair ancient race condition that allowed a transaction to be +seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner +than for other purposes +This is an extremely serious bug since it could lead to apparent +data inconsistencies being briefly visible to applications. +Repair race condition between relation extension and +VACUUM +This could theoretically have caused loss of a page's worth of +freshly-inserted data, although the scenario seems of very low probability. +There are no known cases of it having caused more than an Assert failure. + Fix comparisons of TIME WITH TIME ZONE values The comparison code was wrong in the case where the @@ -1286,7 +1297,7 @@ operations on bytea columns (Joe) Release date - 2005-05-05 + 2005-05-09 @@ -1306,6 +1317,17 @@ operations on bytea columns (Joe) Changes +Repair ancient race condition that allowed a transaction to be +seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner +than for other purposes +This is an extremely serious bug since it could lead to apparent +data inconsistencies being briefly visible to applications. +Repair race condition between relation extension and +VACUUM +This could theoretically have caused loss of a page's worth of +freshly-inserted data, although the scenario seems of very low probability. +There are no known cases of it having caused more than an Assert failure. + Fix EXTRACT(EPOCH) for TIME WITH TIME ZONE values Additional buffer overrun checks in plpgsql