mirrors
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22.

This commit is contained in:
Tom Lane 2015-06-09 14:33:43 -04:00
parent abdeb3504d
commit 57ec3db267
5 changed files with 540 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
doc/src/sgml/release-9.0.sgml
View File

@ -1,6 +1,80 @@
<!-- doc/src/sgml/release-9.0.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-0-22">
<title>Release 9.0.22</title>
<note>
<title>Release Date</title>
<simpara>2015-06-12</simpara>
</note>
<para>
This release contains a small number of fixes from 9.0.21.
For information about new features in the 9.0 major release, see
<xref linkend="release-9-0">.
</para>
<para>
The <productname>PostgreSQL</> community will stop releasing updates
for the 9.0.X release series in September 2015.
Users are encouraged to update to a newer release branch soon.
</para>
<sect2>
<title>Migration to Version 9.0.22</title>
<para>
A dump/restore is not required for those running 9.0.X.
</para>
<para>
However, if you are upgrading from a version earlier than 9.0.18,
see <xref linkend="release-9-0-18">.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix rare failure to invalidate relation cache init file (Tom Lane)
</para>
<para>
With just the wrong timing of concurrent activity, a <command>VACUUM
FULL</> on a system catalog might fail to update the <quote>init file</>
that's used to avoid cache-loading work for new sessions. This would
result in later sessions being unable to access that catalog at all.
This is a very ancient bug, but it's so hard to trigger that no
reproducible case had been seen until recently.
</para>
</listitem>
<listitem>
<para>
Avoid deadlock between incoming sessions and <literal>CREATE/DROP
DATABASE</> (Tom Lane)
</para>
<para>
A new session starting in a database that is the target of
a <command>DROP DATABASE</> command, or is the template for
a <command>CREATE DATABASE</> command, could cause the command to wait
for five seconds and then fail, even if the new session would have
exited before that.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-0-21">
<title>Release 9.0.21</title>

68
doc/src/sgml/release-9.1.sgml
View File

@ -1,6 +1,74 @@
<!-- doc/src/sgml/release-9.1.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-1-18">
<title>Release 9.1.18</title>
<note>
<title>Release Date</title>
<simpara>2015-06-12</simpara>
</note>
<para>
This release contains a small number of fixes from 9.1.17.
For information about new features in the 9.1 major release, see
<xref linkend="release-9-1">.
</para>
<sect2>
<title>Migration to Version 9.1.18</title>
<para>
A dump/restore is not required for those running 9.1.X.
</para>
<para>
However, if you are upgrading from a version earlier than 9.1.16,
see <xref linkend="release-9-1-16">.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix rare failure to invalidate relation cache init file (Tom Lane)
</para>
<para>
With just the wrong timing of concurrent activity, a <command>VACUUM
FULL</> on a system catalog might fail to update the <quote>init file</>
that's used to avoid cache-loading work for new sessions. This would
result in later sessions being unable to access that catalog at all.
This is a very ancient bug, but it's so hard to trigger that no
reproducible case had been seen until recently.
</para>
</listitem>
<listitem>
<para>
Avoid deadlock between incoming sessions and <literal>CREATE/DROP
DATABASE</> (Tom Lane)
</para>
<para>
A new session starting in a database that is the target of
a <command>DROP DATABASE</> command, or is the template for
a <command>CREATE DATABASE</> command, could cause the command to wait
for five seconds and then fail, even if the new session would have
exited before that.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-1-17">
<title>Release 9.1.17</title>

68
doc/src/sgml/release-9.2.sgml
View File

@ -1,6 +1,74 @@
<!-- doc/src/sgml/release-9.2.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-2-13">
<title>Release 9.2.13</title>
<note>
<title>Release Date</title>
<simpara>2015-06-12</simpara>
</note>
<para>
This release contains a small number of fixes from 9.2.12.
For information about new features in the 9.2 major release, see
<xref linkend="release-9-2">.
</para>
<sect2>
<title>Migration to Version 9.2.13</title>
<para>
A dump/restore is not required for those running 9.2.X.
</para>
<para>
However, if you are upgrading from a version earlier than 9.2.11,
see <xref linkend="release-9-2-11">.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix rare failure to invalidate relation cache init file (Tom Lane)
</para>
<para>
With just the wrong timing of concurrent activity, a <command>VACUUM
FULL</> on a system catalog might fail to update the <quote>init file</>
that's used to avoid cache-loading work for new sessions. This would
result in later sessions being unable to access that catalog at all.
This is a very ancient bug, but it's so hard to trigger that no
reproducible case had been seen until recently.
</para>
</listitem>
<listitem>
<para>
Avoid deadlock between incoming sessions and <literal>CREATE/DROP
DATABASE</> (Tom Lane)
</para>
<para>
A new session starting in a database that is the target of
a <command>DROP DATABASE</> command, or is the template for
a <command>CREATE DATABASE</> command, could cause the command to wait
for five seconds and then fail, even if the new session would have
exited before that.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-2-12">
<title>Release 9.2.12</title>

149
doc/src/sgml/release-9.3.sgml
View File

