OSDN Git Service

Update release notes for releases 9.0.3, 8.4.7, 8.3.14, and 8.2.20.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Jan 2011 21:09:39 +0000 (16:09 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Jan 2011 21:09:39 +0000 (16:09 -0500)
doc/src/sgml/release-8.2.sgml
doc/src/sgml/release-8.3.sgml
doc/src/sgml/release-8.4.sgml
doc/src/sgml/release-9.0.sgml

index 195f8c9..dd82ee6 100644 (file)
@@ -1,6 +1,125 @@
 <!-- doc/src/sgml/release-8.2.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-8-2-20">
+  <title>Release 8.2.20</title>
+
+  <note>
+  <title>Release date</title>
+  <simpara>2011-01-31</simpara>
+  </note>
+
+  <para>
+   This release contains a variety of fixes from 8.2.19.
+   For information about new features in the 8.2 major release, see
+   <xref linkend="release-8-2">.
+  </para>
+
+  <sect2>
+   <title>Migration to Version 8.2.20</title>
+
+   <para>
+    A dump/restore is not required for those running 8.2.X.
+    However, if you are upgrading from a version earlier than 8.2.14,
+    see the release notes for 8.2.14.
+   </para>
+
+  </sect2>
+
+  <sect2>
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+     <para>
+      Avoid failures when <command>EXPLAIN</> tries to display a simple-form
+      <literal>CASE</> expression (Tom Lane)
+     </para>
+
+     <para>
+      If the <literal>CASE</>'s test expression was a constant, the planner
+      could simplify the <literal>CASE</> into a form that confused the
+      expression-display code, resulting in <quote>unexpected CASE WHEN
+      clause</> errors.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix assignment to an array slice that is before the existing range
+      of subscripts (Tom Lane)
+     </para>
+
+     <para>
+      If there was a gap between the newly added subscripts and the first
+      pre-existing subscript, the code miscalculated how many entries needed
+      to be copied from the old array's null bitmap, potentially leading to
+      data corruption or crash.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid unexpected conversion overflow in planner for very distant date
+      values (Tom Lane)
+     </para>
+
+     <para>
+      The <type>date</> type supports a wider range of dates than can be
+      represented by the <type>timestamp</> types, but the planner assumed it
+      could always convert a date to timestamp with impunity.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix <application>pg_restore</>'s text output for large objects (BLOBs)
+      when <varname>standard_conforming_strings</> is on (Tom Lane)
+     </para>
+
+     <para>
+      Although restoring directly to a database worked correctly, string
+      escaping was incorrect if <application>pg_restore</> was asked for
+      SQL text output and <varname>standard_conforming_strings</> had been
+      enabled in the source database.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix erroneous parsing of <type>tsquery</> values containing
+      <literal>... &amp; !(subexpression) | ...</literal> (Tom Lane)
+     </para>
+
+     <para>
+      Queries containing this combination of operators were not executed
+      correctly.  The same error existed in <filename>contrib/intarray</>'s
+      <type>query_int</> type and <filename>contrib/ltree</>'s
+      <type>ltxtquery</> type.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix bug in <filename>contrib/seg</>'s GiST picksplit algorithm
+      (Alexander Korotkov)
+     </para>
+
+     <para>
+      This could result in considerable inefficiency, though not actually
+      incorrect answers, in a GiST index on a <type>seg</> column.
+      If you have such an index, consider <command>REINDEX</>ing it after
+      installing this update.  (This is identical to the bug that was fixed in
+      <filename>contrib/cube</> in the previous update.)
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-8-2-19">
   <title>Release 8.2.19</title>
 
index 877e2ad..5d691a4 100644 (file)
@@ -1,6 +1,125 @@
 <!-- doc/src/sgml/release-8.3.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-8-3-14">
+  <title>Release 8.3.14</title>
+
+  <note>
+  <title>Release date</title>
+  <simpara>2011-01-31</simpara>
+  </note>
+
+  <para>
+   This release contains a variety of fixes from 8.3.13.
+   For information about new features in the 8.3 major release, see
+   <xref linkend="release-8-3">.
+  </para>
+
+  <sect2>
+   <title>Migration to Version 8.3.14</title>
+
+   <para>
+    A dump/restore is not required for those running 8.3.X.
+    However, if you are upgrading from a version earlier than 8.3.8,
+    see the release notes for 8.3.8.
+   </para>
+
+  </sect2>
+
+  <sect2>
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+     <para>
+      Avoid failures when <command>EXPLAIN</> tries to display a simple-form
+      <literal>CASE</> expression (Tom Lane)
+     </para>
+
+     <para>
+      If the <literal>CASE</>'s test expression was a constant, the planner
+      could simplify the <literal>CASE</> into a form that confused the
+      expression-display code, resulting in <quote>unexpected CASE WHEN
+      clause</> errors.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix assignment to an array slice that is before the existing range
+      of subscripts (Tom Lane)
+     </para>
+
+     <para>
+      If there was a gap between the newly added subscripts and the first
+      pre-existing subscript, the code miscalculated how many entries needed
+      to be copied from the old array's null bitmap, potentially leading to
+      data corruption or crash.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid unexpected conversion overflow in planner for very distant date
+      values (Tom Lane)
+     </para>
+
+     <para>
+      The <type>date</> type supports a wider range of dates than can be
+      represented by the <type>timestamp</> types, but the planner assumed it
+      could always convert a date to timestamp with impunity.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix <application>pg_restore</>'s text output for large objects (BLOBs)
+      when <varname>standard_conforming_strings</> is on (Tom Lane)
+     </para>
+
+     <para>
+      Although restoring directly to a database worked correctly, string
+      escaping was incorrect if <application>pg_restore</> was asked for
+      SQL text output and <varname>standard_conforming_strings</> had been
+      enabled in the source database.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix erroneous parsing of <type>tsquery</> values containing
+      <literal>... &amp; !(subexpression) | ...</literal> (Tom Lane)
+     </para>
+
+     <para>
+      Queries containing this combination of operators were not executed
+      correctly.  The same error existed in <filename>contrib/intarray</>'s
+      <type>query_int</> type and <filename>contrib/ltree</>'s
+      <type>ltxtquery</> type.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix bug in <filename>contrib/seg</>'s GiST picksplit algorithm
+      (Alexander Korotkov)
+     </para>
+
+     <para>
+      This could result in considerable inefficiency, though not actually
+      incorrect answers, in a GiST index on a <type>seg</> column.
+      If you have such an index, consider <command>REINDEX</>ing it after
+      installing this update.  (This is identical to the bug that was fixed in
+      <filename>contrib/cube</> in the previous update.)
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-8-3-13">
   <title>Release 8.3.13</title>
 
index 37be232..8d00a55 100644 (file)
@@ -1,6 +1,125 @@
 <!-- doc/src/sgml/release-8.4.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-8-4-7">
+  <title>Release 8.4.7</title>
+
+  <note>
+  <title>Release date</title>
+  <simpara>2011-01-31</simpara>
+  </note>
+
+  <para>
+   This release contains a variety of fixes from 8.4.6.
+   For information about new features in the 8.4 major release, see
+   <xref linkend="release-8-4">.
+  </para>
+
+  <sect2>
+   <title>Migration to Version 8.4.7</title>
+
+   <para>
+    A dump/restore is not required for those running 8.4.X.
+    However, if you are upgrading from a version earlier than 8.4.2,
+    see the release notes for 8.4.2.
+   </para>
+
+  </sect2>
+
+  <sect2>
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+     <para>
+      Avoid failures when <command>EXPLAIN</> tries to display a simple-form
+      <literal>CASE</> expression (Tom Lane)
+     </para>
+
+     <para>
+      If the <literal>CASE</>'s test expression was a constant, the planner
+      could simplify the <literal>CASE</> into a form that confused the
+      expression-display code, resulting in <quote>unexpected CASE WHEN
+      clause</> errors.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix assignment to an array slice that is before the existing range
+      of subscripts (Tom Lane)
+     </para>
+
+     <para>
+      If there was a gap between the newly added subscripts and the first
+      pre-existing subscript, the code miscalculated how many entries needed
+      to be copied from the old array's null bitmap, potentially leading to
+      data corruption or crash.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid unexpected conversion overflow in planner for very distant date
+      values (Tom Lane)
+     </para>
+
+     <para>
+      The <type>date</> type supports a wider range of dates than can be
+      represented by the <type>timestamp</> types, but the planner assumed it
+      could always convert a date to timestamp with impunity.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix <application>pg_restore</>'s text output for large objects (BLOBs)
+      when <varname>standard_conforming_strings</> is on (Tom Lane)
+     </para>
+
+     <para>
+      Although restoring directly to a database worked correctly, string
+      escaping was incorrect if <application>pg_restore</> was asked for
+      SQL text output and <varname>standard_conforming_strings</> had been
+      enabled in the source database.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix erroneous parsing of <type>tsquery</> values containing
+      <literal>... &amp; !(subexpression) | ...</literal> (Tom Lane)
+     </para>
+
+     <para>
+      Queries containing this combination of operators were not executed
+      correctly.  The same error existed in <filename>contrib/intarray</>'s
+      <type>query_int</> type and <filename>contrib/ltree</>'s
+      <type>ltxtquery</> type.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix bug in <filename>contrib/seg</>'s GiST picksplit algorithm
+      (Alexander Korotkov)
+     </para>
+
+     <para>
+      This could result in considerable inefficiency, though not actually
+      incorrect answers, in a GiST index on a <type>seg</> column.
+      If you have such an index, consider <command>REINDEX</>ing it after
+      installing this update.  (This is identical to the bug that was fixed in
+      <filename>contrib/cube</> in the previous update.)
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-8-4-6">
   <title>Release 8.4.6</title>
 
index 4df8678..482f628 100644 (file)
@@ -1,6 +1,169 @@
 <!-- doc/src/sgml/release-9.0.sgml -->
 <!-- See header comment in release.sgml about typical markup -->
 
+ <sect1 id="release-9-0-3">
+  <title>Release 9.0.3</title>
+
+  <note>
+  <title>Release date</title>
+  <simpara>2011-01-31</simpara>
+  </note>
+
+  <para>
+   This release contains a variety of fixes from 9.0.2.
+   For information about new features in the 9.0 major release, see
+   <xref linkend="release-9-0">.
+  </para>
+
+  <sect2>
+   <title>Migration to Version 9.0.3</title>
+
+   <para>
+    A dump/restore is not required for those running 9.0.X.
+   </para>
+
+  </sect2>
+
+  <sect2>
+   <title>Changes</title>
+
+   <itemizedlist>
+
+    <listitem>
+     <para>
+      Before exiting <application>walreceiver</>, ensure all the received WAL
+      is fsync'd to disk (Heikki Linnakangas)
+     </para>
+
+     <para>
+      Otherwise the standby server could replay some un-synced WAL, conceivably
+      leading to data corruption if the system crashes just at that point.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid excess fsync activity in <application>walreceiver</>
+      (Heikki Linnakangas)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Make <command>ALTER TABLE</> revalidate uniqueness and exclusion
+      constraints when needed (Noah Misch)
+     </para>
+
+     <para>
+      This was broken in 9.0 by a change that was intended to suppress
+      revalidation during <command>VACUUM FULL</> and <command>CLUSTER</>,
+      but unintentionally affected <command>ALTER TABLE</> as well.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix EvalPlanQual for <command>UPDATE</> of an inheritance tree in which
+      the tables are not all alike (Tom Lane)
+     </para>
+
+     <para>
+      Any variation in the table row types (including dropped columns present
+      in only some child tables) would confuse the EvalPlanQual code, leading
+      to misbehavior or even crashes.  Since EvalPlanQual is only executed
+      during concurrent updates to the same row, the problem was only seen
+      intermittently.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid failures when <command>EXPLAIN</> tries to display a simple-form
+      <literal>CASE</> expression (Tom Lane)
+     </para>
+
+     <para>
+      If the <literal>CASE</>'s test expression was a constant, the planner
+      could simplify the <literal>CASE</> into a form that confused the
+      expression-display code, resulting in <quote>unexpected CASE WHEN
+      clause</> errors.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix assignment to an array slice that is before the existing range
+      of subscripts (Tom Lane)
+     </para>
+
+     <para>
+      If there was a gap between the newly added subscripts and the first
+      pre-existing subscript, the code miscalculated how many entries needed
+      to be copied from the old array's null bitmap, potentially leading to
+      data corruption or crash.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Avoid unexpected conversion overflow in planner for very distant date
+      values (Tom Lane)
+     </para>
+
+     <para>
+      The <type>date</> type supports a wider range of dates than can be
+      represented by the <type>timestamp</> types, but the planner assumed it
+      could always convert a date to timestamp with impunity.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix PL/Python crash when an array contains null entries (Alex Hunsaker)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Remove <application>ecpg</>'s fixed length limit for constants defining
+      an array dimension (Michael Meskes)
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix erroneous parsing of <type>tsquery</> values containing
+      <literal>... &amp; !(subexpression) | ...</literal> (Tom Lane)
+     </para>
+
+     <para>
+      Queries containing this combination of operators were not executed
+      correctly.  The same error existed in <filename>contrib/intarray</>'s
+      <type>query_int</> type and <filename>contrib/ltree</>'s
+      <type>ltxtquery</> type.
+     </para>
+    </listitem>
+
+    <listitem>
+     <para>
+      Fix bug in <filename>contrib/seg</>'s GiST picksplit algorithm
+      (Alexander Korotkov)
+     </para>
+
+     <para>
+      This could result in considerable inefficiency, though not actually
+      incorrect answers, in a GiST index on a <type>seg</> column.
+      If you have such an index, consider <command>REINDEX</>ing it after
+      installing this update.  (This is identical to the bug that was fixed in
+      <filename>contrib/cube</> in the previous update.)
+     </para>
+    </listitem>
+
+   </itemizedlist>
+
+  </sect2>
+ </sect1>
+
  <sect1 id="release-9-0-2">
   <title>Release 9.0.2</title>