mirror of
https://github.com/postgres/postgres.git
synced 2025-05-09 18:21:05 +03:00
Update release notes for upcoming re-releases.
This commit is contained in:
parent
1199026e9e
commit
d8c21181ce
@ -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">
|
<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>
|
<note>
|
||||||
<title>Release date</title>
|
<title>Release date</title>
|
||||||
<simpara>2005-05-05</simpara>
|
<simpara>2005-05-09</simpara>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -72,6 +72,17 @@ misuse</para></listitem>
|
|||||||
<type>INTERNAL</> function results</para></listitem>
|
<type>INTERNAL</> function results</para></listitem>
|
||||||
<listitem><para>Guard against incorrect second parameter to
|
<listitem><para>Guard against incorrect second parameter to
|
||||||
<function>record_out</></para></listitem>
|
<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>
|
<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
|
||||||
@ -2684,7 +2695,7 @@ typedefs (Michael)</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>
|
||||||
@ -2795,6 +2806,17 @@ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
|
|||||||
misuse</para></listitem>
|
misuse</para></listitem>
|
||||||
<listitem><para>Change <filename>contrib/tsearch2</> to avoid unsafe use of
|
<listitem><para>Change <filename>contrib/tsearch2</> to avoid unsafe use of
|
||||||
<type>INTERNAL</> function results</para></listitem>
|
<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>
|
<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
|
||||||
@ -5236,7 +5258,7 @@ DROP SCHEMA information_schema CASCADE;
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<title>Release date</title>
|
<title>Release date</title>
|
||||||
<simpara>2005-05-05</simpara>
|
<simpara>2005-05-09</simpara>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -5313,6 +5335,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
|
||||||
@ -6511,7 +6544,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>
|
||||||
@ -6531,6 +6564,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
|
||||||
@ -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>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>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>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>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>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>
|
<listitem><para>Enable partial indexes (Martijn van Oosterhout)</para></listitem>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user