@ -1,6 +1,155 @@
<!-- doc/src/sgml/release-9.3.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-3-9">
<title>Release 9.3.9</title>
<note>
<title>Release Date</title>
<simpara>2015-06-12</simpara>
</note>
<para>
This release contains a small number of fixes from 9.3.8.
For information about new features in the 9.3 major release, see
<xref linkend="release-9-3">.
</para>
<sect2>
<title>Migration to Version 9.3.9</title>
<para>
A dump/restore is not required for those running 9.3.X.
</para>
<para>
However, if you are upgrading an installation that was previously
upgraded using a <application>pg_upgrade</> version between 9.3.0 and
9.3.4 inclusive, see the first changelog entry below.
</para>
<para>
Also, if you are upgrading from a version earlier than 9.3.7,
see <xref linkend="release-9-3-7">.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix possible failure to recover from an inconsistent database state
(Robert Haas)
</para>
<para>
Recent <productname>PostgreSQL</> releases introduced mechanisms to
protect against multixact wraparound, but some of that code did not
account for the possibility that it would need to run during crash
recovery, when the database may not be in a consistent state. This
could result in failure to restart after a crash, or failure to start
up a secondary server. The lingering effects of a previously-fixed
bug in <application>pg_upgrade</> could also cause such a failure, in
installations that had used <application>pg_upgrade</> versions
between 9.3.0 and 9.3.4.
</para>
<para>
The <application>pg_upgrade</> bug in question was that it would
set <literal>oldestMultiXid</> to 1 in <filename>pg_control</> even
if the true value should be higher. With the fixes introduced in
this release, such a situation will result in immediate emergency
autovacuuming until a correct <literal>oldestMultiXid</> value can be
determined. If that would pose a hardship, users can avoid it by
doing manual vacuuming <emphasis>before</> upgrading to this release.
In detail:
<orderedlist>
<listitem>
<para>
Check whether <application>pg_controldata</> reports <quote>Latest
checkpoint's oldestMultiXid</> to be 1. If not, there's nothing
to do.
</para>
</listitem>
<listitem>
<para>
Look in <filename>PGDATA/pg_multixact/offsets</> to see if there's a
file named <filename>0000</>. If there is, there's nothing to do.
</para>
</listitem>
<listitem>
<para>
Otherwise, for each table that has
<structname>pg_class</>.<structfield>relminmxid</> equal to 1,
<command>VACUUM</> that table with
both <xref linkend="guc-vacuum-multixact-freeze-min-age">
and <xref linkend="guc-vacuum-multixact-freeze-table-age"> set to
zero. (You can use the vacuum cost delay parameters described
in <xref linkend="runtime-config-resource-vacuum-cost"> to reduce
the performance consequences for concurrent sessions.) You must
use <productname>PostgreSQL</> 9.3.5 or later to perform this step.
</para>
</listitem>
</orderedlist>
</para>
</listitem>
<listitem>
<para>
Fix rare failure to invalidate relation cache init file (Tom Lane)
</para>
<para>
With just the wrong timing of concurrent activity, a <command>VACUUM
FULL</> on a system catalog might fail to update the <quote>init file</>
that's used to avoid cache-loading work for new sessions. This would
result in later sessions being unable to access that catalog at all.
This is a very ancient bug, but it's so hard to trigger that no
reproducible case had been seen until recently.
</para>
</listitem>
<listitem>
<para>
Avoid deadlock between incoming sessions and <literal>CREATE/DROP
DATABASE</> (Tom Lane)
</para>
<para>
A new session starting in a database that is the target of
a <command>DROP DATABASE</> command, or is the template for
a <command>CREATE DATABASE</> command, could cause the command to wait
for five seconds and then fail, even if the new session would have
exited before that.
</para>
</listitem>
<listitem>
<para>
Improve planner's cost estimates for semi-joins and anti-joins with
inner indexscans (Tom Lane, Tomas Vondra)
</para>
<para>
This type of plan is quite cheap when all the join clauses are used
as index scan conditions, even if the inner scan would nominally
fetch many rows, because the executor will stop after obtaining one
row. The planner only partially accounted for that effect, and would
therefore overestimate the cost, leading it to possibly choose some
other much less efficient plan type.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-3-8">
<title>Release 9.3.8</title>

181
doc/src/sgml/release-9.4.sgml
View File

@ -1,6 +1,187 @@
<!-- doc/src/sgml/release-9.4.sgml -->
<!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-4-4">
<title>Release 9.4.4</title>
<note>
<title>Release Date</title>
<simpara>2015-06-12</simpara>
</note>
<para>
This release contains a small number of fixes from 9.4.3.
For information about new features in the 9.4 major release, see
<xref linkend="release-9-4">.
</para>
<sect2>
<title>Migration to Version 9.4.4</title>
<para>
A dump/restore is not required for those running 9.4.X.
</para>
<para>
However, if you are upgrading an installation that was previously
upgraded using a <application>pg_upgrade</> version between 9.3.0 and
9.3.4 inclusive, see the first changelog entry below.
</para>
<para>
Also, if you are upgrading from a version earlier than 9.4.2,
see <xref linkend="release-9-4-2">.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<!--
Author: Robert Haas <rhaas@postgresql.org>
Branch: master [068cfadf9] 2015-06-05 09:31:57 -0400
Branch: REL9_4_STABLE [b6a3444fa] 2015-06-05 09:33:52 -0400
Branch: REL9_3_STABLE [2a9b01928] 2015-06-05 09:34:15 -0400
-->
<listitem>
<para>
Fix possible failure to recover from an inconsistent database state
(Robert Haas)
</para>
<para>
Recent <productname>PostgreSQL</> releases introduced mechanisms to
protect against multixact wraparound, but some of that code did not
account for the possibility that it would need to run during crash
recovery, when the database may not be in a consistent state. This
could result in failure to restart after a crash, or failure to start
up a secondary server. The lingering effects of a previously-fixed
bug in <application>pg_upgrade</> could also cause such a failure, in
installations that had used <application>pg_upgrade</> versions
between 9.3.0 and 9.3.4.
</para>
<para>
The <application>pg_upgrade</> bug in question was that it would
set <literal>oldestMultiXid</> to 1 in <filename>pg_control</> even
if the true value should be higher. With the fixes introduced in
this release, such a situation will result in immediate emergency
autovacuuming until a correct <literal>oldestMultiXid</> value can
be determined. If that would pose a hardship, users can avoid it by
doing manual vacuuming <emphasis>before</> upgrading to this release.
In detail:
<orderedlist>
<listitem>
<para>
Check whether <application>pg_controldata</> reports <quote>Latest
checkpoint's oldestMultiXid</> to be 1. If not, there's nothing
to do.
</para>
</listitem>
<listitem>
<para>
Look in <filename>PGDATA/pg_multixact/offsets</> to see if there's a
file named <filename>0000</>. If there is, there's nothing to do.
</para>
</listitem>
<listitem>
<para>
Otherwise, for each table that has
<structname>pg_class</>.<structfield>relminmxid</> equal to 1,
<command>VACUUM</> that table with
both <xref linkend="guc-vacuum-multixact-freeze-min-age">
and <xref linkend="guc-vacuum-multixact-freeze-table-age"> set to
zero. (You can use the vacuum cost delay parameters described
in <xref linkend="runtime-config-resource-vacuum-cost"> to reduce
the performance consequences for concurrent sessions.)
</para>
</listitem>
</orderedlist>
</para>
</listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [f3b5565dd] 2015-06-07 15:32:09 -0400
Branch: REL9_4_STABLE [be25a08a9] 2015-06-07 15:32:09 -0400
Branch: REL9_3_STABLE [4f2458dd7] 2015-06-07 15:32:09 -0400
Branch: REL9_2_STABLE [3e69a73b9] 2015-06-07 15:32:09 -0400
Branch: REL9_1_STABLE [e06e56212] 2015-06-07 15:32:09 -0400
Branch: REL9_0_STABLE [2fe1939b0] 2015-06-07 15:32:09 -0400
-->
<listitem>
<para>
Fix rare failure to invalidate relation cache init file (Tom Lane)
</para>
<para>
With just the wrong timing of concurrent activity, a <command>VACUUM
FULL</> on a system catalog might fail to update the <quote>init file</>
that's used to avoid cache-loading work for new sessions. This would
result in later sessions being unable to access that catalog at all.
This is a very ancient bug, but it's so hard to trigger that no
reproducible case had been seen until recently.
</para>
</listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [ac23b711d] 2015-06-05 13:22:27 -0400
Branch: REL9_4_STABLE [247263dc3] 2015-06-05 13:22:27 -0400
Branch: REL9_3_STABLE [ac86eda63] 2015-06-05 13:22:27 -0400
Branch: REL9_2_STABLE [04358dab2] 2015-06-05 13:22:27 -0400
Branch: REL9_1_STABLE [002e7d144] 2015-06-05 13:22:27 -0400
Branch: REL9_0_STABLE [dbd99c7f0] 2015-06-05 13:22:27 -0400
-->
<listitem>
<para>
Avoid deadlock between incoming sessions and <literal>CREATE/DROP
DATABASE</> (Tom Lane)
</para>
<para>
A new session starting in a database that is the target of
a <command>DROP DATABASE</> command, or is the template for
a <command>CREATE DATABASE</> command, could cause the command to wait
for five seconds and then fail, even if the new session would have
exited before that.
</para>
</listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [3f59be836] 2015-06-03 11:59:10 -0400
Branch: REL9_4_STABLE [f0a8515c4] 2015-06-03 11:58:47 -0400
Branch: REL9_3_STABLE [d3fdec6ae] 2015-06-03 11:58:47 -0400
-->
<listitem>
<para>
Improve planner's cost estimates for semi-joins and anti-joins with
inner indexscans (Tom Lane, Tomas Vondra)
</para>
<para>
This type of plan is quite cheap when all the join clauses are used
as index scan conditions, even if the inner scan would nominally
fetch many rows, because the executor will stop after obtaining one
row. The planner only partially accounted for that effect, and would
therefore overestimate the cost, leading it to possibly choose some
other much less efficient plan type.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-4-3">
<title>Release 9.4.3</title>