mirror of https://github.com/postgres/postgres
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
parent
abdeb3504d
commit
57ec3db267
|
|
@ -1,6 +1,80 @@
|
||||||
<!-- 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-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">
|
<sect1 id="release-9-0-21">
|
||||||
<title>Release 9.0.21</title>
|
<title>Release 9.0.21</title>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,74 @@
|
||||||
<!-- doc/src/sgml/release-9.1.sgml -->
|
<!-- doc/src/sgml/release-9.1.sgml -->
|
||||||
<!-- See header comment in release.sgml about typical markup -->
|
<!-- 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">
|
<sect1 id="release-9-1-17">
|
||||||
<title>Release 9.1.17</title>
|
<title>Release 9.1.17</title>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,74 @@
|
||||||
<!-- doc/src/sgml/release-9.2.sgml -->
|
<!-- doc/src/sgml/release-9.2.sgml -->
|
||||||
<!-- See header comment in release.sgml about typical markup -->
|
<!-- 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">
|
<sect1 id="release-9-2-12">
|
||||||
<title>Release 9.2.12</title>
|
<title>Release 9.2.12</title>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,155 @@
|
||||||
<!-- doc/src/sgml/release-9.3.sgml -->
|
<!-- doc/src/sgml/release-9.3.sgml -->
|
||||||
<!-- See header comment in release.sgml about typical markup -->
|
<!-- 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">
|
<sect1 id="release-9-3-8">
|
||||||
<title>Release 9.3.8</title>
|
<title>Release 9.3.8</title>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,187 @@
|
||||||
<!-- doc/src/sgml/release-9.4.sgml -->
|
<!-- doc/src/sgml/release-9.4.sgml -->
|
||||||
<!-- See header comment in release.sgml about typical markup -->
|
<!-- 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">
|
<sect1 id="release-9-4-3">
|
||||||
<title>Release 9.4.3</title>
|
<title>Release 9.4.3</title>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue