database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-29 13:56:47 +03:00
Code

Update release notes for upcoming re-releases.

Browse Source
This commit is contained in:
Tom Lane 2005-05-09 00:10:35 +00:00
parent dc9e82d0e6
commit e5921b3230
1 changed files with 25 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,5 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.163.2.21 2005/05/05 20:09:11 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.163.2.22 2005/05/09 00:10:35 tgl Exp $
--> -->
<appendix id="release"> <appendix id="release">
@ -10,7 +10,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.163.2.21 2005/05/05 20:09:
<note> <note>
<title>Release date</title> <title>Release date</title>
<simpara>2005-05-05</simpara> <simpara>2005-05-09</simpara>
</note> </note>
<para> <para>
@ -87,6 +87,17 @@ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
<itemizedlist> <itemizedlist>
<listitem><para>Change encoding function signature to prevent <listitem><para>Change encoding function signature to prevent
misuse</para></listitem> 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> <listitem><para>Fix comparisons of <type>TIME WITH TIME ZONE</> values</para>
<para> <para>
The comparison code was wrong in the case where the The comparison code was wrong in the case where the
@ -1286,7 +1297,7 @@ operations on bytea columns (Joe)</para></listitem>
<note> <note>
<title>Release date</title> <title>Release date</title>
<simpara>2005-05-05</simpara> <simpara>2005-05-09</simpara>
</note> </note>
<para> <para>
@ -1306,6 +1317,17 @@ operations on bytea columns (Joe)</para></listitem>
<title>Changes</title> <title>Changes</title>
<itemizedlist> <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 <listitem><para>Fix <function>EXTRACT(EPOCH)</> for
<type>TIME WITH TIME ZONE</> values</para></listitem> <type>TIME WITH TIME ZONE</> values</para></listitem>
<listitem><para>Additional buffer overrun checks in plpgsql <listitem><para>Additional buffer overrun checks in plpgsql