<!-- doc/src/sgml/release-10.sgml -->
<!-- See header comment in release.sgml about typical markup -->
+ <sect1 id="release-10-3">
+ <title>Release 10.3</title>
+
+ <formalpara>
+ <title>Release date:</title>
+ <para>2018-03-01</para>
+ </formalpara>
+
+ <para>
+ This release contains a variety of fixes from 10.2.
+ For information about new features in major release 10, see
+ <xref linkend="release-10"/>.
+ </para>
+
+ <sect2>
+ <title>Migration to Version 10.3</title>
+
+ <para>
+ A dump/restore is not required for those running 10.X.
+ </para>
+
+ <para>
+ However, if you are upgrading from a version earlier than 10.2,
+ see <xref linkend="release-10-2"/>.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Changes</title>
+
+ <itemizedlist>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [159efe4af] 2018-02-19 16:00:31 -0500
+Branch: REL_10_STABLE [517e0fe86] 2018-02-19 16:00:18 -0500
+Branch: REL9_6_STABLE [795f2112e] 2018-02-19 16:00:18 -0500
+Branch: REL9_5_STABLE [340d63bfb] 2018-02-19 16:00:18 -0500
+Branch: REL9_4_STABLE [e11b6488e] 2018-02-19 16:00:18 -0500
+Branch: REL9_3_STABLE [ea6d67cf8] 2018-02-19 16:00:18 -0500
+-->
+ <para>
+ Fix misbehavior of concurrent-update rechecks with CTE references
+ appearing in subplans (Tom Lane)
+ </para>
+
+ <para>
+ If a CTE (<literal>WITH</literal> clause reference) is used in an
+ InitPlan or SubPlan, and the query requires a recheck due to trying
+ to update or lock a concurrently-updated row, incorrect results could
+ be obtained.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [9afd513df] 2018-02-23 13:47:33 -0500
+Branch: REL_10_STABLE [c458970ad] 2018-02-23 13:47:33 -0500
+Branch: REL9_6_STABLE [e7c02a54a] 2018-02-23 13:47:33 -0500
+Branch: REL9_5_STABLE [7dc5f316f] 2018-02-23 13:47:33 -0500
+Branch: REL9_4_STABLE [f6dd08489] 2018-02-23 13:47:33 -0500
+Branch: REL9_3_STABLE [71a0d0c5a] 2018-02-23 13:47:33 -0500
+-->
+ <para>
+ Fix planner failures with overlapping mergejoin clauses in an outer
+ join (Tom Lane)
+ </para>
+
+ <para>
+ These mistakes led to <quote>left and right pathkeys do not match in
+ mergejoin</quote> or <quote>outer pathkeys do not match
+ mergeclauses</quote> planner errors in corner cases.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [38b41f182] 2018-02-21 18:40:24 -0500
+Branch: REL_10_STABLE [5ab5d21aa] 2018-02-21 18:40:24 -0500
+Branch: REL9_6_STABLE [66e203c85] 2018-02-21 18:40:24 -0500
+Branch: REL9_5_STABLE [9936f1499] 2018-02-21 18:40:24 -0500
+Branch: REL9_4_STABLE [2d12c5593] 2018-02-21 18:40:24 -0500
+Branch: REL9_3_STABLE [d3b0a23a2] 2018-02-21 18:40:24 -0500
+-->
+ <para>
+ Repair <application>pg_upgrade</application>'s failure to
+ preserve <structfield>relfrozenxid</structfield> for materialized
+ views (Tom Lane, Andres Freund)
+ </para>
+
+ <para>
+ This oversight could lead to data corruption in materialized views
+ after an upgrade, manifesting as <quote>could not access status of
+ transaction</quote> or <quote>found xmin from before
+ relfrozenxid</quote> errors. The problem would be more likely to
+ occur in seldom-refreshed materialized views, or ones that were
+ maintained only with <command>REFRESH MATERIALIZED VIEW
+ CONCURRENTLY</command>.
+ </para>
+
+ <para>
+ If such corruption is observed, it can be repaired by refreshing the
+ materialized view (without <literal>CONCURRENTLY</literal>).
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [3486bcf9e] 2018-02-20 11:23:42 -0500
+Branch: REL_10_STABLE [6753f6c41] 2018-02-20 11:23:34 -0500
+-->
+ <para>
+ Fix incorrect <application>pg_dump</application> output for some
+ non-default sequence limit values (Alexey Bashtanov)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [5c9f2564f] 2018-02-11 13:24:15 -0500
+Branch: REL_10_STABLE [1298fccef] 2018-02-11 13:24:15 -0500
+-->
+ <para>
+ Fix <application>pg_dump</application>'s mishandling
+ of <literal>STATISTICS</literal> objects (Tom Lane)
+ </para>
+
+ <para>
+ An extended statistics object's schema was mislabeled in the dump's
+ table of contents, possibly leading to the wrong results in a
+ schema-selective restore. Its ownership was not correctly restored,
+ either. Also, change the logic so that statistics objects are
+ dumped/restored, or not, as independent objects rather than tying
+ them to the dump/restore decision for the table they are on. The
+ original definition could not scale to the planned future extension to
+ cross-table statistics.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [e748e902d] 2018-02-14 14:47:18 -0500
+Branch: REL_10_STABLE [4081e1136] 2018-02-14 14:47:18 -0500
+Branch: REL9_6_STABLE [0a2381d13] 2018-02-14 14:47:18 -0500
+Branch: REL9_5_STABLE [db1c597f3] 2018-02-14 14:47:18 -0500
+Branch: REL9_4_STABLE [bd8718637] 2018-02-14 14:47:18 -0500
+Branch: REL9_3_STABLE [457e9e88e] 2018-02-14 14:47:18 -0500
+-->
+ <para>
+ Fix incorrect reporting of PL/Python function names in
+ error <literal>CONTEXT</literal> stacks (Tom Lane)
+ </para>
+
+ <para>
+ An error occurring within a nested PL/Python function call (that is,
+ one reached via a SPI query from another PL/Python function) would
+ result in a stack trace showing the inner function's name twice,
+ rather than the expected results. Also, an error in a nested
+ PL/Python <literal>DO</literal> block could result in a null pointer
+ dereference crash on some platforms.
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [8af87f411] 2018-02-23 14:39:17 -0500
+Branch: REL_10_STABLE [0222e897d] 2018-02-23 14:39:18 -0500
+Branch: REL9_6_STABLE [be87cd2a0] 2018-02-23 14:39:20 -0500
+Branch: REL9_5_STABLE [753875ed4] 2018-02-23 14:39:21 -0500
+Branch: REL9_4_STABLE [3ba503bde] 2018-02-23 14:39:22 -0500
+Branch: REL9_3_STABLE [a7a6051cf] 2018-02-23 14:39:23 -0500
+-->
+ <para>
+ Allow <filename>contrib/auto_explain</filename>'s
+ <varname>log_min_duration</varname> setting to range up
+ to <literal>INT_MAX</literal>, or about 24 days instead of 35 minutes
+ (Tom Lane)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Robert Haas <rhaas@postgresql.org>
+Branch: master [935dee9ad] 2018-02-09 15:54:45 -0500
+Author: Andres Freund <andres@anarazel.de>
+Branch: REL_10_STABLE [2ff2baa22] 2018-02-22 12:54:45 -0800
+Branch: REL9_6_STABLE [83fce670e] 2018-02-22 12:58:43 -0800
+-->
+ <para>
+ Mark assorted GUC variables as <literal>PGDLLIMPORT</literal>, to
+ ease porting extension modules to Windows (Metin Doslu)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </sect2>
+ </sect1>
+
<sect1 id="release-10-2">
<title>Release 10.2</title>
projects / postgresql / commitdiff