Update release notes for upcoming re-releases.

1 files changed, 50 insertions, 6 deletions

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index f5d4c6e9e4..a5ade504f3 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.321.4.11 2005/05/05 20:07:35 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.321.4.12 2005/05/09 00:10:06 tgl Exp $
 -->
 
 <appendix id="release">
@@ -10,7 +10,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.321.4.11 2005/05/05 20:07:35 tg
 
    <note>
    <title>Release date</title>
-   <simpara>2005-05-05</simpara>
+   <simpara>2005-05-09</simpara>
    </note>
 
    <para>
@@ -72,6 +72,17 @@ misuse</para></listitem>
 <type>INTERNAL</> function results</para></listitem>
 <listitem><para>Guard against incorrect second parameter to
 <function>record_out</></para></listitem>
+<listitem><para>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</para>
+<para>This is an extremely serious bug since it could lead to apparent
+data inconsistencies being briefly visible to applications.</para></listitem>
+<listitem><para>Repair race condition between relation extension and
+VACUUM</para>
+<para>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.
+</para></listitem>
 <listitem><para>Fix comparisons of <type>TIME WITH TIME ZONE</> values</para>
 <para>
 The comparison code was wrong in the case where the
@@ -2684,7 +2695,7 @@ typedefs (Michael)</para></listitem>
 
    <note>
    <title>Release date</title>
-   <simpara>2005-05-05</simpara>
+   <simpara>2005-05-09</simpara>
    </note>
 
    <para>
@@ -2795,6 +2806,17 @@ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
 misuse</para></listitem>
 <listitem><para>Change <filename>contrib/tsearch2</> to avoid unsafe use of
 <type>INTERNAL</> function results</para></listitem>
+<listitem><para>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</para>
+<para>This is an extremely serious bug since it could lead to apparent
+data inconsistencies being briefly visible to applications.</para></listitem>
+<listitem><para>Repair race condition between relation extension and
+VACUUM</para>
+<para>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.
+</para></listitem>
 <listitem><para>Fix comparisons of <type>TIME WITH TIME ZONE</> values</para>
 <para>
 The comparison code was wrong in the case where the
@@ -5236,7 +5258,7 @@ DROP SCHEMA information_schema CASCADE;
 
    <note>
    <title>Release date</title>
-   <simpara>2005-05-05</simpara>
+   <simpara>2005-05-09</simpara>
    </note>
 
    <para>
@@ -5313,6 +5335,17 @@ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
 <itemizedlist>
 <listitem><para>Change encoding function signature to prevent
 misuse</para></listitem>
+<listitem><para>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</para>
+<para>This is an extremely serious bug since it could lead to apparent
+data inconsistencies being briefly visible to applications.</para></listitem>
+<listitem><para>Repair race condition between relation extension and
+VACUUM</para>
+<para>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.
+</para></listitem>
 <listitem><para>Fix comparisons of <type>TIME WITH TIME ZONE</> values</para>
 <para>
 The comparison code was wrong in the case where the
@@ -6511,7 +6544,7 @@ operations on bytea columns (Joe)</para></listitem>
 
    <note>
    <title>Release date</title>
-   <simpara>2005-05-05</simpara>
+   <simpara>2005-05-09</simpara>
    </note>
 
    <para>
@@ -6531,6 +6564,17 @@ operations on bytea columns (Joe)</para></listitem>
     <title>Changes</title>
 
 <itemizedlist>
+<listitem><para>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</para>
+<para>This is an extremely serious bug since it could lead to apparent
+data inconsistencies being briefly visible to applications.</para></listitem>
+<listitem><para>Repair race condition between relation extension and
+VACUUM</para>
+<para>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.
+</para></listitem>
 <listitem><para>Fix <function>EXTRACT(EPOCH)</> for
 <type>TIME WITH TIME ZONE</> values</para></listitem>
 <listitem><para>Additional buffer overrun checks in plpgsql
@@ -7133,7 +7177,7 @@ since <productname>PostgreSQL</productname> 7.1.
 <listitem><para>Make ALTER TABLE / RENAME COLUMN update column names of indexes (Brent Verner)</para></listitem>
 <listitem><para>Fix for ALTER TABLE / ADD CONSTRAINT ... CHECK with inherited tables (Stephan Szabo)</para></listitem>
 <listitem><para>ALTER TABLE RENAME update foreign-key trigger arguments correctly (Brent Verner)</para></listitem>
-<listitem><para>DROP AGGREGATE and COMMENT ON AGGREGATE now accepts an aggtype (Tom)</para></listitem>
+<listitem><para>DROP AGGREGATE and COMMENT ON AGGREGATE now accept an aggtype (Tom)</para></listitem>
 <listitem><para>Add automatic return type data casting for SQL functions (Tom)</para></listitem>
 <listitem><para>Allow GiST indexes to handle NULLs and multikey indexes (Oleg Bartunov, Teodor Sigaev, Tom)</para></listitem>
 <listitem><para>Enable partial indexes (Martijn van Oosterhout)</para></listitem>