Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 21187cf

Browse files
tglsfdctglsfdc
committed
First-draft release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22.
1 parent 94232c9 commit 21187cf

File tree

1 file changed

+182
-0
lines changed

1 file changed

+182
-0
lines changed

‎doc/src/sgml/release-9.4.sgml

Lines changed: 182 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,188 @@
11
<!-- doc/src/sgml/release-9.4.sgml -->
22
<!-- See header comment in release.sgml about typical markup -->
33

4+
<sect1 id="release-9-4-4">
5+
<title>Release 9.4.4</title>
6+
7+
<note>
8+
<title>Release Date</title>
9+
<simpara>2015-06-12</simpara>
10+
</note>
11+
12+
<para>
13+
This release contains a small number of fixes from 9.4.3.
14+
For information about new features in the 9.4 major release, see
15+
<xref linkend="release-9-4">.
16+
</para>
17+
18+
<sect2>
19+
<title>Migration to Version 9.4.4</title>
20+
21+
<para>
22+
A dump/restore is not required for those running 9.4.X.
23+
</para>
24+
25+
<para>
26+
However, if you are upgrading an installation that was previously
27+
upgraded using a <application>pg_upgrade</> version between 9.3.0 and
28+
9.3.4 inclusive, see the first changelog entry below.
29+
</para>
30+
31+
<para>
32+
Also, if you are upgrading from a version earlier than 9.4.2,
33+
see <xref linkend="release-9-4-2">.
34+
</para>
35+
</sect2>
36+
37+
<sect2>
38+
<title>Changes</title>
39+
40+
<itemizedlist>
41+
42+
<!--
43+
Author: Robert Haas <rhaas@postgresql.org>
44+
Branch: master [068cfadf9] 2015-06-05 09:31:57 -0400
45+
Branch: REL9_4_STABLE [b6a3444fa] 2015-06-05 09:33:52 -0400
46+
Branch: REL9_3_STABLE [2a9b01928] 2015-06-05 09:34:15 -0400
47+
-->
48+
49+
<listitem>
50+
<para>
51+
Fix possible failure to recover from an inconsistent database state
52+
(Robert Haas)
53+
</para>
54+
55+
<para>
56+
Recent <productname>PostgreSQL</> releases introduced mechanisms to
57+
protect against multixact wraparound, but some of that code did not
58+
account for the possibility that it would need to run during crash
59+
recovery, when the database may not be in a consistent state. This
60+
could result in failure to restart after a crash, or failure to start
61+
up a secondary server. The lingering effects of a previously-fixed
62+
bug in <application>pg_upgrade</> could also cause such a failure, in
63+
installations that had used <application>pg_upgrade</> versions
64+
between 9.3.0 and 9.3.4.
65+
</para>
66+
67+
<para>
68+
The <application>pg_upgrade</> bug in question was that it would
69+
set <literal>oldestMultiXid</> to 1 in <filename>pg_control</> even
70+
if the true value should be higher. With the fixes introduced in
71+
this release, such a situation will result in immediate emergency
72+
autovacuuming until a correct <literal>oldestMultiXid</> value can
73+
be determined. Users can avoid that by doing manual
74+
vacuuming <emphasis>before</> upgrading to this release.
75+
In detail:
76+
77+
<orderedlist>
78+
<listitem>
79+
<para>
80+
Check whether <application>pg_controldata</> reports <quote>Latest
81+
checkpoint's oldestMultiXid</> to be 1. If not, there's nothing
82+
to do.
83+
</para>
84+
</listitem>
85+
<listitem>
86+
<para>
87+
Look in <filename>PGDATA/pg_multixact/offsets</> to see if there's a
88+
file named <filename>0000</>. If there is, there's nothing to do.
89+
</para>
90+
</listitem>
91+
<listitem>
92+
<para>
93+
Otherwise, for each table that has
94+
<structname>pg_class</>.<structfield>relminmxid</> equal to 1,
95+
<command>VACUUM</> that table with
96+
both <xref linkend="guc-vacuum-multixact-freeze-min-age">
97+
and <xref linkend="guc-vacuum-multixact-freeze-table-age"> set to
98+
zero. (You can use the vacuum cost delay parameters described
99+
in <xref linkend="runtime-config-resource-vacuum-cost"> to reduce
100+
the performance consequences for concurrent sessions.) You must
101+
use <productname>PostgreSQL</> 9.3.5 or later to perform this step.
102+
</para>
103+
</listitem>
104+
</orderedlist>
105+
</para>
106+
</listitem>
107+
108+
<!--
109+
Author: Tom Lane <tgl@sss.pgh.pa.us>
110+
Branch: master [f3b5565dd] 2015-06-07 15:32:09 -0400
111+
Branch: REL9_4_STABLE [be25a08a9] 2015-06-07 15:32:09 -0400
112+
Branch: REL9_3_STABLE [4f2458dd7] 2015-06-07 15:32:09 -0400
113+
Branch: REL9_2_STABLE [3e69a73b9] 2015-06-07 15:32:09 -0400
114+
Branch: REL9_1_STABLE [e06e56212] 2015-06-07 15:32:09 -0400
115+
Branch: REL9_0_STABLE [2fe1939b0] 2015-06-07 15:32:09 -0400
116+
-->
117+
118+
<listitem>
119+
<para>
120+
Fix rare failure to invalidate relation cache init file (Tom Lane)
121+
</para>
122+
123+
<para>
124+
With just the wrong timing of concurrent activity, a <command>VACUUM
125+
FULL</> on a system catalog might fail to update the <quote>init file</>
126+
that's used to avoid cache-loading work for new sessions. This would
127+
result in later sessions being unable to access that catalog at all.
128+
This is a very ancient bug, but it's so hard to trigger that no
129+
reproducible case had been seen until recently.
130+
</para>
131+
</listitem>
132+
133+
<!--
134+
Author: Tom Lane <tgl@sss.pgh.pa.us>
135+
Branch: master [ac23b711d] 2015-06-05 13:22:27 -0400
136+
Branch: REL9_4_STABLE [247263dc3] 2015-06-05 13:22:27 -0400
137+
Branch: REL9_3_STABLE [ac86eda63] 2015-06-05 13:22:27 -0400
138+
Branch: REL9_2_STABLE [04358dab2] 2015-06-05 13:22:27 -0400
139+
Branch: REL9_1_STABLE [002e7d144] 2015-06-05 13:22:27 -0400
140+
Branch: REL9_0_STABLE [dbd99c7f0] 2015-06-05 13:22:27 -0400
141+
-->
142+
143+
<listitem>
144+
<para>
145+
Avoid deadlock between incoming sessions and <literal>CREATE/DROP
146+
DATABASE</> (Tom Lane)
147+
</para>
148+
149+
<para>
150+
A new session starting in a database that is the target of
151+
a <command>DROP DATABASE</> command, or is the template for
152+
a <command>CREATE DATABASE</> command, could cause the command to wait
153+
for five seconds and then fail, even if the new session would have
154+
exited before that.
155+
</para>
156+
</listitem>
157+
158+
<!--
159+
Author: Tom Lane <tgl@sss.pgh.pa.us>
160+
Branch: master [3f59be836] 2015-06-03 11:59:10 -0400
161+
Branch: REL9_4_STABLE [f0a8515c4] 2015-06-03 11:58:47 -0400
162+
Branch: REL9_3_STABLE [d3fdec6ae] 2015-06-03 11:58:47 -0400
163+
-->
164+
165+
<listitem>
166+
<para>
167+
Improve planner's cost estimates for semi-joins and anti-joins with
168+
inner indexscans (Tom Lane, Tomas Vondra)
169+
</para>
170+
171+
<para>
172+
This type of plan is quite cheap when all the join clauses are used
173+
as index scan conditions, even if the inner scan would nominally
174+
fetch many rows, because the executor will stop after obtaining one
175+
row. The planner only partially accounted for that effect, and would
176+
therefore overestimate the cost, leading it to possibly choose some
177+
other much less efficient plan type.
178+
</para>
179+
</listitem>
180+
181+
</itemizedlist>
182+
183+
</sect2>
184+
</sect1>
185+
4186
<sect1 id="release-9-4-3">
5187
<title>Release 9.4.3</title>
6188

0 commit comments

Comments
 (0)