Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
29d44219
Commit
29d44219
authored
Jan 27, 2011
by
Tom Lane
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update release notes for releases 9.0.3, 8.4.7, 8.3.14, and 8.2.20.
parent
1e4baa5c
Changes
4
Hide whitespace changes
Inline
Side-by-side
Showing
4 changed files
with
520 additions
and
0 deletions
+520
-0
doc/src/sgml/release-8.2.sgml
doc/src/sgml/release-8.2.sgml
+119
-0
doc/src/sgml/release-8.3.sgml
doc/src/sgml/release-8.3.sgml
+119
-0
doc/src/sgml/release-8.4.sgml
doc/src/sgml/release-8.4.sgml
+119
-0
doc/src/sgml/release-9.0.sgml
doc/src/sgml/release-9.0.sgml
+163
-0
No files found.
doc/src/sgml/release-8.2.sgml
View file @
29d44219
<!-- doc/src/sgml/release-8.2.sgml -->
<!-- doc/src/sgml/release-8.2.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<!-- 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>... & !(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">
<sect1 id="release-8-2-19">
<title>Release 8.2.19</title>
<title>Release 8.2.19</title>
...
...
doc/src/sgml/release-8.3.sgml
View file @
29d44219
<!-- doc/src/sgml/release-8.3.sgml -->
<!-- doc/src/sgml/release-8.3.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<!-- 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>... & !(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">
<sect1 id="release-8-3-13">
<title>Release 8.3.13</title>
<title>Release 8.3.13</title>
...
...
doc/src/sgml/release-8.4.sgml
View file @
29d44219
<!-- doc/src/sgml/release-8.4.sgml -->
<!-- doc/src/sgml/release-8.4.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<!-- 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>... & !(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">
<sect1 id="release-8-4-6">
<title>Release 8.4.6</title>
<title>Release 8.4.6</title>
...
...
doc/src/sgml/release-9.0.sgml
View file @
29d44219
<!-- doc/src/sgml/release-9.0.sgml -->
<!-- doc/src/sgml/release-9.0.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<!-- 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>... & !(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">
<sect1 id="release-9-0-2">
<title>Release 9.0.2</title>
<title>Release 9.0.2</title>
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment