Skip to content

P
Postgres FD Implementation
Commit 2667e019 authored by Tom Lane's avatar Tom Lane
Browse files
Options

Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.

parent 2b9bdda7
Show whitespace changes
Inline Side-by-side
Showing with 1830 additions and 40 deletions
doc/src/sgml/release-10.sgml
View file @ 2667e019
...@@ -497,7 +497,7 @@ Branch: REL_10_STABLE [76ec45756] 2018-03-02 17:40:48 -0500 ...@@ -497,7 +497,7 @@ Branch: REL_10_STABLE [76ec45756] 2018-03-02 17:40:48 -0500
Branch: REL9_6_STABLE [96d2df840] 2018-03-02 17:40:48 -0500 Branch: REL9_6_STABLE [96d2df840] 2018-03-02 17:40:48 -0500
--> -->
<para> <para>
Fix possible leak or double-free of visibility map buffer pins Fix possible leak or double free of visibility map buffer pins
(Amit Kapila) (Amit Kapila)
</para> </para>
</listitem> </listitem>
...@@ -516,7 +516,7 @@ Branch: REL9_6_STABLE [3a11485a5] 2018-05-04 18:23:30 -0300 ...@@ -516,7 +516,7 @@ Branch: REL9_6_STABLE [3a11485a5] 2018-05-04 18:23:30 -0300
<para> <para>
This could happen if some tuples were locked (but not deleted). While This could happen if some tuples were locked (but not deleted). While
queries would still function correctly, vacuum would generally ignore queries would still function correctly, vacuum would normally ignore
such pages, with the long-term effect that the tuples were never such pages, with the long-term effect that the tuples were never
frozen. In recent releases this would eventually result in errors frozen. In recent releases this would eventually result in errors
such as <quote>found multixact <replaceable>nnnnn</replaceable> from such as <quote>found multixact <replaceable>nnnnn</replaceable> from
...@@ -594,8 +594,9 @@ Branch: REL9_4_STABLE [310d1379d] 2018-04-11 23:40:27 +0300 ...@@ -594,8 +594,9 @@ Branch: REL9_4_STABLE [310d1379d] 2018-04-11 23:40:27 +0300
Branch: REL9_3_STABLE [dfc383cf3] 2018-04-11 23:40:31 +0300 Branch: REL9_3_STABLE [dfc383cf3] 2018-04-11 23:40:31 +0300
--> -->
<para> <para>
Ensure client hostname is copied to local memory when copying Ensure client hostname is copied while copying
<structname>pg_stat_activity</structname> data (Edmund Horner) <structname>pg_stat_activity</structname> data to local memory
(Edmund Horner)
</para> </para>
<para> <para>
...@@ -670,7 +671,7 @@ Branch: REL9_6_STABLE [57ef2da43] 2018-03-19 23:59:17 -0400 ...@@ -670,7 +671,7 @@ Branch: REL9_6_STABLE [57ef2da43] 2018-03-19 23:59:17 -0400
--> -->
<para> <para>
Prevent query-lifespan memory leakage with SP-GiST operator classes Prevent query-lifespan memory leakage with SP-GiST operator classes
that use traversal values (Anton Dignös) that use traversal values (Anton Dign&ouml;s)
</para> </para>
</listitem> </listitem>
...@@ -905,7 +906,7 @@ Branch: REL9_5_STABLE [b33e38cb1] 2018-03-29 04:02:34 +0900 ...@@ -905,7 +906,7 @@ Branch: REL9_5_STABLE [b33e38cb1] 2018-03-29 04:02:34 +0900
<para> <para>
Ensure that <application>pg_rewind</application> deletes files on the Ensure that <application>pg_rewind</application> deletes files on the
target server if they are deleted from the source server during the target server if they are deleted from the source server during the
run (Tsunakawa Takayuki) run (Takayuki Tsunakawa)
</para> </para>
<para> <para>
...@@ -951,6 +952,23 @@ Branch: REL9_3_STABLE [f1f7a85d8] 2018-03-17 15:38:15 -0400 ...@@ -951,6 +952,23 @@ Branch: REL9_3_STABLE [f1f7a85d8] 2018-03-17 15:38:15 -0400
<listitem> <listitem>
<!-- <!--
Author: Peter Eisentraut <peter_e@gmx.net>
Branch: master [fa03769e4] 2018-05-03 13:13:09 -0400
Branch: master [7d8679975] 2018-05-03 20:29:54 -0400
Branch: REL_10_STABLE [8f1787a8f] 2018-05-05 23:03:44 -0400
Branch: REL9_6_STABLE [ab7825ead] 2018-05-05 23:34:41 -0400
Branch: REL9_5_STABLE [b812d6372] 2018-05-05 23:48:19 -0400
Branch: REL9_4_STABLE [af9e0d5cd] 2018-05-05 23:53:05 -0400
Branch: REL9_3_STABLE [e7f904715] 2018-05-05 23:54:04 -0400
-->
<para>
Adjust <application>PL/Python</application> regression tests to pass
under Python 3.7 (Peter Eisentraut)
</para>
</listitem>
<listitem>
<!--
Author: Andrew Dunstan <andrew@dunslane.net> Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [966268c76] 2018-05-04 15:22:48 -0400 Branch: master [966268c76] 2018-05-04 15:22:48 -0400
Branch: REL_10_STABLE [56a45646d] 2018-05-04 15:32:31 -0400 Branch: REL_10_STABLE [56a45646d] 2018-05-04 15:32:31 -0400
...@@ -958,6 +976,13 @@ Branch: REL9_6_STABLE [a9fbf550b] 2018-05-04 15:33:06 -0400 ...@@ -958,6 +976,13 @@ Branch: REL9_6_STABLE [a9fbf550b] 2018-05-04 15:33:06 -0400
Branch: REL9_5_STABLE [c1f3638d2] 2018-05-04 15:33:18 -0400 Branch: REL9_5_STABLE [c1f3638d2] 2018-05-04 15:33:18 -0400
Branch: REL9_4_STABLE [134db37d2] 2018-05-04 15:51:31 -0400 Branch: REL9_4_STABLE [134db37d2] 2018-05-04 15:51:31 -0400
Branch: REL9_3_STABLE [af39c1da7] 2018-05-04 15:56:01 -0400 Branch: REL9_3_STABLE [af39c1da7] 2018-05-04 15:56:01 -0400
Author: Andrew Dunstan <andrew@dunslane.net>
Branch: master [2b9bdda74] 2018-05-06 07:37:05 -0400
Branch: REL_10_STABLE [0e6114be8] 2018-05-06 07:39:05 -0400
Branch: REL9_6_STABLE [289bafdbc] 2018-05-06 07:39:37 -0400
Branch: REL9_5_STABLE [3b17d4b9d] 2018-05-06 07:39:51 -0400
Branch: REL9_4_STABLE [1eb24720c] 2018-05-06 07:40:04 -0400
Branch: REL9_3_STABLE [a75b01c61] 2018-05-06 07:40:25 -0400
--> -->
<para> <para>
Support testing <application>PL/Python</application> and related Support testing <application>PL/Python</application> and related
...@@ -987,21 +1012,6 @@ Branch: REL9_6_STABLE [df9040155] 2018-03-22 13:13:58 -0400 ...@@ -987,21 +1012,6 @@ Branch: REL9_6_STABLE [df9040155] 2018-03-22 13:13:58 -0400
<listitem> <listitem>
<!-- <!--
Author: Tom Lane <tgl@sss.pgh.pa.us> Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL9_5_STABLE [3c0e07a46] 2018-05-01 12:02:41 -0400
-->
<para>
Support building with Microsoft Visual Studio 2015 (Michael Paquier)
</para>
<para>
Various fixes needed for VS2015 compatibility were previously
back-patched into the 9.5 branch, but one was missed.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [43e949086] 2018-02-28 18:33:45 -0500 Branch: master [43e949086] 2018-02-28 18:33:45 -0500
Branch: REL_10_STABLE [aac6286d8] 2018-02-28 18:33:45 -0500 Branch: REL_10_STABLE [aac6286d8] 2018-02-28 18:33:45 -0500
Branch: REL9_6_STABLE [11e7700e5] 2018-02-28 18:33:45 -0500 Branch: REL9_6_STABLE [11e7700e5] 2018-02-28 18:33:45 -0500
...@@ -1019,25 +1029,6 @@ Branch: REL9_3_STABLE [10102c91e] 2018-02-28 18:33:45 -0500 ...@@ -1019,25 +1029,6 @@ Branch: REL9_3_STABLE [10102c91e] 2018-02-28 18:33:45 -0500
<listitem> <listitem>
<!-- <!--
Author: Tom Lane <tgl@sss.pgh.pa.us> Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [df629586e] 2018-04-29 15:50:08 -0400
Branch: REL_10_STABLE [783e8f56d] 2018-04-29 15:50:23 -0400
Branch: REL9_6_STABLE [2acbeea48] 2018-04-29 15:50:31 -0400
Branch: REL9_5_STABLE [eaed0d230] 2018-04-29 15:50:37 -0400
Branch: REL9_4_STABLE [37c02b2b0] 2018-04-29 15:50:43 -0400
Branch: REL9_3_STABLE [adcd0c2be] 2018-04-29 15:50:50 -0400
-->
<para>
Update time zone data files to <application>tzdata</application>
release 2018d for DST law changes in Palestine and Antarctica (Casey
Station), plus historical corrections for Portugal and its colonies,
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
Uruguay.
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [b45f6613e] 2018-05-04 12:26:25 -0400 Branch: master [b45f6613e] 2018-05-04 12:26:25 -0400
Branch: REL_10_STABLE [b49f4e69a] 2018-05-04 12:26:34 -0400 Branch: REL_10_STABLE [b49f4e69a] 2018-05-04 12:26:34 -0400
Branch: REL9_6_STABLE [7a83323f2] 2018-05-04 12:26:39 -0400 Branch: REL9_6_STABLE [7a83323f2] 2018-05-04 12:26:39 -0400
...@@ -1060,6 +1051,25 @@ Branch: REL9_3_STABLE [9469ebc71] 2018-05-04 12:26:52 -0400 ...@@ -1060,6 +1051,25 @@ Branch: REL9_3_STABLE [9469ebc71] 2018-05-04 12:26:52 -0400
</para> </para>
</listitem> </listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [df629586e] 2018-04-29 15:50:08 -0400
Branch: REL_10_STABLE [783e8f56d] 2018-04-29 15:50:23 -0400
Branch: REL9_6_STABLE [2acbeea48] 2018-04-29 15:50:31 -0400
Branch: REL9_5_STABLE [eaed0d230] 2018-04-29 15:50:37 -0400
Branch: REL9_4_STABLE [37c02b2b0] 2018-04-29 15:50:43 -0400
Branch: REL9_3_STABLE [adcd0c2be] 2018-04-29 15:50:50 -0400
-->
<para>
Update time zone data files to <application>tzdata</application>
release 2018d for DST law changes in Palestine and Antarctica (Casey
Station), plus historical corrections for Portugal and its colonies,
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
Uruguay.
</para>
</listitem>
</itemizedlist> </itemizedlist>
</sect2> </sect2>
......
doc/src/sgml/release-9.3.sgml
View file @ 2667e019
<!-- 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-23">
<title>Release 9.3.23</title>
<formalpara>
<title>Release date:</title>
<para>2018-05-10</para>
</formalpara>
<para>
This release contains a variety of fixes from 9.3.22.
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.23</title>
<para>
A dump/restore is not required for those running 9.3.X.
</para>
<para>
However, if the function marking mistakes mentioned in the first
changelog entry below affect you, you will want to take steps to
correct your database catalogs.
</para>
<para>
Also, if you are upgrading from a version earlier than 9.3.22,
see <xref linkend="release-9-3-22"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix incorrect volatility markings on a few built-in functions
(Thomas Munro, Tom Lane)
</para>
<para>
The functions
<function>query_to_xml</function>,
<function>cursor_to_xml</function>,
<function>cursor_to_xmlschema</function>,
<function>query_to_xmlschema</function>, and
<function>query_to_xml_and_xmlschema</function>
should be marked volatile because they execute user-supplied queries
that might contain volatile operations. They were not, leading to a
risk of incorrect query optimization. This has been repaired for new
installations by correcting the initial catalog data, but existing
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
</para>
</listitem>
<listitem>
<para>
Avoid re-using TOAST value OIDs that match dead-but-not-yet-vacuumed
TOAST entries (Pavan Deolasee)
</para>
<para>
Once the OID counter has wrapped around, it's possible to assign a
TOAST value whose OID matches a previously deleted entry in the same
TOAST table. If that entry were not yet vacuumed away, this resulted
in <quote>unexpected chunk number 0 (expected 1) for toast
value <replaceable>nnnnn</replaceable></quote> errors, which would
persist until the dead entry was removed
by <command>VACUUM</command>. Fix by not selecting such OIDs when
creating a new TOAST entry.
</para>
</listitem>
<listitem>
<para>
Change <command>ANALYZE</command>'s algorithm for updating
<structname>pg_class</structname>.<structfield>reltuples</structfield>
(David Gould)
</para>
<para>
Previously, pages not actually scanned by <command>ANALYZE</command>
were assumed to retain their old tuple density. In a large table
where <command>ANALYZE</command> samples only a small fraction of the
pages, this meant that the overall tuple density estimate could not
change very much, so that <structfield>reltuples</structfield> would
change nearly proportionally to changes in the table's physical size
(<structfield>relpages</structfield>) regardless of what was actually
happening in the table. This has been observed to result
in <structfield>reltuples</structfield> becoming so much larger than
reality as to effectively shut off autovacuuming. To fix, assume
that <command>ANALYZE</command>'s sample is a statistically unbiased
sample of the table (as it should be), and just extrapolate the
density observed within those pages to the whole table.
</para>
</listitem>
<listitem>
<para>
Fix <literal>UPDATE/DELETE ... WHERE CURRENT OF</literal> to not fail
when the referenced cursor uses an index-only-scan plan (Yugo Nagata,
Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix incorrect planning of join clauses pushed into parameterized
paths (Andrew Gierth, Tom Lane)
</para>
<para>
This error could result in misclassifying a condition as
a <quote>join filter</quote> for an outer join when it should be a
plain <quote>filter</quote> condition, leading to incorrect join
output.
</para>
</listitem>
<listitem>
<para>
Fix misoptimization of <literal>CHECK</literal> constraints having
provably-NULL subclauses of
top-level <literal>AND</literal>/<literal>OR</literal> conditions
(Tom Lane, Dean Rasheed)
</para>
<para>
This could, for example, allow constraint exclusion to exclude a
child table that should not be excluded from a query.
</para>
</listitem>
<listitem>
<para>
Avoid failure if a query-cancel or session-termination interrupt
occurs while committing a prepared transaction (Stas Kelvich)
</para>
</listitem>
<listitem>
<para>
Fix query-lifespan memory leakage in repeatedly executed hash joins
(Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix overly strict sanity check
in <function>heap_prepare_freeze_tuple</function>
(&Aacute;lvaro Herrera)
</para>
<para>
This could result in incorrect <quote>cannot freeze committed
xmax</quote> failures in databases that have
been <application>pg_upgrade</application>'d from 9.2 or earlier.
</para>
</listitem>
<listitem>
<para>
Prevent dangling-pointer dereference when a C-coded before-update row
trigger returns the <quote>old</quote> tuple (Rushabh Lathia)
</para>
</listitem>
<listitem>
<para>
Reduce locking during autovacuum worker scheduling (Jeff Janes)
</para>
<para>
The previous behavior caused drastic loss of potential worker
concurrency in databases with many tables.
</para>
</listitem>
<listitem>
<para>
Ensure client hostname is copied while copying
<structname>pg_stat_activity</structname> data to local memory
(Edmund Horner)
</para>
<para>
Previously the supposedly-local snapshot contained a pointer into
shared memory, allowing the client hostname column to change
unexpectedly if any existing session disconnected.
</para>
</listitem>
<listitem>
<para>
Fix incorrect processing of multiple compound affixes
in <literal>ispell</literal> dictionaries (Arthur Zakirov)
</para>
</listitem>
<listitem>
<para>
Fix collation-aware searches (that is, indexscans using inequality
operators) in SP-GiST indexes on text columns (Tom Lane)
</para>
<para>
Such searches would return the wrong set of rows in most non-C
locales.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during initial build of an
SP-GiST index (Tomas Vondra)
</para>
<para>
Previously, the tuple count was reported to be the same as that of
the underlying table, which is wrong if the index is partial.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during vacuuming of a
GiST index (Andrey Borodin)
</para>
<para>
Previously it reported the estimated number of heap tuples,
which might be inaccurate, and is certainly wrong if the
index is partial.
</para>
</listitem>
<listitem>
<para>
Allow <function>scalarltsel</function>
and <function>scalargtsel</function> to be used on non-core datatypes
(Tomas Vondra)
</para>
</listitem>
<listitem>
<para>
Reduce <application>libpq</application>'s memory consumption when a
server error is reported after a large amount of query output has
been collected (Tom Lane)
</para>
<para>
Discard the previous output before, not after, processing the error
message. On some platforms, notably Linux, this can make a
difference in the application's subsequent memory footprint.
</para>
</listitem>
<listitem>
<para>
Fix double-free crashes in <application>ecpg</application>
(Patrick Krecker, Jeevan Ladhe)
</para>
</listitem>
<listitem>
<para>
Fix <application>ecpg</application> to handle <type>long long
int</type> variables correctly in MSVC builds (Michael Meskes,
Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Fix mis-quoting of values for list-valued GUC variables in dumps
(Michael Paquier, Tom Lane)
</para>
<para>
The <varname>local_preload_libraries</varname>,
<varname>session_preload_libraries</varname>,
<varname>shared_preload_libraries</varname>,
and <varname>temp_tablespaces</varname> variables were not correctly
quoted in <application>pg_dump</application> output. This would
cause problems if settings for these variables appeared in
<command>CREATE FUNCTION ... SET</command> or <command>ALTER
DATABASE/ROLE ... SET</command> clauses.
</para>
</listitem>
<listitem>
<para>
Fix overflow handling in <application>PL/pgSQL</application>
integer <command>FOR</command> loops (Tom Lane)
</para>
<para>
The previous coding failed to detect overflow of the loop variable
on some non-gcc compilers, leading to an infinite loop.
</para>
</listitem>
<listitem>
<para>
Adjust <application>PL/Python</application> regression tests to pass
under Python 3.7 (Peter Eisentraut)
</para>
</listitem>
<listitem>
<para>
Support testing <application>PL/Python</application> and related
modules when building with Python 3 and MSVC (Andrew Dunstan)
</para>
</listitem>
<listitem>
<para>
Rename internal <function>b64_encode</function>
and <function>b64_decode</function> functions to avoid conflict with
Solaris 11.4 built-in functions (Rainer Orth)
</para>
</listitem>
<listitem>
<para>
Sync our copy of the timezone library with IANA tzcode release 2018e
(Tom Lane)
</para>
<para>
This fixes the <application>zic</application> timezone data compiler
to cope with negative daylight-savings offsets. While
the <productname>PostgreSQL</productname> project will not
immediately ship such timezone data, <application>zic</application>
might be used with timezone data obtained directly from IANA, so it
seems prudent to update <application>zic</application> now.
</para>
</listitem>
<listitem>
<para>
Update time zone data files to <application>tzdata</application>
release 2018d for DST law changes in Palestine and Antarctica (Casey
Station), plus historical corrections for Portugal and its colonies,
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
Uruguay.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-3-22"> <sect1 id="release-9-3-22">
<title>Release 9.3.22</title> <title>Release 9.3.22</title>
......
doc/src/sgml/release-9.4.sgml
View file @ 2667e019
<!-- 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-18">
<title>Release 9.4.18</title>
<formalpara>
<title>Release date:</title>
<para>2018-05-10</para>
</formalpara>
<para>
This release contains a variety of fixes from 9.4.17.
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.18</title>
<para>
A dump/restore is not required for those running 9.4.X.
</para>
<para>
However, if the function marking mistakes mentioned in the first
changelog entry below affect you, you will want to take steps to
correct your database catalogs.
</para>
<para>
Also, if you are upgrading from a version earlier than 9.4.17,
see <xref linkend="release-9-4-17"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix incorrect volatility markings on a few built-in functions
(Thomas Munro, Tom Lane)
</para>
<para>
The functions
<function>query_to_xml</function>,
<function>cursor_to_xml</function>,
<function>cursor_to_xmlschema</function>,
<function>query_to_xmlschema</function>, and
<function>query_to_xml_and_xmlschema</function>
should be marked volatile because they execute user-supplied queries
that might contain volatile operations. They were not, leading to a
risk of incorrect query optimization. This has been repaired for new
installations by correcting the initial catalog data, but existing
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
</para>
</listitem>
<listitem>
<para>
Avoid re-using TOAST value OIDs that match dead-but-not-yet-vacuumed
TOAST entries (Pavan Deolasee)
</para>
<para>
Once the OID counter has wrapped around, it's possible to assign a
TOAST value whose OID matches a previously deleted entry in the same
TOAST table. If that entry were not yet vacuumed away, this resulted
in <quote>unexpected chunk number 0 (expected 1) for toast
value <replaceable>nnnnn</replaceable></quote> errors, which would
persist until the dead entry was removed
by <command>VACUUM</command>. Fix by not selecting such OIDs when
creating a new TOAST entry.
</para>
</listitem>
<listitem>
<para>
Change <command>ANALYZE</command>'s algorithm for updating
<structname>pg_class</structname>.<structfield>reltuples</structfield>
(David Gould)
</para>
<para>
Previously, pages not actually scanned by <command>ANALYZE</command>
were assumed to retain their old tuple density. In a large table
where <command>ANALYZE</command> samples only a small fraction of the
pages, this meant that the overall tuple density estimate could not
change very much, so that <structfield>reltuples</structfield> would
change nearly proportionally to changes in the table's physical size
(<structfield>relpages</structfield>) regardless of what was actually
happening in the table. This has been observed to result
in <structfield>reltuples</structfield> becoming so much larger than
reality as to effectively shut off autovacuuming. To fix, assume
that <command>ANALYZE</command>'s sample is a statistically unbiased
sample of the table (as it should be), and just extrapolate the
density observed within those pages to the whole table.
</para>
</listitem>
<listitem>
<para>
Avoid deadlocks in concurrent <command>CREATE INDEX
CONCURRENTLY</command> commands that are run
under <literal>SERIALIZABLE</literal> or <literal>REPEATABLE
READ</literal> transaction isolation (Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix possible slow execution of <command>REFRESH MATERIALIZED VIEW
CONCURRENTLY</command> (Thomas Munro)
</para>
</listitem>
<listitem>
<para>
Fix <literal>UPDATE/DELETE ... WHERE CURRENT OF</literal> to not fail
when the referenced cursor uses an index-only-scan plan (Yugo Nagata,
Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix incorrect planning of join clauses pushed into parameterized
paths (Andrew Gierth, Tom Lane)
</para>
<para>
This error could result in misclassifying a condition as
a <quote>join filter</quote> for an outer join when it should be a
plain <quote>filter</quote> condition, leading to incorrect join
output.
</para>
</listitem>
<listitem>
<para>
Fix misoptimization of <literal>CHECK</literal> constraints having
provably-NULL subclauses of
top-level <literal>AND</literal>/<literal>OR</literal> conditions
(Tom Lane, Dean Rasheed)
</para>
<para>
This could, for example, allow constraint exclusion to exclude a
child table that should not be excluded from a query.
</para>
</listitem>
<listitem>
<para>
Avoid failure if a query-cancel or session-termination interrupt
occurs while committing a prepared transaction (Stas Kelvich)
</para>
</listitem>
<listitem>
<para>
Fix query-lifespan memory leakage in repeatedly executed hash joins
(Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix overly strict sanity check
in <function>heap_prepare_freeze_tuple</function>
(&Aacute;lvaro Herrera)
</para>
<para>
This could result in incorrect <quote>cannot freeze committed
xmax</quote> failures in databases that have
been <application>pg_upgrade</application>'d from 9.2 or earlier.
</para>
</listitem>
<listitem>
<para>
Prevent dangling-pointer dereference when a C-coded before-update row
trigger returns the <quote>old</quote> tuple (Rushabh Lathia)
</para>
</listitem>
<listitem>
<para>
Reduce locking during autovacuum worker scheduling (Jeff Janes)
</para>
<para>
The previous behavior caused drastic loss of potential worker
concurrency in databases with many tables.
</para>
</listitem>
<listitem>
<para>
Ensure client hostname is copied while copying
<structname>pg_stat_activity</structname> data to local memory
(Edmund Horner)
</para>
<para>
Previously the supposedly-local snapshot contained a pointer into
shared memory, allowing the client hostname column to change
unexpectedly if any existing session disconnected.
</para>
</listitem>
<listitem>
<para>
Fix incorrect processing of multiple compound affixes
in <literal>ispell</literal> dictionaries (Arthur Zakirov)
</para>
</listitem>
<listitem>
<para>
Fix collation-aware searches (that is, indexscans using inequality
operators) in SP-GiST indexes on text columns (Tom Lane)
</para>
<para>
Such searches would return the wrong set of rows in most non-C
locales.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during initial build of an
SP-GiST index (Tomas Vondra)
</para>
<para>
Previously, the tuple count was reported to be the same as that of
the underlying table, which is wrong if the index is partial.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during vacuuming of a
GiST index (Andrey Borodin)
</para>
<para>
Previously it reported the estimated number of heap tuples,
which might be inaccurate, and is certainly wrong if the
index is partial.
</para>
</listitem>
<listitem>
<para>
Fix a corner case where a streaming standby gets stuck at a WAL
continuation record (Kyotaro Horiguchi)
</para>
</listitem>
<listitem>
<para>
In logical decoding, avoid possible double processing of WAL data
when a walsender restarts (Craig Ringer)
</para>
</listitem>
<listitem>
<para>
Allow <function>scalarltsel</function>
and <function>scalargtsel</function> to be used on non-core datatypes
(Tomas Vondra)
</para>
</listitem>
<listitem>
<para>
Reduce <application>libpq</application>'s memory consumption when a
server error is reported after a large amount of query output has
been collected (Tom Lane)
</para>
<para>
Discard the previous output before, not after, processing the error
message. On some platforms, notably Linux, this can make a
difference in the application's subsequent memory footprint.
</para>
</listitem>
<listitem>
<para>
Fix double-free crashes in <application>ecpg</application>
(Patrick Krecker, Jeevan Ladhe)
</para>
</listitem>
<listitem>
<para>
Fix <application>ecpg</application> to handle <type>long long
int</type> variables correctly in MSVC builds (Michael Meskes,
Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Fix mis-quoting of values for list-valued GUC variables in dumps
(Michael Paquier, Tom Lane)
</para>
<para>
The <varname>local_preload_libraries</varname>,
<varname>session_preload_libraries</varname>,
<varname>shared_preload_libraries</varname>,
and <varname>temp_tablespaces</varname> variables were not correctly
quoted in <application>pg_dump</application> output. This would
cause problems if settings for these variables appeared in
<command>CREATE FUNCTION ... SET</command> or <command>ALTER
DATABASE/ROLE ... SET</command> clauses.
</para>
</listitem>
<listitem>
<para>
Fix <application>pg_recvlogical</application> to not fail against
pre-v10 <productname>PostgreSQL</productname> servers
(Michael Paquier)
</para>
<para>
A previous fix caused <application>pg_recvlogical</application> to
issue a command regardless of server version, but it should only be
issued to v10 and later servers.
</para>
</listitem>
<listitem>
<para>
Fix overflow handling in <application>PL/pgSQL</application>
integer <command>FOR</command> loops (Tom Lane)
</para>
<para>
The previous coding failed to detect overflow of the loop variable
on some non-gcc compilers, leading to an infinite loop.
</para>
</listitem>
<listitem>
<para>
Adjust <application>PL/Python</application> regression tests to pass
under Python 3.7 (Peter Eisentraut)
</para>
</listitem>
<listitem>
<para>
Support testing <application>PL/Python</application> and related
modules when building with Python 3 and MSVC (Andrew Dunstan)
</para>
</listitem>
<listitem>
<para>
Rename internal <function>b64_encode</function>
and <function>b64_decode</function> functions to avoid conflict with
Solaris 11.4 built-in functions (Rainer Orth)
</para>
</listitem>
<listitem>
<para>
Sync our copy of the timezone library with IANA tzcode release 2018e
(Tom Lane)
</para>
<para>
This fixes the <application>zic</application> timezone data compiler
to cope with negative daylight-savings offsets. While
the <productname>PostgreSQL</productname> project will not
immediately ship such timezone data, <application>zic</application>
might be used with timezone data obtained directly from IANA, so it
seems prudent to update <application>zic</application> now.
</para>
</listitem>
<listitem>
<para>
Update time zone data files to <application>tzdata</application>
release 2018d for DST law changes in Palestine and Antarctica (Casey
Station), plus historical corrections for Portugal and its colonies,
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
Uruguay.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-4-17"> <sect1 id="release-9-4-17">
<title>Release 9.4.17</title> <title>Release 9.4.17</title>
......
doc/src/sgml/release-9.5.sgml
View file @ 2667e019
<!-- doc/src/sgml/release-9.5.sgml --> <!-- doc/src/sgml/release-9.5.sgml -->
<!-- See header comment in release.sgml about typical markup --> <!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-5-13">
<title>Release 9.5.13</title>
<formalpara>
<title>Release date:</title>
<para>2018-05-10</para>
</formalpara>
<para>
This release contains a variety of fixes from 9.5.12.
For information about new features in the 9.5 major release, see
<xref linkend="release-9-5"/>.
</para>
<sect2>
<title>Migration to Version 9.5.13</title>
<para>
A dump/restore is not required for those running 9.5.X.
</para>
<para>
However, if the function marking mistakes mentioned in the first
changelog entry below affect you, you will want to take steps to
correct your database catalogs.
</para>
<para>
Also, if you are upgrading from a version earlier than 9.5.12,
see <xref linkend="release-9-5-12"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix incorrect volatility markings on a few built-in functions
(Thomas Munro, Tom Lane)
</para>
<para>
The functions
<function>query_to_xml</function>,
<function>cursor_to_xml</function>,
<function>cursor_to_xmlschema</function>,
<function>query_to_xmlschema</function>, and
<function>query_to_xml_and_xmlschema</function>
should be marked volatile because they execute user-supplied queries
that might contain volatile operations. They were not, leading to a
risk of incorrect query optimization. This has been repaired for new
installations by correcting the initial catalog data, but existing
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
</para>
</listitem>
<listitem>
<para>
Avoid re-using TOAST value OIDs that match dead-but-not-yet-vacuumed
TOAST entries (Pavan Deolasee)
</para>
<para>
Once the OID counter has wrapped around, it's possible to assign a
TOAST value whose OID matches a previously deleted entry in the same
TOAST table. If that entry were not yet vacuumed away, this resulted
in <quote>unexpected chunk number 0 (expected 1) for toast
value <replaceable>nnnnn</replaceable></quote> errors, which would
persist until the dead entry was removed
by <command>VACUUM</command>. Fix by not selecting such OIDs when
creating a new TOAST entry.
</para>
</listitem>
<listitem>
<para>
Change <command>ANALYZE</command>'s algorithm for updating
<structname>pg_class</structname>.<structfield>reltuples</structfield>
(David Gould)
</para>
<para>
Previously, pages not actually scanned by <command>ANALYZE</command>
were assumed to retain their old tuple density. In a large table
where <command>ANALYZE</command> samples only a small fraction of the
pages, this meant that the overall tuple density estimate could not
change very much, so that <structfield>reltuples</structfield> would
change nearly proportionally to changes in the table's physical size
(<structfield>relpages</structfield>) regardless of what was actually
happening in the table. This has been observed to result
in <structfield>reltuples</structfield> becoming so much larger than
reality as to effectively shut off autovacuuming. To fix, assume
that <command>ANALYZE</command>'s sample is a statistically unbiased
sample of the table (as it should be), and just extrapolate the
density observed within those pages to the whole table.
</para>
</listitem>
<listitem>
<para>
Avoid deadlocks in concurrent <command>CREATE INDEX
CONCURRENTLY</command> commands that are run
under <literal>SERIALIZABLE</literal> or <literal>REPEATABLE
READ</literal> transaction isolation (Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix possible slow execution of <command>REFRESH MATERIALIZED VIEW
CONCURRENTLY</command> (Thomas Munro)
</para>
</listitem>
<listitem>
<para>
Fix <literal>UPDATE/DELETE ... WHERE CURRENT OF</literal> to not fail
when the referenced cursor uses an index-only-scan plan (Yugo Nagata,
Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix incorrect planning of join clauses pushed into parameterized
paths (Andrew Gierth, Tom Lane)
</para>
<para>
This error could result in misclassifying a condition as
a <quote>join filter</quote> for an outer join when it should be a
plain <quote>filter</quote> condition, leading to incorrect join
output.
</para>
</listitem>
<listitem>
<para>
Fix possibly incorrect generation of an index-only-scan plan when the
same table column appears in multiple index columns, and only some of
those index columns use operator classes that can return the column
value (Kyotaro Horiguchi)
</para>
</listitem>
<listitem>
<para>
Fix misoptimization of <literal>CHECK</literal> constraints having
provably-NULL subclauses of
top-level <literal>AND</literal>/<literal>OR</literal> conditions
(Tom Lane, Dean Rasheed)
</para>
<para>
This could, for example, allow constraint exclusion to exclude a
child table that should not be excluded from a query.
</para>
</listitem>
<listitem>
<para>
Fix executor crash due to double free in some <literal>GROUPING
SET</literal> usages (Peter Geoghegan)
</para>
</listitem>
<listitem>
<para>
Avoid crash if a table rewrite event trigger is added concurrently
with a command that could call such a trigger (&Aacute;lvaro Herrera,
Andrew Gierth, Tom Lane)
</para>
</listitem>
<listitem>
<para>
Avoid failure if a query-cancel or session-termination interrupt
occurs while committing a prepared transaction (Stas Kelvich)
</para>
</listitem>
<listitem>
<para>
Fix query-lifespan memory leakage in repeatedly executed hash joins
(Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix overly strict sanity check
in <function>heap_prepare_freeze_tuple</function>
(&Aacute;lvaro Herrera)
</para>
<para>
This could result in incorrect <quote>cannot freeze committed
xmax</quote> failures in databases that have
been <application>pg_upgrade</application>'d from 9.2 or earlier.
</para>
</listitem>
<listitem>
<para>
Prevent dangling-pointer dereference when a C-coded before-update row
trigger returns the <quote>old</quote> tuple (Rushabh Lathia)
</para>
</listitem>
<listitem>
<para>
Reduce locking during autovacuum worker scheduling (Jeff Janes)
</para>
<para>
The previous behavior caused drastic loss of potential worker
concurrency in databases with many tables.
</para>
</listitem>
<listitem>
<para>
Ensure client hostname is copied while copying
<structname>pg_stat_activity</structname> data to local memory
(Edmund Horner)
</para>
<para>
Previously the supposedly-local snapshot contained a pointer into
shared memory, allowing the client hostname column to change
unexpectedly if any existing session disconnected.
</para>
</listitem>
<listitem>
<para>
Fix incorrect processing of multiple compound affixes
in <literal>ispell</literal> dictionaries (Arthur Zakirov)
</para>
</listitem>
<listitem>
<para>
Fix collation-aware searches (that is, indexscans using inequality
operators) in SP-GiST indexes on text columns (Tom Lane)
</para>
<para>
Such searches would return the wrong set of rows in most non-C
locales.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during initial build of an
SP-GiST index (Tomas Vondra)
</para>
<para>
Previously, the tuple count was reported to be the same as that of
the underlying table, which is wrong if the index is partial.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during vacuuming of a
GiST index (Andrey Borodin)
</para>
<para>
Previously it reported the estimated number of heap tuples,
which might be inaccurate, and is certainly wrong if the
index is partial.
</para>
</listitem>
<listitem>
<para>
Fix a corner case where a streaming standby gets stuck at a WAL
continuation record (Kyotaro Horiguchi)
</para>
</listitem>
<listitem>
<para>
In logical decoding, avoid possible double processing of WAL data
when a walsender restarts (Craig Ringer)
</para>
</listitem>
<listitem>
<para>
Allow <function>scalarltsel</function>
and <function>scalargtsel</function> to be used on non-core datatypes
(Tomas Vondra)
</para>
</listitem>
<listitem>
<para>
Reduce <application>libpq</application>'s memory consumption when a
server error is reported after a large amount of query output has
been collected (Tom Lane)
</para>
<para>
Discard the previous output before, not after, processing the error
message. On some platforms, notably Linux, this can make a
difference in the application's subsequent memory footprint.
</para>
</listitem>
<listitem>
<para>
Fix double-free crashes in <application>ecpg</application>
(Patrick Krecker, Jeevan Ladhe)
</para>
</listitem>
<listitem>
<para>
Fix <application>ecpg</application> to handle <type>long long
int</type> variables correctly in MSVC builds (Michael Meskes,
Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Fix mis-quoting of values for list-valued GUC variables in dumps
(Michael Paquier, Tom Lane)
</para>
<para>
The <varname>local_preload_libraries</varname>,
<varname>session_preload_libraries</varname>,
<varname>shared_preload_libraries</varname>,
and <varname>temp_tablespaces</varname> variables were not correctly
quoted in <application>pg_dump</application> output. This would
cause problems if settings for these variables appeared in
<command>CREATE FUNCTION ... SET</command> or <command>ALTER
DATABASE/ROLE ... SET</command> clauses.
</para>
</listitem>
<listitem>
<para>
Fix <application>pg_recvlogical</application> to not fail against
pre-v10 <productname>PostgreSQL</productname> servers
(Michael Paquier)
</para>
<para>
A previous fix caused <application>pg_recvlogical</application> to
issue a command regardless of server version, but it should only be
issued to v10 and later servers.
</para>
</listitem>
<listitem>
<para>
Ensure that <application>pg_rewind</application> deletes files on the
target server if they are deleted from the source server during the
run (Takayuki Tsunakawa)
</para>
<para>
Failure to do this could result in data inconsistency on the target,
particularly if the file in question is a WAL segment.
</para>
</listitem>
<listitem>
<para>
Fix <application>pg_rewind</application> to handle tables in
non-default tablespaces correctly (Takayuki Tsunakawa)
</para>
</listitem>
<listitem>
<para>
Fix overflow handling in <application>PL/pgSQL</application>
integer <command>FOR</command> loops (Tom Lane)
</para>
<para>
The previous coding failed to detect overflow of the loop variable
on some non-gcc compilers, leading to an infinite loop.
</para>
</listitem>
<listitem>
<para>
Adjust <application>PL/Python</application> regression tests to pass
under Python 3.7 (Peter Eisentraut)
</para>
</listitem>
<listitem>
<para>
Support testing <application>PL/Python</application> and related
modules when building with Python 3 and MSVC (Andrew Dunstan)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: REL9_5_STABLE [3c0e07a46] 2018-05-01 12:02:41 -0400
-->
<para>
Support building with Microsoft Visual Studio 2015 (Michael Paquier)
</para>
<para>
Various fixes needed for VS2015 compatibility were previously
back-patched into the 9.5 branch, but this one was missed.
</para>
</listitem>
<listitem>
<para>
Rename internal <function>b64_encode</function>
and <function>b64_decode</function> functions to avoid conflict with
Solaris 11.4 built-in functions (Rainer Orth)
</para>
</listitem>
<listitem>
<para>
Sync our copy of the timezone library with IANA tzcode release 2018e
(Tom Lane)
</para>
<para>
This fixes the <application>zic</application> timezone data compiler
to cope with negative daylight-savings offsets. While
the <productname>PostgreSQL</productname> project will not
immediately ship such timezone data, <application>zic</application>
might be used with timezone data obtained directly from IANA, so it
seems prudent to update <application>zic</application> now.
</para>
</listitem>
<listitem>
<para>
Update time zone data files to <application>tzdata</application>
release 2018d for DST law changes in Palestine and Antarctica (Casey
Station), plus historical corrections for Portugal and its colonies,
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
Uruguay.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-5-12"> <sect1 id="release-9-5-12">
<title>Release 9.5.12</title> <title>Release 9.5.12</title>
......
doc/src/sgml/release-9.6.sgml
View file @ 2667e019
<!-- doc/src/sgml/release-9.6.sgml --> <!-- doc/src/sgml/release-9.6.sgml -->
<!-- See header comment in release.sgml about typical markup --> <!-- See header comment in release.sgml about typical markup -->
<sect1 id="release-9-6-9">
<title>Release 9.6.9</title>
<formalpara>
<title>Release date:</title>
<para>2018-05-10</para>
</formalpara>
<para>
This release contains a variety of fixes from 9.6.8.
For information about new features in the 9.6 major release, see
<xref linkend="release-9-6"/>.
</para>
<sect2>
<title>Migration to Version 9.6.9</title>
<para>
A dump/restore is not required for those running 9.6.X.
</para>
<para>
However, if the function marking mistakes mentioned in the first two
changelog entries below affect you, you will want to take steps to
correct your database catalogs.
</para>
<para>
Also, if you are upgrading from a version earlier than 9.6.8,
see <xref linkend="release-9-6-8"/>.
</para>
</sect2>
<sect2>
<title>Changes</title>
<itemizedlist>
<listitem>
<para>
Fix incorrect volatility markings on a few built-in functions
(Thomas Munro, Tom Lane)
</para>
<para>
The functions
<function>query_to_xml</function>,
<function>cursor_to_xml</function>,
<function>cursor_to_xmlschema</function>,
<function>query_to_xmlschema</function>, and
<function>query_to_xml_and_xmlschema</function>
should be marked volatile because they execute user-supplied queries
that might contain volatile operations. They were not, leading to a
risk of incorrect query optimization. This has been repaired for new
installations by correcting the initial catalog data, but existing
installations will continue to contain the incorrect markings.
Practical use of these functions seems to pose little hazard, but in
case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
</para>
</listitem>
<listitem>
<para>
Fix incorrect parallel-safety markings on a few built-in functions
(Thomas Munro, Tom Lane)
</para>
<para>
The functions
<function>brin_summarize_new_values</function>,
<function>brin_summarize_range</function>,
<function>brin_desummarize_range</function>,
<function>gin_clean_pending_list</function>,
<function>cursor_to_xml</function>,
<function>cursor_to_xmlschema</function>,
<function>ts_rewrite</function>,
<function>ts_stat</function>,
<function>binary_upgrade_create_empty_extension</function>, and
<function>pg_import_system_collations</function>
should be marked parallel-unsafe; some because they perform database
modifications directly, and others because they execute user-supplied
queries that might do so. They were marked parallel-restricted
instead, leading to a risk of unexpected query errors. This has been
repaired for new installations by correcting the initial catalog
data, but existing installations will continue to contain the
incorrect markings. Practical use of these functions seems to pose
little hazard unless <varname>force_parallel_mode</varname> is turned
on. In case of trouble, it can be fixed by manually updating these
functions' <structname>pg_proc</structname> entries. (Note that that
will need to be done in each database of the installation.) Another
option is to <application>pg_upgrade</application> the database to a
version containing the corrected initial data.
</para>
</listitem>
<listitem>
<para>
Avoid re-using TOAST value OIDs that match dead-but-not-yet-vacuumed
TOAST entries (Pavan Deolasee)
</para>
<para>
Once the OID counter has wrapped around, it's possible to assign a
TOAST value whose OID matches a previously deleted entry in the same
TOAST table. If that entry were not yet vacuumed away, this resulted
in <quote>unexpected chunk number 0 (expected 1) for toast
value <replaceable>nnnnn</replaceable></quote> errors, which would
persist until the dead entry was removed
by <command>VACUUM</command>. Fix by not selecting such OIDs when
creating a new TOAST entry.
</para>
</listitem>
<listitem>
<para>
Change <command>ANALYZE</command>'s algorithm for updating
<structname>pg_class</structname>.<structfield>reltuples</structfield>
(David Gould)
</para>
<para>
Previously, pages not actually scanned by <command>ANALYZE</command>
were assumed to retain their old tuple density. In a large table
where <command>ANALYZE</command> samples only a small fraction of the
pages, this meant that the overall tuple density estimate could not
change very much, so that <structfield>reltuples</structfield> would
change nearly proportionally to changes in the table's physical size
(<structfield>relpages</structfield>) regardless of what was actually
happening in the table. This has been observed to result
in <structfield>reltuples</structfield> becoming so much larger than
reality as to effectively shut off autovacuuming. To fix, assume
that <command>ANALYZE</command>'s sample is a statistically unbiased
sample of the table (as it should be), and just extrapolate the
density observed within those pages to the whole table.
</para>
</listitem>
<listitem>
<para>
Avoid deadlocks in concurrent <command>CREATE INDEX
CONCURRENTLY</command> commands that are run
under <literal>SERIALIZABLE</literal> or <literal>REPEATABLE
READ</literal> transaction isolation (Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix possible slow execution of <command>REFRESH MATERIALIZED VIEW
CONCURRENTLY</command> (Thomas Munro)
</para>
</listitem>
<listitem>
<para>
Fix <literal>UPDATE/DELETE ... WHERE CURRENT OF</literal> to not fail
when the referenced cursor uses an index-only-scan plan (Yugo Nagata,
Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix incorrect planning of join clauses pushed into parameterized
paths (Andrew Gierth, Tom Lane)
</para>
<para>
This error could result in misclassifying a condition as
a <quote>join filter</quote> for an outer join when it should be a
plain <quote>filter</quote> condition, leading to incorrect join
output.
</para>
</listitem>
<listitem>
<para>
Fix possibly incorrect generation of an index-only-scan plan when the
same table column appears in multiple index columns, and only some of
those index columns use operator classes that can return the column
value (Kyotaro Horiguchi)
</para>
</listitem>
<listitem>
<para>
Fix misoptimization of <literal>CHECK</literal> constraints having
provably-NULL subclauses of
top-level <literal>AND</literal>/<literal>OR</literal> conditions
(Tom Lane, Dean Rasheed)
</para>
<para>
This could, for example, allow constraint exclusion to exclude a
child table that should not be excluded from a query.
</para>
</listitem>
<listitem>
<para>
Fix executor crash due to double free in some <literal>GROUPING
SET</literal> usages (Peter Geoghegan)
</para>
</listitem>
<listitem>
<para>
Avoid crash if a table rewrite event trigger is added concurrently
with a command that could call such a trigger (&Aacute;lvaro Herrera,
Andrew Gierth, Tom Lane)
</para>
</listitem>
<listitem>
<para>
Avoid failure if a query-cancel or session-termination interrupt
occurs while committing a prepared transaction (Stas Kelvich)
</para>
</listitem>
<listitem>
<para>
Fix query-lifespan memory leakage in repeatedly executed hash joins
(Tom Lane)
</para>
</listitem>
<listitem>
<para>
Fix possible leak or double free of visibility map buffer pins
(Amit Kapila)
</para>
</listitem>
<listitem>
<para>
Avoid spuriously marking pages as all-visible (Dan Wood,
Pavan Deolasee, &Aacute;lvaro Herrera)
</para>
<para>
This could happen if some tuples were locked (but not deleted). While
queries would still function correctly, vacuum would normally ignore
such pages, with the long-term effect that the tuples were never
frozen. In recent releases this would eventually result in errors
such as <quote>found multixact <replaceable>nnnnn</replaceable> from
before relminmxid <replaceable>nnnnn</replaceable></quote>.
</para>
</listitem>
<listitem>
<para>
Fix overly strict sanity check
in <function>heap_prepare_freeze_tuple</function>
(&Aacute;lvaro Herrera)
</para>
<para>
This could result in incorrect <quote>cannot freeze committed
xmax</quote> failures in databases that have
been <application>pg_upgrade</application>'d from 9.2 or earlier.
</para>
</listitem>
<listitem>
<para>
Prevent dangling-pointer dereference when a C-coded before-update row
trigger returns the <quote>old</quote> tuple (Rushabh Lathia)
</para>
</listitem>
<listitem>
<para>
Reduce locking during autovacuum worker scheduling (Jeff Janes)
</para>
<para>
The previous behavior caused drastic loss of potential worker
concurrency in databases with many tables.
</para>
</listitem>
<listitem>
<para>
Ensure client hostname is copied while copying
<structname>pg_stat_activity</structname> data to local memory
(Edmund Horner)
</para>
<para>
Previously the supposedly-local snapshot contained a pointer into
shared memory, allowing the client hostname column to change
unexpectedly if any existing session disconnected.
</para>
</listitem>
<listitem>
<para>
Fix incorrect processing of multiple compound affixes
in <literal>ispell</literal> dictionaries (Arthur Zakirov)
</para>
</listitem>
<listitem>
<para>
Fix collation-aware searches (that is, indexscans using inequality
operators) in SP-GiST indexes on text columns (Tom Lane)
</para>
<para>
Such searches would return the wrong set of rows in most non-C
locales.
</para>
</listitem>
<listitem>
<para>
Prevent query-lifespan memory leakage with SP-GiST operator classes
that use traversal values (Anton Dign&ouml;s)
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during initial build of an
SP-GiST index (Tomas Vondra)
</para>
<para>
Previously, the tuple count was reported to be the same as that of
the underlying table, which is wrong if the index is partial.
</para>
</listitem>
<listitem>
<para>
Count the number of index tuples correctly during vacuuming of a
GiST index (Andrey Borodin)
</para>
<para>
Previously it reported the estimated number of heap tuples,
which might be inaccurate, and is certainly wrong if the
index is partial.
</para>
</listitem>
<listitem>
<para>
Fix a corner case where a streaming standby gets stuck at a WAL
continuation record (Kyotaro Horiguchi)
</para>
</listitem>
<listitem>
<para>
In logical decoding, avoid possible double processing of WAL data
when a walsender restarts (Craig Ringer)
</para>
</listitem>
<listitem>
<para>
Allow <function>scalarltsel</function>
and <function>scalargtsel</function> to be used on non-core datatypes
(Tomas Vondra)
</para>
</listitem>
<listitem>
<para>
Reduce <application>libpq</application>'s memory consumption when a
server error is reported after a large amount of query output has
been collected (Tom Lane)
</para>
<para>
Discard the previous output before, not after, processing the error
message. On some platforms, notably Linux, this can make a
difference in the application's subsequent memory footprint.
</para>
</listitem>
<listitem>
<para>
Fix double-free crashes in <application>ecpg</application>
(Patrick Krecker, Jeevan Ladhe)
</para>
</listitem>
<listitem>
<para>
Fix <application>ecpg</application> to handle <type>long long
int</type> variables correctly in MSVC builds (Michael Meskes,
Andrew Gierth)
</para>
</listitem>
<listitem>
<para>
Fix mis-quoting of values for list-valued GUC variables in dumps
(Michael Paquier, Tom Lane)
</para>
<para>
The <varname>local_preload_libraries</varname>,
<varname>session_preload_libraries</varname>,
<varname>shared_preload_libraries</varname>,
and <varname>temp_tablespaces</varname> variables were not correctly
quoted in <application>pg_dump</application> output. This would
cause problems if settings for these variables appeared in
<command>CREATE FUNCTION ... SET</command> or <command>ALTER
DATABASE/ROLE ... SET</command> clauses.
</para>
</listitem>
<listitem>
<para>
Fix <application>pg_recvlogical</application> to not fail against
pre-v10 <productname>PostgreSQL</productname> servers
(Michael Paquier)
</para>
<para>
A previous fix caused <application>pg_recvlogical</application> to
issue a command regardless of server version, but it should only be
issued to v10 and later servers.
</para>
</listitem>
<listitem>
<para>
Ensure that <application>pg_rewind</application> deletes files on the
target server if they are deleted from the source server during the
run (Takayuki Tsunakawa)
</para>
<para>
Failure to do this could result in data inconsistency on the target,
particularly if the file in question is a WAL segment.
</para>
</listitem>
<listitem>
<para>
Fix <application>pg_rewind</application> to handle tables in
non-default tablespaces correctly (Takayuki Tsunakawa)
</para>
</listitem>
<listitem>
<para>
Fix overflow handling in <application>PL/pgSQL</application>
integer <command>FOR</command> loops (Tom Lane)
</para>
<para>
The previous coding failed to detect overflow of the loop variable
on some non-gcc compilers, leading to an infinite loop.
</para>
</listitem>
<listitem>
<para>
Adjust <application>PL/Python</application> regression tests to pass
under Python 3.7 (Peter Eisentraut)
</para>
</listitem>
<listitem>
<para>
Support testing <application>PL/Python</application> and related
modules when building with Python 3 and MSVC (Andrew Dunstan)
</para>
</listitem>
<listitem>
<para>
Fix errors in initial build of <filename>contrib/bloom</filename>
indexes (Tomas Vondra, Tom Lane)
</para>
<para>
Fix possible omission of the table's last tuple from the index.
Count the number of index tuples correctly, in case it is a partial
index.
</para>
</listitem>
<listitem>
<para>
Rename internal <function>b64_encode</function>
and <function>b64_decode</function> functions to avoid conflict with
Solaris 11.4 built-in functions (Rainer Orth)
</para>
</listitem>
<listitem>
<para>
Sync our copy of the timezone library with IANA tzcode release 2018e
(Tom Lane)
</para>
<para>
This fixes the <application>zic</application> timezone data compiler
to cope with negative daylight-savings offsets. While
the <productname>PostgreSQL</productname> project will not
immediately ship such timezone data, <application>zic</application>
might be used with timezone data obtained directly from IANA, so it
seems prudent to update <application>zic</application> now.
</para>
</listitem>
<listitem>
<para>
Update time zone data files to <application>tzdata</application>
release 2018d for DST law changes in Palestine and Antarctica (Casey
Station), plus historical corrections for Portugal and its colonies,
as well as Enderbury, Jamaica, Turks &amp; Caicos Islands, and
Uruguay.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="release-9-6-8"> <sect1 id="release-9-6-8">
<title>Release 9.6.8</title> <title>Release 9.6.8</title>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment