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

Commit 5c40494

Browse files
tglsfdctglsfdc
committed
Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.
1 parent 289bafd commit 5c40494

File tree

4 files changed

+1780
-0
lines changed

4 files changed

+1780
-0
lines changed

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

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

4+
<sect1 id="release-9-3-23">
5+
<title>Release 9.3.23</title>
6+
7+
<formalpara>
8+
<title>Release date:</title>
9+
<para>2018-05-10</para>
10+
</formalpara>
11+
12+
<para>
13+
This release contains a variety of fixes from 9.3.22.
14+
For information about new features in the 9.3 major release, see
15+
<xref linkend="release-9-3">.
16+
</para>
17+
18+
<sect2>
19+
<title>Migration to Version 9.3.23</title>
20+
21+
<para>
22+
A dump/restore is not required for those running 9.3.X.
23+
</para>
24+
25+
<para>
26+
However, if the function marking mistakes mentioned in the first
27+
changelog entry below affect you, you will want to take steps to
28+
correct your database catalogs.
29+
</para>
30+
31+
<para>
32+
Also, if you are upgrading from a version earlier than 9.3.22,
33+
see <xref linkend="release-9-3-22">.
34+
</para>
35+
</sect2>
36+
37+
<sect2>
38+
<title>Changes</title>
39+
40+
<itemizedlist>
41+
42+
<listitem>
43+
<para>
44+
Fix incorrect volatility markings on a few built-in functions
45+
(Thomas Munro, Tom Lane)
46+
</para>
47+
48+
<para>
49+
The functions
50+
<function>query_to_xml</function>,
51+
<function>cursor_to_xml</function>,
52+
<function>cursor_to_xmlschema</function>,
53+
<function>query_to_xmlschema</function>, and
54+
<function>query_to_xml_and_xmlschema</function>
55+
should be marked volatile because they execute user-supplied queries
56+
that might contain volatile operations. They were not, leading to a
57+
risk of incorrect query optimization. This has been repaired for new
58+
installations by correcting the initial catalog data, but existing
59+
installations will continue to contain the incorrect markings.
60+
Practical use of these functions seems to pose little hazard, but in
61+
case of trouble, it can be fixed by manually updating these
62+
functions' <structname>pg_proc</structname> entries. (Note that that
63+
will need to be done in each database of the installation.) Another
64+
option is to <application>pg_upgrade</application> the database to a
65+
version containing the corrected initial data.
66+
</para>
67+
</listitem>
68+
69+
<listitem>
70+
<para>
71+
Avoid re-using TOAST value OIDs that match dead-but-not-yet-vacuumed
72+
TOAST entries (Pavan Deolasee)
73+
</para>
74+
75+
<para>
76+
Once the OID counter has wrapped around, it's possible to assign a
77+
TOAST value whose OID matches a previously deleted entry in the same
78+
TOAST table. If that entry were not yet vacuumed away, this resulted
79+
in <quote>unexpected chunk number 0 (expected 1) for toast
80+
value <replaceable>nnnnn</replaceable></quote> errors, which would
81+
persist until the dead entry was removed
82+
by <command>VACUUM</command>. Fix by not selecting such OIDs when
83+
creating a new TOAST entry.
84+
</para>
85+
</listitem>
86+
87+
<listitem>
88+
<para>
89+
Change <command>ANALYZE</command>'s algorithm for updating
90+
<structname>pg_class</structname>.<structfield>reltuples</structfield>
91+
(David Gould)
92+
</para>
93+
94+
<para>
95+
Previously, pages not actually scanned by <command>ANALYZE</command>
96+
were assumed to retain their old tuple density. In a large table
97+
where <command>ANALYZE</command> samples only a small fraction of the
98+
pages, this meant that the overall tuple density estimate could not
99+
change very much, so that <structfield>reltuples</structfield> would
100+
change nearly proportionally to changes in the table's physical size
101+
(<structfield>relpages</structfield>) regardless of what was actually
102+
happening in the table. This has been observed to result
103+
in <structfield>reltuples</structfield> becoming so much larger than
104+
reality as to effectively shut off autovacuuming. To fix, assume
105+
that <command>ANALYZE</command>'s sample is a statistically unbiased
106+
sample of the table (as it should be), and just extrapolate the
107+
density observed within those pages to the whole table.
108+
</para>
109+
</listitem>
110+
111+
<listitem>
112+
<para>
113+
Fix <literal>UPDATE/DELETE ... WHERE CURRENT OF</literal> to not fail
114+
when the referenced cursor uses an index-only-scan plan (Yugo Nagata,
115+
Tom Lane)
116+
</para>
117+
</listitem>
118+
119+
<listitem>
120+
<para>
121+
Fix incorrect planning of join clauses pushed into parameterized
122+
paths (Andrew Gierth, Tom Lane)
123+
</para>
124+
125+
<para>
126+
This error could result in misclassifying a condition as
127+
a <quote>join filter</quote> for an outer join when it should be a
128+
plain <quote>filter</quote> condition, leading to incorrect join
129+
output.
130+
</para>
131+
</listitem>
132+
133+
<listitem>
134+
<para>
135+
Fix misoptimization of <literal>CHECK</literal> constraints having
136+
provably-NULL subclauses of
137+
top-level <literal>AND</literal>/<literal>OR</literal> conditions
138+
(Tom Lane, Dean Rasheed)
139+
</para>
140+
141+
<para>
142+
This could, for example, allow constraint exclusion to exclude a
143+
child table that should not be excluded from a query.
144+
</para>
145+
</listitem>
146+
147+
<listitem>
148+
<para>
149+
Avoid failure if a query-cancel or session-termination interrupt
150+
occurs while committing a prepared transaction (Stas Kelvich)
151+
</para>
152+
</listitem>
153+
154+
<listitem>
155+
<para>
156+
Fix query-lifespan memory leakage in repeatedly executed hash joins
157+
(Tom Lane)
158+
</para>
159+
</listitem>
160+
161+
<listitem>
162+
<para>
163+
Fix overly strict sanity check
164+
in <function>heap_prepare_freeze_tuple</function>
165+
(&Aacute;lvaro Herrera)
166+
</para>
167+
168+
<para>
169+
This could result in incorrect <quote>cannot freeze committed
170+
xmax</quote> failures in databases that have
171+
been <application>pg_upgrade</application>'d from 9.2 or earlier.
172+
</para>
173+
</listitem>
174+
175+
<listitem>
176+
<para>
177+
Prevent dangling-pointer dereference when a C-coded before-update row
178+
trigger returns the <quote>old</quote> tuple (Rushabh Lathia)
179+
</para>
180+
</listitem>
181+
182+
<listitem>
183+
<para>
184+
Reduce locking during autovacuum worker scheduling (Jeff Janes)
185+
</para>
186+
187+
<para>
188+
The previous behavior caused drastic loss of potential worker
189+
concurrency in databases with many tables.
190+
</para>
191+
</listitem>
192+
193+
<listitem>
194+
<para>
195+
Ensure client hostname is copied while copying
196+
<structname>pg_stat_activity</structname> data to local memory
197+
(Edmund Horner)
198+
</para>
199+
200+
<para>
201+
Previously the supposedly-local snapshot contained a pointer into
202+
shared memory, allowing the client hostname column to change
203+
unexpectedly if any existing session disconnected.
204+
</para>
205+
</listitem>
206+
207+
<listitem>
208+
<para>
209+
Fix incorrect processing of multiple compound affixes
210+
in <literal>ispell</literal> dictionaries (Arthur Zakirov)
211+
</para>
212+
</listitem>
213+
214+
<listitem>
215+
<para>
216+
Fix collation-aware searches (that is, indexscans using inequality
217+
operators) in SP-GiST indexes on text columns (Tom Lane)
218+
</para>
219+
220+
<para>
221+
Such searches would return the wrong set of rows in most non-C
222+
locales.
223+
</para>
224+
</listitem>
225+
226+
<listitem>
227+
<para>
228+
Count the number of index tuples correctly during initial build of an
229+
SP-GiST index (Tomas Vondra)
230+
</para>
231+
232+
<para>
233+
Previously, the tuple count was reported to be the same as that of
234+
the underlying table, which is wrong if the index is partial.
235+
</para>
236+
</listitem>
237+
238+
<listitem>
239+
<para>
240+
Count the number of index tuples correctly during vacuuming of a
241+
GiST index (Andrey Borodin)
242+
</para>
243+
244+
<para>
245+
Previously it reported the estimated number of heap tuples,
246+
which might be inaccurate, and is certainly wrong if the
247+
index is partial.
248+
</para>
249+
</listitem>
250+
251+
<listitem>
252+
<para>
253+
Allow <function>scalarltsel</function>
254+
and <function>scalargtsel</function> to be used on non-core datatypes
255+
(Tomas Vondra)
256+
</para>
257+
</listitem>
258+
259+
<listitem>
260+
<para>
261+
Reduce <application>libpq</application>'s memory consumption when a
262+
server error is reported after a large amount of query output has
263+
been collected (Tom Lane)
264+
</para>
265+
266+
<para>
267+
Discard the previous output before, not after, processing the error
268+
message. On some platforms, notably Linux, this can make a
269+
difference in the application's subsequent memory footprint.
270+
</para>
271+
</listitem>
272+
273+
<listitem>
274+
<para>
275+
Fix double-free crashes in <application>ecpg</application>
276+
(Patrick Krecker, Jeevan Ladhe)
277+
</para>
278+
</listitem>
279+
280+
<listitem>
281+
<para>
282+
Fix <application>ecpg</application> to handle <type>long long
283+
int</type> variables correctly in MSVC builds (Michael Meskes,
284+
Andrew Gierth)
285+
</para>
286+
</listitem>
287+
288+
<listitem>
289+
<para>
290+
Fix mis-quoting of values for list-valued GUC variables in dumps
291+
(Michael Paquier, Tom Lane)
292+
</para>
293+
294+
<para>
295+
The <varname>local_preload_libraries</varname>,
296+
<varname>session_preload_libraries</varname>,
297+
<varname>shared_preload_libraries</varname>,
298+
and <varname>temp_tablespaces</varname> variables were not correctly
299+
quoted in <application>pg_dump</application> output. This would
300+
cause problems if settings for these variables appeared in
301+
<command>CREATE FUNCTION ... SET</command> or <command>ALTER
302+
DATABASE/ROLE ... SET</command> clauses.
303+
</para>
304+
</listitem>
305+
306+
<listitem>
307+
<para>
308+
Fix overflow handling in <application>PL/pgSQL</application>
309+
integer <command>FOR</command> loops (Tom Lane)
310+
</para>
311+
312+
<para>
313+
The previous coding failed to detect overflow of the loop variable
314+
on some non-gcc compilers, leading to an infinite loop.
315+
</para>
316+
</listitem>
317+
318+
<listitem>
319+
<para>
320+
Adjust <application>PL/Python</application> regression tests to pass
321+
under Python 3.7 (Peter Eisentraut)
322+
</para>
323+
</listitem>
324+
325+
<listitem>
326+
<para>
327+
Support testing <application>PL/Python</application> and related
328+
modules when building with Python 3 and MSVC (Andrew Dunstan)
329+
</para>
330+
</listitem>
331+
332+
<listitem>
333+
<para>
334+
Rename internal <function>b64_encode</function>
335+
and <function>b64_decode</function> functions to avoid conflict with
336+
Solaris 11.4 built-in functions (Rainer Orth)
337+
</para>
338+
</listitem>
339+
340+
<listitem>
341+
<para>
342+
Sync our copy of the timezone library with IANA tzcode release 2018e
343+
(Tom Lane)
344+
</para>
345+
346+
<para>
347+
This fixes the <application>zic</application> timezone data compiler
348+
to cope with negative daylight-savings offsets. While
349+
the <productname>PostgreSQL</productname> project will not
350+
immediately ship such timezone data, <application>zic</application>
351+
might be used with timezone data obtained directly from IANA, so it
352+
seems prudent to update <application>zic</application> now.
353+
</para>
354+
</listitem>
355+
356+
<listitem>
357+
<para>
358+
Update time zone data files to <application>tzdata</application>
359+
release 2018d for DST law changes in Palestine and Antarctica (Casey
360+
Station), plus historical corrections for Portugal and its colonies,
361+
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
362+
Uruguay.
363+
</para>
364+
</listitem>
365+
366+
</itemizedlist>
367+
368+
</sect2>
369+
</sect1>
370+
4371
<sect1 id="release-9-3-22">
5372
<title>Release 9.3.22</title>
6373

0 commit comments

Comments
 (0)