mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-01-30 19:00:29 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update release notes for upcoming re-releases.

Browse Source
This commit is contained in:
Tom Lane 2005-05-09 00:09:45 +00:00
parent 1199026e9e
commit d8c21181ce
1 changed files with 50 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
doc/src/sgml/release.sgml
View File

@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.335 2005/05/05 17:59:40 tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.336 2005/05/09 00:09:45 tgl Exp $
-->
<appendix id="release">
@ -10,7 +10,7 @@ $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.335 2005/05/05 17:59:40 tgl Exp
<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>